H.264 encoding: enabling Open GOP? Disadv. when decrease Keyframe Interval?

[pxstein]

I am investigating optimal encoding parameters for encoding movies and for playback on screen/TV.
I set as default:

VBR wit bitrate=2500
Profile=High
Level: 5.1
Preset=Slow

This looks good so far. But I consider some fine tuning for some of the parameters and overwrite the defaults:
Therefore some questions:

1.) Should I enable "Open GOP" or not?
As far as I can see one can set the keyframe interval even when Open GOP is disabled. So it must be independent. Am i corect?

2.) What are the disadvantages of decreasing the maximum Keyframe Interval?

Occasionally I plan to later cut some intervals from the resulting video. But cutting is only perfect and recommended at keyframes.
So if I want to be able to cut precisely at scene changes I need to have as much keyframes as possible. The increase in video file size in negligible
as I found out. So why not decreasing the maximum keyframe interval from 250 (=default?) to 30?

3.) The default number of B-Frames is (I guess) 2. Is this value optimal?
I read in an older article a recommendation to disable "B pyramid". Is this nowadays still true?

[jagabo]

1) If you ever think you might want a lossless cut/paste edit in the future don't use open GOPs. Open GOPs use the keyframe of the next GOP as reference frames for the last few B-frames of the GOPs. It gives you a small bitrate savings.

2) Shorter GOPs are easier to seek during playback and editing. But I-frames are expensive. Using short GOPs increases the bitrate requirement. Short GOPs give you better granularity for lossless cut/paste editing. Short GOPs can reduce keyframe pumping with some encoders.

3) More B-frames gives more compression. But they require more memory/power to encode and decode. Many devices don't support a large number of consecutive B-frames or B pyramid. The default for most presets in x264 is 3.

There's no single optimal value for settings like this. It's a matter of what compromises are appropriate for different situations. And some encoders deal with some settings better than others.

[pxstein]

1) If you ever think you might want a lossless cut/paste edit in the future don't use open GOPs. Open GOPs use the keyframe of the next GOP as reference frames for the last few B-frames of the GOPs. It gives you a small bitrate savings.

Very interesting!
Thank you

2) .... But I-frames are expensive. Using short GOPs increases the bitrate requirement. ......

Hmm, I tried (re)encoding a "normal" movie with bitrate 2500, same other parameters and
a) keyframe interval 250=default
and
b) keyframe interval=30

The resulting video file size increased only by 0,08%

So I cannot confirm that "I-frames are expensive".

From where did you get this opinion?

[jagabo]

When you use bitrate based encoding the file size will always be the same. That's the whole point of bitrate based encoding. What will vary is the quality. Spending more bits on more keyframes leaves less bits for the other frames.

[pxstein]

When you use bitrate based encoding the file size will always be the same. That's the whole point of bitrate based encoding. What will vary is the quality. Spending more bits on more keyframes leaves less bits for the other frames.

Ok, I understand.

Assume I set a constant quality level of X
Any idea on how much the resulting video size increases when I reduce the max keyframe interval from 250 to 30?
Just roughly make a guess

[jagabo]

Typically single digit percentages. But it will depend on the particular video and the other settings. For example, a music video with lots of short shots will have lots of keyframes anyway (assuming you have the encoder to insert keyframes at scene changes). But a slow moving movie with few shot changes will see a greater effect.

[pxstein]

@jagabo:

Thank you for the comments so far.

In order to get a better estimation about the required additional file space when using smaller keyframe intervals I encoded a sample movie video with Constant bitrate CBR Rate Control Mode.

As far as I know the CBR encoding is know to keep a constant quality level with unpredictable file size.

So the resulting video file size difference between keyframe intervals 250 and 30 is about 0,2% (all other parameters are equal).
So "single digit percentages" seems to be overestimated.
Whats wrong?

Is there another way to keep quality encoding level constant while vary only keyframe interval?

Beside this I would like to revert to your statement about Open GOP:

Is there another parameter/feature which should be avoided when I plan lossless cut/edit in future?
What about "lookahead" feature? Can I use it?
Or CABARC/Trellis?

[jagabo]

CBR is not constant quality. It is Constant BitRate, another bitrate based encoding method. You want to use CRF or QP encoding.

What encoder are you using? I just ran a quick test with some mixed movie clips and the x264 command line encoder (preset=slow, CRF=18). keyint=30 was nearly 8 percent larger than keyint=250. The former file had 83 keyframes vs. 29 in the latter.

[Sharc]

As far as I know the CBR encoding is know to keep a constant quality level with unpredictable file size.

So the resulting video file size difference between keyframe intervals 250 and 30 is about 0,2% (all other parameters are equal).
So "single digit percentages" seems to be overestimated.
Whats wrong?

CBR means ConstantBitRate. The filesize will depend on the video duration only, means in theory independent of the encoder settings which explains your little difference. For CBR the quality fluctuates between simple vs complex scenes.
You should do your tests with CRF (ConstantRateFactor) encoding which will dynamically adjust the bitrate according to the picture complexity in order to keep the visual quality 'constant'.
It seems you are mixing up CBR and CRF.

[pxstein]

Here on Win10 notebook there is no CRF mode (in free, wide spread Xmedia Recode tool, GUI based on ffmpeg).

See attached snapshot

I used ICQ instead. with quality level 25.
The difference in file size is 25%
That seems to be too big.


[Attachment 63229 - Click to enlarge]

[Selur]

Never tested gop size effect on intels qsv encoder, but I agree 25% seems to large, unless you use a really low quality setting.

[pxstein]

ICQ Level=25 results in a bitrate of ~3500
So its by far not a low quality settings

[Selur]

ans using the same setting, but with a keyframe interval of 250 results in a bitrate of ~2800 (=3500/1.25) that seems too much judging by what x264 for example would do.
(I would have expected something around may be 10%, but not 25%)
Seems like QSV isn't that good saving bitrate with low gop sizes.

[jagabo]

I ran a quick test with ffmpeg with . I got 73376 KB with g=30, 71570 KB with g=250. Same video I tested with in post #8.

"G:\program files\ffmpeg64\bin\ffmpeg.exe" -y -benchmark -init_hw_device qsv=hw -filter_hw_device hw -v verbose ^
    -i %1 -pix_fmt nv12 ^
    -load_plugin h264_hw -c:v h264_qsv -preset veryslow -global_quality 21 -look_ahead 1 -look_ahead_depth 30 ^
    -profile:v high -level:v 4.2 -adaptive_b 1 -rdo 1 -g 30 -colorspace bt709 -color_range tv ^
    -acodec copy ^
    "%~dpn1.h264.qsv.mkv"

[Selur]

that's one percent, so the 25% might just be related to the sources pxsatein uses and not a general issue.

[poisondeathray]

Why are you forcing Level 5.1 ? This can cause compatibility issues with some types of hardware and software

What are your dimensions and framerate ? Certainly they can't be that high if your bitrates are around 2-4Mb/s

https://en.wikipedia.org/wiki/Advanced_Video_Coding#Levels

[Sharc]

@selur:

that's one percent,...

2.52%, no?

[Selur]

yes, 2.52%

[Sharc]

https://forum.doom9.org/showthread.php?p=1963398#post1963398