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

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Paul Adenot (:padenot)]

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/).

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

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.

Comment 2

[Paul Adenot (:padenot)]

Attachment: Patch v0

Chris, I've implemented what you said above, it solves indeed the issue.

Comment 3

[Paul Adenot (:padenot)]

Attachment: Patch v0.

Sorry, I attached the wrong file.

Comment 4

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/6d19d5dccf0c

Comment 5

[Marco Bonardo [:mak]]

http://hg.mozilla.org/mozilla-central/rev/6d19d5dccf0c

Comment 6

[Vlad [QA]]

Setting resolution to Verified Fixed on  Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0 beta 3

Comment 7

[u279076]

(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.

Comment 8

[Vlad [QA]]

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.

Comment 9

[u279076]

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.