[FFmpeg-devel] ffmpeg mpegts muxing overhead

[Pushkar Pradhan]

On Tue, Jan 18, 2011 at 1:16 PM, Tomas H?rdin <tomas.hardin at codemill.se>wrote:

> Pushkar Pradhan skrev 2011-01-18 21:18:
>
>  Hi Coudurier,
>>
>> On Tue, Jan 18, 2011 at 11:14 AM, Baptiste Coudurier<
>> baptiste.coudurier at gmail.com>  wrote:
>>
>>  Hi
>>>
>>>
>>> On 01/18/2011 09:05 AM, Pushkar Pradhan wrote:
>>>
>>>  On Mon, Jan 17, 2011 at 11:38 PM, Tomas H?rdin<tomas.hardin at codemill.se
>>>>
>>>>> wrote:
>>>>>
>>>>
>>>>  Pushkar Pradhan skrev 2011-01-18 01:39:
>>>>
>>>>>
>>>>>  I need to be able to predict the mpegts muxing overhead before the
>>>>> actual
>>>>>
>>>>>  muxing happens.
>>>>>>
>>>>>>  Why? Also, does it need to be exact, or can it be an overestimate?
>>>>>>
>>>>>
>>>>>
>>>> This is for HTTP Live Streaming. We need to publish the bitrate in the
>>>> playlist. If the actual bitrate deviates too much (20-25%) from the
>>>> published the App Store rejects the app. In our architecture the
>>>> playlist
>>>> has to be sent out before doing the actual muxing. Otherwise it is a big
>>>> architectural change. So the estimate has to be within a reasonable
>>>> limit.
>>>>
>>>>
>>> You can specify a muxrate to the muxer which will add padding as
>>> necessary.
>>> Account video bitrate + audio bitrate + reasonable margin.
>>>
>>>  I think you're talking about the AVFormatContext:mux_rate which is used
>> as
>> the MpegTSWrite muxrate, the default is 1. I followed this variable's use
>> in
>> mpegtsenc.c and found that it is used to set the pcr values written out.
>> It
>> also inserts null packets or pcr_only packets if some other conditions on
>> the DTS are also satisfied.
>> So overall, I see it will increase the muxing overhead, but not make it a
>> fixed size.
>>
>
> Yes, the amount of padding is determined from pts and file size. Through
> "magic" it becomes CBR. Or rather close at least.
>
> Try ffmpeg -i foo -muxrate 10M blargh and, assuming the VBV buffer is less
> that 6-7 Mbit or so, the output should be 10 Mbps. The limit is something
> like bufsize < muxrate*muxdelay or thereabouts.

That is a cool option. Even if I had estimated the average overhead for a
media of N seconds, if the individual .ts segments (10 secs default)
deviated from the average by more than 10-15% the app would be rejected by
Apple.
ffmpeg is so flexible. You guys are the best.

>
>
>  I think most of the muxing overhead comes from padding the TS packets when
>> writing out the PES packet. IMHO this cannot be predicted unless you know
>> the frame sizes etc.
>>
>> Or am I missing something?
>>
>
> Not quite, but I'm not sure how to explain it. Consider that the TS packets
> are all 188 B while the payload (AVPacket) is often much larger. IIRC
> padding only happens for the last bit of data in each AVPacket.
>
> (hopefully I configured Thunderbird correctly this time and my quotes
> weren't messed up)
>
> /Tomas
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>



-- 
pushkar