Closed Bug 1202475 Opened 4 years ago Closed 4 years ago
Seeking broken with the new MP3 demuxer for some MP3 files
After opening an MP3 file that was broken before bug 1197985 landed, playback works, but seeking is broken - you can click/tap on the time line and the play indicator moves, but after releasing the mouse/finger, it jumps back to the original position, with playback continuing unaffected (except possibly for a brief stutter/gap). This affects only files loaded from the network - when loading the same file from the local file system (file://) seeking works. Files that were working even before bug 1197985 landed seem to be completely unaffected.
After a bit of testing, it seems that the handling of ID3v2 headers isn't to blame: When uploaded to my own webspace, seeking works fine for affected files. Likewise, seeking will be broken on a file without any ID3v2 headers at all when uploaded to e.g. the Infinite Jukebox (see e.g. http://static.echonest.com/audio2/1441654823902/12%20o%20clock.mp3).
No longer depends on: 1197985
It turns out that this affects MP3 files coming from servers which don't support range requests - in that case, we want/need to use the buffer for seeking (see https://dxr.mozilla.org/mozilla-central/rev/5fe9ed3edd6811a662d40d05e37b0d66e9520d82/dom/media/MediaDecoder.cpp#1132), however the new MP3 demuxer doesn't yet support GetBuffered(), hence seeking fails.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1169485
Actually, the source code comment was outdated. Implementing GetBuffered is bug 1194080.
Duplicate of bug: 1194080
You need to log in before you can comment on or make changes to this bug.