Interesting idea, just streaming thought rtmp the display changes as AMF at level of VNC protocol (if I did understand that correctly)
On 6/14/06, Bram Biesbrouck <[EMAIL PROTECTED]> wrote: > 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 > -- Roberto Saccon _______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
