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

[Uoti Urpala]

On Tue, 2010-03-09 at 23:29 +0000, M?ns Rullg?rd wrote:
> 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.

You missed the point. Adjacent packets would be allowed, thus you could
get huge padding with little overhead by using those. What you DID want
to make harder/disallow was using a global padding value for all codecs.
But by using a buffer with adjacent packets the application could be
able to provide huge padding without much overhead, and with a simpler
implementation than codec-specific padding adjustments. It's thus an
example which shows that avoiding a globally sufficient padding value as
you preferred would needlessly increase application complexity with no
benefit.