Loading the url above in 3.6 buffers for about 2 seconds. Loading it in Minefield after the new ogg backend landing can take anywhere from 20-40 seconds. Running it in some code I see more than one canplaythrough event being generated, but I'm not hooked up to every event so I'm not sure if it's re-buffering after the initial canplaythrough. Will dig some more.
Thanks Blizzard. Which OSes? This is probably the same as or related to bug 556893.
I'm testing on Linux, haven't tried other OSes.
I'm seeing similar behavior on Mac 10.5.
And on Win 7.
blocking2.0: ? → beta1+
Priority: -- → P2
Currently we set nsOggPlayStateMachine::mBufferExhausted to PR_TRUE when the decode catches up with the end of the downloaded data. In the old backend this was OK, because we only kept about 10 (?) frames worth of decoded audio and video data, but the new backend buffers up to 2000ms of audio data (and 10 video frames). Because we buffer so much more audio data, we're decoding much further ahead of the current playback position than we used to. This causes us to hit the "has the decode caught up with the download?" condition much more, particularly at the start of a load, and so we set mBufferExhausted to PR_TRUE more often. This causes us to go into buffering state more often, where we buffer for up to 30 seconds. The solution is to change the play state machine decoding state to not switch to buffering state when mBufferExhausted is PR_TRUE unless we also don't have much decoded audio/video left, i.e. only start buffering if the decode has caught up with the download, and the current playback position has caught up with the decode.
Created attachment 438406 [details] [diff] [review] Patch v1 Patch v1: * Only switch to buffering state from decoding state in nsOggPlayStateMachine when we're running out of decoded data, not just when the decode catches up to the end of the downloaded data.
Attachment #438406 - Flags: review?(chris.double)
Looks good to me.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.