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
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
