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

[David Conrad]

On Mar 9, 2010, at 3:41 PM, Reimar D?ffinger wrote:

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

For vp3 (not that I'm advocating basing lavc design decisions on it...), the only granularities with which it makes sense to check for overruns in the coeff decode are:

1. 64 times each plane (for the coeff level). Worst-case, this requires padding of (num blocks)*28 bits, which for 1080p is just over 111kb
2. once per token. This requires no more padding than is already provided, but the average token will use under 16 bits, so this is not ideal. It's slower than the current lack of checking by less than 1% in a worst case test (high bitrate intra-only) I just tried.

Anything between those two will just add another branch to check whether or not to check for overrun, which I can't see being worth it.