[vorbis-dev] Problems with vorbisfile

Maciej Miasik maciek at detalion.com
Sat Mar 17 23:17:13 PST 2001



Hi,

I downloaded libvorbis plus vorbis-sdk, started a new project (a Win32
console application) in my Visual C++ 6.0 Standard Edition under Windows
ME, pasted vorbisfile_example.c to my only source file, fiddled with some
include and lib directories and successfully compiled the example. It took
me some time to get rid off of library symbols conflicts - I couldn't link
the program with static libraries therefore I used the dynamic ones. I run
the program and it immediately crashed in the kernel. Hmm...

I run the debug session only to discover that it crashes in ov_open(), or
rather deeper in some ogg/vorbis functions I couldn't debug, while
performing some seek operation. Strange, but what could I do with that?

I wrote my own code based on the same example hoping that it would help me
in some way. No luck, it crashed in the same position. I thought that I'm
helpless.

I took a look at vorbisfile source to discover that ov_open() only sets up
the file callback functions and immediately calls ov_open_callbacks():

ov_callbacks callbacks = {
  (size_t (*)(void *, size_t, size_t, void *))  fread,
  (int (*)(void *, ogg_int64_t, int))           _fseek64_wrap,
  (int (*)(void *))                             fclose,
  (long (*)(void *))                            ftell
};

return ov_open_callbacks((void *)f, vf, initial, ibytes, callbacks);

I cut this fragment of code and pasted into my program in place of
ov_open() call. Unfortunately I couldn't compile it because I didn't have a
prototype for _fseek64_wrap(). I already knew that seeking caused problems
and the vorbisfile lib would treat the stream as unseekable if the seek
function returned -1. I wrote a simple seek functions returning -1 and
placed it in the callbacks structure. After that the vorbisfile_example
compiled and run fine, and my version of the code as well. There's
definitely something wrong with vorbisfile library as Visual C++ users are
concerned.

I also had some problems with using ov_read() - I pass to this function a
number of bytes I want it to return (the docs suggest 4096), but it always
(at least with my ogg/vorbis files) returns 512 or less bytes depending on
the current packet or something. It messed a bit my code because I had
alreayd set up the playing buffers to be 4096 bytes in size and supposedly
simple code suddenly became more complicated. I quickly figured out when I
set the buffer to 512 bytes I needed to make only one additional call to
ov_read() to fill the buffer - the buffer is always filled with 2 calls at
most - this obviously would need more testing with my files but I wasn't
writing all purpose decoder but the decoder capable of reading a well
definded set of files. But this leads to one very important questions -
couldn't just ov_read() return all the bytes the caller requests? Just one
call to fill the buffer and job done and the code in ov_read() takes care
of everything else... That code could be written with somone with deeper
knowledge of ogg/vorbis files structure in order to avoid problems with
missing packets/date freeing the users like me from digging into it - we
just want to easily implement the decoding not to learn the technology
inside out.

Maciek

---
Maciej Miasik - Game Developer 
www.detalion.com

--- >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-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.




More information about the Vorbis-dev mailing list