Created attachment 399073 [details] lsusb.log This is what I see on the console: Capuring still images works great. Video *preview* also works great. However, as soon as I start capturing video, the preview only displays a frame or very short series of frames every few seconds. The recorded video is the same, totally non-smooth. I changed the resolution to the next smaller one from 640x480 (highest, default) to 352x288. With this, the video preview and recorded video are smooth again. Previously (in F11 at least) I could record 640x480 smoothly. However even with the lower resolution there is still a problem on the beginning of recordings: when I press the record button, the webcam preview turns black for 2-3 seconds. During this time, I get corruption in the recorded video. I guess Cheese should just wait until the cam is "ready" before stating to write the video. This, also, used to work at some point... Console output while running cheese: --- [liveuser@localhost Desktop]$ cheese libv4l2: error converting / decoding frame data: v4l-convert: error parsing JPEG header: Not a JPG file ? libv4l2: error converting / decoding frame data: v4l-convert: error parsing JPEG header: We do not support more than 4 AC Huffman table << starting recording >> << stopping recording >> (cheese:3723): GLib-GObject-CRITICAL **: g_signal_emit_valist: assertion `signal_id > 0' failed libv4l2: error converting / decoding frame data: v4l-convert: error parsing JPEG header: Not a JPG file ? libv4l2: error converting / decoding frame data: v4l-convert: error parsing JPEG header: Not a JPG file ? ---
Created attachment 399156 [details] lsusb output for the Pixart Imaging, Inc 093a:2700 webcam lsusb output for the Pixart Imaging, Inc 093a:2700 webcam device on the ASUS EeePC 900HA.
Nearly the same thing happens with the Pixart Imaging, Inc. 093a:2700 device on the ASUS EeePC 900HA (it's the embedded web cam). I don't get any corruption with smaller resolutions though. Anyway, I've attached the lsusb.log for the webcam under lsusb-pi-093a.2700.log.
(In reply to comment #2) > Nearly the same thing [...] Just to be clear "the same thing" means you can record in lower resolutions just fine but not in the highest/higher/default resolution? I think my issue is actually two separate issues, but this is for the maintainer to decide.
Well, it only records smoothly at a lower resolution after 10 seconds of spontaneous frames, and so far it has only worked at a resolution of 160 x 120. Anything higher just doesn't work very well. Also, in case anyone wonders, I'm using the Nightly Live image from here: http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/
Created attachment 399167 [details] lsusb output for the Microsoft Corp. LifeCam VX-3000 045e:00f5
A similar thing occurs with the Microsoft Corp. LifeCam VX-3000. Aside from the fact that it doesn't record audio, it records just 2 or 3 frames of video and then freezes. At lower resolutions, it doesn't even record smoothly at all, even after waiting for about 30 seconds to see if it would kick in.... I've attached the lsusb output for the Microsoft LifeCam VX-3000 in the file lsusb-ms-lifecam-vx-3000-045e.00f5.log.
(In reply to comment #4) > Well, it only records smoothly at a lower resolution after 10 seconds of > spontaneous frames [...] Ok so this is basicly the same for us with different hardware. Is your cam also using the UVC driver btw? > Aside from the fact that it doesn't record audio Is cheese supposed to record audio? That doesn't work for me either...
(In reply to comment #7) > (In reply to comment #4) > > Well, it only records smoothly at a lower resolution after 10 seconds of > > spontaneous frames [...] > > Ok so this is basicly the same for us with different hardware. Is your cam also > using the UVC driver btw? > I believe so. The uvcvideo driver is loaded when I run lsmod. > > Aside from the fact that it doesn't record audio > > Is cheese supposed to record audio? That doesn't work for me either... Yes, it does. When I recorded video with the Pixart Imaging Inc. device, it also got audio from the built in mic.
(In reply to comment #8) > > I believe so. The uvcvideo driver is loaded when I run lsmod. > With the Microsoft LifeCam VX-3000, the gspca_sonixj and gspca_main drivers are loaded......
Same issues here, no matter what resolution I use there is always a 2-3s lug in playback corresponding with preview turning black after pressing record button. On lowest resolution (320x240) the playback is otherwise smooth, Totem shows 30fps. On high res. (1280x800) the playback is choppy (after the first lug) for another 2-3s, then it seems smooth to me. Totem shows 15fps. Hardware: UVC Camera (17ef:4807), Vendor: Lenovo (bultin webcam in T500), Manufacturer: Chicony Electronics Co., Ltd.
Hardware: Z-Star Microelectronics Corp. ZC0302 Webcam, id 0ac8:0302, driver zc3xx Different webcam, no lug at the begging of playback, but there is another issue. This camera calibrate itself at each start - the picture is overexposed and then it fades. All this is visible during playback and it corresponds with the preview. But still image pictures captured by the camera are ok. The cheese should on "restart" webcam when starting record or just wait until camera is ready.
s/should on/should not
I have the same experience in F14 currently. Recording at 640x480 gives very jerky video, and I notice CPU usage on one core is 100% during this time. Recording at 320x240 is smooth. Perhaps recording in Cheese is very CPU-inefficient somehow? This system should have more than enough power to record video at 640x480. I can record at 640x480 using mplayer: mencoder tv:// -tv driver=v4l2:width=640:height=480:device=/dev/video0 -nosound -ovc lavc -o wcrecording.avi and it comes out smooth. I can also do Skype and others report that the video is fine (though that may be at a low resolution, I'm not sure what resolution Skype uses).
*** Bug 507450 has been marked as a duplicate of this bug. ***
Cheese fail Video http://www.youtube.com/watch?v=1CFRFINb76k system: [user@localhost ~]$ rpm -qa cheese cheese-2.30.1-1.fc13.i686 [user@localhost ~]$ uname -r 2.6.34.7-56.fc13.i686 [user@localhost ~]$
Created attachment 453262 [details] Log running Cheese with --gst-debug-level=2 turned on Same problem with "Bus 002 Device 003: ID 0c45:6481 Microdia" Webcam rpm -qa cheese cheese-2.30.1-1.fc13.i686 Cheese website tells that it coud be linked with the GStreamer not using the Gpu to record the video. http://live.gnome.org/Cheese/FAQ#I.27m_getting_a_really_slow_response_with_the_video.2C_the_video_is_sluggish_and_everything_looks_quite_slow.2C_like_as_the_video_lags.2C_what_could_i_do.3F But I couldnt find Gst properties as is saying in the Cheese website.
rafael: no, that won't be it. That relates to video playback, not recording. If you had that problem, it'd be choppy just watching the current feedback from the camera without recording. (Anyway, I know I have that setting at Xv, not Xshm). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 469104 [details] CWC on Fedora14 FAILS gdb --batch --ex "t a a bt" -pid=2410 &> ~/Desktop/cheeseborking_on_record.txt
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I updated to FC15, and tried testing Cheese, but bow it doesn't produce video at all, reporting that "One or more elements are missing: camerabin." I'd love to test it to report whether or not this bug is still out there. Can anyone tell me how to get camerabin, Googling didn't produce anything that works on Fedora.
Install gstreamer-plugins-bad-free . -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Thanks, I just did, and ... the problem persists. Cheese records sound just fine, but the video includes barely a fraction of the frames. (In addition, gstreamer-plugins-bad-free should be noted as a dependency for cheese.)
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Wait, as you can see, I posted less than a month ago that this problem persists in F15! Don close, fix. Please.
Reopening for F15.
Hi, So there seem to be 2 problems discussed in this bug: 1) The capturing of video is not smooth. This is a problem and I will galdly admit so, but don't expect a fix anytime soon. The problem is that realtime encoding of video takes a lot of CPU horsepower, and we don't support GPU offload for this... So the only advise I can give atm is lower the resolution until it works, onfortunately that often means going as low as 320x240! 2) : > Hardware: Z-Star Microelectronics Corp. ZC0302 Webcam, id 0ac8:0302, driver > zc3xx > > Different webcam, no lug at the begging of playback, but there is another > issue. > This camera calibrate itself at each start - the picture is overexposed and > then it fades. All this is visible during playback and it corresponds with > the preview. But still image pictures captured by the camera are ok. > > The cheese should on "restart" webcam when starting record or just wait > until camera is ready. The problem is there is no way for cheese to determine if the camera is ready. Often cameras don't even signal this at the hardware level (I'm the upstream maintainer of the zc3xx driver and tons of other webcam drivers). So cheese can penalize all people with cams which do settle quickly by always throwing away 5 seconds of video at the beginning, or it can record some bad frames for slower cams, there is no way to make everyone happy. Regards, Hans
*** Bug 748187 has been marked as a duplicate of this bug. ***
Upgrading version to avoid auto-close, this is still an issue with Fedora-17.
Hans: note my comment #13: the hardware I was testing on at the time was certainly capable of smooth real-time encoding at the resolution in question.
(In reply to comment #29) > Hans: note my comment #13: the hardware I was testing on at the time was > certainly capable of smooth real-time encoding at the resolution in question. I'm afraid that that comment is comparing apples to oranges: -it is encoding to x264 rather then webm, so using a completely different (more mature and optimized) encoder -it is likely using multiple threads, where as webm encoding is single threaded -it is not applying any video effects to the stream -it does not display the video real time while encoding it
not multithreaded, no. mplayer is not multithreaded by default, yet. the other points apply, but still, if gstreamer encoding is so inefficient that a full-voltage Core i5 with high-end RAM and an SSD can't encode 640x480 at something at least more than a single frame per second, I'd say that's a bug _in itself_.
I've done some tweaking to cheese's encoding parameters, making the situation much better, cheese can now record full HD videos on my "Intel(R) Core(TM)2 Duo CPU P9500 @ 2.53GHz", albeit at a somewhat low framerate of circa 10 fps, at 1280x720 it is recording smooth video. An update with these changes is on its way.
cheese-3.4.2-3.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/cheese-3.4.2-3.fc17
Package cheese-3.4.2-3.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing cheese-3.4.2-3.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-9727/cheese-3.4.2-3.fc17 then log in and leave karma (feedback).
cheese-3.4.2-3.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.