Setting currentTime while video is in stop state doesn't seek video anymore

VERIFIED FIXED in mozilla1.9.3a1

Status

()

P2
normal
VERIFIED FIXED
9 years ago
9 years ago

People

(Reporter: whimboo, Assigned: cpearce)

Tracking

({regression, testcase, verified1.9.2})

Trunk
mozilla1.9.3a1
regression, testcase, verified1.9.2
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 +
in-testsuite ?

Firefox Tracking Flags

(status1.9.2 beta1-fixed)

Details

Attachments

(2 attachments)

Created attachment 402132 [details]
testcase

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b1pre) Gecko/20090922 Namoroka/3.6b1pre

There is another regression from the work on bug 501031. I noticed that too while working on the Mozmill video test (bug 489474) from Mikeal. It's another regression.

Steps:
1. Open the testcase
2. Wait around 1-2s and check that the scrubber is not positioned to 6s.
Flags: blocking1.9.2?
(Assignee)

Comment 1

9 years ago
Created attachment 402274 [details] [diff] [review]
Patch v1

Problem was with bounds check on the seek. When we seek, we calculate the timestamp at the extremities of the byte range we're seeking in by taking the granulepos' timestamp from the first and last page in the range. Unfortunately the granulepos corresponds to the end time of the last sample in that page, so if the seek target lies before that, it's assumed to be outside of the buffered range, and so the seek fails. This is particularly a problem at the start of media; if the seek target lies before the end of the first page, we'll assume it's not in the [0..end] range, and the seek fails. The fix is to assume the byte-range start time is 0 when the byte-range begins at the start of a media.

I also missed resetting some oggz internal data fields on some exit-paths on failure.
Assignee: nobody → chris
Status: NEW → ASSIGNED
Attachment #402274 - Flags: review?(chris.double)
(Assignee)

Updated

9 years ago
Duplicate of this bug: 518125
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P2

Updated

9 years ago
Attachment #402274 - Flags: review?(chris.double) → review+
(Assignee)

Comment 3

9 years ago
Pushed to m-c: http://hg.mozilla.org/mozilla-central/rev/1ecaf8a4c05a
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Whiteboard: needs-landing-192
(Assignee)

Comment 4

9 years ago
Should be easy enough to make a testcase, just need to seek to a time which is less than the end-time of the first ogg page.
Flags: in-testsuite?
(Assignee)

Comment 5

9 years ago
Pushed to 1.9.2: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/a5acfd2831e0
status1.9.2: --- → beta1-fixed
Whiteboard: needs-landing-192
Depends on: 519155
Verified fixed on trunk and 1.9.2 with builds on OS X and the given Mozmill video test:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091003 Minefield/3.7a1pre

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b1pre) Gecko/20091003 Namoroka/3.6b1pre
Status: RESOLVED → VERIFIED
Keywords: verified1.9.2
Target Milestone: --- → mozilla1.9.3a1
You need to log in before you can comment on or make changes to this bug.