2 sec gop vs 4sec gop

[TEB]

hi, anyone have any experience on longer gop settings with x264?
If yes, whats ure experience with regards to bitrate reduction given the same quality?

I have been trying with 4 sec gops lengths, which fits perfectly with 4 sec segments for Mpeg Dash/HLS and i see good results, but it could be interesting to see/hear what the rest of the experts here have observed ;)

TEB

[sneaker_ger]

I remember others coming to the same conclusion. Compression doesn't seem to increase much beyond 4 second keyint on most content.

https://i.imgur.com/u5xWMgd.png

[mkver]

This graph is obviously wrong (it says that with a change in keyint from about 90 to a bit over 100 filesize decreases to about 1/8 of what it was!) and directly contradicts the (believable) numbers contained in the linked post:

keyint file size (MB)
----------------------
4 191
8 143
16 118
32 104
64 97
128 92
256 91

[nevcairiel]

The axis labels are just swapped, otherwise matches your data jsut fine. :)

[benwaggoner]

I remember some long-ago research suggesting that 3 second might be optimal for simple heuristics. The 2 second GOP was made up relatively arbitrarily for an example in a white paper by a former boss of mine, who was amazed when people treated it as somehow magic. Four is fine as well. Really, no packaging system should have particular size requirements anymore. We're long past the days of 10 sec for HLS and 2 sec for everything else.

[mkver]

The axis labels are just swapped, otherwise matches your data jsut fine. :)
True, I should have figured this out.

[TEB]

I remember some long-ago research suggesting that 3 second might be optimal for simple heuristics. The 2 second GOP was made up relatively arbitrarily for an example in a white paper by a former boss of mine, who was amazed when people treated it as somehow magic. Four is fine as well. Really, no packaging system should have particular size requirements anymore. We're long past the days of 10 sec for HLS and 2 sec for everything else.

I totally agree Ben on a general perspective, but since we are JITxíng out both HLS and Dash, in combination with VBR (CRF) + sucky video servers and players, we found that a segment of 4 sec was the best compromise. In light of this i saw no reason for keeping the GOP at 2 sec... just as well bump it to 4 sec, as long as we have scenecut detection and local iframe insertion..

[benwaggoner]

I totally agree Ben on a general perspective, but since we are JITxíng out both HLS and Dash, in combination with VBR (CRF) + sucky video servers and players, we found that a segment of 4 sec was the best compromise. In light of this i saw no reason for keeping the GOP at 2 sec... just as well bump it to 4 sec, as long as we have scenecut detection and local iframe insertion..
It is a luxury to be able to spec out my own heuristics, yes :).

If you are stuck with legacy heuristics, a statistically derived approach like yours is the best option.

[Blue_MiSfit]

Yeah 2-6 seconds is in the sweet spot on most currently supported clients

https://bitmovin.com/mpeg-dash-hls-segment-length/

2-3 seconds can give better throughput and offer quicker ABR switching if your clients are all new. Older clients that can't make persistent and/or multiple connections do better with a slightly longer segment size.

Apple does a very good job of this with their HLS stack on iOS etc. Lots of careful optimization has been done here for a wide range of connection types. Modern DASH players do pretty well too, but some custom tuning ends up being helpful :) Live vs VOD is always a big factor as is how good your caching / edge delivery is.