Alex Bennee wrote:

> Some of what you mentioned started to make more sense as I dug through
> the code. By proper fix do you mean dealing with multiple sets of seek
> data?

I mean building a (possibly reduced) seek table while/right after
reading the metadata, before the file is buffered (and then only the
mdats would need to be buffered, really). It is a bigger change,
involving metadata.c, playback.c and possibly buffering.c too. It would
mean less code duplication, as much of libm4a in the codec could be removed.

> Sorry, should have been clearer. Zero length of data (the mdat length
> was 8 which is the size of the header).

I see. Still, should be no seek points in it, so it should be safe to
ignore...

> The message I seem to be getting here is it doesn't really matter how
> many mdat's we have as long as the codec can skip between them as it plays.

Yes, the chunks currently need to come "in order" though; the codec can
already skip ahead if there are gaps between chunks. If the gap is due
to a new mdat or something else shouldn't matter.

> I shall continue to grok as I go through the code. So if I understand
> correctly we should be able to start the codec at the start of the
> first mdat atom and pick up the later "moov" for seeking when we get there?

Not really. The codec needs metadata stuff in order to decode, and
seeking information is needed to resume playback.

> Does the seeking really kill the performance?
>
> My naivety assumed that using "stream_skip(qtmovie->stream, len);"
> would not actually read the intervening bytes into memory.

The problem is that the codec typically works on already buffered data.
If the codec then seeks to a part of the file that isn't buffered, it
triggers a full buffer refill, which is very expensive. (And if it then
seeks back to the start of the same file, it would trigger a rebuffer
again). So, big seeks in the codec should be avoided, if possible.

   Magnus
Received on 2009-05-06