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

[mike23]

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?

[FranceBB]

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


Why level 5.1? You mean 4.1 I hope.
Anything HD/FULL HD should not exceed 4.1, especially at that bitrate. If you set it higher, hardware players might not play it at all. I'm talking about TVs, consoles etc.


1.) Should I enable "Open GOP" or not?


For simple playback on your own couch? Yes, definitely. The only ones who use closed gop are hardware playout ports that require strict constraints on the GOP pattern, but this is not your case and your TV at home won't care.


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?


Yes, you can set the keyframe regardless of the GOP type.


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


A keyframe is an intra, so essentially you're putting more intra frames. In a video you have I, P, B, where "I" is Intra and is the frame which holds all the information and is used as reference, P is a partially predicted frame, B is a bi-predicted frame. Intra frames clearly require more bitrate, so by increasing intra frames, you're gonna use more bitrate, but since you fixed your bitrate at 2500 kbit/s, you're gonna have less quality overall.



Occasionally I plan to later cut some intervals from the resulting video. But cutting is only perfect and recommended at keyframes.


Ehm... you mean cutting without re-encoding? Then yes. If you're re-encoding, it doesn't matter whether you cut at an Intra, a P or a B, 'cause you're effectively re-encoding. This is the reason why there are all intra classes of H.264 which are used as mezzanine files by editors to cut wherever they want, but they're definitely not bitrate efficient and they're only really used as temporary stuff.



I need to have as many 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?

If you wanna be totally compliant with standards, you can use framerate = keyframe as a rule of thumb. So, if your video is 23,976, --min-keyint 1 --keyint 24, if your video is 25, --min-keyint 1 --keyint 25, if your video is 29,970, --min-keyint 1 --keyint 30, if your video is 50p, --min-keyint 1 --keyint 50, if your video is 60p, --min-keyint 1 --keyint 60 etc.


About the bitrate, please please please consider using --crf instead of fixed bitrate. Unless you need it for some particular reason, crf will achieve better results in almost every scenario. Try with --crf 18 and go up from there if you think the file is too big.

[jpsdr]

Personnaly, if i'm not targeting Blu-Ray, but just be compliant with hardware device player, i let the keyframe at his default value. I agree with a lot of things with FranceBB, but not this one... :D
Keyframe=framerate is small and reduce efficiency of other things, but unfortunately it's mandatory for Blu-Ray.
Bitrate 2500 is VERY low (i hope you don't try on encode FHD content), you'll need all the tweaks you can to increase quality, so, absolutely yes, open GOP. When they implemented it, the devs said it produces around 10% quality improve.
And also keep B pyramid (i'm curious about this "article"), keep mbtree (case need disabling is very specific).
Sometimes people who made tests and give advices, are doing, without knowing, wrong things.

[benwaggoner]

Personnaly, if i'm not targeting Blu-Ray, but just be compliant with hardware device player, i let the keyframe at his default value. I agree with a lot of things with FranceBB, but not this one... :D
Keyframe=framerate is small and reduce efficiency of other things, but unfortunately it's mandatory for Blu-Ray.
For Blu-ray, you can actually use a 2-second GOP if using Level 4.0 and --vbv-maxrate 15000 or lower. You also don't have to use slices between Level 4.1

[mike23]

Thank you for comments for far.

First of all:
I plan to encode movies for playing
- on computers/notebooks
and/or
- copying the video files on USB flash drive and plug them into USB port in TVs

BlueRay players are not the target

Why level 5.1? You mean 4.1 I hope.
Anything HD/FULL HD should not exceed 4.1, especially at that bitrate. If you set it higher, hardware players might not play it at all. I'm talking about TVs, consoles etc.

Really?
I have never experienced any problems when playing videos with 5.1 on computers or TVs.



For simple playback on your own couch? Yes, definitely. The only ones who use closed gop are hardware playout ports that require strict constraints on the GOP pattern, but this is not your case and your TV at home won't care.

I heard that Open GOP is problematic when I plan to lossless cut/paste/edit these videos later.


A keyframe is an intra, so essentially you're putting more intra frames. In a video you have I, P, B, where "I" is Intra and is the frame which holds all the information and is used as reference, P is a partially predicted frame, B is a bi-predicted frame. Intra frames clearly require more bitrate, so by increasing intra frames, you're gonna use more bitrate, but since you fixed your bitrate at 2500 kbit/s, you're gonna have less quality overall.

So more keyframe/I-frames consume a portion of the (variable) bitrate at the expense of quality.

Assume I reduce the max keyframe interval from 250 to 30 at encoding time: how much more video file space (in percent) would be required when the quality should be the same?
...for a "normal" average movie? Give an estimation

[FranceBB]

Really?
I have never experienced any problems when playing videos with 5.1 on computers or TVs.


Perhaps modern TVs are checking the bitrate and as long as that doesn't exceed the level 4.1 constraints, even if you say it's a 5.1 one (which they couldn't play), they don't care and they just play it anyway. I don't know, I'm just guessing here.



I heard that Open GOP is problematic when I plan to lossless cut/paste/edit these videos later.


Well... I mean... technically you can cut at non I frames without re-encoding, but it's something that I would never ever do as a home user. Ok, so, if you have an I frame you can cut there and everything is nice and dandy, however if you have a sequence like IPBBPBBPBB and you cut at the last B without re-encoding, what happens is that the file will STILL be cut at the first I frame (so it will still have all the other frames in the GOP), but the muxer will write in the container a value in frames called "pre-charge". Pre-charge is the number of frames that are in the stream that a decoder must ignore before it starts displaying the video. So, in a nutshell, you will still have all the frames of the GOP, but the player will only display the frame you specified and wanted to cut on, which will be composed by using the Intra as reference and performing the operations specified in the motion compensation.

A remark: I have never done this with any muxer other than ommcp.exe which is the paid Omneon Muxer by Harmonic, so I have no idea which muxers actually support this and how many players will actually honor the precharge value.



So more keyframe/I-frames consume a portion of the bitrate at the expense of quality.


Yes, however if you use --crf you can pick a quality you like and x264 will adjust the bitrate dynamically for you to achieve the same quality across the whole video, so I strongly suggest to use --crf once again.



Assume I reduce the max keyframe interval from 250 to 30 at encoding time: how much more video file space (in percent) would be required when the quality should be the same?
...for a "normal" average movie? Give an estimation

It depends on a number of factors in the sense that it depends on how well motion compensation works and if there's like noise or grain or if it's mostly static etc, but you asked me a very rough estimation, so I'll try...

Assume the following sequence produced with

--no-scenecut --keyint 12 --bframes 2 --bitrate 50000:

pict_type=I
pict_type=B
pict_type=B
pict_type=P
pict_type=B
pict_type=B
pict_type=P
pict_type=B
pict_type=B
pict_type=P
pict_type=B
pict_type=B

it has:

pkt_size=728158 I
pkt_size=270192 B
pkt_size=272571 B
pkt_size=478986 P
pkt_size=291032 B
pkt_size=292296 B
pkt_size=476047 P
pkt_size=127445 B
pkt_size=125467 B
pkt_size=287332 P
pkt_size=114072 B
pkt_size=147912 B
pkt_size=634226 I

So we have:

728158 for I frames
476047 for P (partially predicted) frames
270192 for B (bi-predictive) frames

so an I frame is 728158÷476047 = 1.5 times larger than a P frame and 728158÷270192 = 2.7 times larger than a B frame...

I agree with a lot of things with FranceBB, but not this one... :D


Nah, we agree on this one too! ;)

In fact:


Keyframe=framerate is small and reduce efficiency of other things


I agree and I would never ever do it for my personal encodes, I was just pointing out to him that if he really wanted to reduce the keyframe value, he might as well do it as the standard indicates rather than randomly xD

Still, for things I wanna watch on my couch, I would never do that.

[Sharc]

https://forum.videohelp.com/threads/404691-H-264-encoding-enabling-Open-GOP-Disadv-when-decrease-Keyframe-Interval

[BuccoBruce]

Sorry for the necro, but for what it's worth, I have had issues seeking x264's open GOP output! But:

1. Only with AMD HW decoders.
2. Didn't matter how it was muxed, whether or how it was interleaved, fragmented, etc. It always happened. mp4 made with either mp4box or ffmpeg, mkv, raw .h264 (seeking issues honestly expected there) - it didn't matter.
3. Particularly if it was used for streaming, even without an AMD HW decoder involved.

It affected any/all seeks, fairly consistently, and it always froze on the same exact frames. It would "start" playing on what I suspect were IDRs that didn't need any "missing" refs, and play for a few frames or a few seconds or sometimes longer, up until the last B/P-frame that didn't have a ref outside the nearest IDR, and then freeze frame until the next IDR. Playing the file beginning to end had no issues, even as an elementary stream. I should try it again, or find one of the old files if I kept one, and check VLC's debug window again. I think it mentioned some kind of picture buffer something or another, even though it was Level 4.1, 1440x1080, with ref=5, automatically set by specifying L4.1 High. Well within DPB limits, and again, working fine if played beginning to end anyways.

I'd say the demuxer was consistently being really dumb and not seeking appropriately to grab the needed references, but .mkv/.mp4 were the same, and I suspect the decoder itself was throwing them out! Forcing CPU decoding with LAV did work, and mpv didn't seem to fare any better than VLC.

Re-encoding with the same settings and disabling open GOP made the issues go away, at a single digit % (or honestly even MB) increase in file-size, in a file that was already <200 MB. HEVC (x265) worked just fine with open GOP (default) on the other hand, even for streaming, and even with all the b-frames and refs you could want. Of course, streaming HEVC means limiting your audience to Edge and Safari...

[FranceBB]

I have had issues seeking x264's open GOP output! But:

1. Only with AMD HW decoders.



Yeah, hardware decoders can be a bit peaky in what they're gonna get and perhaps they might not behave as expected. Technically they should be able to seek through frames and get the info from the relative I frames all the way to the P/B frame that you're trying to seek. Some other hardware decoders just play dumb and only allow you to seek through I frames. In other words, if you go to let's say 00:10:22.23 it might ignore it and show you 00:10:22.00 as the first I frame. It really depends on the decoder.


Forcing CPU decoding with LAV did work


Yeah software decoding is always gonna work