Closed
Bug 476813
Opened 16 years ago
Closed 16 years ago
progress events shouldn't be fired while the network is stalled
Categories
(Core :: Audio/Video, defect, P2)
Tracking
()
RESOLVED
FIXED
People
(Reporter: Dolske, Assigned: kinetik)
References
()
Details
(Keywords: fixed1.9.1)
Attachments
(1 file)
(deleted),
patch
|
cajbir
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
No description provided.
Flags: blocking1.9.1?
Reporter | ||
Comment 1•16 years ago
|
||
*sigh* Bugzilla fail.
The video spec says that "progress" and "stalled" events should be fired as such:
Every 350ms (±200ms) or for every byte received, whichever is least frequent,
queue a task to fire a progress event called progress at the element.
If at any point the user agent has received no data for more than about three
seconds, then queue a task to fire a progress event called stalled at the
element.
However, it appears we're just sending progress events on a fixed timer interval. When a "stalled" event does fire, it's fired in the middle of a bunch of progress events with the same event.loaded values.
EG:
...video loading normally...
videoctl: +++ load, 921600 of 11228656
videoctl: Got progress media event
videoctl: +++ load, 936080 of 11228656
videoctl: Got progress media event
videoctl: +++ load, 1024000 of 11228656
videoctl: Got progress media event
videoctl: +++ load, 1024000 of 11228656
videoctl: Got progress media event
videoctl: +++ load, 1024000 of 11228656
videoctl: Got progress media event
...a few more bogus progress events @ 1024000...
videoctl: Got stalled media event
...bogus progress events keep rolling in...
videoctl: Got progress media event
videoctl: +++ load, 1024000 of 11228656
videoctl: Got progress media event
videoctl: +++ load, 1024000 of 11228656
videoctl: Got progress media event
I wrote a little PHP script to send Ogg media with a forced pause during transmission:
http://dolske.net/mozilla/tests/video/slowsend.php?rate=100&stallat=1000000&stallfor=15
This sends data at ~100kbps. Once it's sent about 1MB it will pause for 15 seconds and then resume.
I also noted in bug 476035 that we sometimes fire bogus progress events like this while seeking. Maybe bug 455654 will also help here? It's not clear to me from looking at the patch.
Blocks: 470983
Comment 2•16 years ago
|
||
That's an error on my part reading the spec. I missed the 'least frequent' bit.
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Reporter | ||
Comment 3•16 years ago
|
||
Same behavior with bug 455654 fixed.
Should be a relatively easy fix I guess
Assignee: nobody → chris.double
I think this can just be 'wanted'.
Flags: blocking1.9.1+ → wanted1.9.1+
Comment 6•16 years ago
|
||
See bug 479863 comment 6. Matthew has a fix.
Assignee: chris.double → nobody
Assignee | ||
Updated•16 years ago
|
Assignee: nobody → kinetik
Assignee | ||
Comment 7•16 years ago
|
||
Fix. Tests pass.
Attachment #364860 -
Flags: superreview?(roc)
Attachment #364860 -
Flags: review?(chris.double)
Attachment #364860 -
Flags: superreview?(roc) → superreview+
Updated•16 years ago
|
Attachment #364860 -
Flags: review?(chris.double) → review+
Assignee | ||
Updated•16 years ago
|
Whiteboard: [needs landing]
Comment 8•16 years ago
|
||
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing] → [baking for 1.9.1]
Keywords: fixed1.9.1
Whiteboard: [baking for 1.9.1]
You need to log in
before you can comment on or make changes to this bug.
Description
•