Well I've never looked, but the nicely written library only has about  
150 lines of C code in mpeg3io.c
which is were all the fseek fread fopen fclose fstat etc work happens.

Seems to me you could alter that to talk to a buffer which contains N  
kbytes of data with a known start/end range.

Trick of course would be say to setup a C++ like exception handler
http://www.on-time.com/ddj0011.htm
and toss an exception when the seek or read is outside the buffer  
boundaries.  The plugin interfaces could be changed to
handle the exception and return primfail.  On primfail you could  
determine via another call what buffer is needed and populate the
internal buffer with data, then retry the cmd.

Or you could have two buffers findable (slang code is?) that you  
switch between and signal a squeak semaphore. The task
waiting on the semaphore is responsible for populating the buffer  
that is free with the next buffer of data.

Both assume data is read roughly sequentially and a buffer could  
satisfy M frames of video. However I'm not sure if audio is
located elsewhere in the file or mixed in with the video, which would  
make things a bit harder.


On 20-Dec-05, at 6:21 PM, Josh Gargus wrote:

> Hi everyone (John :-),
>
> Do you have a feeling about how difficult it would be to adapt the  
> Mpeg 3 plugin to read from an in-memory buffer instead of from a  
> file?  Did the current file-based design follow something file- 
> specific about the libmpeg3 API,  or was it based more on the  
> anticipated use-cases for the plugin?
>
> Thanks,
> Josh
>

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===