I realise the it's hard to do a seek in a variable bitrate file but I didn't think it was this bad. It seems to vary a lot with the file but the total time to do an ov_open() and ov_pcm_seek() can add upp to a second or more. By this time my DirectX buffers have wrapped around and are looping. Can anybody think of a solution for this? I really need a faster response time for my in-game sounds. I realize the difficulties of doing the seek, I was looking for a lateral thinking sort of a solution. Can I open/seek the files beforehand and somehow store the internal state ready for a fast startup? There's a lot of files and various seek points within each one so I'm not keen on having an open OggVorbis_File for each file/seek point, that seems a little inelegant to me. I imagine I'd also need to start creating other threads to ov_seek() them back to the right place after each use, ready for the next time around. Gak! Anybody have any ideas...can I somehow grab the internal state of a decoder into a buffer then restore it? -- <\___/> / O O \ \_____/ FTB. --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Thu, Mar 29, 2001 at 11:56:35AM +0100, fungus wrote:> > I realise the it's hard to do a seek in a variable bitrate > file but I didn't think it was this bad. It seems to vary > a lot with the file but the total time to do an ov_open() > and ov_pcm_seek() can add upp to a second or more. By this > time my DirectX buffers have wrapped around and are looping.i'm using ov_pcm_seek_page() wich is giving me good performance on linux. -- jrml ..//korova.dyne.org 6EEE 4FB2 2555 7ACD 8496 AB99 E2A2 93B4 6C62 4800 --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
At 11:56 AM 3/29/01 +0100, you wrote:> >I realise the it's hard to do a seek in a variable bitrate >file but I didn't think it was this bad. It seems to vary >a lot with the file but the total time to do an ov_open() >and ov_pcm_seek() can add upp to a second or more. By this >time my DirectX buffers have wrapped around and are looping.This is a known problem (not exactly a bug - it's doing what it's designed to do, but it is a problem). Libvorbisfile was written primarily as example code - it's intended to be correct, but it isn't all that fast. Seeking and opening are the only places where it's particularly bad (i.e. much worse than it should/could be), that I know of. There's no fundamental reason for seek to be that slow. However, sample-precise seeking is never going to be super-fast. vorbisfile provides another function - ov_pcm_seek_page(), which seeks to (I think) the page which contains the offset you specify. At 128 kbps, a page will typically be about a quarter of a second - probably too much for your purposes. It would also be possible (but vorbisfile doesn't do this currently) to provide a packet-precision seek function. That would be sufficiently accurate for you, I think, and would be easy to add to vorbisfile. Otherwise (as happens currently), it actually decodes part of a packet just to throw it away (unless your seek point is at the start of the packet). It's actually fairly easy to make vorbisfile (libvorbis itself has no particular speed problem with seeking) much faster for seeking - there's a patch floating around somewhere for that, and it'll get committed sometime soon, probably (it's not perfect, though, so it hasn't yet been added). The alternative, if you need a solution _now_, is to not use vorbisfile (i.e. just use libvorbis/libogg directly). This is fairly easy for decoding straight through, but seeking is quite difficult to get right. Michael --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Thu, Mar 29, 2001 at 11:56:35AM +0100, fungus wrote:> > I realise the it's hard to do a seek in a variable bitrate > file but I didn't think it was this bad. It seems to vary > a lot with the file but the total time to do an ov_open() > and ov_pcm_seek() can add upp to a second or more. By this > time my DirectX buffers have wrapped around and are looping.Andrew from Sonique has submitted a seek patch that speeds things up considerably (for pcm_seek and pcm_seek_page) and I'll be applying it to CVS soon. It's also the case that you can just seek to a raw point in the file (raw_seek) and just start decoding. The bitrate doesn't vary that much, and vorbisfile will pick up the correct time offset from the file. (much of the delay is because vorbisfile prebuffers enough decode after a seek, up to the next PCM position marker, to be sure of the exact sample offset. Vorbisfile is meant to be a simple, easy to understand lib, not a 100% solution to every possible application). Monty --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.