It is definitely too slow to compress every frame and save it while recording (unless the frame size is tiny I’d guess).

But it very well might be possible to at least convert every bitmap into an uncompressed FLV frame in real time, so that it gets saved to FLV instead of using the intermediate “RAW” format that the app uses now.

Running a background service in C++ or .NET or Java that the app could send the raw data to for compression in realtime would be very cool, and doable, it seems to me.

One thing I’m very keen on is the potential of using Alchemy in tandem with an opensource C++ library to convert a series of BitmapData’s (the raw video data) into x264, Xvid, and/or MPEG2, all on the client side, all within Flash… I think the first implementation of this idea could create quite a sensation…

Thanks,
Lee

If you compressed it, would it slow down the capture rate? I haven’t experimented with this yet, so this is why I ask.

I was also thinking that although this is great, it might be more efficient to hook the display driver with c++ or even a managed language like c#; yet, have it run in the back ground and keep the interface a flash based one; as well, the same would go for the audio data.

Too bad all these workarounds have to be done to achieve something which should be simple.