Hi, I have a 21.1134 built on 64-bit Linux machine last week and it works fine.

So first of all, have you enabled the media-stream and peer-connection flags?
Second, maybe you can try to use another camera, as mine are logitec 9000 and C910, both are fine.

Strange,
I tried the cromium current build (18.xxx), the google-chrome-beta and the google-chrome-dev and all of them show the same issue to me. The cam is registered as /dev/video0 and works with the google-talk-plugin as well as skype or even vlc.. the only video client that doesn't work is the webrtc implementation in chrome.

Weird. At least the Beta Chrome, version 19.0.1084.46 beta, also works on my Linux box.

Did you really follow the instructions on https://sites.google.com/site/webrtc/running-the-demos ?

And where do you find those error logs? Could you show me the JS log, at Settings->Tools->JavaScript Console?

Even the "red dot" appears after granting access to the webcam.. the JS Console gives me the following with opening apprtc:

Initializing; room=84812591. /?r=84812591:88
Opening channel. /?r=84812591:99
Requested access to local media with new syntax. /?r=84812591:122
Channel opened. /?r=84812591:182
User has granted access to local media. 

really weird.. any idea were should I have a look at?

The errorlog I posted appeared on the terminal after opening chrome and going to apprtc..

OK. Thanks for all the info.
It's because there is some error when we try to open that camera. Since GTalk plugin could open that device, it means they did more compatible works.

To help us, could you let us know the exact device model you have? And also can you try other cameras, such as the logitech ones I listed before?

I tried with the integrated and two other Logitech cams, they all were registered as /dev/videoX, even google chrome lets me select them in the access to the webcam dialog (I will attach a screenshot). My notebook is a lenovo x121e and the webrtc worked with ubuntu 11.10 as well as 12.04. I have absolutely no idea why the webrtc doesn't start the webcam, but I am sure that this is not happening because of the webcams I use.. 

	2012-05-17-152408_1366x768_scrot.png 76.3 KB View Download

Hi Christian,

Could you list the logitech cams model here? It's hard for us to get a Lenovo x121e, maybe it's easier to find same cams. 
So far there is no enough info to know what's going wrong. The most reasonable thing should be we try to replicate your failure here. If we can't reproduce it, we can't know the reason.

And have you ever tried on another linux machine, such as a desktop? It's better to exclude any platform specific problem.

I only know one of the models used: A logitech C160 USB.
The cam integrated in the lenovo isn't easy to identify, but shouldn't matter because they where all treated the same way by my system. The same machine works with Ubuntu, using the same webcam(s) and webrtc! But after switching to archlinux everything else but google-chrome with webrtc works. Maybe the the fresh kernel could make problems? Did you take a look to my attached error log? What is meant by "Not implemented reached"?

Ah, Thanks for the clarification. Now things are more clear.
I misunderstood your previous comments. Since webrtc works on Ubuntu 11.10/12.04, so the culprit should be Arch Linux itself. I guess it might be the too-new kernel 3.3.5. I'm not sure whether it's a bug in this kernel or this version changes something with V4L2. We access the camera via V4L2 interface only, you can refer the codes at "chromium/src/media/video/capture/linux/video_capture_device_linux.cc".
We woud be grateful if you can help to debug a little bit. You can do some V4L2 operation as same as that file shows, or you can build a webrtc and run the vie test app. Then we would know what the problem is.

And answer your question: those "Not implemented" logs just mean those are some functions we haven't implemented yet. It's because the failure at opening a camera, then you will see those log. 

I'd like to help you debug this issue. Since I had some kernel updates which all show the same problem, I would suggest the kernel doesn't matter.
It could even come with some 64Bit/32Bit issues..
Next step for me is to compile the client on my own and have a try with it.

Thanks so much!
And I just wonder what's gonna happen on an elder version of Arch Linux with kernel before 3.2? 

I don't get the right dependencies for building the demo peerconnection_client on ArchLinux, therefore that's not the way to exclude some possible reasons for this issue. But: Running apprtc in loopback-mode as mentioned in the webrtc mailing list, the sound is looped! Which means to me that the whole peerconnection stuff should work. The only point that isn't running is the webcam, which is still not initialized.
My kernel version right now is 3.3.7.. I ran chrome with --enable-logging, but the logfile didn't show something interesting.. any other ideas?

I got the same troubles.
Same configuration as christian667.

Great, now I have some hope this isn't fault!

If you choose to debug with webrtc building, I think the vie_auto_test would be more suitable for debugging this issue. Please try sync to the newest trunk and build. Then you can find the vie_auto_test app in src\build\Debug. The relative source code is under src\video_engine\test\auto_test\source\vie_autotest_custom_call.cc.

You can try to run with option 7 for a simple loopback test. The trace file would locate under src\out. Let's see what's in it at present.

Same problem here, current 32-bit Slackware distro, stable 3.4.0 kernel. Camera [ simple UVC 1.00 device Webcam C170 (046d:082b) ] works with all apps, including internal chrome flash plugin, except chrome webrtc module [both failed: latest canaries and betas] - chrome shows the same error, camera led is off in any demo/app.

..............
[Dao]:rus:~ # google-chrome --enable-media-stream --enable-peer-connection --enable-p2papi --enable-webgl 
[31:31:6591341473:ERROR:peer_connection_handler.cc(107)] Not implemented reached in virtual void PeerConnectionHandler::OnStateChange(webrtc::PeerConnectionObserver::StateType)
[31:33:6591342818:ERROR:capture_video_decoder.cc(68)] Not implemented reached in virtual void CaptureVideoDecoder::OnStarted(media::VideoCapture*)
[31:33:6591343592:ERROR:video_capture_module_impl.cc(93)] Not implemented reached in virtual void VideoCaptureModuleImpl::OnStarted(media::VideoCapture*)
[31:33:6591354385:ERROR:video_capture_module_impl.cc(125)] Not implemented reached in virtual void VideoCaptureModuleImpl::OnDeviceInfoReceived(media::VideoCapture*, const media::VideoCaptureParams&)
[31:33:6591354513:ERROR:capture_video_decoder.cc(84)] Not implemented reached in virtual void CaptureVideoDecoder::OnError(media::VideoCapture*, int)
[31:33:6591354533:ERROR:capture_video_decoder.cc(88)] Not implemented reached in virtual void CaptureVideoDecoder::OnRemoved(media::VideoCapture*)
[31:33:6591354547:ERROR:video_capture_module_impl.cc(106)] Not implemented reached in virtual void VideoCaptureModuleImpl::OnError(media::VideoCapture*, int)
[31:33:6591354562:ERROR:video_capture_module_impl.cc(110)] Not implemented reached in virtual void VideoCaptureModuleImpl::OnRemoved(media::VideoCapture*)
[31:31:6591550363:ERROR:media_stream_impl.cc(374)] Not implemented reached in virtual void MediaStreamImpl::OnVideoDeviceFailed(const std::string&, int)
[31:31:6594729664:ERROR:peer_connection_handler.cc(107)] Not implemented reached in virtual void PeerConnectionHandler::OnStateChange(webrtc::PeerConnectionObserver::StateType)
..............

As I see the chrome webrtc failed to open the device as it using the wrong/missed name 'Default' despite the selection that was made on initial camera access dialog.

P.S. Just downloaded the latest beta (20.0.1132.21) and found that the internal flash plugin stops work with camera too - during opening the SWF the camera led shortly blinks. The previous beta (19.x) works with flash and camera. The webrtc module has the same behaviour - no work, no led blink at all.

Same issue as the OP; 21.0.1163.0-140240 on Fedora 17 (kernel 3.3.7) both x86_64 and i686; uvcvideo-driven camera.

Having enabled verbose debugging in the driver with

# echo 0xffffffff > /sys/module/uvcvideo/parameters/trace
# echo 0xffff > /sys/module/videobuf2_core/parameters/debug

I observe the error:

...

[116074.790460] uvcvideo: uvc_v4l2_ioctl(VIDIOC_REQBUFS)
[116074.790985] vb2: Buffer 0, plane 0 offset 0x00000000
[116074.790987] vb2: Buffer 1, plane 0 offset 0x00096000
[116074.790989] vb2: Allocated 2 buffers, 1 plane(s) each
[116074.790994] uvcvideo: uvc_v4l2_ioctl(VIDIOC_QUERYBUF)
[116074.791657] uvcvideo: uvc_v4l2_mmap
[116074.791660] vb2: Invalid vma flags, VM_SHARED needed
[116074.792533] uvcvideo: uvc_v4l2_release
[116074.792719] vb2: streamoff: not streaming
[116074.792766] vb2: Freed plane 0 of buffer 0
[116074.792804] vb2: Freed plane 0 of buffer 1
[116076.792147] uvcvideo: Suspending interface 1
[116076.792155] uvcvideo: Suspending interface 0
...

trying to figure out why VM_SHARED is missing.

vie_auto_test --automated --gtest_filter=ViEStandardIntegrationTest.RunsCaptureTestWithoutError

passes.

The driver logs show successful initiation of the video streaming from the camera:


[267861.070456] uvcvideo: uvc_v4l2_ioctl(VIDIOC_S_FMT)
[267861.070464] uvcvideo: Trying format 0x56595559 (YUYV): 640x480.
[267861.070468] uvcvideo: Using default frame interval 33333.3 us (30.0 fps).
[267861.072091] uvcvideo: uvc_v4l2_ioctl(VIDIOC_REQBUFS)
[267861.072591] vb2: Buffer 0, plane 0 offset 0x00000000
[267861.072593] vb2: Buffer 1, plane 0 offset 0x00096000
[267861.072595] vb2: Allocated 2 buffers, 1 plane(s) each
[267861.072600] uvcvideo: uvc_v4l2_ioctl(VIDIOC_QUERYBUF)
[267861.072618] uvcvideo: uvc_v4l2_mmap
[267861.072647] vb2: Buffer 0, plane 0 successfully mapped
[267861.072650] uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF)
[267861.072653] vb2: qbuf of buffer 0 succeeded
[267861.072655] uvcvideo: uvc_v4l2_ioctl(VIDIOC_QUERYBUF)
[267861.072658] uvcvideo: uvc_v4l2_mmap
[267861.072682] vb2: Buffer 1, plane 0 successfully mapped
[267861.072684] uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF)
[267861.072687] vb2: qbuf of buffer 1 succeeded
[267861.072775] uvcvideo: uvc_v4l2_ioctl(VIDIOC_STREAMON)
[267861.072779] vb2: Streamon successful

Hi, many thanks for the great info. Could you please run vie_auto_test with a simple loopback test, option 7? Please let us know if you can see the local view. And please update the trace file "ViELoopbackCall_trace.txt" under 'trunk\out' folder if you fail to see the local view (please keep the test short after start a call, e.g less than 10s, to keep all the traces of initialization).

I'm still fighting to connect a camera to the newly installed VM, which would cause the VM halting. :(

I have only remote access to the devel box ATM so I run the test without seeing the local view on the screen.  However, the test passed, and the kernel log contains correct debug messages from the driver.  The requested log attached, even though it doesn't contain anything interesting.

The problem is only observed when using google-chrome.

ViELoopbackCall_trace.txt 1.6 MB View Download

The sequence of system calls leading to the problem is fairly short:

open("/dev/videoN")
ioctl(VIDIOC_S_FMT)
ioctl(VIDIOC_REQBUFS)
ioctl(VIDIOC_QUERYBUF)
mmap()

so there are not so many places to check ;)

Unfortunately strace can't interpret the arguments of VIDIOC_* ioctls; I'll try to figure out a better way.

What source code in chromium is responsible for the above operations?  It doesn't appear to be the same as what is in webrtc trunk now.  At the very least, google-chrome mmap()-s the video device file with PROT_READ while webrtc code uses PROT_READ|PROT_WRITE (see src/modules/video_capture/main/source/Linux/video_capture_linux.cc).

This *isn't* the cause the problem (webrtc tests work without PROT_WRITE just fine), but it indicates that the code is different. 

Many thanks again! It might not be the system calls but the video format we pass to V4L2 that might change in the new kernel. 
the relative source code is here: http://code.google.com/searchframe#OAMlx_jo-ck/src/media/video/capture/linux/video_capture_device_linux.cc

Well, the requested video format is passed via ioctl(VIDIOC_S_FMT), so this was among the suspects I listed ;)

However, according to the kernel logs the format is the same:

[116074.788805] uvcvideo: uvc_v4l2_ioctl(VIDIOC_S_FMT)
[116074.788812] uvcvideo: Trying format 0x56595559 (YUYV): 640x480.
[116074.788814] uvcvideo: Using default frame interval 33333.3 us (30.0 fps).

in both cases.

It's also weird that all ioctl-s succeed and it's only mmap that fails.

Thanks for the link to the source; it does match the strace from google-chrome.  I don't see any significant difference to the webrtc version which might be proclaimed guilty, though.

Yep, there shouldn't be many differences between the two versions. 
It's worthy to try to call mmap with PROT_READ only in webrtc, as a quick verification.

BTW: I'm re-setting up my test environment, which might cause some time.

Sorry, I just see that you have already tried that parameter.

@Per & Wei, as Mr.rvkagan has found out, our wertc auto_test app could open the camera on Linux with kernel newer than 3.3, while Chrome couldn't. The kernel log doesn't show much difference. Do you guys have any other idea?

I'm still trying to setup a test environment here...

Finally I have a test environment to repro this issue here.
Thanks so much for all the helpful info. Hope we can fix it soon.

Got it.

The video device node is open(O_RDONLY).  For such file descriptors VM_SHARED is cleared regardless of the flag in mmap(), see mm/mmap.c:do_mmap_pgoff().

webrtc opens device node with O_RDWR so things work fine.

Doing r/o open of the camera device in webrtc with this patch

Index: src/modules/video_capture/main/source/Linux/video_capture_linux.cc
===================================================================
--- src/modules/video_capture/main/source/Linux/video_capture_linux.cc  (revision 2372)
+++ src/modules/video_capture/main/source/Linux/video_capture_linux.cc  (working copy)
@@ -143,7 +143,7 @@
     char device[20];
     sprintf(device, "/dev/video%d", (int) _deviceId);
 
-    if ((_deviceFd = open(device, O_RDWR | O_NONBLOCK, 0)) < 0)
+    if ((_deviceFd = open(device, O_RDONLY | O_NONBLOCK, 0)) < 0)
     {
         WEBRTC_TRACE(webrtc::kTraceError, webrtc::kTraceVideoCapture, _id,
                    "error in opening %s errono = %d", device, errno);
@@ -326,7 +326,7 @@
             return false;
         }
 
-        _pool[i].start = mmap(NULL, buffer.length, PROT_READ | PROT_WRITE, MAP_SHARED,
+        _pool[i].start = mmap(NULL, buffer.length, PROT_READ, MAP_SHARED,
                               _deviceFd, buffer.m.offset);
 
         if (MAP_FAILED == _pool[i].start)


makes the tests fail with the same symptoms as google-chrome.

The relevant code in linux is rather old, so it guess it's a chromium regression.

I didn't manage to find the corresponding change in svn history of https://src.chromium.org/chrome/trunk/src/media/video/capture/linux, though.

Ever since https://src.chromium.org/chrome/trunk/src/media/video/capture/linux/video_capture_device_linux.cc was checked in, the device has been opened with O_RDONLY.

I also looked into mm/mmap.c. It seems that there is no major change, especially in do_mmap_pgoff(). (source code is here: http://lxr.linux.no/). The logic (to clear VM_SHARED when it's not FMODE_WRITE) has been there ever since 2.6.11. My computer gives me 2.6.38.8 when running "uname -a".

I can update chrome code to open device with O_RDWR. But it might be good to know why mmap succeeds in 2.6.38.8, but failed in 3.3.5.

commit 6998b6fb4b1c8f320adeee938d399c4d8dcc90e2
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Mon Oct 24 11:53:59 2011 -0300

    [media] uvcvideo: Use videobuf2-vmalloc
    
    Replace the current video buffers queue implementation with
    videobuf2-vmalloc.
    
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

# git describe --contains 6998b6fb4b1c8f320adeee938d399c4d8dcc90e2
v3.3-rc1~48^2~441

I.e. until 3.3 uvcvideo used its own implementation which didn't require VM_SHARED on the mappings.

I'm not sure it should BTW...

+ posciak@, our uvcvideo expert for more investigation.

https://src.chromium.org/viewvc/chrome?view=rev&revision=141308 should fix this. This is a temporary fix, dependent on posciak@'s investigation.

Well the comment in the patch is a bit misleading: r/w opening has been required for the majority of camera drivers in Linux since very long ago.  Furthermore, many of them even require VM_WRITE (PROT_WRITE in mmap()).

uvcvideo used to be an exception to this rule until it migrated to videobuf2 infrastructure in 3.3.  It's just the fact that the majority of desktop USB webcams these days implement the standardized USB Video Class interface and are thus handled by the uvcvideo driver, that made chromium appear fine here.

Great work! Will this fix be available with the next google-chrome-dev update?

Thanks all for your great help here!
The temp fix is committed and should be in next chrom-dev update.

Would update this issue depending on posciak's comments.

Great work! 
I've just tested successfully Google Chrome 21.0.1171.0 dev on Linux Kernel 3.4.0-1.fc17.x86_64 :-)
Thanks guys!

Fully agreed, latest dev works again.
Big thanks to all your work!!! :)

Just to let you know, I've been doing some initial inquiries, but the POSIX standard does not seem very clear about it and we have no general agreement what is the correct way yet. V4L2 API requires read+write even on capture devices, but enforcement is happening in layers above.

Well, the fact that uvcvideo which implements V4L2 API used to work fine in read-only mode until it changed its inner workings seems to indicate that the API doesn't require r/w per ce.

As for the enforcement in the upper layer, the code in videobuf2-core.c appears to be just a c&p from similar parts in other drivers, and their motivation is hidden in the pre-git history of linux kernel.

OTOH the videobuf2-core.c seems to treat VM_SHARED and VM_WRITE as orthogonal which we know is not true.

POSIX (per mmap(3p)) is explicit in that private read-only mappings behavior is undefined WRT changes in the underlying file; in Linux it's the same as for shared read-only mappings.  In fact, the only difference between the two is the behavior WRT mprotect(PROT_WRITE) (aka VM_MAYSHARE).

I guess the assertion can be changed to VM_SHARED | VM_WRITE for output buffers and VM_READ for input ones; this will allow capturing on devices opened read-only.

This patch doesn't helps me. Still shows green screen.
I tested this on 141317, 146953 revs and on current chrome dev.
My webcam is Philips spc 230 nc and kernel version is 3.4.4.

I have a Fedora 17 with kernel 3.4.4 too. And I just tried with Chrome dev 22.1207 and it works well with apprtc demo, with built-in webcam.

So could you please double check the chrome version and test newest Chrome dev with Apprtc demo? If it still fails, please post the JS console log here. 
And it might be worthy of trying another Webcam.

AFAICS philips spc 230 nc has vendor id 0x093a and product id 0x262c, and is handled by gspca_pac7302 driver, which doesn't use common videobuf or videobuf2 infrastructure, so most of the discussion above doesn't apply.

I couldn't spot anything suspicious from quick skimming through gspca driver code; you'll have to trace chrome to figure out which of the syscalls fails.

That might deserve filing a separate issue though.

Thanks all for your comments! Issue closed!