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
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.
Assignee: nobody → kinetik
Status: NEW → ASSIGNED
Created attachment 452182 [details] [diff] [review] patch v0 Only buffer if the decoder read past the buffered range.
Attachment #452182 - Flags: review?(chris)
Whiteboard: [needs landing]
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing]
Target Milestone: --- → mozilla1.9.3a6
You need to log in before you can comment on or make changes to this bug.