Closed Bug 476813 Opened 11 years ago Closed 11 years ago

progress events shouldn't be fired while the network is stalled

Categories

(Core :: Audio/Video, defect, P2)

x86
macOS
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: Dolske, Assigned: kinetik)

References

()

Details

(Keywords: fixed1.9.1)

Attachments

(1 file)

No description provided.
Flags: blocking1.9.1?
*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.
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
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+
See bug 479863 comment 6. Matthew has a fix.
Assignee: chris.double → nobody
Assignee: nobody → kinetik
Attached patch patch v0Splinter Review
Fix.  Tests pass.
Attachment #364860 - Flags: superreview?(roc)
Attachment #364860 - Flags: review?(chris.double)
Attachment #364860 - Flags: superreview?(roc) → superreview+
Attachment #364860 - Flags: review?(chris.double) → review+
Whiteboard: [needs landing]
Pushed: http://hg.mozilla.org/mozilla-central/rev/09df911a0ca2
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing] → [baking for 1.9.1]
You need to log in before you can comment on or make changes to this bug.