[GEM-dev] VideoIO Framework

[IOhannes m zmoelnig]

chris clepper wrote:
> Why are you doing this?

he is basically doing this, because i told him so. (you could have
guessed;-))
we (that is: the iem) proposed this project as a gsoc-project, and it
was accepted.

>   I can maybe see the utility on Linux but what
> you propose makes no sense on OSX or Windows.

it makes sense on windows, as there are already 2 (or 3, if you count
the old vfw/avi stuff) APIs (directshow, quicktime).

on os-x things are a bit different, as there is basically just one API.

nevertheless, the platform that will benefit most from it will be linux.


furthermore, the proposed videoIO framework might (in a 2nd step) be
extended to be usable not only by Gem, but by other libraries (pdp,
GridFlow, probably pure-pd once it gets that far...) too.

the main reason for doing so is to separate the grabbing/outputting code
 from the Gem core, in order to reduce dependencies on dynamic
libraries. i don't know how things are now (because i spend so little
time in front of w32-machines), but iirc adding QuickTime support to the
w32 (which was a great thing to do), also added the need to have the
quicktime-framework installed, in order to use Gem at all (but i might
be completely mistaken here, so forgive my ignorance).


> On 6/12/07, Thomas Holzmann <holzi1 at gmx.at> wrote:
>> Hello,
>>
>> I have been chosen for Google Summer of Code and am working on a video
>> input-output framework for GEM.
>> This framework should make it possible to load different video
>> encoders/decoders at runtime so that there is no need for them to be
>> available at compiling time.

the framework should cover:
 - READING: random access reading of media (e.g. movie files; images,
frameserver read access)
 - READING: stream readers (camera input, web video-stream input)
 - WRITING: stream writers (movie files, video out (e.g. firewire), web
video streaming, images, sending data to frameservers)

so basically it should provide the grand unified API for r/w access of
image data.

this should (in theory) make it easier to add r/w capabilities of
image-data to all sorts of objects, not just the [pix_video],
[pix_film], [pix_write], [pix_record]: for instance it might make the
[pix_share_*] objects obsolete (could be covered by
[pix_streamIN]/[pix_streamOUT]), or [pix_buffer] could very easily have
read and write capabilities,....



>> So if you have some suggestions for my project it would be nice to let
>> me know.


while we have some rather ok knowledge on how things work on linux, it
would be good if people familiar with os-x and windows (chris, that's
you!) shared some of there knowledge so that the framework can be
designed in a way that it will be possible to add QuickTime and
DirectShow support efficiently once someone is in the mood for doing so.

since i think that these APIs are fundamentally different from most (if
not all) linux APIs, it would be good to not repeat the filmNEW and
videoNEW problems, that kind of mapped not so easy to QT/DS as i would
have wished.

so chris, even if you are not interested in this project and have better
things to do, it would be very nice if you could warn thomas of possible
pitfalls with his project.

in the end we might all benefit from such a thing (or not; but we will
only know afterwards)


mfga.sdr
IOhannes