Re: [9fans] dataflow programming from shell interpreter

[Patrick Kelly <kameo76890@gmail.com>]

On Jan 20, 2010, at 4:13 PM, Eris Discordia <eris.discordia@gmail.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.
>
> 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.
Why XML? Surely there are better options.
>
> 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
>>
>
>
>
>
>