Last Comment Bug 655792 - Final media progress event fires before media.buffered TimeRanges are full to 100%
: Final media progress event fires before media.buffered TimeRanges are full to...
Status: RESOLVED FIXED
[inbound]
:
Product: Core
Classification: Components
Component: Audio/Video (show other bugs)
: unspecified
: x86_64 Windows 7
: -- normal with 1 vote (vote)
: mozilla8
Assigned To: Paul Adenot (:padenot) (in PTO until early September)
:
Mentors:
http://www.jplayer.org/
: 599205 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-09 12:26 PDT by Mark Panaghiston
Modified: 2011-07-25 10:36 PDT (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch v0 - Send progress when the download is supended. (915 bytes, patch)
2011-07-20 09:58 PDT, Paul Adenot (:padenot) (in PTO until early September)
no flags Details | Diff | Splinter Review
Patch v1 - adressed Kinetik remarks. (988 bytes, patch)
2011-07-21 06:07 PDT, Paul Adenot (:padenot) (in PTO until early September)
kinetik: review+
Details | Diff | Splinter Review

Description Mark Panaghiston 2011-05-09 12:26:12 PDT
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

When attaching a progress event handler that sums the media.buffered TimeRange information, the final progress event occurs before the TimeRange raches the final state of being length 1 with the media.buffered.start(0) = 0 and media.buffered.end(0) = media.duration.

The behaviour varies and appears to depend on how lucky you are as to whether it reaches 100% or not.

The URL that demonstrates the problem, contains a circle player with buffered and currentTime feedback in a ring. It works. The final progress event does not, which is why the white ring does not always fill completely.

Chrome, Safari, iOS Mobile Safari work fine. Opera does not give buffered info.

Reproducible: Always

Steps to Reproduce:
1. Add a media element to a page
2. Attach a progress event handler to the media element that logs the TimeRanges information and the duration.
3. Notice that the final progress event logs does not have the buffered TimeRanges object equal to the duration.

Actual Results:  
Varies but, appears that the last 20% of the file I test with sometimes does not register in the final progress even. Depends on bandwidth and size of the file.

Expected Results:  
The last progress event should occur after the buffered TimeRange object equals the duration.
Comment 1 Matthew Gregan [:kinetik] 2011-05-09 14:04:24 PDT
*** Bug 599205 has been marked as a duplicate of this bug. ***
Comment 2 Paul Adenot (:padenot) (in PTO until early September) 2011-07-20 09:58:30 PDT
Created attachment 547129 [details] [diff] [review]
Patch v0 - Send progress when the download is supended.

After a quick gdb session, it appeared that |nsHTMLMediaElement::ResourceLoaded| which sends the "progress" event, is called only when the end of the media is buffered, thus, is the media stops downloading from natural causes (i.e. we reached a range that is already available), "progress" was not fired.

This patch fixes this behavior by sending a "progress" event whenever the download stops, ensuring a correct refresh of the controls, which are relying on this event.

Consequently, this patch fixes bug 599205 too.
Comment 3 Matthew Gregan [:kinetik] 2011-07-20 18:53:01 PDT
This seems reasonable, but you need to fire progress before suspend, otherwise it looks as if the download suspended and immediately resumed.
Comment 4 Paul Adenot (:padenot) (in PTO until early September) 2011-07-21 06:07:45 PDT
Created attachment 547382 [details] [diff] [review]
Patch v1 - adressed Kinetik remarks.
Comment 5 Marco Bonardo [::mak] 2011-07-25 06:15:47 PDT
http://hg.mozilla.org/mozilla-central/rev/3252ee5456ff
Comment 6 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-07-25 09:55:24 PDT
Is there a minimized test case which I can use to verify this fix?
Comment 7 Paul Adenot (:padenot) (in PTO until early September) 2011-07-25 10:36:07 PDT
http://paul.cx/test/progress.html

Seek almost at the end of the audio (like 9/10), and then seek at the beginning (like 2/10).

The buffering bar should fill completely, and the progress member (showed in the page for convenience) should consist in only one range.

Without this patch, the buffered range consists in only one range, and the buffered zone doesn't fill the seek bar completely, by an amount which depends on the media downloaded and the bandwidth.

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