2009/7/19 Bryan Jacobs <no_at_landwarsin.asia>:
> On Sun, 19 Jul 2009 01:30:09 +0200
> Rafaël Carré <rafael.carre_at_gmail.com> wrote:
>> The down side you mentioned (codecs relying on reading small amounts
>> of data repeatedly from the buffer) doesn't make sense to me, I would
>> think a chunk would be de-allocated as soon as another chunk has been
>> read for the same file.
>>
>> Here I suppose codecs never seek backwards in the bitstream, but I may
>> be wrong since my knowledge in codecs bitstreams is very close to 0.
>
> Some codecs are almost random access.  The issue with small reads is
> that currently codecs are guaranteed that there will be
> BUFFERING_DEFAULT_FILECHUNK bytes available after they advance the
> buffer.  So if they read small amounts from two files in alternation,
> you get really terrible performance because every bufadvance requires a
> memcpy.  If we relax this requirement there's no issue - you just free
> the chunks when you're done with them.
>

When I was investigating problems with odd .m4a files (FS#10160) I found I had
to seek all through most of the file to read enough of the metadata to
get playback
working. The patch as is won't get accepted because that behavior is potentially
poor from a buffer/file performance point of view.

Unfortunately I haven't had a chance to work on a clean solution that
picks up new
metadata as the stream decodes. This is mostly because of the learning curve in
understanding the metadata and codec code.

Thanks for the design document, it makes interesting reading.

-- 
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk