summaryrefslogtreecommitdiff
path: root/apps/gui
diff options
context:
space:
mode:
authorAidan MacDonald <amachronic@protonmail.com>2022-04-18 14:21:12 +0100
committerAidan MacDonald <amachronic@protonmail.com>2022-05-02 12:16:21 -0400
commit4dd3c2b33ec3d181f54cc1bcf5b596401a8cfcbb (patch)
treefdccdcaed0d0dc3faea515daad410b5f3b064f02 /apps/gui
parentb79eefc8583536da9faa87b50d82eaef8a3e0dde (diff)
downloadrockbox-4dd3c2b33ec3d181f54cc1bcf5b596401a8cfcbb.tar.gz
rockbox-4dd3c2b33ec3d181f54cc1bcf5b596401a8cfcbb.zip
codecs: m4a: improve seek accuracy
Seeking doesn't work well in M4A files with very few chunks due to the seek method used (chunk based using the info in the 'stco' atom). According to libm4a/demux.c the expected seek resolution using this method is 1/4 to 1/2 seconds. However, ffmpeg generates files with a 1 megabyte chunk size, so the resolution is much worse than expected on some files: around 30-40 seconds at 256kbps. There was a bug with the seek position reported back to Rockbox: the codec pretended it could seek exactly to the requested sample, but it would only seek to the start of a chunk. This could leave the UI in a confusing state because the real playback position was different from what the elapsed time showed. Fix this by recalculating the reported sample position using the chunk start. To fix the low seek accuracy, use the table in the 'stsz' atom to skip individual packets within a chunk. This is very accurate, but it takes a lot of RAM to allocate the table. Currently the table is not allowed to use more than half of the codec RAM, which should suffice for short files on most targets. On files where the table is too large the codec will fall back to the less accurate chunk-based seek method. Change-Id: Ide38ea846c1cdd69691e9b1e1cd87eb0fa11cf78
Diffstat (limited to 'apps/gui')
0 files changed, 0 insertions, 0 deletions