Closed Bug 1202475 Opened 9 years ago Closed 9 years ago

Seeking broken with the new MP3 demuxer for some MP3 files

Categories

(Core :: Audio/Video: Playback, defect)

Product:
Core
Component:
Audio/Video: Playback
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1194080
Tracking Flags:
Tracking Status
firefox43 --- affected

People

(Reporter: JanH, Unassigned)

References

(
URL
)

Details

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: 9 years ago
Resolution: --- → DUPLICATE
Assignee: jh+bugzilla → nobody
Actually, the source code comment was outdated. Implementing GetBuffered is bug 1194080.
You need to log in before you can comment on or make changes to this bug.