Rockbox mail archiveSubject: Re: Bring me your broken MP4s, your twitchy AACs and other non-working m4a's
Re: Bring me your broken MP4s, your twitchy AACs and other non-working m4a's
From: Vladimir Pantelic <pan_at_nt.tu-darmstadt.de>
Date: Wed, 06 May 2009 09:44:22 +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.
> 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.
moov after mdat is not uncommon at all. Some MP4 writer SW do that so
they can 1st write all the data, then add the "header" at the end. Of
course that messes up streaming such files....
> 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.
Yes, in theory you could have each "sample" inside it's own mdat if you
> So do you have any mp4, m4a or other mp4-alike file that won't play
> with the rockbox libm4a codec? If so could you send me a copy?
> Even better would be if anyone could tell me the command line foo to
> generate such a multi-chucked mp4 file so I can make my own test
there is the ffmpeg/mplayer samples database, maybe they have something.
Received on 2009-05-06