Re: [9fans] dataflow programming from shell interpreter

[Eris Discordia <eris.discordia@gmail.com>]

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.

The OP's question, too, finds one answer in MS PowerShell where instead of
byte streams .NET objects are passed between various tools and a C#-like
shell language is used for manipulating them. .NET objects can at any point
be serialized/deserialized to/from XML using stock classes and routines in
System.Xml.Serialization namespace.

Just a note that at least some implementations of both ideas exist in
production settings.


--On Tuesday, January 19, 2010 15:40 +0000 Steve Simon <steve@quintile.net>
wrote:

>> The PBM utilities (now net pbm) did something similar for bitmaps.
>> I think V10 also had some pipeline utils for manipulating images.
>
> Indeed, however I make a firsm distinction between image proccessing (2d)
> and video processing (3d).
>
> In Video processing the image sequences can be of arbitary length, the
> processing is often across several fields, and, because we want our
> results ASAP tools should present the minimum delay possible (e.g. a
> gain control only needs a one pixel buffer).
>
> Aditionally image processing pipelines often have nasty things like
> feedback loops and mixing different paths with differing delays which all
> need special care.
>
> We have a package of good old unix tools developed jointly by us and the
> BBC which works as you might expect
>
> 	cat video-stream | interpolate -x 0.7 -y 0.3 | rpnc - 0.5 '*' | display
>
> however this can get quite ugly when the algorithm gets complex.
>
> We need to cache intermediate results - processing HD (let alone 2k 3d)
> can get time consuming so we want an environment which tee's off
> intermediate results automagicially and uses them if possible - sort of
> mk(1) combined with rc(1).
>
> It is also a pain that its not easy to work at different scales i.e.
> writing expressions to operate at the pixel level and using large blocks
> like interpolate, the rpnc is an attempt to do this but its interpreted
> (slow).
>
> a restricted rc(1)-like language which supports pipelines,
> and scalar (configuration) variables combined with a JIT compiler
> (in the vein of popi) looks like a solution but I have never go further
> than wishful thinking.
>
> -Steve
>