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

Claudiu Rad-Lohanel 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:
>
> https://trac.ffmpeg.org/ticket/2857

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...

-- 
jazzman



More information about the ffmpeg-user mailing list