Seeking fails to complete on MSE videos since landing of bug 1050652

RESOLVED FIXED in mozilla34

Status

()

RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: cajbir, Assigned: kinetik)

Tracking

(Blocks: 1 bug)

Trunk
mozilla34
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Since the landing of Bug 1050652 seeking on MSE videos no longer completes. Reverting the patch in that bug allows seeking to work again.

Steps to reproduce:

1) Make sure MSE is enabled
2) Visit URL http://cd.pn/mse/ytdemo/dash-player.html?url=http://cd.pn/mse/ytdemo/feelings2.mpd
3) When video starts playing, seek somewhere

Expected result:

4) Seek completes and playback continues

Actual result

5) Seek does not complete, but data shows as being buffered. Playback does not continue.
(Reporter)

Updated

5 years ago
Assignee: nobody → cajbir.bugzilla
Blocks: 778617
Status: NEW → ASSIGNED

Comment 1

5 years ago
aren't bug id 1040552 and this similar cases?
(Assignee)

Updated

5 years ago
Blocks: 1050652
(Assignee)

Comment 2

5 years ago
Changing http://dxr.mozilla.org/mozilla-central/source/content/media/webm/WebMReader.cpp#1014 from CLUSTER_START to BLOCK_START will give you back the old behaviour (which is also broken, no idea how it ever worked, but...)
(Assignee)

Comment 3

5 years ago
It looks like it was working before out of luck, mostly.  A block offset was passed to nestegg_seek_offset (which expects a cluster offset), and the parser would recover by skipping unexpected elements until it arrived at the next cluster.

With my changes from bug 1050652, nestegg_seek_offset is passed a cluster offset.  Unfortunately, the calculation of this offset was slightly off and resulted in the seek landing in the wrong position, from which the parser could not recover.  Fix coming up.
(Assignee)

Updated

5 years ago
Assignee: cajbir.bugzilla → kinetik
(Assignee)

Comment 4

5 years ago
Created attachment 8474958 [details] [diff] [review]
WebM cluster offset calculation accounted for size of ID incorrectly.

The old implementation copied the block offset calculation, which adjusted
the offset by 1 byte (the length of the block element ID).  The cluster
element ID is 4 bytes, so the offset must be adjusted by that amount.
Attachment #8474958 - Flags: review?(cajbir.bugzilla)
(Reporter)

Updated

5 years ago
Attachment #8474958 - Flags: review?(cajbir.bugzilla) → review+
(Assignee)

Comment 5

5 years ago
Oops, the landed got attributed to bug 1050652.

https://hg.mozilla.org/integration/mozilla-inbound/rev/59cc2ccbdd64
https://hg.mozilla.org/mozilla-central/rev/59cc2ccbdd64
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Updated

5 years ago
Target Milestone: --- → mozilla34
You need to log in before you can comment on or make changes to this bug.