Is it possible to have an network-streaming filter?

[slow_as_hell]

Hi,
Although I have read a prior discussion about distributed computing and rendering of dv-material in this forum, I still wonder if it might be possible to have a filter for AviSynth that can act as stream-server on an tcp/ip network even if the sent data would be huge.
It could have a server and a client component in one dll. It would then be placed as the last filter in the script. If the server is set up on a specific tcp/ip port on one computer it waits for some client to connect and would stream the already processed frames to the client. Since it needs a player to be "activated" it could send a "fake" clip to the player containing info about the streaming process, like "client connection: yes/no", number of frames send, etc. The client would be in a avs-script as well and could therefore be played or compressed in any application that reads avs-scripts.

Since I have read how the filter chain works it could be possible, since AviSynth is not sending frames backwards through the chain, just requests to process a frame.

I'm sorry if my question may be not clear enough due to my "german" english. if anyone should be interested at all please feel free to ask for clarifications.

SAH

[sh0dan]

I see no problems in implementing this as a plugin. It would however have to be multithreaded, or otherwise lock up vdub while it is serving.

Probably a small pop-up GUI would make sense.

[Malcolm]

if you have 2 PCs connected in a LAN, you could process AVIs via avisynth on one pc while encoding the result on another pc..!!

Or split your avs in 2 and do the first part of the processing on one pc and the rest on another pc..

[slow_as_hell]

Originally posted by sh0dan
I see no problems in implementing this as a plugin. It would however have to be multithreaded, or otherwise lock up vdub while it is serving.

Probably a small pop-up GUI would make sense.

First of all, thank you for you quick answer :)
And after that:
I guess it would be easier if the server is a standalone app, that just gets the stream from AviSynth and serves the video+audio. so no other prog would be needed (and possible cause any trouble :) )

@Malcolm: that's exactly why I thought this kind of filter would be useful. unfortunately I'm not able to code at all, or I would try to provide this kind of filter. I was just asking out of curiosity and maybe to inspire someone who is more capable in conceiving and programming such a filter, than I am.

[Richard Berg]

I wrote an ISAPI filter that called Avisynth once. It was pretty nifty, but requires IIS, which would rule out Win9x. A real implementation (as an Avisynth plugin) would be better, I'd just have to brush up on how to use raw sockets in Windows.

Next time I have free time to code, however, I've already committed to finishing the new alpha/transparency framework. Anyone else feel free to grab this one.

[esby]

For the computer to computer serving part:

I think you just need two applications,
one that decompresses the avi and send it frame by frame uncompressed,
Another one that take these frames and redirect to vdub,
something like avisource in fact...

and a simple dialog protocol
using stuff like that
askframe(XXX);
asknextframe;
reaskcurrentframe;
etc.

In this case, video decoding & filtering could be done
on a computer and encoding on another one,
supposing the data transmission doesn't take all the cpu power.

For a global distributed encode, what would be needed could be:
a server sending pack of frames to encode
some slaves doing the dirty job and sending the job once done back to the server...
The main problem being that using such strategy requires to know
how to segment frames in a non linear approach, and would probably
be not fully compatible with the encoding control of the actual existing codecs or tools.
Eg: Even if you do a dummy 1st pass to find the segmenting Kf,
you won't be able to control the frame size properly with the actual algorithm,
of course reducing bitrate of the next pack to be encoded would work,
but it's probably not the cleaner or the safer method...

esby