How do I convert 60fps to 30fps to halve file size?

[DigitalOxygen.ca]

I have video from a Canon 7d shot as 60fps and would like to...

1. halve the file size by converting from 60fps to 30fps.
2. maintain original format, quality, etc.
3. avoid a re-encode if possible (i.e. just drop the additional frames)
4. do this in batch with files in various locations (i.e. not all in the same source folder)
5. do it "in place" meaning I don't want to have to put all the resulting files in a single destination folder and then have to put those files back in their original locations manually afterwards.

Points 4&5 are optional, willing to flex on the 3rd point if I must.

[aedipuss]

good luck
1 filesize is bitrate times time, it has nothing to do with fps.
2 half the bitrate to make half the filesize is half the quality(usually if all other factors are left the same).
3 re-code is required for almost any change.
4 try vidcoder if it will accept your source files.
5 vidcoder has an option to write to source directory.


edit - sorry you're out of luck vidcoder is win only, just noticed this mac use.

[DigitalOxygen.ca]

Assuming all the original properties are maintained (as I don't want to change the codec or any other aspects aside from the frame rate) would the file size not roughly be halved if the frame rate was halved?

vidcoder appears to be Windows only, looking for something that will run on OS X as per the original post.

This may have potential but can't get a sense of whether the video will be playing at normal speed (i.e frames were dropped) or whether it will be slow motion.
http://www.avidemux.org/smf/index.php?topic=10206.0

[aedipuss]

no - the bitrate is all that determines filesize. so unless you use half the bitrate there will be no corresponding change in size.

[Baldrick]

Try handbrake.

[DigitalOxygen.ca]

A gottcha. so if I halve the bit rate and the frame rate I should end up with roughly the same quality but half the file-size?

[DigitalOxygen.ca]

Try handbrake.

Have tried that before and to my knowledge there is no option to maintain the original video format I only have options to re-encode to something else which impacts the quality and color in the process. Ideally I was hoping for something that would quite literally just drop every second frame without touching anything else about the file.

[poisondeathray]

Try handbrake.

Have tried that before and to my knowledge there is no option to maintain the original video format I only have options to re-encode to something else which impacts the quality and color in the process. Ideally I was hoping for something that would quite literally just drop every second frame without touching anything else about the file.

Not possible with 7D files. You have to re-encode , and lose quality. You can use lossless compression when re-encoding, but filesize will be 10-20x as large

7D uses long GOP compression (or temporal compression) - not every frame is encoded completely by itself intact - they rely on previous frames for data, and code & store only the differences between frames. So you cannot just pick & choose frames

[DigitalOxygen.ca]

aaaah of course. hmmm, well that sucks.

So to make sure I understand correctly...
- I must re-encode to a different format.
- Changing frame rate during re-encode will have no effect on the final size of the video

Will I be throwing away information (frames) unnecessarily if I drop the frame rate with the intend of reducing file size? i.e. will there be any noticeable difference in the resulting files size between 60fps and 30fps assuming all other encode settings are the same?

[aedipuss]

the major difference between 60 and 30 fps is apparent smoothness of moving objects. the faster an object is moving the jerkier it will get when reducing framerate.

[poisondeathray]

aaaah of course. hmmm, well that sucks.

So to make sure I understand correctly...
- I must re-encode to a different format.
- Changing frame rate during re-encode will have no effect on the final size of the video

Yes, and yes

Filesize = bitrate x running time

But, a higher FPS will require slightly more bitrate to have similar frame quality. How much more depends on the content complexity. Lots of motion means larger differences between frames, thus more data must be stored and more bitrate required for "similiar quality". With static scenes, there is very little difference, so the amount of extra bitrate required is a lot less

Will I be throwing away information (frames) unnecessarily if I drop the frame rate with the intend of reducing file size? i.e. will there be any noticeable difference in the resulting files size between 60fps and 30fps assuming all other encode settings are the same?

It depends. See above.

There are many more factors, like encoding settings, encoder choice, viewer factors (some are very preceptive, some are not) that can make a difference

Personally, I would just get more HDD space, I wouldn't bother re-encoding, waste of time and quality

[DigitalOxygen.ca]

Appreciate all the answers.

There are several reasons I'm focused on reducing file size at the moment (laptop with limited space is my primary working machine, backup my files off-site, etc).

I suppose then if I cannot reduce the file size by halving the framerate I must sacrifice quality.

However, maybe there is a middle ground where I can potentially reduce bitrate by reducing the fps? In your above example you state that if the content is fairly static there could be a reduction in bitrate when the framerate is dropped thus a reduction in file size. Could I then not reduce the framerate while having it recalculate the bitrate and see if I end up with a smaller filesize? For example, some kind of 'same as source' to get the destination settings the same as source initially then you can set to 30fps and variable bitrate?

[poisondeathray]

This is an immutable law, (like gravity):

Filesize = bitrate x running time

It's a math equation. If you want 1/2 the size, just enter 1/2 the bitrate, assuming it's the same video duration (not edited). Note this says nothing about quality. If you enter 1/10 the bitrate, you get..... <drumroll> 1/10 the filesize. Of course it will look like garbage because the bits per frame will be too small

However, maybe there is a middle ground where I can potentially reduce bitrate by reducing the fps? In your above example you state that if the content is fairly static there could be a reduction in bitrate when the framerate is dropped thus a reduction in file size. Could I then not reduce the framerate while having it recalculate the bitrate and see if I end up with a smaller filesize? For example, some kind of 'same as source' to get the destination settings the same as source initially then you can set to 30fps and variable bitrate?

You're implying VFR (variable frame rate) encoding, and while you can do this, there are many reasons not to - the biggest being compatibility with editors.

In a static scene (lets say a blank wall with no motion). That 1 second might be represented by 1 frame instead of 60 frames. You only encode 1 frame if you used VFR, so that takes less bitrate than 60 encoded frames of the same frame type. BUT the difference is long gop compression uses P, B frames (they consume less bitrate than I frames) - so efficiency is much greater than using all coded I frames (intra compression)

I was not speaking of VFR - I was only speaking of differences between frames. If there is little difference, the residual values required to be encoded are low. On a static scene , the difference might only be a few % increase when using long GOP over encoding 1 frame.

You should experiment with how much quality loss you can tolerate. It varies wildly. Huge continuum. Some people are pixel peepers, but some think youtube offers "great quality."

[greymalkin]

I'm going to clap my hands to end world hunger while you drop frames to reduce file size.

[DigitalOxygen.ca]

Thanks again for the info.

This thread makes it abundantly clear that I cannot take a shortcut by simply reducing the framerate. I will continue to experiment with Handbrake and other apps to find a balance between filesize and quality. Some videos I can heavily compress as they are just "home movies" while others I will likely keep in their original format and just trim.

Speaking of trimming video what apps allow this in OS X Lion? In Snow Leopard Quicktime Player (not QT Pro) used to allow you to trim the video and save in the original format without re-encoding. It would quite literally just truncate the beginning or end of the video. However in Lion they removed that functionality and force you to re-encode into a different format.

Any free applications out there that can do a simple trim without a re-encode?

Edit: It looks like MPEG Streamclip lets you do this (i.e. open movie, set in/out points, File > Save As) but you have to save it as another filename then delete the original. Quicktime Player used to let you save over top of the original which shorted the workflow a little but this is minor.

[edDV]

As said the main determinate of quality at various bit rates is the type of motion being shot. The example of a still scene with a locked down camera requires very little bit rate to maintain a high quality image. Likewise a hand held shot of moving objects requires a great deal of bit rate to maintain quality. Hand holding a camera puts all pixels into a combination of X Y and rotational motion. The result is less interframe compression is possible because the change data is great. To meet a fixed bit rate requirement, the encoder must apply more compression to the I frames thus lowering quality substantially.

Separate from bit rate, if you halve the frame rate, you reduce the motion sample rate of the interframe data (B and P change data). This causes motion to become stepped.

The DVB and ATSC are currently studying the feasibility of 1080p50 and 1080p60 for broadcast. What they have found is pro shot video (i.e. stable, well lit, well exposed) needs only a small amount of extra bit rate vs. 1080i. This is because pro shooting technique keeps the change data under control allowing high quality I frames.


PS: The Canon 7d uses only h.264 compression for video. If it had an MJPEG mode (sequence of JPEG stills), then file size would be proportional to frame rate assuming intraframe compression was held constant. However, for equivalent video quality MJPEG requires much higher bit rate vs. h.264.

[poisondeathray]

Handbrake can encode in VFR, you may have small efficiency gains over CFR, but beware this will reduce compatibilty in NLE's. It will be out of sync or cause frame decoding errors in some (will play fine in media players). I forget how to force CFR in handbrake, I think you enter the FPS manually instead of "same as source"

Compression wise, the 7D produces very poorly compressed video . It doesn't use b-frames (only p-frames) , and uses a low quality baseline h.264 profile. For your average viewer, re-encoding it with at maybe 2/3 the bitrate with more optimized compression usually not make a noticable difference. But the more compressed the video, the more difficult to edit in programs (longer latency & seek times)

[DigitalOxygen.ca]

I have to types of footage I am working with. "Home movies" i.e. the kids playing sports, horsing around, etc. and stock footage I've collected with the specific purpose of making a short film, etc. Obviously I don't want to compress the stock stuff any more than it already is hence my original thought of just halving the framerate for clips which would not be used for slow motion, etc. Since that is out the window I will likely leave those alone. When I get to the editing stage I will possibly use MPEG streamclip to convert to ProRes or something else easier to work with in the editors, haven't reached that stage yet.

The home movies on the other hand I am willing to compress to save space and take the quality hit.

I have been experimenting with Handbrake again and notice a difference between converting to 30fps and maintaining the original 60fps. I assume this is because it's using VBR or some other property is variable.

I used the following handbrake CLI command in an AppleScript once with 30fps and once at the original 60fps. The 30fps file is roughly 1/2 the size of the 60fps file.

/Applications/HandBrakeCLI -e x264 -q 16.0 -a 1,1 -B 160,160 -6 dpl2,auto -R Auto,Auto -D 0.0,0.0 -f mp4 " & frameRateParemeter & " --loose-anamorphic -m -x b-adapt=2: rc-lookahead=5D: psy-rd=1.0,0.50

I'm fairly happy with the results (did lots of comparison with various settings) but curious now about the filesize difference between 30fps and 60fps. For the purposes of home movies I will likely go with 30fps since the space savings are so great and I don't care as much about quality or smoothness.

[aedipuss]

use mediainfo in text mode on both 30 and 60. note the bitrates.

[DigitalOxygen.ca]

Yeah, as expected it's about 1/2. Suppose, I was more curious about the setting in the CLI command that dictates CBR or VBR. I can just look that up though.

[_Al_]

....sorry, taking that back ...

[DigitalOxygen.ca]

....sorry, taking that back ...

Was wondering about that one. Was going to reply saying that wasn't what I was after. Thanks nonetheless

[swetekman]

1 filesize is bitrate times time, it has nothing to do with fps.

Let's move in to the real world and answer the question: what is bitrate?

"Bitrate or Bit Rate is the average number of bits that one second of video or audio data will consume."

An example:
Taking an uncompressed (no container), black and white (1 pixel color depth) video with a picture size of 1280 x 720 in 60 frames per second. The number of bits needed for one second is roughly 1280 x 720 x 60 => bitrate of app 55 Mbps.

Using 30 fps uses 1280 x 720 x 30 => bitrate of app 28 Mbps.

So filesize is related to bitrate and time. And bitrate is related to fps which leads to ... filesize has something to do with fps.
Moving into the world of compressed video changes the equation but the relathionship is still there.

I used the following handbrake CLI command in an AppleScript once with 30fps and once at the original 60fps. The 30fps file is roughly 1/2 the size of the 60fps file.

And reality showes that I am right.

I'm going to clap my hands to end world hunger while you drop frames to reduce file size.

I do not think you can end world hunger but the frames are dropped and the size of the file is reduced.

[greymalkin]

bitrate is related to fps which leads to ... filesize has something to do with fps.

Let's examing the terms shall we:

Framerate is measured in fps = Frames per second
Bitrate is measured in Kbps/Mbps = Kilobits per second or Megabits per second

fps and kbps do have something in common, the unit of measurement they use = seconds. This is the one and only standard by which they associate one with the other.

The amount of frames per second and the amount of kilobits allocated to each second are two seperate variables..changing one does not change the other. Only one of those 2 variables will affect file size. If you noticed a different file size between 2 files you were converting then that is because instead of specifying a constant bitrate you elected to use a variable bitrate or constant quality setting. This may appear to be a 3rd variable (let's call it Kilobits per frame) that causes fps and bitrate to be related but it's actually the program just adjusting the bitrate based on the complexity of motion between frames. The end result is a higher file size but ONLY because you told the program to allocate more bitrate by issuing the vbr or constant quality command. So end the end it's still just bitrate x time...halve the file size by halving the bitrate.

[Cornucopia]

I agree, greymalkin.

@swetekman,
Your original calculation of Uncompressed bitrate is based on an ASSUMPTION of a certain QUALITY (that quality being "uncompressed" or "pristine").
Your compressed calculations should also be based on an ASSUMPTION of a certain quality, but that is arbitrary, based on WHAT YOU (or the Encoding App) CHOOSE.
So, to compare apples to apples (the way you want to), you'd have to fit that ALSO into your equation. When you do that, there are other factors that must also be included besides FPS - Motion & Image complexity, codec efficiency, contrast, resolution, artifacts, & other levels of quality acceptability or non-acceptability. Gets pretty complicated pretty fast...

Scott

[swetekman]

Framerate is measured in fps = Frames per second
Bitrate is measured in Kbps/Mbps = Kilobits per second or Megabits per second

fps and kbps do have something in common, the unit of measurement they use = seconds. This is the one and only standard by which they associate one with the other.

You are confusing by just looking at the unit of measurement.

Given one video file the bitrate is a function of frame size, frame rate and compression.

So end the end it's still just bitrate x time...halve the file size by halving the bitrate.

And if you look at my example again: By reducing the frame rate by half, the bit rate is reduced by half and the file size is reduced by half.

So I have always agreed that reducing bitrate will reduce file size. Setting a target bitrate half the original will produce half the size. I am just arguing that reducing frame rate will also reduce bitrate and that in turn will reduce the file size.

[swetekman]

I agree.

Good

@swetekman,
Your original calculation of Uncompressed bitrate is based on an ASSUMPTION of a certain QUALITY (that quality being "uncompressed" or "pristine").

No, that is your assumption. I have not used the word quality in my text.

Uncompressed video is not a statement about the quality of the content. It is just an simplification to easier explain the concept of relationship between frame size, frame rate and bitrate.

Your compressed calculations should also be based on an ASSUMPTION of a certain quality, but that is arbitrary, based on WHAT YOU (or the Encoding App) CHOOSE.

Again, I stayed in the realm of uncompressed video and did not make any assumption about certain, arbitrary quality or encoding choices.

So, to compare apples to apples (the way you want to), you'd have to fit that ALSO into your equation. When you do that, there are other factors that must also be included besides FPS - Motion & Image complexity, codec efficiency, contrast, resolution, artifacts, & other levels of quality acceptability or non-acceptability. Gets pretty complicated pretty fast..

And I stated that "Moving into the world of compressed video changes the equation but the relathionship is still there". Still no sign of quality assumptions. I have a good understanding of the complexity of video compression.

The statement that files size do not relates to frame frequency (fps) is still wrong.

[manono]

The statement that files size do not relates to frame frequency (fps) is still wrong.

Nope, dead wrong. It's entirely a function of the bitrate and the length of the video. Framerate has nothing at all to do with it.

A video at, for example, 30fps, at a bitrate of 1000 and a minute long will be the same size as another video at 24fps with the same bitrate and length. Roughly 7325KB.

[poisondeathray]

The statement that files size do not relates to frame frequency (fps) is still wrong.

This is wrong.

There is only a relationship if you make an assumption about average macroblock or frame quantizer, or other "quality" metric like SSIM, PSNR

Strictly speaking, (Mathematically), fps doesn't come into the equation

Filesize = bitrate x running time.

That's it. End of story .

FPS and bitrate are independent parameters. You can increase , decrease or keep the bitrate the same when halfing the FPS. Only if you make an assumption about quality or rate control method , does a constraint relationship exist

But for a given level of quality (<= see, this is an assumption) , If you double the number of frames, you will require more bitrate . Conceptually , you can think of it as spreading the bitrate over more frames, so the average quality of frame will decrease if you keep the same bitrate. In order to keep the same average "quality" , you need to increase the bitrate

However, in today's temporal encoding schemes (long GOP compression) with h.264 such as handbrake which uses x264, you never require 100% more bitrate or 1:1 more bitrate to increase in frames ratio. I believe (I know for a fact) that the OP is mistaken somewhere in his observation. 2x the number of frames will never require 2x the bitrate with long GOP compressed encoding. (He used CRF rate control method , which in itself is an assumption about quality) . On average, you might need 1.1-1.3x more bitrate for 2x the number of frames. As mentioned earlier, it depends on many factors like the type of content. Simple compressible content like cartoons might only need 1.1x more. Heavy action , lots of noise, might need as much as 1.3-1.4x more.

[swetekman]

The statement that files size do not relates to frame frequency (fps) is still wrong.

This is wrong. [..] FPS and bitrate are independent parameters.

I assume that you are talking about compression parameters and on that point I do not have any issue. By reading your messages I can see that you have a better understanding of the video compression technology then I have but I am still not talking about that.

Can you agree on this assumption:

Given a uncompressed video file, dropping half of the frames and retaining the same running time produces an uncompressed video file that has half the size, half the bitrate and half the FPS.

If we agree on that, we should agree on the assumption that filesize has a relationship to FPS otherwise the size of the file in the assumption above would not have change.

That is my point. Nothing else.

Then you can compress the shit out of it with any parameters you like. If you use the same settings (and do not use any stupid setting like setting the same target bitrate for both files) the 60 fps file will always be bigger then the 30 fps file. Could be by 1.3-1.4x more as poisondeathray said.

Here is a bitrate calculator for FLV/h264 that says that you should aim for 2x more:
http://www.adobe.com/devnet/flash/apps/flv_bitrate_calculator.html

I have uploaded a screenshots with calculations for 720p60fps and 720p30fps. When using the settings they recommend their encoder will produce a file with app half the bitrate and half the size if you start by dropping half of the frames in the source file.

And the original question has been solved already...

He dropped the frame rate and ended up with a file that has half the size of before and still has a quality he is happy with.
That is what this thread should end with, a simple way to reduce file size and bitrate.

I will use his handbrake settings as inspiration to drop the bitrate on a couple of 720p60fps videos which has to high bitrate for my computers. By reencode them in 720p30fps I will get half the bitrate and probably be able to watch them on any of my computers.

I will now stop explaining this any more and let the rest of you who still disagree stay in your bubbles of bitrates that are independent of FPS.