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

[Alex Converse]

On Tue, Mar 9, 2010 at 10:25 PM, Jason Garrett-Glaser
<darkshikari at gmail.com> wrote:
> 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).
>

The maximum crafted MB is likely larger than the amount of padding
needed if the value of the padding is known.