572299 - Stuttering audio playback with some Vorbis files (ffmpeg muxed)

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Matthew Gregan [:kinetik]]

Audio playback starts stuttering about 1/2 way thoughall of the ffmpeg produced Vorbis files hosted here (tested on OS X):

http://people.xiph.org/~greg/audio/vorbis/ffvorbis/new01/
http://people.xiph.org/~greg/audio/vorbis/ffvorbis/new02/

The libvorbis/aotuv versions play fine.  The ffmpeg versions play fine in VLC.  Can also reproduce this with locally downloaded files.

In new02/ffmpeg.fbarchard.br128000.ogg, the stuttering starts around 6-7 seconds into playback.  Looking at some DecodeLoop diagnostic logging I've got in place for another bug:

When playback starts, we've decoded 5.4s of audio:
vq 0 aq 254 ad 5397/5397 ct 0/-1 a await vwait vpump

At 3.9s, buffering kicks in (and mAudioQueue drains completely at 3.947s):
vq 0 aq 24 ad 491/2474 ct 2902/4885 a await vwait vpump
vq 0 aq 23 ad 469/1475 ct 3900/5077 a vwait vpump buffer
vq 0 aq 0 ad 0/1492 ct 3947/5439 a vwait vpump buffer

We never managed to refill the audio queue after this.

Audio buffered in the audio backend (calculated from mAudioEndTime - currentTime) drops below LOW_AUDIO_MS:
vq 0 aq 0 ad 0/344 ct 6397/6741 a vwait vpump buffer
vq 0 aq 0 ad 0/331 ct 6431/6762 a vwait vpump buffer
vq 0 aq 0 ad 0/305 ct 6478/6783 a vwait vpump buffer
vq 0 aq 0 ad 0/292 ct 6513/6805 a vwait vpump buffer skipkf
vq 0 aq 0 ad 0/267 ct 6559/6826 a vwait vpump buffer skipkf
vq 0 aq 0 ad 0/253 ct 6594/6847 a vwait vpump buffer skipkf

Comment 1

[Matthew Gregan [:kinetik]]

So, these files only have a couple of pages:

00:00:05.418: serialno 1, granulepos 260096, packetno 257: 76 bytes
00:00:10.858: serialno 1, granulepos 521216, packetno 512: 88 bytes
00:00:11.008: serialno 1, granulepos 528384, packetno 519 *** eos: 84 bytes

This is why the DecodeLoop starts off with 5397ms of audio decoded due to the initial decoding done by FindStartTime.

What happens is that we finally fall below AMPLE_AUDIO_MS and attempt to decode some audio.  ReadOggPage ends up reading the entire rest of the file into the ogg_sync_state (it happens to read more than one page because it attempts to read in 4k chunks, and the last read includes both the end of the page it is trying to read and the remaining part of the file).

ReadPacket doesn't do any EOF handling yet because we're processing the second to last packet.  DecodeAudioData decodes the packet and returns.

In DecodeLoop, initialDownloadPosition is now equal to mDecoderPosition, so we enter buffering and never recover.

Comment 2

[Matthew Gregan [:kinetik]]

Attachment: patch v0

Only buffer if the decoder read past the buffered range.

Comment 3

[Marco Bonardo [:mak]]

http://hg.mozilla.org/mozilla-central/rev/b793c7686b4f