From: Magnus Holmgren <magnushol_at_gmail.com>
Date: Wed, 06 May 2009 17:49:38 +0200

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
> Rpckbox'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.)

> 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.

> 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.

> 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.

   Magnus
Received on 2009-05-06