Steve Castellotti - [05/09/08 04:25 AM ] A temporary workaround for Linux users is available here: http://www.swift-tools.net/Flashcam/ Note that this video loopback based workaround requires significant CPU overhead during emulation.

Steve Castellotti - [05/09/08 05:15 AM ] Further details in the Blog post: http://swifthumors.blogspot.com/2008/03/linux-flash-webcam-headache.html

tom zerucha - [05/13/08 01:41 PM ] This is technically a duplicate of FP-137. I managed to adapt a version of the above tool for my Nokia tablets which uses little CPU (<10%, probably <5%), not much memory, and is all but transparent. However Flash itself is doubly broken - normally it will attempt to open the first /dev/videoX device, which will be the wrong one and most sites don't present a camera selector. This behavior is copied by other applications, so shuffling the minor device numbers and the video numeric suffixes breaks one or the other as they are all V4L version 2. The conflict can be solved it by changing the text string within the flash plugin from "/dev/video" to "/dev/v4lv1" or something similar, but apparently the EULA says fixing it in this way is forbidden. (Otherwise, is there someone at Adobe who could grant me and/or other developers permission to make this one specific change to the binary image?).

tom zerucha - [05/13/08 01:59 PM ] To clarify, the above program (flashcam) used a modified version of the video loopback kernel module to proxy V4Lv2 to V4Lv1, creating a video sink at /dev/videoX and video source (which is V4Lv1 compatible!) at /dev/video(X+1) (it can do multiple pipes). It then launches a program to continuously read from one device and write to the video sink, so flash can read from the V4Lv1 video source. The video sink will block if the video source is not being read, so it is designed to not consume CPU. Note I had to modify the video loopback further to make it block properly, but have verified with the patches on the Nokia tablets it works correctly. I did some further modifications to make a Nokia specific version of flashcam that was extremely efficient and would not open the camera device until Flash started reading and close it when it stopped so it would be completely transparent when not used (zero cpu, /dev/video0 works normally, etc.). This would work for ordinary Linux, but some further adaptation would be needed for various acquisition methods, multiple cameras, resolutions, etc. if you wanted everything to work transparently. The problem remains that the plugin wants to open /dev/video or /dev/video0 by default. So either the LD_PRELOAD shim is needed or the binary needs to be patched to point to a V4Lv1 device node, or some other mechanism.

tom zerucha - [05/16/08 07:12 AM ] I stand corrected - the default comes from the Flash Settings... which can normally be set in the dialog, but if flash attempts to open a V4L2 device, it crashes, so there is no effective way to set the default to the V4L1 device without something to prevent the V4L2 devices from being visible.

Markus - [05/21/09 03:58 PM ] I would rather call this a bug than a feature request because it practicly completely breaks web cam support for newer hardware on Linux. Rather than arguing about dirty workarounds (which i could not convince to work on my x86-64 ubuntu) you should natively provide V4L2 support ASAP!