Long gop

[TEB]

hi! We are in the process of moving from 2 sec segments to 4 sec segments for Mpeg Dash for various reasons (overhead cough...!)

Instead of having 2x2sec gops inside a segment, does anyone know if theres a negative side to have a 4 sec gop instead?

Besides the improved quality vs 2 sec gop, and by using some form for scenecut detection with inserted I-frames inside the gop for sudden temporal changes, i cant come up with why this isnt a good idea?

Any comments ?

/TE

[benwaggoner]

hi! We are in the process of moving from 2 sec segments to 4 sec segments for Mpeg Dash for various reasons (overhead cough...!)



Instead of having 2x2sec gops inside a segment, does anyone know if theres a negative side to have a 4 sec gop instead?



Besides the improved quality vs 2 sec gop, and by using some form for scenecut detection with inserted I-frames inside the gop for sudden temporal changes, i cant come up with why this isnt a good idea?



Any comments ?



/TE



If you are using fixed GOP, you’ll get better quality the longer the GOPs, since you’ll get fewer forced IDR frames, and more natural I-frames at scene cuts. Since the fixed IDRs take place without any relation to the underlying content, you can wind up with an IDR and an i-frame next to each other when a scene cut is 1 frame off the fixed GOP cadence, which can cause VBV and quality challenges. The fewer fixed IDR, the more VBV flexibility you have to get more consistent quality.

The downside of longer GOPs is that switching bitrates is slower, and that a lot of legacy heuristics assume they’ll be 2 sec and can behave sub-optimally with different sizes.

My old boss picked 2 second arbitrarily years ago when writing a proof of concept; it was never meant to be a default a decade later!


Sent from my iPad using Tapatalk

[Blue_MiSfit]

2 seconds is convenient because the best practice for HLS is 6 second segments, and the best practice for DASH is 4 second segments. If you're making H.264 for both formats (as many premium services will do because of DRM) this is beneficial since you can use the same encodes for both formats.

I'd prefer if we could do 4 seconds, but hey, at least we're not in the 15 frame broadcast world ;)

[TEB]

2 seconds is convenient because the best practice for HLS is 6 second segments, and the best practice for DASH is 4 second segments. If you're making H.264 for both formats (as many premium services will do because of DRM) this is beneficial since you can use the same encodes for both formats.

I'd prefer if we could do 4 seconds, but hey, at least we're not in the 15 frame broadcast world ;)

Well, i see ure point, but doesnt HLS support 4sec or 8sec in v7+ segments?
Due to the fact that we are moving over to Constant quality rate control methods, the VBR spikes are to hard for the included overhead of 2 sec dash segments..

[Blue_MiSfit]

HLS supports any fragment size you want AFAIK, but best practice is still 6 seconds per https://developer.apple.com/documentation/http_live_streaming/hls_authoring_specification_for_apple_devices

[benwaggoner]

HLS supports any fragment size you want AFAIK, but best practice is still 6 seconds per https://developer.apple.com/documentation/http_live_streaming/hls_authoring_specification_for_apple_devices
The Pantos spec has always been spotty in its “best practice” recommendations. For years it recommended 10 second fragments AND a key frame every 3 seconds, which doesn’t even give GOP alignment! And it recommended using Baseline for low bitrates for YEARS after the last Baseline-only device was obsolescent.

6 second seems to work if you need to be compatible will all the random 3rd party HLS .ts heuristics implementations out there. But modern HLS should use fmp4 not .ts, and happily can use shorter fragments for quicker bitrate shifts. Note DRM protected HEVC HLS REQUIRES fmp4. That is definitely the future of HLS on iOS/MacOS.

[Blue_MiSfit]

Yep, I've recently implemented HEVC HLS with CMAF (using FairPlay DRM), but still make TS for AVC. I don't suppose there's a particularly good reason for the latter, now that I think about it (other than changing as little as possible at a time, of course :D)

I think the Apple specs have improved a lot recently. Agreed that they were a bit crufty for a long time ;)

[TEB]

thx for the good info guys.. Im aiming for a common ground 4 sec segment size, since we are not burdened by legacy devices..
Our minimum baseline now is : IOS10, Android 5.5 as well as our Q22 stb (Android 7)..

Based on my tests a 4 sec segment size is actually faster to start than a 2 secs (in a VBR world) due to the fact of the overhead of TCP/HTTP + rampup at the start on our player..

4 seconds seems like a good common ground segment size that would work on HLS as well as Dash.

PS! Anyone got some good info on CMAF?

[benwaggoner]

Yep, I've recently implemented HEVC HLS with CMAF (using FairPlay DRM), but still make TS for AVC. I don't suppose there's a particularly good reason for the latter, now that I think about it (other than changing as little as possible at a time, of course :D)
If you need to use FairPlay with H.264 too, you need to keep using .ts. But without DRM, you can use CMAF for everything.

Alas, the software HEVC decoder on older iOS devices doesn't support FairPlay, so if you're targeting pre iPhone 6s devices with DRM content, you need to keep supporting .ts.

Fortunately the phone replace cycle is such that this won't matter in a few years.

[Blue_MiSfit]

Ah! I didn't realize FairPlay with H.264 HAD to be in TS. Thanks for the tip.

[kabelbrand]

If you need to use FairPlay with H.264 too, you need to keep using .ts. But without DRM, you can use CMAF for everything.

Unless you are aiming for older devices you can use H.264 in Fairplay encrypted fMP4 for HLS streaming in Safari from iOS 11.2 on.