Re: More Ming fun.... :)

Justin Clift wrote:
> Agreed, there's a lot of good toolsets handy for many approaches.  The
> CLIC approach (and the Beowulf) ones are pretty much for dedicated
> machines, whereas I was musing about something similar to say...
> Folding@Home (http://folding.stanford.edu), SETI@Home (don't remember
> the URL offhand), or similar.
> 
> The musing I was making here was that we already have millions of
> computers, across many architectures (x86, SPARC, PowerPC, etc), hooked
> up to the net and with a browser+flash installed.  Interesting platform
> concept to work from, as we don't need to install anything extra on the
> PC's, they've already got the main engine installed.
Ok.  If you keep your requirements to the lowest common denominator you will be
more successful.
i.e. Don't ask for tons of memory or hard drive space on the client machine.
Don't do much on the client machine.  Let the client do it.
Step one:
send client a message like go to some URL on another machine and not the
requester.  The URL holds for example all or part of a flash.  How it's broken
up, for now I don't know.

Step two:
the client machine gets the data into memory in an actionscript variable.
In this case it is a flash frame data I guess somehow.

Step three:
your actionscript does stuff to the memory.
I guess in your case it would take every pixel from the device context
representing the flash frame somehow and placing it into a results variable.

Step four:
the results in memory are then sent back via whatever comm link xmlSocket, blah
blah to a resulter machine holding all the frames as jpg/png data ready for
avi/ram stream assembly.   i.e. not the requestor machine.

The pre steps are planning who gets what to do, what they need to do it, and to
start it.
The post steps are the requester to get the resulter's status, and processed
data once completed.

So that's one kind of distributed job.  Then there's the compression job for the
video stream itself because if I remember correctly you want to make an avi from
your flash.  From what I understand it starts with the first frame being
complete as a jpg.  Then the real compression starts as a comparison from the
previous jpg frame to the next jpg frame.  I don't know if you're following me
but sometimes I wonder if I follow myself ;)
I suggesting a second batch job here that you could pass to every client being
you pass to the client two frame jpgs and your client computes the compressed
stream difference for the next frame.  Does this make sense?  I think it is much
more complicated than that but that's a gist about what the smoke and mirrors
have to do.

IMHO in an undistributed way, you will find the sources
dvdrip/openflashplayer/jpeglib/mp4ip have what you need to make what you want. 
It's just to reorder the sequence:
1)by taking a few code tidbits from openflashplayer when it displays a flash
frame and shoving into a jpg.
2)do 1) for every frame in the flash
3)extracting code from dvdrip/transcode to transcode an avi/mpeg for you from
your jpg's.
4)use mp4ip to convert the end result into a internet realplayer stream.  I am
not sure but Darwin Streaming Server serves up mp4ip produced streams.  Darwin
Streaming Server is an open-source project by the way that runs on linux and MAC
OS X.

I'm no expert I am just repeating what I've read somewhere.

Cheers,
David Marceau