[FFmpeg-devel] ffmpeg mpegts muxing overhead

[Pushkar Pradhan]

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.

>
>  I have basic stream information available like video frame
>> rate, audio sampling frequency, duration and size.
>> I first thought there is a theoritical minimum I can calculate by looking
>> at
>> the !SO 13818 part 1 specifications but I think there is a lot of freedom
>> in
>> implementation.
>> E.g. the spec says PCR packets must be sent every 100 msec but looking at
>> mpegtsenc.c I think it is configurable and the default is less than 100
>> msecs, am I correct?
>>
> Usually. Unfortunately it can end up > 100 ms in some cases (VFR, low frame
> rate).
>

>  So I am thinking at this point, the best way to find the theoritical
>> minimum
>> overhead is to read ffmpeg ts muxing code.
>>
> I would say this is the only way, for almost all muxers.
>
>> Any suggestions?
>>
> Try to model the muxer's behaviour outside it. Or just allocate some
> constant number of bytes for fixed overhead plus a percentage of the total
> size of the essence.
>
I think the most variable part is the amount of padding of the TS packet
(adaptation field). It will be very hard to make a good guess.

>
> This whole thing sounds very risky though, since any muxer's behavior is
> likely to change without notice. This is especially true for mpegts, since
> the muxer is.. suboptimal. What exactly are you trying to do?
>
I understand the estimate will break if the muxer code changes. Again, this
is for Live HTTP Streaming. Due to architectural and performance reasons I
do not have the actual data available only the stream properties like fps,
audio sampling rate, etc. when I publish the bitrate. Please see
http://tools.ietf.org/html/draft-pantos-http-live-streaming-05#section-3.2.7if
interested.
Thanks for your suggestions.

>
> /Tomas
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>



-- 
pushkar