Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Codecs
  • Assigned To No-one
  • Operating System Sansa AMSv2
  • Severity Medium
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by sideral - 2011-03-04
Last edited by sideral - 2011-03-07

FS#11991 - MP4 playback broken

Rockbox on my ClipV2 cannot play back (at least certain) MPEG-4 audio files. When these files are encountered in the playlist, playback skips over them. In that instant I can see that the track metadata is displayed correctly in the WPS, and it is also correct in the database.

Sometimes skipping over the “broken” tracks even hangs playback totally, with a subsequent non-mp4 file stuck at 0:00, requiring a stop + resume.
Sometimes, I see a “codec error” splash for a couple of milliseconds when the files are skipped.

I have tested various revisions between SVN current and r28308 (a pre-3.7 revision), and all show the same behavior.

Here are two files I’ve encountered this problem with: (warning, large podcast tracks) 

http://www.club-autonomic.com/podcast/autonomic_podcast_layer_11.m4a
http://www.club-autonomic.com/podcast/autonomic_podcast_layer_12.m4a

These files seem to play fine in the simulator.

However, one really strange thing I’ve encountered is that the simulator pauses playback after playing back the file for a few minutes. I can then manually unpause to resume playback of the track. This may be a related or totally unrelated problem.

This mailing-list report may be related: 

http://www.rockbox.org/mail/archive/rockbox-archive-2011-03/0011.shtml
Closed by  sideral
2011-03-07 15:54
Reason for closing:  Duplicate
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Duplicate of  FS#8923  . Added a comment to that task pointing to the problematic files listed here.

thomasjfox commented on 2011-03-04 13:43

How soon does it go into pause mode? Playing fine for eleven minutes in the sim + valgrind now.

thomasjfox commented on 2011-03-04 14:27

Also plays for 30 minutes in gdb now.

You might want to try the following
- Compile the sim with “–sdl-threads” - Start the sim in gdb
- Play back the file
- Break into gdb and set a breakpoint on audio_pause: 

"break audio_pause"

- Continue program execution until it pauses

The next time it pauses, it should directy jump into
gdb and you can get a nice backtrace from the call site.

sideral commented on 2011-03-04 15:08

In two experiments, pause (after a more or less random mid-track unpause) was triggered after about 2:10 min and 2:30 min, respectively.

Trying GDB was a good idea. The backtrace shows:

#0 audio_pause () 

  at /home/sideral/priv/src/rockbox/rockbox/apps/playback.c:717

#1 0x000000000043248c in fade (fade_in=0×0, updatewps=0×0) 

  at /home/sideral/priv/src/rockbox/rockbox/apps/gui/wps.c:165

#2 0x0000000000410c9e in car_adapter_mode_processing (inserted=0×0) 

  at /home/sideral/priv/src/rockbox/rockbox/apps/misc.c:460

#3 0x0000000000410e62 in default_event_handler_ex (event=0xffffffffa0000002, 

  callback=0, parameter=0x0)
  at /home/sideral/priv/src/rockbox/rockbox/apps/misc.c:580

#4 0x0000000000410eb4 in default_event_handler (event=0xffffffffa0000002) 

  at /home/sideral/priv/src/rockbox/rockbox/apps/misc.c:679

#5 0×0000000000433340 in gui_wps_show () 

  at /home/sideral/priv/src/rockbox/rockbox/apps/gui/wps.c:1046

…

So the strange automatic pause is likely related to the simulator simulating removal of a charger, and car-adapter mode being used (although I didn’t turn on that mode). So, still strange, but probably unrelated to the (remaining) MPEG-4 audio skipping problem.

Thanks for your help so far, thomasjfox!

sideral commented on 2011-03-04 15:20

BTW, the setting was overwritten with 0xCB (!) in read_nvram_data. Deleting simdisk/.rockbox/nvram.bin fixed the simulator issue.

saratoga commented on 2011-03-04 17:00

That MP4 file is 1 hour and 30 minutes long. Our parser will run out of memory on any MP4 file exceeding about 55 minutes (IIRC) on a target with 1 MB of codec RAM. If it plays in the sim then I suspect the sim has more RAM available to the codec’s malloc buffer.

I had a sort of fix for this years ago (basically only storing some points in the mp4 file table of contents and assuming that elements would be sequential in the stream), but I was never able to convince my self that it was standards compliant and not just me taking advantage of iTunes preferred way to arrange an mp4 stream.

saratoga commented on 2011-03-04 17:01
http://www.rockbox.org/mail/archive/rockbox-archive-2011-03/0011.shtml

Thats a .aac file, basically a nonstandard raw stream. We don’t support those. Only MP4/M4A and RM are allowed for MPEG4-Audio.

Buschel commented on 2011-03-04 20:19

autonomic_podcast_layer_11.m4a requires about ~815 KB for the seek tables. The file with the largest seek table I own is ~690 KB – this file plays on iPod Video and has duration of >2:00h. So, playability will most likely depend on the seek table size. The seek table size depends on the internal structure of the m4a file, there is no easy rule to tell playability from the files duration.
I linked a related task ( FS#8923 ) that also contains a proof-of-concept and several comments on seek table reduction. First step would be to get rid of calling get_sample_offset() each frame in the decoding loop. If this is done we could reduce precision and size of the seek tables.

Edit: Imho the tasks name should be changed as there is no change in behaviour. It is just a new task with new files which describes the known issues with playability of m4a files with large seek tables.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing