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
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@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Thanks John, that makes sense. I think it's a bit too involved for me right now, but I'll keep it in mind.
Josh
On Dec 21, 2005, at 1:30 AM, John M McIntosh wrote:
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@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com ====================================================================== =====
squeak-dev@lists.squeakfoundation.org