A image challenge, is no lag possible?

[cody112]

Ok I am trying to make an online game in flash right now. But I am very much interested in making a way of making webcams viewable to other users, and I have gotten it working. But the one major flaw is that the images have to be small and speed at which a new one comes in has to be slow in order to avoid lag. Now I want to create a challenge to all possible to find a way to play through images like a movie without lag.

Can people tell me if there is a currently existing solution if you know there is?

Other than that, people are free to try and figure out how to get at least 12 fps playback of images of 200*200 pixels or higher. I appreciate any effort made by the threads viewers.

Makes me wonder why already on stage playback stays fast.

[5TonsOfFlax]

http://labs.adobe.com/technologies/afcs/

Adobe's service for collaborative applications. You can share webcam video with it.

[cody112]

http://labs.adobe.com/technologies/afcs/

Adobe's service for collaborative applications. You can share webcam video with it.

I'm sorry but I would prefer to use my own code to find a solution and not use anything outside flash engine like. Well I'm using Base64 for something, but its small bit it solves but it definitely helps. But yeah I would prefer flash in itself to be the solution, I won't decide otherwise till I get proof for sure that I can't avoid the lag.

[5TonsOfFlax]

You must already be using something outside the client-side flash, or else users would not be able to see anything from other users. If you prefer to keep everything open source and on your own servers, then you could use red5's rtmp processing stuff to handle video.

http://code.google.com/p/red5/

Why don't you describe what you're already doing? Here's my guess: every so often, you capture webcam video into a bitmap. You then JPG encode that bitmap (or PNG depending on whether you are trading time for accuracy), Base64 encode that, and send it to your server via an xmlsocket. Through the same or a different socket, your server passes that base64 encoded image to all the relevant clients who decode it on their sides and display it.

[cody112]

You must already be using something outside the client-side flash, or else users would not be able to see anything from other users. If you prefer to keep everything open source and on your own servers, then you could use red5's rtmp processing stuff to handle video.

http://code.google.com/p/red5/

Why don't you describe what you're already doing? Here's my guess: every so often, you capture webcam video into a bitmap. You then JPG encode that bitmap (or PNG depending on whether you are trading time for accuracy), Base64 encode that, and send it to your server via an xmlsocket. Through the same or a different socket, your server passes that base64 encoded image to all the relevant clients who decode it on their sides and display it.

Maybe I should have explained this lol.

I already am running my own custom made xmlSocket server made in java. I already set up the whole online part to it, I just need to find a way to stop the lag.

I am trying to run it as close to video level as possible, but the lag is overwhelmingly high. Like when I was doing it at 24 fps with 300*300 images. God I could say at 11 minutes in, the images were 5 minutes behind. In other words, what ever was showing up at the cam 6 mins after the scene started, was showing up five minutes later on the imagecam(thats what I call it).

So basically I need to overcome how big of an amount of data is being drawn into a whole image at a fast or atleast fairly fast speed. I say 2 fps with images at 75*75 is way to small and slow. I want to atleast be able to handle 200*200 images at 12 fps.

So I got the whole online dileyo down. Now the only thing left is making images shall I say smaller in filesize but keep them the same size.

[5TonsOfFlax]

Then you need to find a more efficient way to encode them. I'm no video codec ninja, but offhand I'd say you could encode only the changed pixels in a compact representation. You'd probably want to encode full keyframes every now and then, or when there's enough movement that the full frame would actually be smaller than encoding only the changed pixels.

You may also want to ditch the xmlsocket in favor of a binary socket, which should let you avoid the base64 serialization and some overhead.

You are, of course, re-inventing the wheel. Nothing particularly wrong with that if your goal is more about doing things than getting them done.