Last Comment Bug 667929 - OGG media buffered member is not correct when the stream is infinite
: OGG media buffered member is not correct when the stream is infinite
Status: VERIFIED FIXED
[inbound]
:
Product: Core
Classification: Components
Component: Audio/Video (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla7
Assigned To: Paul Adenot (:padenot) (in PTO until early September)
:
Mentors:
http://bde.asso.insa-lyon.fr/orgaif/t...
Depends on:
Blocks: 462960
  Show dependency treegraph
 
Reported: 2011-06-28 09:34 PDT by Paul Adenot (:padenot) (in PTO until early September)
Modified: 2011-09-01 08:35 PDT (History)
7 users (show)
Ms2ger: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch v0 (2.66 KB, patch)
2011-06-29 05:38 PDT, Paul Adenot (:padenot) (in PTO until early September)
no flags Details | Diff | Splinter Review
Patch v0. (2.02 KB, patch)
2011-06-29 05:46 PDT, Paul Adenot (:padenot) (in PTO until early September)
cpearce: review+
Details | Diff | Splinter Review

Description Paul Adenot (:padenot) (in PTO until early September) 2011-06-28 09:34:23 PDT
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 PTO until Sep 5 NZ time; Chris Pearce (:cpearce) 2011-06-28 18:04:38 PDT
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) (in PTO until early September) 2011-06-29 05:38:24 PDT
Created attachment 542780 [details] [diff] [review]
Patch v0

Chris, I've implemented what you said above, it solves indeed the issue.
Comment 3 Paul Adenot (:padenot) (in PTO until early September) 2011-06-29 05:46:03 PDT
Created attachment 542782 [details] [diff] [review]
Patch v0.

Sorry, I attached the wrong file.
Comment 5 Marco Bonardo [::mak] 2011-07-02 01:46:34 PDT
http://hg.mozilla.org/mozilla-central/rev/6d19d5dccf0c
Comment 6 Vlad [QA] 2011-08-31 05:12:28 PDT
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 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-08-31 10:36:22 PDT
(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] 2011-09-01 05:29:03 PDT
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 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-09-01 08:35:16 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.