Closed Bug 580795 Opened 15 years ago Closed 15 years ago

HD WebM videos (e.g. YouTube HTML5 720p) stutter or freeze after 4-12 minutes

Categories

(Core :: Audio/Video, defect)

Product:
Core
Component:
Audio/Video
Platform:
x86_64
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: WdFCRTsSDyWZ, Unassigned)

Details

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 Build Identifier: Minefield 4.0b2pre nightly trunk build - 2010-07-20 Similar/related to #571422 and #571816. However, problem still exists on Mac OSX 64-bit build-- but takes longer to develop (4-12 minutes). Once it starts to misbehave, you can sometimes coax it to restart, but, it won't work for long. Reproducible: Always Steps to Reproduce: 1. Use Snowleopard, 2010-07-20 Minefield. Go to YouTube WebM beta 2. Select an HD video. NASA TV example below using WebM. 3. Wait 8-12 minutes. Video will freeze. NASA astronaut leads tour of space station in HD http://www.youtube.com/watch?v=-1OTSbIzcwI Actual Results: Video will freeze. You can try to fiddle and restart it, but, won't get far. This sounds like the problem in #571422 and #571816. However, it is still there on MacOS X in the trunk build. Also, it takes somewhat longer to develop. That problem, as reported, happened at 2:30 into the playback. Expected Results: Smooth video that did not freeze. Try these: http://www.youtube.com/watch?v=-1OTSbIzcwI&hd=1 http://www.youtube.com/watch?v=7rfmb3uuLE8
Version: unspecified → Trunk
http://www.youtube.com/watch?v=UOtJUmiUZ08&feature=featured&videos=MQtHliJAPpU EXACTLY after 12 minutes. 12:00 and the video stopped.
I can't reproduce this on Windows with the NASA video or the Katy Perry video in either 360p or 720p. In all cases the video played through to the end. In the 720p version of the Katy Perry video, playback stutters badly but does not stop (we're skipping to the next key frame, but the audio is also dropping out) around 23-24 minutes in. This might be the same bug people were seeing in bug 571422. How long are you waiting before you give up on the video? It may pause to buffer for up to 30 seconds, and unfortunately YouTube's custom controls don't give any indication that playback has paused due to buffering.
I've seen 720p Webm video file sizes be well over a hundred megabytes. Yeah, Youtube doesn't show you UI when its stopped while getting more data, I checked this video at 720p: http://www.youtube.com/watch?v=-1OTSbIzcwI&hd=1&html5=1 and the video from comment 1. Both stopped showing new footage at times, then I waited for a bit and they started playing again. So the videos should not be actually freezing or stopped playback altogether per say, but 720 playback is most likely a lot data to download, so imagine its just buffering playback because its just waiting for more.
I was watching that video on a 25mbps connection. The video buffered nearly instantly, yet it stopped completely at exactly 12:00. When I clicked pause, and then play, it started playing from 0:00 instead of continuing playback
It does buffer instantly to start playback, but doesn't mean the connection isn't still streaming. I don't seem to be experiencing the problem like that on Win7 with latest nightly. What build and OS are you running on?
Ah, it seems to be fixed in latest nightly. :)
"I can't reproduce this on Windows with the NASA video or the Katy Perry video in either 360p or 720p. In all cases the video played through to the end." This problem is with the Mac version. I have not tested the Windows version.
OK, now I'm confused. I can't get the latest 2010-07-29 nightly build to attempt to use WebM. I checked using Google Chrome - I have WebM videos I'm pointing at on YouTube. I checked html5test.com -- it believes that WebM is available on this version of Minefield. But, YouTube is insisting on Flash. Maybe operator error. It has been a long day ...
The videos from comment 0 and comment 1 WFM on [Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b3pre) Gecko/20100802 Minefield/4.0b3pre], and on may Win7 machine. Maybe you're just having connection problems?
(In reply to comment #8) > OK, now I'm confused. I can't get the latest 2010-07-29 nightly build to > attempt to use WebM. I checked using Google Chrome - I have WebM videos I'm > pointing at on YouTube. I checked html5test.com -- it believes that WebM is > available on this version of Minefield. But, YouTube is insisting on Flash. > Maybe operator error. It has been a long day ... Well, before maybe there was a real problem.. that is why posted the direct WebM link to the Nasa video in comment 3 which is the same of that from comment 0 - but must easier to test. If your not aware this, if your not logged into Youtube's HTML5 beta, you can still try videos by adding &html5=1 to end of the URL, but that doesn't mean that all Youtube videos will comeback with WebM versions of their flash counterparts, they may not exist, but if they do (like the Nasa video) you'll know WebM videos on Youtube by a few things: its context menu, the html5 throbber and the bottom right says HTML5 & WebM - at least when using fx.
I have been suffering from stuttering WebM HD videos on youtube, so in response to comment 2, I paused the NASA tour video at the beginning until my network monitor showed no activity. I resumed playback ~8 sec after all network activity had stopped and played the video continuously. Results: - The video did not freeze (this has never happened to me) - The video continues to stutter - Seems a bit smoother playback than earlier but still dropped 2-3 frames every 8 sec or so. - The network monitor showed no more activity during the rest of the playback indicating the entire video was initially buffered This test was run on: Windows 7 (x86), FF4 beta 2
note: redid the same thing as earlier and now it stutters every 2-3 sec
Please retest with tomorrow's nightly build--it's possible that this is fixed by bug 576539.
(In reply to comment #13) Yeah, seems to be fixed. I didn't notice any stuttering in the NASA Astronaut video. Good Job whoever fixed this. Still requires initial buffering but I only buffered for ~20 sec but this is acceptable as he video is 28 min long. I don't know how much of the vid was downloaded as there is no indicator as with flash. Perhaps there should be way to buffer some of the video before playback. If this is already the case, then increase the buffer size (I'm on a 3 Mbps line and still needed the buffer).
I just tried out 4.0b5pre. A couple of observations on 4.0b5pre: 1) I could not use 64-bit version because, even though I'm trying to look at WebM, it still insists Flash be there. Is this a change to YouTube, or, a new bug in Minefield-- IDK. 2) 32-bit 4.0b5pre works (with Flash present, but, not being used). WebM still not very smooth, but, so far, no freeze. As far as I am concerned, the reported Minefield bug is fixed, but, WebM playback is not very smooth. I don't know if that belongs to Mozilla or Google.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Resolution: FIXED → WORKSFORME
(In reply to comment #15) 1) You probably need to rejoin the youtube html5 beta (www.youtube.com/html5). i have noticed that i have to do this independently in every Firefox build i have even though they all share the same the profiles. Webm worked fine for me in Minefield x64 and this was without any flash plugin present (no 64-bit version of flash developed for windows). 2) It actually worked well for me in 32-bit Minefield. One caveat though. My processor usage was 85-90% (with spikes to 100%) when playing 720p in any player size. And this is on a 2.9 GHz overclocked to 3.2 GHz. I don't know your system specs but that might cause the stutter for you. If you can, check using Google Chrome (Don't forget to join the html5 beta here too) which handles webm much better (my usage was 50-60% with spikes to 80%) This may be related to bug 577843 - Video scaling (up or down) is too slow. Minefield x64 shows marginally better results (80-85%).
Bug still exists in 64-bit version of Minefield. Stutter every 2-3 sec with ~3-8 frames dropped
Fixed in the 20100911 x64 nightly
I just retested with the 20100913 x64 nightly, and, it breaks at 4:25 in on the following video: http://www.youtube.com/watch?v=7rfmb3uuLE8&hd=1 (This is the STS-129 HD Landing HTML5 WebM at 720p.) Host is Mac OS 10.6.4 with latest patches. CPU is 2.4 GHz C2D. (MacBookPro3,1 - 4 GB - graphics GeForce 8600M GT).
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
I just retested with the 20100913 x64 nightly, and, it breaks at 4:25 in on the following video: http://www.youtube.com/watch?v=7rfmb3uuLE8&hd=1 (This is the STS-129 HD Landing HTML5 WebM at 720p.) Host is Mac OS 10.6.4 with latest patches. CPU is 2.4 GHz C2D. (MacBookPro3,1 - 4 GB - graphics GeForce 8600M GT).
I was able to reproduce this once today.
Status: UNCONFIRMED → NEW
Ever confirmed: true
It might be slightly easier to see what's going on in tomorrow's nightly for those that can reproduce this--we landed support for buffered ranges in WebM today (bug 570904). With this, if we're running out of data, it'll be obvious in YouTube's custom controls.
I think I reproduced this around 7:25 into the video. It looked like the download had terminated early, we were still playing in the downloaded range, and we had started keyframe skipping (showing a new frame every ~2s). Is that what others are seeing?
Do we know for a fact that youtube is using buffered controls?
I haven't seen this for awhile, but my disk and media cache are both set to 512MB
I think it is a buffering issue. WebM HD videos are be HUGE. The STS-129 Landing video is 275 MB for a 8 min video (you can check with: right-click on blank area -> view page info -> media tab -> scroll list to find the video -> save as) The STS-129 Landing video froze for me at 1:34, but resumed after ~10 sec. This happened a few times. Reloaded the page but buffered the video before playing it (kept paused for ~10 min). Network activity monitor showed network activity even after 10 min, but i played the vid anyway. It worked smoothly until 7:35 when i it froze for a few sec but resumed in a few sec.
(In reply to comment #25) Any idea how much pre-buffering does youtube does for WebM videos before beginning playback? On a related note, I'm sure this has been filed elsewhere but we need to have an indicator for how much of the WebM video has been buffered (similar to what is seen when playing flash). I know the chromium nightlies have had this for a while now.
(In reply to comment #26) Regarding offline cache: So do I, about:cache never shows any activity there (i.e. the Offline Cache stored in \profile-folder\OfflineCache\) for youtube videos. All activity for youtube videos (flash and HTML5) has always been in the disk cache (\prefile-folder\Cache\). the video is downloaded there and once it is finished downloading it is immediately moved to %temp% (even if the video is currently playing). In the olden days, youtube downloaded to the offline cache but videos stored there were easy to find and copy.
(In reply to comment #27) P.S. compare the 275 MB WebM HD version of the STS-129 landing video to 60.86 MB for the MP4 version of the same.
(In reply to comment #28) > (In reply to comment #25) > On a related note, I'm sure this has been filed elsewhere but we need to have > an indicator for how much of the WebM video has been buffered (similar to what > is seen when playing flash). I know the chromium nightlies have had this for a > while now. This should be in nightly builds now - support for the 'buffered' attribute was required for it to appear in YouTube's user interface. See bug 462957 and bug 570904.
(In reply to comment #29) \> Regarding offline cache: > So do I, about:cache never shows any activity there (i.e. the Offline Cache > stored in \profile-folder\OfflineCache\) for youtube videos. The offline cache entry you see there is something different. It's for offline storage of web application files (IIRC). Video's are downloaded to a special media cache which only contains partial pieces of the video so there won't be a single file you can copy to get it, sorry.
(In reply to comment #31) Fantastic. Just checked and it works picture perfect! Great Job by all those involved! No freeze or stutter for me now. Playback never reached the buffer limit. (In reply to comment #32) Nice way to protect videos.
Just checked today's build. Once enough is buffered in that you never exhaust the buffer, it looks pretty good. Still occasional skips, but, that may be because decode can't quite keep up (need more efficient decode or faster machine). However, the first time I tried it, it paused itself and did not self-restart several times. Not a big problem, but, when you use other codecs, it will pause until the buffer gets sufficiently ahead, and then, restart itself.
OGV video files are also stuttering - not sure if this should be spun out into its own bug or not. Steps to reproduce 1. Using the latest nightly (15-10-2010), go to http://blog.mozilla.com/blog/2010/10/14/a-message-from-gary-kovacs/ 2. When the video starts playing, it jumps / stutters about once every 5-8 seconds. Allowing the video to completely download doesn't help playback.
(In reply to comment #35) > OGV video files are also stuttering - not sure if this should be spun out into > its own bug or not. What hardware and OS are you on? What CPU?
@cpearce: Macbook (2.33ghz Core 2 Duo, 4G ram), Mac OS X 10.6.5.
I'm going to mark this particular bug as fixed. If there are stuttering problems with other videos can you guys open another bug?
Status: NEW → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.