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

[Jason Garrett-Glaser]

On Tue, Mar 9, 2010 at 3:30 PM, M?ns Rullg?rd <mans at mansr.com> wrote:
> 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.

NB: what I said is basically equivalent to what Michael said (you need
a few kilobytes to catch the maximum possible crafted MB size in
H.264).

Dark Shikari