FFI, Ogg Vorbis, and char[]
Jason Dufair
jase at dufair.org
Fri Nov 22 21:27:15 UTC 2002
Bert Freudenberg wrote:
>That *is* ugly. I guess you have to dissect the structure by yourself
>(pointer arithmetics). What does the structure actually look like?
>
>
Here's what the struct looks like:
typedef struct {
unsigned char *body_data; /* bytes from packet bodies */
long body_storage; /* storage elements allocated */
long body_fill; /* elements stored; fill mark */
long body_returned; /* elements of fill returned */
int *lacing_vals; /* The values that will go to the segment
table */
ogg_int64_t *granule_vals; /* granulepos values for headers. Not compact
this way, but it is simple coupled to the
lacing fifo */
long lacing_storage;
long lacing_fill;
long lacing_packet;
long lacing_returned;
unsigned char header[282]; /* working space for header encode */
int header_fill;
int e_o_s; /* set when we have buffered the last packet
in the
logical bitstream */
int b_o_s; /* set after we've written the initial page
of a logical bitstream */
long serialno;
long pageno;
ogg_int64_t packetno; /* sequence number for decode; the framing
knows where there's a hole in the data,
but we need coupling so that the codec
(which is in a seperate abstraction
layer) also knows about the gap */
ogg_int64_t granulepos;
} ogg_stream_state;
The outer structure (OggVorbis_File) has various fields and nested
structures (one of which is this ogg_stream_state). This is the only
place where I actually see an array of chars - I realize I typed the
declaration incorrectly in my earlier email. I doubt I'll ever need to
use that buffer in my code, but I'm not sure how to tell
ExternalStructure to just move ahead 282 bytes. Any ideas?
--
Jason Dufair - jase at dufair.org
http://www.dufair.org/
<xterm> The problem with America is stupidity. I'm not saying there
should be a capital punishment for stupidity, but why don't we just
take the safety labels off of everything and let the problem solve
itself?
More information about the Squeak-dev
mailing list
|