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

[Uoti Urpala]

On Tue, 2010-03-09 at 18:29 +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.

That is already quite complicated. It for example assumes that no
packets are created during the demuxer open(). You're also missing the
fact that for the kind of maximal efficiency you're talking about below
the padding would need to be stream-specific. So "allocate a packet for
size X plus sufficient padding" would no longer work as an abstract
operation but would need to depend on the particular stream the packet
will be used for, or the calls would need to add the padding size to X.

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

Using that value might well be the right decision, and there would be
nothing wrong in encouraging people to do the right thing. Unless the
"wasted" padding per packet is significantly more than 64 bytes the
efficiency gains are likely to be insignificant in almost all practical
cases.