John Drinkwater (:beta) Reporter
	Description • 16 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.

	Justin Dolske [:Dolske]
	Comment 1 • 16 years ago

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.

	John Drinkwater (:beta) Reporter
	Comment 2 • 16 years ago

The oval playback knob-thing jitters left to right.

	Justin Dolske [:Dolske]
	Comment 3 • 16 years ago

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.

	Justin Dolske [:Dolske]
	Comment 5 • 14 years ago

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.

	Asa Dotzler [:asa]
	Comment 8 • 14 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.

	Andreas Madsen
	Comment 10 • 14 years ago

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.

	Ben Bucksch (:BenB)
	Comment 11 • 14 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.

	Matěj Cepl
	Comment 13 • 14 years ago

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

	Andreas Madsen
	Comment 14 • 14 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.

	Kyle Huey (Exited; not receiving bugmail, old account, do not use)
	Comment 15 • 14 years ago

(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.

	Andreas Madsen
	Comment 16 • 14 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.

	Kyle Huey (Exited; not receiving bugmail, old account, do not use)
	Comment 17 • 14 years ago

(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).

	Chris Pearce [:cpearce (Not reading bugmail)]
	Comment 18 • 14 years ago

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?

	Jb Drucker
	Comment 19 • 14 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)

	Chris Pearce [:cpearce (Not reading bugmail)]
	Comment 20 • 14 years ago

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

	Chris Pearce [:cpearce (Not reading bugmail)]
	Comment 21 • 14 years ago

I filed bug 619752 to track that the duration should report +Inf for an infinite length stream.

	Frank Yan (:fryn) Assignee
	Comment 22 • 14 years ago

updated testcase to use renamed API from window.createBlobURL to window.URL.createObjectURL.

	Frank Yan (:fryn) Assignee
	Comment 23 • 14 years ago

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.

	Frank Yan (:fryn) Assignee
	Comment 24 • 14 years ago

Pushed.

http://hg.mozilla.org/mozilla-central/rev/f05a36cfa8cb

	Cameron Dawson [:camd]
	Comment 25 • 14 years ago

Tested with 4.0 Beta 10.
I no longer see this on XP, Windows 7, Linux or Mac 10.6.
Marking verified.