Encoding Closed GOP with FFMPEG

[UltraTV]

I need to setup an encoding pipeline with ffmpeg to support adaptive bitrate streaming (HLS, SS, HDS). These streaming formats all need to have Closed GOPs or at least aligned Keyframes during bitrate switching on devices.

With x264 + avisynth, this is very straightforward: -no-scenecut means that the GOPs will all be aligned and occurring at the -keyint interval.

However, I cannot find a similarly simple way to handle this with ffmpeg. I've tried -flags +cgop -flags2 +sgop as well as some other things, but the keyframes are not being generated at the expected points.

There is a recommendation elsewhere to use a single 1st pass encoding .stats for all of the bitrates, which is something that is also possible for x264, but this makes it difficult to distribute the processes across multiple machines since they are all dependent on that first pass.

Thoughts?

[natt]

You asked about x264 as well, so this may be of some help:
http://mailman.videolan.org/pipermail/x264-devel/2012-April/009294.html

> 3. adaptive bitrate has become very important, and with it, synchronized
> GOPs across encodes in different bitrates.
> this is currently supported in x264 by using fixed sized GOPs. what are your
> thoughts regarding a more content-aware approach?

x264 supports this with adaptive GOP too; all encodes with the same
lookahead settings and the same source will give the same distribution
of frame types, no matter what the bitrate.

[UltraTV]

If I understand correctly that is saying that with both ffmpeg and standalone x264 as long as keyint is the same the distribution of keyframes will be the same as well. Is that correct?

That helps some, but really I would like to say create an I frame every 96 frames, or every 120 frames. This allows our HLS splitting tool to split on an I frame for every .ts section.

[poisondeathray]

I think in ffmpeg , -sc_threshold 0 would be equivalent to x264's --scenecut 0 (which is equivalent to --no-scenecut)

http://sites.google.com/site/linuxencoding/x264-ffmpeg-mapping

[Blue_MiSfit]

I'd suggest not forcing I frames at specific locations, and making your splitting algorithm more intelligent.

As long as you encode all your streams at the same resolution (and possibly even if you change resolution, but I'm not 100% sure on this), and don't change keyint, x264 will pick the same GOP structure. Adaptive GOP is a good thing, use it if you can.

[Midzuki]

I think in ffmpeg , -sc_threshold 0 would be equivalent to x264's --scenecut 0 (which is equivalent to --no-scenecut)

http://sites.google.com/site/linuxencoding/x264-ffmpeg-mapping

Not sure how much things have changed lately, but ffmpeg's "-sc_threshold" ¿was? :confused: an integer value between -1000000000 and +1000000000 :scared:

[UltraTV]

Thanks for the replies. I tried the threshold settings and some other things but still couldn't force regular I frames.

You're correct that adaptive I frames are good to have. Our splitting tool can do some interesting things like adapt for a certain percentage of error past the expected cut point (30%, 40% etc), but in actual deployments the perceptual quality difference doesn't justify the potential issues. Each HLS playback stack uses custom heuristics to determine the best stream, and those heuristics change fluidly from one OS version to another, so it's entirely possible that these types of small differences can cause playback issues at some point in the future.

In any event, seems like the route we are going to take is to use ffmpeg for decoding and pipe to x264. This seems to be producing results on par with avisynth (minus the flexibility) while being significantly faster.

[Blue_MiSfit]

in actual deployments the perceptual quality difference doesn't justify the potential issues


It sounds like you're approaching this issue with a clear head. Best of luck!

Derek

[smok3]

from ffmpeg man:
x264opts options
Allow to set any x264 option, see x264 −−fullhelp for a list.
options is a list of key=value couples separated by ":".
For example to specify libx264 encoding options with ffmpeg:
ffmpeg −i foo.mpg −vcodec libx264 −x264opts keyint=123:min−keyint=20 −an out.mkv

p.s. i'am not claiming it will work, but certainly worth trying before going with piping solution.