Strange you mention this, since that's exactly what my project does, hear me out:
The captorials.com website is only one (major) module in the larger Instrudeo-project. The project was started to bring screen-capturing (video, not screenshots) into the "open-source world", together with some revolutionary ideas surrounding this. I started out with a simple vncrec program, studied the source and optimised it. Created a new file format that only records the updated pixels in the X frame buffer. The rectangle gets gzipped (RLE) and a special "seekback-frame" is generated. This is the rectangle you need to go back to, to rebuild the stream (in this way, when seeking backwards, you don't have to re-generate the stream from frame zero). The results I get from this method are very good. At least the filesize (better than flv with one keyframe). Moreover: all lossless. Because of the nature of the sequential file format, seeking is not always very efficient, but I don't get any unacceptable seek-times when seeking back. Because I use VNC/RFB, there's no need to actively look for the updated regions: RFB does this for me. Even better: with the fairly new and optimized NX-protocol, it may even be possible to host different environments that can be accessed (and proxied/recorded) on a central cluster, serving a very large userbase. Since the file-format gets converted to FLV by the processing webservice, a lot of efficiency/tight filesize gets lost because of the inserted keyframes, not to mention the need to use a proprietary fileformat. My ultimate goal is to stream directly from my own file format, only sending the rectangles to the client, add some logic in the flash-player and saving enormous amounts of bandwidth. The main drawback for this is the needed ability to seek through the files and the massive amounts of memory this will require (commentboxes are drawn in OpenGL) when the load gets higher. The whole philosophy of the project is to do more with remote-computing and -recording; starting off with a client that records a stream, a user that edits it (commentboxes, clipping, ...), a service that receives the work, a machine that post-processes it (eg. automated translation), and een website that publishes it. As I speak, all of this is implemented (beta, roughly) and 90% will be GPL'd before july (together with the file-formats). I'm not trying to push anything here, I just would like to hear your comments on this. Perhaps trying to find some co-developers here and there, or at least some curious users who want to experiment together with me. I'l love to hear more from you on this. Bram On Thursday 15 June 2006 01:47, . m a r c o s a u g u s t o wrote: > I think that screen sharing should not be tratated as video. > I m looking further for screen sharing, live primary... > > Correct me, but sorenson (video codecs in geral) isn't all that good for > it.. I mean.. it will send duplicated info anyway, > I was thinking about: > > getting the screen as a video inside the player > check all the pixels with 2 loops, get what is changed, compact those > pixels to png or jpg (inside the player 9) > send only this changed information.. compacted as image.. with its X, Y > pos... > And... least but not last, get the mouse as vetorial information.. and > transmit in SO too... > > what u guys think? > > another thing, vnc2swf.. something like vnc2red5... sure vnc should be > studied for this... > > but anyway.. the point is.. mouse as info from the system, and send only > and only changed pixels... > > On 6/14/06, Bram Biesbrouck <[EMAIL PROTECTED]> wrote: > > On Wednesday 14 June 2006 18:09, Joachim Bauch wrote: > > > Hi Bram, > > > > > > Bram Biesbrouck wrote: > > > > Come on you guys, there must be someone who has a clue? > > > > > > Sorry, I don't have an idea but as Steven is refactoring the streaming > > > code in the trunk, there might be some issues he's currently working > > > on... > > > > > > Please note that we all are developing Red5 in our free time, so during > > > the weekdays responses to emails could take some time! ;) > > > > I'm sorry, honestly. > > I'm working on this for over a half a year now, with no earnings at all, > > and > > it takes 100% of my time, so I really know what you are talking about. > > :-) I'll take a look at the trunk to see it provides some better results. > > I think someone announced the next stable release soon, so perhaps I > > should > > wait until then to work my way through the Java-code to search for some > > bottlenecks myself and contribute my share. > > > > b. > > > > _______________________________________________ > > Red5 mailing list > > [email protected] > > http://osflash.org/mailman/listinfo/red5_osflash.org _______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
