STR: 0. Visit http://youtube.com/html5 and click the link for the youtube HTML5 trial, if you don't already have that enabled. 1. Load https://www.youtube.com/watch?v=aVYfmw7gKd0 2. Watch the video (or seek to somewhere near the end, to save some time) 3. When the video completes, click the "Replay" button at the lower-left of the video. EXPECTED RESULTS: Video replays ACTUAL RESULTS: Video freezes at first frame. Also, the pause button doesn't work anymore. (clicking it doesn't toggle it from "Pause" to "Play" as I'd expect it to) Workaround: I can make the video play by clicking the scrubber (triggering a seek). VERSION INFO: I can reproduce this in the most recent nightly... Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0 ...and also in an old nightly from Jan 2012 (over 6 months ago)... Mozilla/5.0 (X11; Linux x86_64; rv:12.0a1) Gecko/20120101 Firefox/12.0a1 ...so I suspect this is actually a regression on YouTube's end that affects all versions of Firefox Still -- filing a bug, so that we can track the issue, and because I don't know where to file YouTube bugs.
I get similar behavior (though less-broken) behavior in Opera. There, the Replay button seeks the video to the beginning and pauses it. (and then I have to click the "play" button to make it play.) Do we have any contacts at YouTube to investigate this on their end? I'm pretty sure this used to work.
(In reply to Daniel Holbert [:dholbert] from comment #1) > Do we have any contacts at YouTube to investigate this on their end? I'm > pretty sure this used to work. I've got a few. Want me to ping them?
I could reproduce with nsBuiltinDecoder log enabled,  is what I got. I never ever used that feature on youtube before, but I'm almost certain I've seeked to the beginning of a video in a way that trigger the same code path before. The reference to a poorly muxed file in the log can be a lead. I'll test the video using tools to see if this assertion is bogus or not. On an unrelated node, I also get an error in the web console: TypeError: a is undefined @ https://s.ytimg.com/yt/jsbin/www-core-vflQVw0Eu.js:60 : http://pastebin.mozilla.org/1713562
WFM in Midori (a webkit-based browser for Linux), FWIW. So this might be WFM-in-webkit. (I tried chromium as well, but my chromium version doesn't seem to like HTML5-enabled-youtube for some reason. Might be too bleeding-edge.)
As a sanity-check, I confirmed that this isn't specific to that one video -- it reproduces here as well: https://www.youtube.com/watch?v=VBLHsh_4z_8 (So as far as I know, it could affect all YouTube+HTML5 videos.) Also: After I've hit ACTUAL RESULTS, it appears that the video is actually playing, but it's just not being repainted. If I focus the URL bar with Ctrl+L, then that makes the video's region repaint with a frame from later on. (The audio definitely doesn't play during this "playing-in-the-background" time, though.) (In reply to Timothy B. Terriberry (:derf) from comment #2) > > Do we have any contacts at YouTube to investigate this on their end? I'm > > pretty sure this used to work. > > I've got a few. Want me to ping them? Hmm -- I'll defer to Paul on that, after his testing noted in comment 3. It could be that YouTube changed in a way that exposes a real Gecko bug, in which case we should fix our bug. :) It looks like at least something's wonky on our end, per the assertion Paul mentioned and my "Also:" noted above.
(In reply to Daniel Holbert [:dholbert] from comment #5) > Also: After I've hit ACTUAL RESULTS [... i]f I focus the URL bar with > Ctrl+L, then that makes the video's region repaint with a frame from later > on. Nevermind on this part - this seems to be because YouTube interprets "L" as a "seek" command.
(In reply to Paul ADENOT (:padenot) from comment #3) > I could reproduce with nsBuiltinDecoder log enabled,  is what I got. I > [...] > : http://pastebin.mozilla.org/1713562 It looks like you're using the GStreamer backend here Paul, and Daniel's using nightly which doesn't use ship GStreamer, so we can conclude that either the bug is not in backend decoders, or it exists in both the WebMDecoder and the GStreamer backends.
Removing regressionwindow-wanted -- there's no regression in Gecko here, AFAICT. I can reproduce this in pre-Firefox 4 nightly, from November 2010: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101117 Firefox/4.0b8pre (I tried an even older nightly, from Jan 1 2010, but it segfaulted when trying to load a YouTube HTML5 video. :)) So, I'm pretty sure this went from working --> not-working due to a change on the YouTube side (though it's not necessarily a YouTube bug -- it might be tickling a Gecko bug, given that we warn & assert as shown by Paul's pastebin in comment 3).
Summary: Clicking "Replay" button on HTML5 Youtube Videos makes the video freeze at the beginning → Clicking "Replay" button on HTML5 Youtube Videos makes the video freeze at the beginning (and fire "ASSERTION: Seek target should lie inside the first audio block after seek [...] nsBuiltinDecoderStateMachine.cpp, line 1883")
Chris, I was indeed using a build with --enable-gstreamer. However, I just tried again with a normal build, I can reproduce the bug, and I approximately get the same trace, but with more info: http://pastebin.mozilla.org/1724704 Note the : WebMReader detected gap of 12993, 573 frames, in audio stream WebMReader detected gap of 9931, 438 frames, in audio stream WebMReader detected gap of 793, 35 frames, in audio stream
I've investigated a bit further. It appears that during DecodeToTarget, and playing the video specified in comment 0, the first frame we pop from the audio queue have a mTime (start time) of 13000µs (we expect 0, since we are seeking to the very beginning of the file, i.e. 0.0s), which is frame 573. The VideoData, however, shows an mTime of 0, so audio and video are desynchronized. My guess is that the files are poorly muxed, as the assertion states. Then comes the youtube bug. When we click the replay button, |video.paused == true|, while the UI shows the paused button indicating that the video is playing, and that the user can pause it by clicking on the button. If, in the web console, I call |play()| on the video, everything works just fine (i.e. the video plays). The Youtube player calls |pause()| at the end of the video (beautified code path: http://pastebin.mozilla.org/1724948). When we click on the replay button, |play()| is called, then |pause()| is called up to three times (it seems variable), hence, the video not playing. Somehow, it works in Chrome, but Youtube may be sniffing for the user agent, and they do no seem to call |pause()| after the click on the replay button. Maybe |pause()| is called in a handler to an event we fire and Chrome does not fire, or something like that. On an unrelated note, if found bug 778902 while searching the cause for this bug. Fixing bug 778902 does not fix this youtube problem, though. Ideas welcome, but it could be useful to have someone on the Youtube side, here, their code is quite impenetrable.
Also occurs on Windows. Chrome works fine for me too. Tried to switch my User Agent to Chrome in 15b5, but this didn't do the trick.
OS: Linux → All
Hardware: x86_64 → All
I _think_ this is a Youtube bug. If one call |play()| on the video on the webconsole, everything works fine. From what I've read in the code, they were working around the fact we did not Pause() when the end of the video was reached (now fixed, bug 778902).
This now appears to be fixed. I get the Expected Results (video starts replaying) using Firefox 16 beta 3.
Indeed it is, thank you for telling us!
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.