GNOME Bugzilla – Bug 154785
Clock does not run if audio stream lacks data for a short while
Last modified: 2005-08-25 23:58:00 UTC
I'm having some trouble playing a file with 0.99.17 using the gstreamer backend. On my FC3 build, downloading and playing: http://www.itcollege.ee/dl/OGG/avaloeng10_1.ogg with alsasink: Unable to get the video to start playing with osssink: Initially the video plays extremely slow, and no audio. If I seek a bit into the stream it starts playing fine.
http://www.itcollege.ee/dl/OGG/avaloeng10_2.ogg works well, so its something about the first part of the file.
Wim claims this file to be invalid, because the video and audio are muxed inappropriately. I'm assuming that the file plays fine in other players?
I haven't really tried it. It was linked from the vorbis home page, and i wanted to try vorbis playback in totem.
I had a closer look. The file indeed has a large, cruelly large, max-page-delay. Totem-gst has a workaround for such files. You can set /schemas/apps/totem/buffer-size to a value (float, in seconds) of the buffersize. The default is 3; this file seems to start playing at 6. The direct bug is fixed with that. I'll keep the bug open to fix the deeper clocking issue: the clock does not run if there is no data. This is not good...
1) the file has huge pages, time-wise 2) the beginning of it has digital silence. See oggzdump | grep granulepos, all the 1-byte packets are digital silence. 3) there starts being audio when the stallman starts speaking. The file is muxed correctly, thinks Mike Smith. Also oggz-validate does not complain. Totem with GStreamer 0.9 handles playback of this file correctly, without fumbling around with GConf keys. Closing as fixed, yay! (Reopen if there is still a problem.)