STR: > 1. load http://upload.wikimedia.org/wikipedia/commons/b/b3/Inukai_no_taki_video.ogv > 2. pause at 4 seconds > 3. load http://upload.wikimedia.org/wikipedia/commons/b/b3/Inukai_no_taki_video.ogv in a second tab > 4. pause at 3 seconds > 5. switch back to the first tab and try to let it play After step 5, I get batches of something like 5 frames every two seconds and no sound. This is on Linux. I haven't seen it on Windows yet.

WFM on Mac.

I'd want confirmation before we can mark this blocking

Chris, is this fixed by the BYPASS_CACHE_IF_BUSY patch?

Matthew, can you reproduce this?

Yeah, except the video doesn't seem to make progress at all when I try to resume playback. Weird.

Can't block on it, but definitely wanted.

Dão, is the Linux machine that you can reproduce this on running PulseAudio? I can only reproduce it running PulseAudio. Using ALSA directly works as expected, which suggests something funny going on with the pause/resume handling in the PulseAudio ALSA plugin. What's happening is that, on resume, we're getting stuck in the wait-for-current-frame-time loop in PlayFrame. The frame queue is full, and the current frame time is slightly ahead of the time reported by the audio backend. There's no data buffered in the nsAudioStream.

In fact, I can't resume even a single paused video when using PulseAudio on current Fedora rawhide... so it's possible I'm seeing a different problem.

Dão, if you could reproduce and confirm this is a problem with/without PulseAudio, that'd be great. Also, if you could attach gdb to Firefox when this problem is occurring and verify whether the playback thread is in the following loop: http://mxr.mozilla.org/mozilla-central/source/content/media/ogg/nsOggDecoder.cpp#917 That would be totally awesome.

This is now WFM. Will also try with the other system that I reproduced this on.

I can't reproduce it on the other system either. There's something strange going on (rather slow playback, no sound), but that's different from the original problem.