I made an effort to recompile the lccs.swc by modifying the netstream for the WebcamPublisher to use h.264 but I couldn't get it to work. It wouldn't throw any exceptions and a debug of the code showed flash player executing my h.264 configuration however the video did not look any different than the Sorenson Spark codec.
I could get h.264 video to work if I just did a simple p2p netconnection/netstream app using rtmfp://stratus.adobe.com completely bypassing lccs. The video in this app with apples-to-apples quality/resolution/bandwidth to lccs looked/performed much better.
In the lccs code I modified the WebcamPublisher's createNetStream() method by performing the following code before returning the netstream:
|var h264Settings:H264VideoStreamSettings = new H264VideoStreamSettings();|
|_stream.videoStreamSettings = h264Settings;|
|return _stream ;|
So not sure what I'm missing but I just wanted to start testing this since the flash player 11 rc is available. Any pointers on what I might be doing wrong in modifying the lccs swc? Maybe the lccs server is reverting my h.264 configuration(if it could even do that) Any timeline on having a lccs beta from your side that has h.264 correctly setup?
On the surface, it looks as though you’re doing the right thing... You say you’re POSITIVE (trace statements, for example) that it’s going into the code block you’ve detailed? The server shouldn’t have any impact on the encoding (in fact, it would be REALLY expensive to have it do anything around transcoding).
Did you check also the webcam subscriber ? Could it be that you don't see the improvement in quality because the "receiver" end is not expecting h.264 ? Also, for what I remember the camera stuff is "evil code": if you don't resize the component correctly in order to match the webcam resolution you'll get some ugly scaling artifacts that make the output look horrible
The camera is twitchy. I've gotten h.264 working, but the audio/video syncronization is lousy. I've taken to rewriting the publisher in order to fix it.
As far as I can tell, there's no need to tell the subscriber what type of video to expect. It gets that information from the stream container itself.