x.264 intraframe compression and short GOP encoding

[anonymous_whatever]

Any x.264 users out there that can provide some of the key and necessary command-line settings for x.264 to force intraframe compression? i'm also looking for the settings to force short GOP encoding. i'm familiar with the command-line options but i'm looking for the best possible set of parameters to encode these two ways with. any general opinions?

[poisondeathray]

--keyint 1 forces intra

--keyint x means "x" is the max value for the keyframe interval. x264 adaptively inserts keyframes when necessary - for example a scenechange , or camera flash, but it will never go above that --keyint value

For example , if you have 29.97p material , --keyint 30 would give you 1sec max keyframe interval

There are no "best possible set" of parameters, because "ideal" settings might change for different scenarios. Some content might be better with more bframes for example - for examples cartoons greatly benefit from strings of bframes. Or maybe you have a target in mind, then you might need very specific settings or rules to encoding (e.g. devices)

There are tradeoffs pros/cons for longer keyframes vs. shorter keyframe distance

Have a look here for other settings and short description
http://mewiki.project357.com/wiki/X264_Settings

[anonymous_whatever]

i took a 110mb DV file and used --keyint 1 and got a 20mb file. this seems like its compressing a lot... i would expect an intraframe file to be much more than 20mb. is it the bitrate that has the ultimate control over the file size? does bitrate trump --keyint 1 when determining filesize?

[poisondeathray]

i took a 110mb DV file and used --keyint 1 and got a 20mb file. this seems like its compressing a lot... i would expect an intraframe file to be much more than 20mb. is it the bitrate that has the ultimate control over the file size? does bitrate trump --keyint 1 when determining filesize?

I'm not sure if bothered to read your other threads, but this was answered several times. People get sick of repeating it...

filesize = bitrate x running time

It's a universal rule. Just a simple equation. Note resolution doesn't factor in either. Just bitrate and running time.

What other settings did you specify? What method of rate control? CRF? Did you even specify a bitrate ?

Intraframe is a method of encoding. It says nothing about the quality or filesize. But to get a decent level of "quality", intraframe encoding (any type of compression ) will require enormous amounts of bitrate compared to long GOP, using the same compression/settings

[anonymous_whatever]

i took a 110mb DV file and used --keyint 1 and got a 20mb file. this seems like its compressing a lot... i would expect an intraframe file to be much more than 20mb. is it the bitrate that has the ultimate control over the file size? does bitrate trump --keyint 1 when determining filesize?

I'm not sure if bothered to read your other threads, but this was answered several times. People get sick of repeating it...

filesize = bitrate x running time

It's a universal rule. What other settings did you specify? What method of rate control? CRF? Did you even specify a bitrate ?

Intraframe is a method of encoding. It says nothing about the quality or filesize

lol yes i know this was answered and i understand that. correct me here if necessary:

i'm thinking that if i set --keyint 1, that will drastically increase the size of a file because every frame is an iframe. on the other hand, there is a bitrate set. is the bitrate the ultimate determination of filesize?

i suppose what i mean is, if you mess around with whatever settings, encoding methods, whatever you can in x.264 settings, whatever the bitrate is multiplied by the length of the file will determine the file size? as in, there is no setting than can force the bitrate to go above and beyond the value you specified?

[poisondeathray]

lol yes i know this was answered and i understand that. correct me here if necessary:

i'm thinking that if i set --keyint 1, that will drastically increase the size of a file because every frame is an iframe. on the other hand, there is a bitrate set. is the bitrate the ultimate determination of filesize?

--keyint 1 says nothing about rate control, or frame quantizers. So it says nothing about quality or filesize. For example, if your average frame quantizer was 50, quality would be garbage, and filesize very tiny. If your average frame quantizer was 1, filesize would be many times larger than original, but it would be nearly lossless

Yes bitrate ALONG with running time = filesize. Ultimate determination. Again:

FILESIZE = BITRATE x RUNNING TIME

there is no setting than can force the bitrate to go above and beyond the value you specified?

It depends how you define bitrate, but if you mean average bitrate over the entire video, if you use a 2pass encode , then the value you enter will be very close to the value you get (it may go over very slightly). ABR is not as accurate , but will be fairly close as well

But if you are referring to local bitrate peaks (this is a different definition of bitrate)

[poisondeathray]

If you need a specific size, then most people use 2pass encoding (for example fixed capacity limitations like fitting to a BD).

If you need a certain level of quality, then most people use CRF encoding (1pass quality based encoding), but the resulting filesize may vary according to content complexity (e.g. blank wall will get very little bitrate, action movie will get lots of bitrate)

[anonymous_whatever]

ok, gotcha. yeah, i haven't been able to find a good guide that summarizes all of this in a concise manner. i'm more or less piecing it all together using a variety of sources. i appreciate your answers.

[anonymous_whatever]

yeah 2-pass sucks with virtualdub

[anonymous_whatever]

so if i were to set --keyint 1, would i get the same quality of editing as i would with DV?

[poisondeathray]

so if i were to set --keyint 1, would i get the same quality of editing as i would with DV?

Again, it depends on the other settings.

AGAIN, --keyint 1 ALONE says NOTHING about rate control, says NOTHING about quality or size. All it specifies is distribution of frametype. All it indicates is every frame is a IDR keyframe , that's it.

if you used --keyint 1 --crf 0 , this would be lossless and huge , probably 10x the size, but decoded image bit for bit identical as the decoded DV image (there would be no point in doing this, unless you were using it as a lossless intermediate for applying filters, you would use DV instead if it was just for editing purposes)

[anonymous_whatever]

so if i were to set --keyint 1, would i get the same quality of editing as i would with DV?

Again, it depends on the other settings.

AGAIN, --keyint 1 ALONE says NOTHING about rate control, says NOTHING about quality or size. All it specifies is distribution of frametype

if you used --keyint 1 --crf 0 , this would be lossless and huge , probably 10x the size, but decoded image bit for bit identical as the decoded DV image (there would be no point in doing this, unless you were using it as a lossless intermediate for applying filters, you would use DV instead if it was just for editing purposes)

Yes, I understand that. --keyint 1 doesn't have any effect whatsoever on the ultimate size of the file produced, it just specifies that every frame in the video is classified as an i-frame. what this means to me, when i go in and edit, it will be as easy as editing DV footage but without the DV quality.

i say this under the assumption that all footage with only keyframes in it (as DV is and --keyint 1 x.264 would be) is easy to cut and manipulate because you don't have the problem of interacting with B and P frames.

so although there might be a big downgrade in quality, --keyint 1 would make it easy to edit, as easy as DV. does this sound good to you?

[poisondeathray]

No. It will NEVER be as smooth as DV in "editability" . Go back and re-read your 1st or 2nd thread. It's all repeated there.

Even if you disable features like CABAC, inloop deblocking , it will be worse (this will reduce compression efficiency , lower quality at a given bitrate, but increase the ease of editing) - I've stated this 3 or 4 times already... There is no combination of settings that will allow you to edit as smoothly as DV.

Those are several reasons why a dozen different people have told repeatedly you to keep DV

[anonymous_whatever]

No. It will NEVER be as smooth as DV in "editability" . Go back and re-read your 1st or 2nd thread. It's all repeated there.

Even if you disable features like CABAC, inloop deblocking , it will be worse (this will reduce compression efficiency , lower quality at a given bitrate, but increase the ease of editing) - I've stated this 3 or 4 times already... There is no combination of settings that will allow you to edit as smoothly as DV.

Those are several reasons why a dozen different people have told repeatedly you to keep DV

wtf is so special about dv? lol

if every frame is encoded into and of itself, as --keyint 1 would provide, why can't this be a low quality DV? no frame depends on any other, each frame should be independent, so what stops x.264 --keyint 1 from being a low quality version of DV? what is the technical reason for this?

[poisondeathray]

The technical reason is h.264 is more compressed (spatially as well) and requires more cpu cycles to decompress = higher latency

Deblocking and CABAC by far eat up the most decoding cycles, but even if you disable those, it' s still more compressed (that's the whole reason to use h.264 - BETTER COMPRESSION ) Features like Intra 8x8, 4x4 prediction are not available in DV, but take up more CPU decoding cycles. DV is very old style compression but very low in terms of resource consumption

Now on a modern computer, SD intra h.264 is a viable alternative. On a P4,..... probably not. The NLE you use adds extra overhead. Even if the SD intermediate plays fine in a media player, it will probably stutter in a NLE. You need minmum dual core for smooth sailing

[anonymous_whatever]

The technical reason is h.264 is more compressed (spatially as well) and requires more cpu cycles to decompress = higher latency

Deblocking and CABAC by far eat up the most decoding cycles, but even if you disable those, it' s still more compressed (that's the whole reason to use h.264 - BETTER COMPRESSION ) Features like Intra 8x8, 4x4 prediction are not available in DV, but take up more CPU decoding cycles. DV is very old style compression but very low in terms of resource consumption

Now on a modern computer, SD intra h.264 is a viable alternative. On a P4,..... probably not. The NLE you use adds extra overhead. Even if the SD intermediate plays fine in a media player, it will probably stutter in a NLE. You need minmum dual core for smooth sailing

i have one more powerful as well. is SD intra h.264 a separate codec?

[poisondeathray]

i have one more powerful as well. is SD intra h.264 a separate codec?

No, it's all part of mpeg4 part 10 or AVC. It's a huge spec, with many different profiles
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC

If you have a powerful PC, then use long GOP h.264 since your primary goal was small file size. That's the only way you will get very good compression . This has been discussed many times already.

For example, if you were "happy" with the quality of that 20MB intra file, you could probably reduce it to 10MB and better quality using long GOP

[anonymous_whatever]

so, theoretically, if i had an absolute powerhouse PC, could h.264 intra be easy to edit?

[poisondeathray]

SD long GOP h264 is fine to edit with a quad core I've stated this already. You don't need an absolute powerhouse or multisocket workstation for SD

It's only when you get to HD, that it starts to get sluggish. But even 1 HD long GOP stream is easy to edit with an i7 . But when you have multiple layers, it will get sluggish

A good starting point might be a 1sec GOP, so if you have a bob deinterlaced NTSC DV-AVI, it would be 59.94p, so --keyint 60 .

[anonymous_whatever]

if i had two x.264 files, at a variable bitrate of say, 2200kbps and one had --keyint 1 set and the other did not have that parameter set, just left to default, would the file where --keyint 1 is set technically be of lower quality?

i see this because the data required to store each frame as an iframe would lead to an overall degradation in quality as opposed to letting x.264 use temporal compression. is this the case?

[poisondeathray]

if i had two x.264 files, at a variable bitrate of say, 2200kbps and one had --keyint 1 set and the other did not have that parameter set, just left to default, would the file where --keyint 1 is set technically be of lower quality?

i see this because the data required to store each frame as an iframe would lead to an overall degradation in quality as opposed to letting x.264 use temporal compression. is this the case?

In most cases , yes. But it depends where on the compression curve you are.

If 2200kbps was "low" for that content complexity and frame size, most certainy the intra file will be much lower in quality. If it's a very simple compression case, like a blank wall, then the intra case might actually give better quality, because I frames are higher in quality than P or B, IF you allocate sufficient bitrate. In most compression schemes, I frames require much more bitrate, more than P, and P more than B, but the ratios are fully adjustable in x264 (I:P ratio, P:B ratio)