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

[David Conrad]

On Mar 9, 2010, at 7:31 PM, Alex Converse wrote:

> On Tue, Mar 9, 2010 at 7:21 PM, David Conrad <lessen42 at gmail.com> wrote:
>> On Mar 9, 2010, at 3:41 PM, Reimar D?ffinger wrote:
>>>>>>> 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
> 
> Is that based on random padding or zero padding?

Random I guess, with zero padding worst case should be (num blocks)*13 since it's valid for the 0 VLC to require 12 additional non-VLC bits.