[FFmpeg-devel] ffmpeg mpegts muxing overhead

Kieran Kunhya kieran
Tue Jan 18 09:31:45 CET 2011

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

In the spec they use 20% as a crude overhead. It's likely that'll be ok for ffmpeg's muxer although it's quite buggy. I plan to fix it at some point this year, perhaps as a gsoc mentor or by myself.

More information about the ffmpeg-devel mailing list