Closed Bug 566920 Opened 15 years ago Closed 10 years ago

WebM: If the stream can't keep up with the playback, video stops and doesn't restart

Categories

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

Product:
Core
Component:
Audio/Video: Playback
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: BenB, Unassigned)

References

Details

Reproduction: 1. Click on Youtube WebM video <http://www.youtube.com/results?search_query=mozilla&aq=f&webm=1> 2. If the stream can't keep up with the playback, ... Actual result: 1. ... the player (in Firefox) stalls, but never resumes. 2. Load throbber (dots as circle, in middle of video) shows 3. Clicking on Pause/play (once or several times) has no effect. 4. When I switch between fullscreen and windowed, it resumes playback Expected result: 1. Video halts, shows throbber 2. Once it has enough data to play (possibly buffering a few seconds), playback resumes automatically.
Blocks: 559052
Confirming this, as it is showing up on the trunk now. Its really choppy and all the same issues, sound doesn't stop, video doesn't stay paused and restarts, etc. testcase: http://www.youtube.com/watch?v=0CRPz3kvou0&webm=1&html5=1 Tested win 7.
I should note playing the default of 360p plays better than 720p which is real choppy even over cable modem so you'll notice this easier. Seems like buffering/seek issues need to be addressed like theora. Also be sure to clear the cache if you play the video too many times when testing this.
The video in comment 1 can't be viewed: "This video has been removed due to terms of use violation. " Is there another test case that exhibits the issue? If the problem is 720p videos playing choppy but 360p videos playing better then it may be bug 577843.
Chris Double, I could see the problem with *any* video, see the search posted in comment 0. All you need is a connection too slow for the video. It has nothing to do with 360p vs. 720p, apart from 720p needing more bandwidth.
Thanks, I tried the search, picked a few videos and everything seems to work fine on trunk (with scaling patch from bug 577843 applied). I'm rebuilding without the patch to see if it makes a difference. What I'm seeing is the video pausing for buffering, then it resumes playing for about 15 seconds, then pauses for more buffering, etc.
You did try WebM, right? This bug is specific to WebM, IIRC.
Summary: If the stream can't keep up with the playback, video stops and doesn't restart → WebM: If the stream can't keep up with the playback, video stops and doesn't restart
Yes, I used WebM. I'll update shortly with the results of a trunk build without the scaling patch in case that affected things.
Without the scaling patch the playaback is definitely choppier due to skipping to keyframes but the buffering still works fine. The playback pauses, there's a delay while more network data is loaded, then it resumes (about 20-30 seconds later). I don't see a throbber though and you mention it in comment 0. The throbber does not display if the site is using custom JS controls which YouTube is. Possibly their controls code is causing issues? Do you see the same problem on WebM videos not hosted on YouTube?
> Without the scaling patch... > playback pauses, there's a delay while more network data is loaded, > then it resumes (about 20-30 seconds later). That may be the bug I saw. I am not patient enough to wait 30s for a computer :-) (also, length depends on network speed). > Do you see the same problem on WebM videos not hosted on YouTube? I don't know many good sample videos as WebM. Also, I usually have a fast connection and it was just bad at that day. So, you're saying that the "scaling patch" definitely improved matters, by not waiting for a keyframe? Maybe that's enough to call this bug FIXED.
(In reply to comment #9) > That may be the bug I saw. I am not patient enough to wait 30s for a computer > :-) (also, length depends on network speed). Currently we've set the buffering code to wait up to 30s or until we think we can playback the entire video without stopping, whichever comes first. If you think this is too long, please raise a bug for that. 30s was chosen to balance playing a reasonable amount of video vs constant stop/start of the buffering. > So, you're saying that the "scaling patch" definitely improved matters, by not > waiting for a keyframe? Maybe that's enough to call this bug FIXED. Thanks, I'll resolve this bug as 'wontfix', assuming it's the 30s buffering you saw. You can follow bug 577843 for the scaling issue and if the 30s is an issue you're welcome to raise a bug for that and we'll address it.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
What I saw was clearly a bug, because "Clicking on Pause/play (once or several times) has no effect" and there was a clear difference in behavior between WebM and other codecs, it worked with others. It was very clearly broken, from a user perspective (to such a severe extend that it would prevent me from using the feature at all). If the problem was the waiting for keyframes, and you fixed that, this bug is "FIXED". If the problem was something else, it needs to be fixed. I'll follow bug 577843.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Sorry, I changed the status based upon your comment: "Maybe that's enough to call this bug FIXED."
Assignee: chris.double → nobody
I just entered bug #614695, could well be related to this one. Ben, do your playback problems appear on the testcase page mentioned in that report?
(In reply to comment #11) > What I saw was clearly a bug, because "Clicking on Pause/play (once or several > times) has no effect" and there was a clear difference in behavior between WebM > and other codecs, it worked with others. It was very clearly broken, from a > user perspective (to such a severe extend that it would prevent me from using > the feature at all). > > If the problem was the waiting for keyframes, and you fixed that, this bug is > "FIXED". If the problem was something else, it needs to be fixed. This could be helped by bug 610570, which fixes some issues with the buffering behaviour. Once that lands, please retest.
The point of this bug IMHO (and I have seen it a lot with the current Aurora; switching to Nightly to see whether I can reproduce here) is not an erratic behavior, but the fact that once playback stalls, it never recovers. Also, sometimes sound for the such stalled video recovers even when the original tab is actually closed.
Bug 736342 may help here. That fix is in Nightly builds but not Aurora builds, so if you don't see this problem (as much) in Nightly builds, then main thread IO could be the culprit. There's also a tweak to our frame dropping logic in the patches in bug 664918 which may help here too, but that's not yet landed.
Chris, I think you're still misunderstanding this bug. It's *not* about something not being fast enough. It doesn't work at all in some situations, while there's no problem in another situation: See comment 0: > 3. Clicking on Pause/play (once or several times) has no effect. > 4. When I switch between fullscreen and windowed, it resumes playback Also, Matej said in the last comment: > this bug ... is not an erratic behavior, but ... that once playback stalls, it never recovers So, there's nothing that can "help" with this bug occuring "less much". This bug is binary: either nothing works at all or everything works flawlessly.
In other words, while various "too slow" situations might trigger this bug, the bug here is not about them, but the fact that we don't recover from that situation. We can recover without problem, given that switching to/from fullscreen recovers. But we need to recover without manual intervention. It's about the recovering, not about the "might be too slow".
(In reply to Ben Bucksch (:BenB) from comment #17) > Chris, I think you're still misunderstanding this bug. It's *not* about > something not being fast enough. It doesn't work at all in some situations, > while there's no problem in another situation: I agree, but Chris is also a bit right ... it occurs much much less often on Nightly.
That may be, but it's like "when it's raining, my roof leaks water in my computers". And people answer "But it's raining less recently". That may be, but the amount of rain has nothing to do with how to protect against the rain. We need to *recover* from the situation that the stream stalls temporarily.
I've had this a few times too. It's not a slow computer, but I do some heavy calculations from time to time. This last time, the video froze and never started again, while the audio kept playing (youtube, WebM). Reloaded the tab, audio went on. Closed Firefox, audio stopped, but the process didn't shut down not even after a minute. I killed the process and it generated a crash dump (I've got crash dumps enabled on my system). If anyone needs it, let me know, I'll upload it somewhere.
Component: Audio/Video → Audio/Video: Playback
The situation described can no longer happen with the new WebM Reader found in 42 and later.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.