i don't think a direct mapping of COM to Plan 9 fs model is unnecessary. for example, instead of mapping every control or configuration interface and method to synthetic directories and files, a single ctl file will do.
It didn't occur to me at all that anyone would want to implement DirectShow or anything like that on Plan 9. Anyhow, I suppose if anyone's going to do that they should probably first work on fast display drivers that leverage modern cards' overlay capabilities and a facilitating media infrastructure equivalent to DirectX. On run-of-the-mill PCs good video works depends a lot on software support of video hardware, of course.
The logic inside most DirectShow filters either is open source (like ffdshow) or has good open source equivalents. The interfacing (COM), as you have noted, and input/output, which is hardware-dependent and therefore probably weakly developed in Plan 9 (I don't really have an idea, just guessing), are the missing bits from a DirectShow-like (multi-pipe) video processing pipeline on Plan 9.
--On Thursday, January 21, 2010 13:36 -0800 Skip Tavakkolian <9...@9netics.com> wrote:
Aren't DirectShow filter graphs and programs like GraphStudio/GraphEdit one possible answer to the video processing question? Filter graphs can be generated by any program, GUI or CLI, and fed to DirectShow provided one learns the in and out of generating them.DirectShow is COM; source/mux/transform/sink filters must provide a number of interfaces (e.g. IFileSinkFilter); other components (e.g. GraphBuilder) are there to make it easier to hook them together. i don't think a direct mapping of COM to Plan 9 fs model is unnecessary. for example, instead of mapping every control or configuration interface and method to synthetic directories and files, a single ctl file will do. something like this seems sufficient: /ctl # e.g. accepts run, stop, etc. returns: paused, #outputs, config, etc. /event # instead of callback notification /ipin/clone /ipin/n/ctl /ipin/n/event /ipin/n/data /opin/clone /opin/n/ctl /opin/n/event /opin/n/data for a special purpose kernel one could add a driver and a fancy new hook syscall (similar to pushssl and '#D') that would hook two fd's together to eliminate the need for a user proc to transfer between ipin/?/data and opin/?/data.
