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

[Måns Rullgård]

Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:

> On Tue, 2010-03-09 at 18:47 +0000, M?ns Rullg?rd wrote:
>> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
>> > 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.
>
> What codec would require kilobytes, and would it really be that hard to
> avoid? Even if such a codec did exist that still wouldn't justify trying
> to force applications to do codec-specific padding. There are
> alternatives that can be more efficient and simpler than your "doesn't
> seem that complicated" codec-specific padding; for example allocating a
> larger buffer and storing multiple packets there, so that most of the
> packets do not require much extra storage even if the padding value is
> large (the later packets work also as "padding").

Nobody said multiple adjacent packets would be disallowed, only that a
minimum amount of readable memory must exist beyond the end of the
packet.

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