[FFmpeg-devel] ffmpeg mpegts muxing overhead

[Pushkar Pradhan]

On Tue, Jan 18, 2011 at 12:31 AM, Kieran Kunhya <kieran at kunhya.com> wrote:

> > > 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.
>
What spec is that, ISO 13818-1? I did not see any mention of this.

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



-- 
pushkar