[FFmpeg-devel] ffmpeg mpegts muxing overhead
Tue Jan 18 22:16:30 CET 2011
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:
>> 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
>>> Pushkar Pradhan skrev 2011-01-18 01:39:
>>>> I need to be able to predict the mpegts muxing overhead before the
>>>>> 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)
More information about the ffmpeg-devel