531280 - ogg/theora/vorbis video stuck at start

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Sylvain BERTRAND]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2b3) Gecko/20091125 Gentoo Firefox/3.6b3
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2b3) Gecko/20091125 Gentoo Firefox/3.6b3

playback won't start

Reproducible: Always

Comment 1

[Matthew Gregan [:kinetik]]

Can you please post the specs of the machine you're testing on?  The three bugs you've filed all use very high resolution videos, and I suspect we're too slow (right now) to playback properly on your machine.

Comment 2

[Matthew Gregan [:kinetik]]

This plays okay for me on OS X once downloaded locally.  It plays from tinyvid.tv too, but keeps pausing to buffer (it's very short and quite high bitrate, I think our buffering is getting a bit confused).

cpearce can reproduce the playback problem on Windows, though, so confirming.

Comment 3

[Chris Pearce [:cpearce (Not reading bugmail)]]

Looks like the problem here is that liboggplay isn't giving us enough sound data to push the audio clock forwards into the next frame. The audio clock on OSX advances by itself, so that's why it works on OSX, but not Linux/Windows.

The audio in that file is encoded with one vorbis packet per page, which is a little weird (vorbis packets rely on their preceding packet to decode), but not invalid. We often get no sound samples delivered to us from liboggplay. If I hack our nsOggDecodeStateMachine::NextFrame() to inject silence when liboggplay doesn't give us enough audio data to advance the audio clock to the next frame, we can play this video ok. So I'd say this is a bug in liboggplay. Adding silence is not a robust solution - assuming the file has the correct amount of audio embedded in it, we'd be injecting extra silence, and get out of sync.

viktor: any idea what's happening in liboggplay?

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to comment #3)
> Looks like the problem here is that liboggplay isn't giving us enough sound
> data to push the audio clock forwards into the next frame. The audio clock on
> OSX advances by itself, so that's why it works on OSX, but not Linux/Windows.

We've fixed this issue in the new decoder backend, so marking resolved fixed until we hear otherwise.