From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 22 Jan 2010 09:44:56 +0000 From: Eris Discordia To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: In-Reply-To: <19fdeb6b36ad349c8856ef7330812e5e@9netics.com> References: <19fdeb6b36ad349c8856ef7330812e5e@9netics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [9fans] dataflow programming from shell interpreter Topicbox-Message-UUID: c25a3db8-ead5-11e9-9d60-3106f5b1d025 > 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 <9nut@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. > >