- Status Unconfirmed
- Percent Complete
- Task Type Bugs
- Category Codecs
- Assigned To No-one
- Operating System All players
- Severity Medium
- Priority Very Low
- Reported Version Daily build (which?)
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#13159 - rockbox hangs on certain m4a files
I primarily use my unit for audio books while driving, but the latest build (as I write this) won't play one of the files properly. It tries to start, stuck at 0:00. Trying to seek hangs the player altogether, requiring a hard restart.
I've recreated this problem on a flaky Clip+ and an AGPTek Rocker.
The 'file' tool identifies it as: ISO Media, MP4 v2 [ISO 14496-14]
Here's what mplayer has to say (while playing it back properly):
[lavf] stream 0: audio (aac), -aid 0, -alang eng
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
libavcodec version 58.18.100 (external)
[aac @ 0x7f93de0eeb00]Multiple frames in a packet.
AUDIO: 22050 Hz, 1 ch, floatle, 64.0 kbit/9.07% (ratio: 7999→88200)
Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio))
AO: [pulse] 22050Hz 1ch floatle (4 bytes per sample)
Video: no video
Starting playback… [aac @ 0x7f93de0eeb00]channel element 2.0 is not allocated
(It's a large file (>400MB) that has proper chapter markers. I can provide it upon request. In the mean time I'm converting it to mp3..)
After running the file through the 'MP4Box' tool's hinting mode, rockbox is able to play the file back without hanging.
I'm not sure if there's a sane way to detect this problem though..
I spoke too soon. The file still refuses to play, instead skipping to the next file, or if there are none, hangs indefinitely.
MP4 parsing is very memory intensive, so given a file that long it should just recognize that it'd need tens of MBs to parse and skip it. It shouldn't crash though so that is a bug in the parser.
Rockbox skips it cleanly iff there are other files in the directory. Otherwise it just stays on that file, stuck at 0:00, and allows you to attempt to seek within the file, which in turn hangs the player.
Does this bug extend to any broken audio file in a directory by itself?