[FFmpeg-user] Reduce mux overhead of HLS stream creation
jazzman at misalpina.net
Mon Feb 16 19:05:50 CET 2015
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
Interesting observation, thanks. Did you figure out where those 2s
A parallel playback or some kind of frame-level A/B comparison would be
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):
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
(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.
More information about the ffmpeg-user