[FFmpeg-devel] ffmpeg mpegts muxing overhead

[Tomas Härdin]

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.

> 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