Closed & Unvariable GOP (keyint)

[NyaR]

Hello comrades, I require a small clarification if you would be so kind as to assist.

The conundrum is as follows: I want to make a Closed GOP video per YouTube Advanced Encoding Settings (https://support.google.com/youtube/answer/1722171). However in the x264 config I am presented with two choices: --keyint --min-keyint , there is also an option to set GOP Calculation to Fixed or FPS Based. My intention is to set the GOP to 30, unvariable. If I set Maximum and Minimum GOP size to 30 the command line outputs -keyint 30 --min-keyint 16, if I set 0/30 it makes --keyint infinite --min-keyint 1, 30/0 makes --keyint 30 --min-keyint 1

With that considered the question is as follows: how to make "Closed GOP. GOP of half the frame rate."?

http://i.imgur.com/NT4f8P3.png

:thanks:

[Asmodian]

They simply mean do not use --open-gop and set --keyint. Leave --min-keyint at default.

[raffriff42]

I wuz gonna say the same, but you beat me to it:

With that considered the question is as follows: how to make "Closed GOP. GOP of half the frame rate."?I'm gonna guess that "GOP of half the frame rate" here means GOPs should be one-half second in duration, at most. (Why they should want that, I don't know. Short GOP specs are normally for seek-ability, but since YouTube re-encodes the video anyway, this makes no sense to me). In the dialog in the screen shot, that would be set by selecting GOP calculation=FPS based, max GOP=12 (25/2 or one-half second).

There's no need to force any minimum GOP size IMHO. You want to allow x264 to start new GOPs at scene changes as it normally does. Since there is no "default" or "auto" minimum in MeGUI, I would set min GOP to 1.

EDIT I see you have set --tune-zerolatency; this does nothing for you as far as YouTube goes - it's for live video (http://x264dev.multimedia.cx/archives/249).

[pandy]

Two cents from my side - min-keyint may be useful to brake scene detection (as such scenecut and pre-scenecut can be controlled separately).

AFAIR GOP size advised for H.264 is around 1 - 1.25 second

For H.264/AVC or HEVC, the maximum time interval between successive RAP pictures shall be less than or equal to
1,28 seconds. This value accommodates variations either due to non-integer frame rates or GOP lengths that are a
power of 2 up to 32 frames for interlaced video, and up to 64 frames for progressive video. While the 1,28 seconds
value is derived for a GOP of 32 frames for 25 Hz, the corresponding value is 1,068 seconds for frame rates of
30 000/1 001 Hz. It is strongly recommended that the maximum time interval be less than or equal to 1,068 seconds for
frame rates of 30 Hz, 30 000/1 001 Hz, 60 Hz and 60 000/1 001Hz

Digital Video Broadcasting (DVB);
Specification for the use of Video and
Audio Coding in Broadcasting Applications
based on the MPEG-2 Transport Stream
DVB Document A157
March 2015

[vivan]

Advised for DVB, because waiting while switching channels sucks.

For offline playback and with not terrible encoders there's no reason to waste that much bitrate on frequent keyframes.

[pandy]

Advised for DVB, because waiting while switching channels sucks.

For offline playback and with not terrible encoders there's no reason to waste that much bitrate on frequent keyframes.
Advised for broadcast (so i assume ATSC have similar guidance) - there is huge difference between PC playback and non PC playback - side to this usually request like OP are due some special functionality required from stream and quality of video is meaningless (for example channel switching measure need to be done in exactly static conditions to simplify setup and receive repeatable results) - when special functionality is required from stream then there is no wasted bits - this is how i understand question.

btw in headends without statistical multiplexing (i.e. most of stream based headends) adaptivity may be not optimal as it is not controllable and frequently lead to mux overload - usually fixed GOP & CBR can provide better results in such environment as less stuffing may be reserved to accommodate VBR (average video quantizer will be lower) - for adaptive headend you need to have reencoders...

[Asmodian]

Advised for broadcast (so i assume ATSC have similar guidance) - there is huge difference between PC playback and non PC playback - side to this usually request like OP are due some special functionality required from stream and quality of video is meaningless (for example channel switching measure need to be done in exactly static conditions to simplify setup and receive repeatable results) - when special functionality is required from stream then there is no wasted bits - this is how i understand question.

This isn't such a use case, this is for uploading to YouTube.

[pandy]

This isn't such a use case, this is for uploading to YouTube.

Then whole topic is irrelevant as YT will reencode video anyway.

[kieranrk]

Then whole topic is irrelevant as YT will reencode video anyway.

The reason Youtube suggests closed gop is to aid their slicing algorithm I assume.