Rockbox

The stop at the mdat atom is deliberate, since the decoder currently can’t handle files with metadata after the mdat. In order to play a file, the codec needs various information (decoding parameters, some tables describing the file layout). This metadata can be fairly large (e.g., around 40 kB for a 4 minute song), so it can’t be stuffed into the mp3entry struct. Also, a decoder shouldn’t start playback by seeking back and forth, potentially causing a rebuffer.

To really fix this, the metadata reader should first extract (and somehow buffer) the information needed, then let the playback code buffer the rest of the file.

I saw the comment as I was tweaking this bit. I’d like to fix the codec as well as there are obviously well formed files rockbox can’t currently play. I’m just getting my head round how the playback code works. Currently the playback thread is paused very soon after playback is resumed via a STOP message. Is this the codec detecting an mdat it can’t handle?

How much information does the codec need from the metadata. I assume anything not already covered by mp3data (bitrate and length) can be covered by giving a list of mdat pointers and sizes describing the blocks of media data that make up the file?

That stop is likely due to the codec failing or returning immediately, yes.

What the codec needs is this:

1) The data to pass to NeAACDecInit2 (in apps/codecs/aac.c; read from the esds atom).

2) Seek information (from the atoms stts, stsz, stsc and stco). Keeping the size of each sample (or frame) isn’t necessary, as far as I know, so it should be enough to keep a number of seek point, as you suggest. For each seek point, the number of frames is needed (between this point and the next), as well as a time offset (as a sound sample count, I think). That should be enough to be able to decode a file, and seek in it based on file offset or time.

When creating a seek table, remember that there can be gaps between chunks, so a seek point can’t always “begin” in one chunk and “end” in the next.

This is the current WIP patch. It seems the problem with my MP4
one of the mov data being after the mdat data. The second mdat
my test track is a phantom (0 length) as can be seen from this log:

audio_current_track: no id3 data

res = 0

read_mp4_container(16, 0×991680, 3933035)

un-handled case: type=0x17809
un-handled case: type=0x38c
second MP4_mdat (0), this file may not play

read_mp4_container(16, 0×991680, 96294)

un-handled case: type=0x64

read_mp4_container(16, 0×991680, 56705)

un-handled case: type=0x54
un-handled case: type=0x1c

read_mp4_container(16, 0×991680, 56569)

un-handled case: type=0x18

read_mp4_container(16, 0×991680, 56471)

un-handled case: type=0x8
un-handled case: type=0x1c

read_mp4_container(16, 0×991680,
0×991680, 983)

un-handled case: type=0x2c30
un-handled case: type=0x9d54
un-handled case: type=0xec0

read_mp4_container(16, 0×991680, 39423)

un-handled case: type=0x22

MP4 bitrate 127, frequency 44100 Hz, length 233732
Looking for album art for /03 - This House Is Not for
elap=0, offset=0,
audio_finish_load_track
qtmovie_read: Found a chunk ftyp,
Found a chunk free,
Found a chunk free,
Found a chunk mdat,
off=97229,
Found a chunk mdat,
Found a chunk moov,

maxBitrate=136288,
j=3837254 - Skipping 6

entering main decoding
No Data.

This presents me with a number of possibilities. One is simply to
MP4 decoder handle such simple cases or find some more MP4s
multiple mdat assignments.

commit
Alex Bennee
Wed May 6 07:52:44 2009 +0100

  Wind stream position back to first mdat atom before starting playback.
  
  This also leaves a FIXME for dealing with seeking in libm4a which needs fixing

apps/codecs/aac.c | 6 +++++- apps/codecs/libm4a/demux.c | 3 ++- apps/codecs/libm4a/m4a.c | 5 +++– 3 files changed, 10 insertions(+), 4 deletions(-)

commit
Alex Bennee
Wed May 6 07:51:17 2009 +0100

  Commentry for playback.c

apps/playback.c | 29 +++++++++++++++++———— 1 files changed, 17 insertions(+), 12 deletions(-)

commit
Alex Bennee
Tue May 5 18:37:35 2009 +0100

  Parse MP4 files for multiple mdat chunks

apps/codecs/libm4a/demux.c | 97 ++++++++++++++++++++++++++++++++———– apps/codecs/libm4a/m4a.h | 21 +++++++– 2 files changed, 88 insertions(+), 30 deletions(-)

commit
Alex Bennee
Tue May 5 18:35:29 2009 +0100

  Bit more info in DEBUGF

apps/metadata/mp4.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)

commit
Alex Bennee
Wed Apr 22 13:17:00 2009 +0100

  Clean up the MP4 metadata parsing.
  
  The parser used to finish as soon as it saw an "mdat" atom and has set
  the filesize. There is nothing that says all you metadata will have
  been seen at this point. I've tweaked the parser to ensure it goes all
  the way through the file scanning for metadata.
  
  If tested this with an m4a of iTunes which mp4info parsed OK:
  
  09:44 alex@danny/x86_64 [simdisk] >mp4info 03\ -\ This\ House\ Is\ Not\ for\ Sale.m4a
  mp4info version 1.5.0.1
  03 - This House Is Not for Sale.m4a:
  Track   Type    Info
  1       audio   MPEG-4 AAC LC, 233.732 secs, 128 kbps, 44100 Hz
   Metadata Name: This House Is Not for Sale
   Metadata Artist: Ryan Adams
   Metadata Year: 2003
   Metadata Album: Love Is Hell Part 1
   Metadata track: 3 of 10
   Metadata Disk: 1 of 1
   Metadata Genre: Alt.Country
   Metadata Cover Art pieces: 1
  
  However the file still won't play on Rockbox, I assume because the
  codec that does the actual playing cannot deal with the unusual
  structure of the m4a. Interestingly it plays the other songs of the
  album fine!

apps/metadata/mp4.c | 116 +++++++++++++++++++++++++++++++++++—————- 1 files changed, 80 insertions(+), 36 deletions(-)

   current.patch (13.8 KiB)

Please consider  FS#10832 

This bug can now be closed as FS 10832 supersedes it.