[FFmpeg-cvslog] r22288 - trunk/libavcodec/avcodec.h

[Reimar Döffinger]

On Tue, Mar 09, 2010 at 06:47:22PM +0000, M?ns Rullg?rd wrote:
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> > On Tue, Mar 09, 2010 at 06:29:06PM +0000, M?ns Rullg?rd wrote:
> >> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> >> > On Tue, Mar 09, 2010 at 11:21:46AM +0100, Michael Niedermayer wrote:
> >> >> 3. add a field to AVCodec that specifies the required padding
> >> >> for each decoder
> >> >
> >> > That's not very nice, it means and application needs a reverse data
> >> > path from decoder to demuxer to tell it what value it needs.
> >> 
> >> 1. open demux
> >> 2. open codecs
> >> 3. pass padding from codecs back to demux
> >> 4. profit
> >> 
> >> Doesn't seem that complicated to me.
> >
> > Sure, as long as you don't try anything unusual.  Like try to decode
> > with decoder A and then switch to decoder B if that failed.
> 
> The use the maximum value.  Or update the demuxer when you decide to
> switch.

Yes, and I am exactly asking for FFmpeg to provide that maximum value.

> >> > At least it should be done in a way that an application at least
> >> > also has the choice of querying a padding value sufficient for all
> >> > codecs.
> >> 
> >> That would encourage people to use that value rather than go the
> >> slightly longer, but more efficient, route.
> >
> > So? Not all applications have to care about 64 bytes per packet.
> 
> 64 bytes isn't the issue.  We're talking about kilobytes for some
> decoders.  That's not an issue for _them_ since they typically have
> packet sizes much larger than that anyway.

In what kind of codec would it not be efficient enough to check for overruns
at least every few hundred bytes?
Unless of course this whole thing is meant as an excuse to be able to write
decoders sloppily...