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

[Måns Rullgård]

Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:

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

FFMAX(padding_for_codec_A, padding_for_codec_B)

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

I'm only repeating what Jason said on IRC.

-- 
M?ns Rullg?rd
mans at mansr.com