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/).
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.
Created attachment 542780 [details] [diff] [review] Patch v0 Chris, I've implemented what you said above, it solves indeed the issue.
Created attachment 542782 [details] [diff] [review] Patch v0. Sorry, I attached the wrong file.
Setting resolution to Verified Fixed on Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0 beta 3
(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.
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.