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.
Component: General → Video/Audio
Product: Firefox → Core
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.
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
Component: Video/Audio → Video/Audio Controls
Product: Core → Toolkit
QA Contact: video.audio → video.audio
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
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.
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.
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.
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
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.
> 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).
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?
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
I filed bug 619752 to track that the duration should report +Inf for an infinite length stream.
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
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)
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b10
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.