Video progress slider jitters on indefinite length streams

VERIFIED FIXED in mozilla2.0b10

Status

()

VERIFIED FIXED
10 years ago
8 years ago

People

(Reporter: beta, Assigned: fryn)

Tracking

({regression})

unspecified
mozilla2.0b10
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: [softblocker])

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b4pre) Gecko/20090328 Shiretoko/3.5b4pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b4pre) Gecko/20090328 Shiretoko/3.5b4pre

Live streaming video doesn’t fit the progress bar metaphor that the current <video> controls use.

Reproducible: Always

Steps to Reproduce:
1. Visit http://air.mozilla.com/europe/
2. Wait for video to load
3. Hover mouse over video to see controls
Actual Results:  
The video load progress bar can be seen to wobble between 99% & 100%

Expected Results:  
The load progress shouldn’t wobble.
Suggested fix would be to change it be a barbers pole (moving stripes), or similar, to indicate streaming.
(Reporter)

Updated

10 years ago
Component: General → Video/Audio
Product: Firefox → Core
QA Contact: general → video.audio
What's wobbling? The oval playback position, or the progress bar underneath? Neither should be happening, and I'm not sure how either could happen. (The thumb could juggle if the video is firing skewed durationchange events, but I haven't seen that happen). Unfortunately AirMozilla is down right now, so I can't test.
(Reporter)

Comment 2

10 years ago
The oval playback knob-thing jitters left to right.
Ok, I see this with my trunk debug build. Not sure what's going on. Since it's a stream, we're setting scrubber.value and scrubber.max to the same value.

Might be a rounding issue somewhere [eg, something does round(max) but floor(value)], or some integer issues ala the weirdness in bug 473103.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: x86 → All
Summary: <video> progress bar should change behaviour for streaming video → scrubber thumb jitters during Air Mozilla stream

Updated

10 years ago
Blocks: 470629
Component: Video/Audio → Video/Audio Controls
Product: Core → Toolkit
QA Contact: video.audio → video.audio
Duplicate of this bug: 557276
This seems to have recently regressed badly; instead of a 1-2 pixel jitter is jumps around wildly at the beginning of a stream, with smaller gyrations the longer the stream plays.

Blizzard nailed the cause: looks like we now send durationchange events as the indeterminate-length stream plays, basically 1:1 with timeupdate events. The videocontrols throttle the processing of timeupdate (but not durationchange), so the UI display was displaying oddly (ie, larger duration moved the thumb backwards because the scale changed).

Not sure if the original 1-2 pixel bounce was the same issue or if it's still lurking.

Fix should be to throttle both durationchange *and* timeupdate. I guess the need for tracking maxCurrentTimeSeen probably goes away too.
Summary: scrubber thumb jitters during Air Mozilla stream → Video progress slider jitters on indefinite length streams

Updated

8 years ago
Duplicate of this bug: 597714

Updated

8 years ago
Duplicate of this bug: 599929

Comment 8

8 years ago
Can we just pin the scrubber thumb to the beginning or the end of the widget for indeterminate duration videos? The current situation is ugly and if it's possible to just pin or remove the thumb, that should make things a lot better without any real loss of user functionality.

Updated

8 years ago
Duplicate of this bug: 557077

Comment 10

8 years ago
Created attachment 484637 [details]
testcase

This is a very simple testcase.

Just download the file (or any other oga file): 
http://audioscene.org/scene-files/humph/slideshow/Revolve.ogg

And select it in the testcase file.

Comment 11

8 years ago
I'm seeing that with non-live streams, e.g. case 5 on http://smormedia.gavagai.nl/geckovideo/ , which is:
<video controls="true" src="http://smormedia.gavagai.nl/2010/10/TiranaTraffic.ogv" type="video/ogv"/>

https://developer.mozilla.org/en/Configuring_servers_for_Ogg_media says the server should not using gzip encoding, but this one does. This also means the server doesn't send the Content-Length header, which means Gecko cannot estimate the video length nor skip. This is why this non-live stream also exhibits the same problem as live streams.
Duplicate of this bug: 616993

Comment 13

8 years ago
Created attachment 495811 [details]
screencast of the issue

Still live and well with firefox-4.0-0.5b7.fc15.x86_64 and http://audio-ogg.ibiblio.org:8000/wcpe.ogg

Comment 14

8 years ago
It's actually very funny that the 2 timers do not always show the same, the left is in fact a little backward in time.
(In reply to comment #14)
> It's actually very funny that the 2 timers do not always show the same, the
> left is in fact a little backward in time.

Well, yes, that's the bug here.  The current time is increasing as time passes, the total time appears to be increasing in integer increments.

Comment 16

8 years ago
> Well, yes, that's the bug here.  The current time is increasing as time passes,
> the total time appears to be increasing in integer increments.

What I actually meant was that the "total time" and the "now time" is not always the same. Sometime the “total time” shows 1:32, and the “now time” shows 1:31.

So when someone says that the “total time” is increasing, I think that it’s relevant to tell that the “total time” is a little bit forward compared to the “now time”.


Do you know witch scenario where it is necessary that the “total time” change, since the program allows it.
(In reply to comment #16)
> Do you know witch scenario where it is necessary that the “total time” change,
> since the program allows it.

When the length of the video is not known ahead of time (e.g. a live stream).
blocking2.0: --- → final+
Assignee: nobody → fryn
Keywords: regression
In order to fix this, do we need to expose a custom moz attribute on the media element which reports whether we're on an infinite length stream?

Comment 19

8 years ago
In fact, in the case of a live stream, the total duration is unknown (obviously), so its value should be "Infinity", as in http://www.w3.org/TR/html5/video.html#dom-media-duration.

Instead, with live streams, we have "duration equals currentTime", and that's not supposed to be this way. Chrome and Opera manage to get those information right, but Firefox doesn't.

So, if this issue is solved, no more problem about bouncing slider.

An example : http://www.flumotion.com/demosite/webm/ Compare with FF and Chrome, you'll see the difference (and if you want more, just check the duration and currentTime in DOM or with Javascript)
Ah yes, we're in violation of the spec, we should report the duration as +Inf when the stream is known to be unbounded:

"The duration attribute must return the time of the end of the media resource, in seconds, on the media timeline. If no media data is available, then the attributes must return the Not-a-Number (NaN) value. If the media resource is known to be unbounded (e.g. a streaming radio), then the attribute must return the positive Infinity value."

http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-duration
Depends on: 619752
I filed bug 619752 to track that the duration should report +Inf for an infinite length stream.
(Assignee)

Comment 22

8 years ago
Created attachment 500074 [details]
updated Andreas Madsen's testcase

updated testcase to use renamed API from window.createBlobURL to window.URL.createObjectURL.
Attachment #484637 - Attachment is obsolete: true
(Assignee)

Comment 23

8 years ago
Created attachment 500488 [details] [diff] [review]
patch

I investigated this with Dolske, and it seems that the durationchange event is being fired much more frequently than the timeupdate event. For media that do not report a definite duration immediately, each durationchange event that does not have a corresponding timeupdate event reports a duration that is slightly larger than the currentTime. (Bug 619752 proposes correcting this reported duration to +Inf or NaN to match the spec, but it won't break this patch. :) This patch ignores durationchange events and uses timeupdate events to update the duration on-the-fly. Also, this.maxCurrentTimeSeen is in fact still needed.
Attachment #500488 - Flags: review?(dolske)
Whiteboard: [soft blocker]
Attachment #500488 - Flags: review?(dolske) → review+
(Assignee)

Comment 24

8 years ago
Pushed.

http://hg.mozilla.org/mozilla-central/rev/f05a36cfa8cb
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b10
Whiteboard: [soft blocker] → [softblocker]
Tested with 4.0 Beta 10.
I no longer see this on XP, Windows 7, Linux or Mac 10.6.
Marking verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.