OGG media buffered member is not correct when the stream is infinite

VERIFIED FIXED in mozilla7

Status

()

Core
Audio/Video
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: padenot, Assigned: padenot)

Tracking

Trunk
mozilla7
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [inbound], URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

6 years ago
It appears that the buffered member is quite buggy when retrieved from unfinite ogg stream.

Step to reproduce : 
0 - Open the page and play the media
1 - Open the js console
2 - Click the "buffered" button, and see that the range reported is not correct (start greater than end, and values not correct).

Expected : normalized time range, and correct values (i.e. for that stream [0, total time buffered]).

This looks fine using a webm infinite stream (see : http://www.flumotion.com/demosite/webm/).
(Assignee)

Updated

6 years ago
Assignee: nobody → paul
Looks like in nsOggReader::GetBuffered() in the live case we're setting startTime to aStartTime when startOffset==0, but ranges are supposed to be normalized to be [0...duration] (until we implement HTMLMediaElement.initialTime that is).

Best to not subtract aStartTime from startTime inside the loop (when we call ns*State::Time()) and subtract aStartTime from startTime when we call aBuffered->Add(...) at the end, like we do for endTime. Better change the assertions to assert startTime>=aStartTime as well.
(Assignee)

Comment 2

6 years ago
Created attachment 542780 [details] [diff] [review]
Patch v0

Chris, I've implemented what you said above, it solves indeed the issue.
Attachment #542780 - Flags: review?(chris)
(Assignee)

Comment 3

6 years ago
Created attachment 542782 [details] [diff] [review]
Patch v0.

Sorry, I attached the wrong file.
Attachment #542780 - Attachment is obsolete: true
Attachment #542782 - Flags: review?(chris)
Attachment #542780 - Flags: review?(chris)
Attachment #542782 - Flags: review?(chris) → review+
(Assignee)

Updated

6 years ago
Keywords: checkin-needed
http://hg.mozilla.org/integration/mozilla-inbound/rev/6d19d5dccf0c
Status: NEW → ASSIGNED
Flags: in-testsuite?
Keywords: checkin-needed
Whiteboard: [inbound]
Target Milestone: --- → mozilla7
Version: unspecified → Trunk
http://hg.mozilla.org/mozilla-central/rev/6d19d5dccf0c
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 6

6 years ago
Setting resolution to Verified Fixed on  Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0 beta 3
Status: RESOLVED → VERIFIED
(In reply to Vlad [QA] from comment #6)
> Setting resolution to Verified Fixed on  Mozilla/5.0 (Windows NT 6.1;
> rv:7.0) Gecko/20100101 Firefox/7.0 beta 3

Not sure how you verified this Vlad. It has landed on mozilla-central (Firefox 9) and not mozilla-beta (Firefox 7). Please re-verify this on Firefox 9.
Status: VERIFIED → RESOLVED
Last Resolved: 6 years ago6 years ago

Comment 8

6 years ago
We are verifying bugs that have target milestone: mozilla 7, so this bug enters that category. If the milestone is mozilla 7, then I have to make sure that the bug is fixed in Firefox 7.
Is the milestone set wrong in this case?

I have tried this on Mozilla/5.0 (Windows NT 6.1; rv:9.0a1) Gecko/20110830 Firefox/9.0a1 and the behavior is the same as in Fx 7 beta 3.
Vlad, I believe that patches landing on mozilla-central only affect Nightly builds (which was Firefox 7 at the time of check-in -- July 2nd). Forgive my previous comment.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.