Camera Class Quirks with FMS

I did a project recently requiring a web camera recording to Flash Media Server 3. Whilst I was working on this I found out some interesting (annoying) things about the Camera class. These include :

Tip 1.

When initiating a connection to the Camera it’s best to do this through the Microphone class. Sounds odd I know! The reason for this is when this code is called :

var camera:Camera = Camera.getCamera();
ns.attachCamera(camera);

there’s a hang just after the allow button is selected on the security dialog panel. This is rationalled in the Adobe Flash help as ‘Scanning the hardware for cameras takes time’. So it’s best to trigger the security panel via

var microphone:Microphone = Microphone.getMicrophone();
ns.attachAudio(microphone);

then listen for the Status Event of UnMuted or later in your application call

var camera:Camera = Camera.getCamera();
ns.attachCamera(camera);

There will always be a delay on this code ns.attachCamera(camera); but at least via activating the Microphone first you won’t get a bug like delay of the security panel not disappearing immediately after the allow button is pressed.

Tip 2.

When recording to a Flash Media Server make sure the camera has activity via the Activity Status Event before publishing the stream. Otherwise you may get a static or black frame at the beginning of the recorded stream.

Tip 3.

To disable/turn off the Camera after a recording is complete do so via :

ns.attachCamera(null);

Though this is actually documented for AS3 it wasn’t in AS2. Once this has been done the Camera will need to be reconnected for a new recording and users will experience this delay again as the Camera starts as mentioned above.

Tip 4.

When embedding your Flash do not change the wmode from default. Otherwise you will get problems on specific browser configurations i.e. Firefox PC . These problems include that the allow button on the security dialog box will not hide on click.

Tip 5.

When detecting wether the user has a web camera you can’t rely on Camera.names.length(). This is because there are scenarios whereby devices will appear in the list which may not be webcameras but devices like TV capture cards and can not be used as a camera. The solution for this is when the camera is attached via

var camera:Camera = Camera.getCamera();
ns.attachCamera(camera);

Then add a time out catch which can be cleared via the camera’s activity event, so that if camera activity occurs within the time out of say 5 seconds then clear the timeout. Otherwise if the timeout happens handle the error scenario.

Tip 6.

Further to the above it’s good at the point of displaying the error message to give the user an option to fix this problem. This is because it may simply be a matter of the user changing the default camera selected. This can be done via adding a button and firing the Camera devices security dialog by the following :

Security.showSettings(SecurityPanel.CAMERA);

It’s interesting to know that when the user is selecting options from the Camera devices list it’s possible to detect wether the option selected is actually a Camera. Once again this is done via camera.activityLevel>0 on the Camera’s activity event. Sadly there is not yet a reliable way to detect when the dialog panel close event occurs. So with this in mind when the user has picked a camera, you should make a noticible visual change somewhere behind the dialog box (and overlay screen) so the user will proceed to the close button – happy days.