audio streams have to buffer for a long time before they can play through

RESOLVED FIXED

Status

()

P2
normal
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: blizzard, Assigned: cpearce)

Tracking

unspecified
x86
Linux
Points:
---

Firefox Tracking Flags

(blocking2.0 beta1+)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
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.
(Assignee)

Comment 1

9 years ago
Thanks Blizzard. Which OSes? This is probably the same as or related to bug 556893.
(Reporter)

Updated

9 years ago
Depends on: 556893
(Reporter)

Comment 2

9 years ago
I'm testing on Linux, haven't tried other OSes.
I'm seeing similar behavior on Mac 10.5.
(Reporter)

Comment 4

9 years ago
And on Win 7.
blocking2.0: --- → ?
blocking2.0: ? → beta1+
Priority: -- → P2
(Assignee)

Comment 5

9 years ago
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.
(Assignee)

Comment 6

9 years ago
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)

Updated

9 years ago
Attachment #438406 - Flags: review?(chris.double) → review+
(Assignee)

Comment 8

9 years ago
http://hg.mozilla.org/mozilla-central/rev/77edf4302cdd
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.