[FFmpeg-user] Reduce mux overhead of HLS stream creation
jazzman at misalpina.net
Mon Feb 16 11:31:58 CET 2015
On 2/16/2015 10:46 AM, Moritz Barsnick wrote:
> On Mon, Feb 16, 2015 at 04:38:47 +0000, Wesley Wen wrote:
>> I'm using FFmpeg to create HLS stream, but noticed significant TS muxing
>> overhead (especially for low bitrate condition). I used Elecard Stream
>> Analyzer to look at the stream and came up some questions.
>> ffmpeg -loglevel fatal -y -i audio_p0.mp4 -i video_p0.mp4 -dn -sn -threads
>> 0 -map 0:0 -map 1:0 -f ssegment -segment_time 5.005 -segment_list p0.m3u8
>> -segment_list_entry_prefix p0/ -segment_format mpegts -c:v copy -c:a copy
>> -vbsf h264_mp4toannexb -flags -global_header p0/%d.ts
> You should always also show us the complete, uncut console output from
> your command.
> For one, we might identify that your problem has been fixed already.
> Here's a (fixed) ticket concerning a similar matter:
No, that didn't fix what Wesley reports.
I am watching the subject for a quite long time, seen also when that
ticket was closed. I compiled, tested afterwards, the HLS segmenting
overhead seems the same. I've compiled and tested many times since, the
problem is the same.
Maybe actually what we report is a different problem than #2857 with
similar effect so I didn't comment on it without proof.
I wanted to report this but never had the time to gather all the samples
and create a nice report of it. Maybe now I'll be more motivated if
Wesley doesn't do it before me.
Bottom line: Apple's segmenter introduces low overhead of only a few
precent at low bitrates like 150-200kbit, while ffmpeg may reach 15-20%
no matter what mpegts path you choose. And this is a problem not only
because of such high waste but also as it yields Apple validation
warnings for the HLS stream generated with ffmpeg.
Also the mpegts output is the same for ffmpeg no matter if you generate
.ts directly or use ssegment or whatever, which would make sense as from
what I figured from the source, the muxer used is the same? Or maybe
here I am wrong..
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.
Wesley, command line and samples, even from Apple's mediafilesegmenter I
think would be relevant for continuing this thread.
I still don't have the time right now for a complete report...
More information about the ffmpeg-user