From: Alex Bennee <kernel-hacker_at_bennee.com>
Date: Wed, 6 May 2009 17:09:23 +0100

2009/5/6 Magnus Holmgren <magnushol_at_gmail.com>:
> Alex Bennee wrote:
>
>> I've been working on a patch (FS#10160) to get some m4a files I own to
>> play on Rockbox. Originally it looked as though the problem was
>> Rockbox's limitation on only being able to handle files with a single
>> "mdat" atom containing data for the codec. Some I dug into the code
>> and started adding support for this case.
>
> So, you didn't go for the "proper" fix then. :) (By the way, I hope you know
> you can make the files play in Rockbox my "optimizing" them.)

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?

>> As it happens although the test file in question has two "mdat" atoms
>> the second one is of zero length (probably a placeholder). However the
>> reason the file wasn't playing is because additional information
>> needed to start playback (in the "moov" atom) is after the main "mdat"
>> atom where rockbox used to stop parsing the file.
>
> A zero length means that a (top-level) atom extends to the end of
>> the file.

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

>> I could take this as a quick win, redefine the code to only deal with
>> single mdat's but parse the whole file before starting. However there
>> is nothing in the MP4 container spec that says files can't have
>> multiple "mdat" atoms. However I'm suffering a lack of good test cases
>> to work with.
>
> If multiple mdat:s are valid, it shouldn't cause a problem, since stco
> contains file offsets, not relative to any atom start (as Vladimir Pantelic
> mentioned). Thus, just ignore it.

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.

>> In the meantime the code is in Flyspray for your comments
>> (http://www.rockbox.org/tracker/task/10160). It currently has one very
>> un-handled case in it (the FIXME) and quite a lot of enabled DEBUGFs
>> which will need to be cleaned up before final submission. However
>> comments are always welcome.
>
> I'd prefer to see the "proper" fix, so that non-streamable files don't cause
> a long buffer seek on start (which could cause a buffer refill). It would
> also solve the long file problem.

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?

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.

-- 
Alex, homepage: http://www.bennee.com/~alex/
CV: http://www.bennee.com/~alex/cv.php

Received on 2009-05-06