[FFmpeg-devel] Audio decoding in api-example.c broken?

[Michael Niedermayer]

On Mon, May 24, 2010 at 05:19:40PM +0300, Martin Storsj? wrote:
> On Mon, 24 May 2010, Michael Niedermayer wrote:
> 
> > On Mon, May 24, 2010 at 03:46:08PM +0300, Martin Storsj? wrote:
> > > On Mon, 24 May 2010, Michael Niedermayer wrote:
> > > 
> > > > On Mon, May 24, 2010 at 02:27:42PM +0300, Martin Storsj? wrote:
> > > > > On Mon, 24 May 2010, Michael Niedermayer wrote:
> > > > > 
> > > > > > and the refill must be implemented so as to minimize memmove/cpy
> > > > > > moving is only needed once we get close to the end of the buffer ...
> > > > > 
> > > > > How do we know that we're "close to the end of the buffer"? 
> > > > 
> > > > How do you know your buffer is large enough to begin with?
> > > 
> > > I don't, I just hope it is.
> > > 
> > > > > Something like 
> > > > > if (avpkt.size < 2*len)?
> > > > 
> > > > if len was the last packets len then no this is not good
> > > > sizes can surely vary by more
> > > 
> > > That's why I always refilled the buffer in the previous suggestion.
> > 
> > its quite inefficient if you have a 4096 buffer and 40 byte packets
> > and as this is example code such hacks are obviously something we cant
> > do
> > 
> > you could allocate a 100k buffer and keep filling it so there is at least
> > 4k there, and once you hit the end memmove the <=4k left to the begin
> > this still is a hack without us knowing for sure 4k is enough in the
> > first place but its better than what we have now
> 
> In this particular case, the data it decodes is just 41 KB so that part of 
> the code would never be used. But if you'd accept such a version of the 
> example anyway, I can try to rewrite it in that way.

uhm, then make it 20k istead of 100k otherise its dead code which tends to
rot

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100524/af6b2dcd/attachment.pgp>