[FFmpeg-user] Reduce mux overhead of HLS stream creation

[Claudiu Rad-Lohanel]

On 2/16/2015 3:27 PM, Christian Ebert wrote:
> * Claudiu Rad-Lohanel on Monday, February 16, 2015 at 12:31:58 +0200
>> And to also clarify something: ffmpeg's overhead is ALWAYS bigger than
>> Apple's mediafilesegmenter, no matter the bitrate. But I assume it
>> tends to be more constant (or it grows slower with bitrate), thus, you
>> don't see such high percentages with higher bitrates. But if you
>> segment a 1mbit 1GB video with ffmpeg vs. Apple's segmenter, you'll
>> see tens of MB of difference between them.
>> It's clearly a general efficiency problem in ffmpeg in HLS case, I
>> assume that's because Apple squeezed everything it could from mpegts
>> while ffmpeg uses the generic mpegts muxer which must create valid and
>> compatible streams for all kinds of devices.
> Don't have blind faith in Apple's segmenter though. It seems to
> overoptimize and may get the duration wrong (and actually quite
> massively):
>
> http://flowplayer.blacktrash.org/fp5/hls-segmenter.html
>

Interesting observation, thanks. Did you figure out where those 2s 
disappeared?
A parallel playback or some kind of frame-level A/B comparison would be 
interesting.
Can't this actually be related to the player (maybe not implementing HLS 
standard 100% precisely)?
SMP + Flashls actually view the file as 4:14 from the beginning, and 
even at the end although, it's true, when started drops 2s but the 
length its adjusted during playback (weird): 
http://www.flashls.org/latest/examples/osmf/StrobeMediaPlayback.html?src=http%3A%2F%2Fmedia.blacktrash.org%2Ffp%2Fenc%2Fccc_trailer1-as.m3u8
Running both sources through <ffmpeg -i <src.m3u8> -c copy out.ts> 
generate a file with almost the same length (18ms difference). It's 
true, the one encoded by Apple's segmenter generate some DTS warnings.

However, I won't defend Apple's segmenter, it may have bugs or even 
conceptual problems. It's just that it's their official tool for *their* 
official streaming standard so they should be the most familiar with 
their needs and create a good segmenter that generate good results. It 
should be a pretty good example implementation.

What it does succeed is have the smallest muxing overhead (or maybe one 
of the smallest? I didn't compare with other 3rd parties like 
encoding.com that claim very low overhead) and this is really useful 
especially when you have HLS stream validation issues when you get over 
10% overhead.
Also 
http://blog.zencoder.com/2011/12/08/announcing-the-clouds-most-efficient-http-live-streaming/ 
(although old) illustrates that others had this problem and successfully 
made good optimizations.

And this brings us back exactly to the subject of the topic: "Reduce mux 
overhead of HLS stream creation". It is very much possible via muxing 
optimizations but what can be done in ffmpeg?
I would also reconsider https://trac.ffmpeg.org/ticket/2857 as *maybe* 
not so closed?

Actually I have asked about what Wesley asks now (how can we influence 
overhead) a couple of months ago on this mailing list but didn't receive 
any answers.. I assume we can't and optimizations must be coded.

-- 
jazzman