[vorbis] Using vorbisfile with an in-memory file instead of FILE*
Olaf van der Spek
Olaf at XCC.TMFWeb.NL
Thu Dec 28 09:48:47 PST 2000
----- Original Message -----
From: "Michael Smith" <msmith at labyrinth.net.au>
To: <vorbis at xiph.org>
Sent: Thursday, December 28, 2000 4:40 PM
Subject: Re: [vorbis] Using vorbisfile with an in-memory file instead of
> >Is it planned to add const?
> >And maybe initial could be changed to const void*, so you don't need a
> >if you have for example an unsigned char*.
> Not particularly planned. It wouldn't break (or otherwise change) anything
> to add it, though. You don't need a cast here anyway.
Why don't I need the cast?
My input is unsigned char*, while the parameter is (signed) char*
> Feel free to send in a patch if you think it's worthwhile (you might like
> to see if there are other relevent places to add const qualifiers in
> vorbisfile while you're doing so).
Ok, I'll think about that, as the const_cast isn't neat.
> >Also, I tried to use an in-memory file with the following code, but that
> >code hung in ov_open.
> >I didn't setup the callbacks yet, but I thought that wasn't necessary
> >because of the real (empty) file.
> >Of course I'm going to setup callbacks in the future.
> >When I use the fwrite, but not the rewind, it seems to work.
> >When I use both fwrite and rewind, but not initial and initial size, it
> >works also.
> >What did I do wrong?
> Can't say, since you haven't given all the relevent code here. If you gave
> more code (specifically, that for get_data() and get_size(), I could give
I thought the usage of those functions in fwrite() would be enough to
understand how they worked. Giving the function code is also useless, as
they're simply single returns. The first returns the file data as const
byte*, the second returns the file size as int.
> conclusive answer, though if those are complex it'd be better to just give
> a simplified version of your code.
> My best guess, based on what the code might be doing, is that you're
> writing data to a file (this much is obvious) then
> a) not rewinding, and giving buffers with initial and ibytes. ov_open()
> will then read data from the buffer, and find that the file is at EOF,
Yes, but that should work, right?
> b) rewinding, and not giving extra buffers. Then ov_open() just reads
> from the file as normal.
That worked too.
The problem is that using an empty file and giving the buffers caused a
> If you rewind AND specify initial/ibytes, then the raw data gets read in
> twice, which isn't permitted (if this is the whole file, then you've
I didn't do that.
> essentially given a physical bitstream containing two logical bitstreams
> with the same serial number, which isn't allowed, so things fail. If it's
> part of the file (or part of the file is in the memory buffer), then
> corrupting the headers by sending them twice).
> Giving a memory buffer, and an empty (length 0) file should work, though
> isn't a particularly sensible way to do things unless you have extremely
> small files. Useful as a test, maybe, but go to using the callbacks ASAP.
Callbacks are done, see code. I was indeed testing and was wondering why it
ize_t null_read(void *ptr, size_t size, size_t nmemb, void* datasource)
int null_seek(void* datasource, ogg_int64_t offset, int whence)
int null_close(void* datasource)
long null_tell(void* datasource)
> --- >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 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.
--- >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 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