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
