GNOME Bugzilla – Bug 547422
hangs and does not stop recording sound
Last modified: 2008-09-14 17:07:40 UTC
Methodology with a logitech quickcam pro 5000: - hit the video button - hit the record button - wait 10 seconds - hit the stop button In the latest dev tarball, cheese seemingly hangs at the last step (nothing outputted to the terminal with cheese -v, when that happens). The "stop recording" button is set in a "pressed/pushed" state and I cannot interact with the gui. Further investigation reveals that the resulting video file keeps increasing its filesize. The resulting video file shows that its length went way past the 10 seconds duration, and is instead 45 seconds long or more. Actually, the video image frames stop (become still) at 10 seconds, but the sound continues afterwards. The video only stops recording at the moment I kill cheese by doing ctrl-C in the terminal. This did not happen in cheese 0.22.3.
*** This bug has been marked as a duplicate of 547320 ***
Is this really a duplicate? I filed it as a separate bug report, because I felt 547320 was a needed usability change, but this bug here is about an encoding or hardware problem. I believe they are separate?
Ok. Let's investigate a bit about this bug. I cannot reproduce it, so you have to give as much details as possible. Does this happen everytime? Does it happen in a particular, uncommon, situation? In the other bug you said you have a pentium M, frequency? I'm asking this because I have a dual core but recording is using a single core and it's limited to 1GHz and I still have to wait no more than half a second before pipeline shuts down. A Gstreamer log of the bug could be also very useful GST_DEBUG=*:5 cheese -v > gst.log 2>&1 Bzip it since it can be big! If bugzilla still complains attach it elsewhere and give us a link.
My CPU is clocked at 1.73 GHz with a 2 mb cache. The problem happens every time on my end with this webcam and cheese 2.23.6. I'll upload the gst log when I get home soonish, as the connexion here won't let me upload files (holy cow, 75 mib compressed to 2.6 mib).
Just to be sure this is not already fixed, would you mind try latest svn trunk? >The problem happens every time >on my end with this webcam and cheese 2.23.6. With this webcam? do you have any other? does it happens with this one only? Which driver does it uses? version? is it v4l2 or v4l? Thank you.
promised gst log is here: http://jeff.ecchi.ca/public/cheese-bug-547422-gst-log.tar.bz2 I don't know how to determine if V4L or V4L2 is used here. Though when I did tests in the commandline, I used v4l2 in that huge gstreamer pipeline command, I think. I'll test with another cheap webcam and add a comment (I fear that one may crash the kernel or something).
tested with another webcam (ezonics ezcam II), here again the video does not stop recording when I hit the stop button. There is a difference however: this one keeps recording image frames TOO, not just the sound (on the quickcam, it freezes the image and continues recording sound).
I tested with latest svn as well. The bug is still there (with the crappy ezonics camera, I can't test the quickcam right now).
>so you have to give as much details as possible Again, I need more infos! Which driver do they use? is it the same? do you have any particular configuration that should be noted? Please tell us at least: - linux distribution and version - gstreamer version - kernel version - random things that you think could be useful, especially things that can tell us what is different with your configuration, since you are the only one who reported this. Another thing: when cheese "freezes" the button is pressed or insensitive (greyed out)? do menus work? and the other buttons? Thanks
I am running ubuntu 8.04.1 with the 2.6.24-19 generic and Gstreamer 0.10.3-6. The USB controller is an Intel 82801 thingy (ICH6 family) rev 03. The GPU is an Intel i915. The sound is also ICH6 (AC'97 stuff). The Logitech Quickcam Pro 5000 (2006 model, USB id 046d:08ce) uses the UVC driver. The EZonics EZcam II uses the gspca driver. When cheese freezes, the button is /not/ to the gtk insensitive state. It really is in the "pushed" state. Nothing in the cheese ui can be interacted with. If using compiz, one will see a greyed out window. This happens with metacity too, composited or not.
Ok here is what I found looking at your gst.log.. What we do to stop the recording pipeline, from cheese-webcam.c is void cheese_webcam_stop_video_recording (CheeseWebcam *webcam) { CheeseWebcamPrivate* priv = CHEESE_WEBCAM_GET_PRIVATE (webcam); /* Send EOS message down the pipeline by stopping video and audio source*/ gst_element_send_event (priv->video_source, gst_event_new_eos ()); gst_element_send_event (priv->audio_source, gst_event_new_eos ()); } looking at a log produced here (where I cannot reproduce the bug) I get: 0:00:14.201686324 ... gst_element_send_event: send eos event on element video_source event starts to propagate downstream and after a couple of msecs: 0:00:14.229373917 ... gst_element_send_event: send eos event on element audio_source event continue to propagate until "all sinked posted EOS" and a new eos message is generated (the one we wait before to stop the pipeline). looking at your log: 0:00:27.634107054 6596 0x8065470 DEBUG GST_ELEMENT_PADS gstelement.c:1381:gst_element_send_event: send eos event on element video_source and then nothing happens.. there are 10 seconds of LOG messages from audiosrc and ringbuffer, no eos is sent on audio_source no event propagates downstream... It seems that it gets stuck in gst_element_send_event (priv->video_source, gst_event_new_eos ()); Since cheese_webcam_stop_recording is called by the button-clicked callback it would explain why the button stays clicked and the ui freezes. I'll investigate more but I suppose it's more a gstreamer bug than a cheese one.
This will only work properly (with send_event non-blocking) with GStreamer core 0.10.20 or later. The log indicates that 0.10.18 is being used here. Probably best to just upgrade the requirements to core >= 0.10.20.
if so, we should bump the requirements
So, ok for me too. Jean-François, if you could test cheese svn with gstreamer 0.10.20 that would be great!
*** Bug 547320 has been marked as a duplicate of this bug. ***
Hrm, is there way for me to test this without using a development release or some crazy black magic upgrade-half-your-system-from-svn thing? I mean, compiling a small app such as cheese is doable for me, but gstreamer is an entirely different beast to me. Could there be an ubuntu repository or package set I could use, by any chance? Or should I download a foresight daily gnome live cd and test directly from that?
A live cd would probably be the easiest choice.. not sure about foresight but ubuntu intrepid (one of latest dev releases) already has 0.10.20.
you can also download the gnome developer kit, which is available as a vmware image or as a live cd: http://live.gnome.org/GnomeDeveloperKit
OK, so I tested with ubuntu 8.10 fully updated, as well as the gnome developer kit fully updated, and in both cases, I was unable to achieve any recorded video at all. Besides, it lagged a lot, colors were sometimes way off, etc. Hitting the record button worked, then hitting stop did nothing (but the UI didn't freeze this time), sometimes there were crashes (even then, apport could not help me), and it seemed to lag with metacity composite, and ... bleh, as you can guess, there are so many weird symptoms intertwined, combined with the fact that all this is running on "unstable" dev distros, I can't really be sure of anything. If it's not cheese, it's gstreamer, or the kernel, or the distro, or the planet's alignment, but it seems there is a curse on me being unable to test it further properly. At this rate I'll probably not be able to help gather more info (I will have to give back the webcam soon).
did you use gstreamer >= 10.20 ? cheese from svn or one of the 2.23.x tarballs?
in comment #19, yes
I don't know if it's the same issue but I'm experiencing something similar (cheese svn, gstreamer 10.20): if I quickly click "stop recording" right after start the eos event randomly doesn't propagate down the pipeline. I think this happens because the pipeline is still starting up but I should take a better look at gst logs. Anyway, when this happens no eos message is posted to the bus, the pipeline is not stopped, no video_saved signal is emitted and the start button stays insensitive. Since it seems we cannot completely trust on the eos message to cleanly shutdown the pipeline I'd suggest to wait a timeout for it to propagate and force stop recording if it expires. Suggested patch following.
(In reply to comment #22) > I think this happens because the pipeline > is still starting up but I should take a better look at gst logs. As a confirm for this the issue disappears if I wait the pipeline to correctly start with gst_element_get_state.
Created attachment 118300 [details] [review] force recording stop if the eos takes too much to propagate Wait a timeout (2secs) for the eos message to appear otherwise force pipeline shutdown. This combined with gstreamer 10.20 dependency bump should prevent us from other issues related to eos event and recording pipeline shutdown. If no one complains I'll commit later this evening.
Any reason not to just check the pipeline state with _get_state (..., 0) and proceed to shutdown the pipeline immediately without waiting for EOS if the pipeline state is < PLAYING?
(In reply to comment #25) > Any reason not to just check the pipeline state with _get_state (..., 0) and > proceed to shutdown the pipeline immediately without waiting for EOS if the > pipeline state is < PLAYING? > You've been too fast, I was thinking to do that right now :) (updated patch following). Anyway I think that setting the timeout is still needed to be sure cheese doesn't hangs waiting for the eos (if it takes too much or doesn't propagate correctly for other reasons).
(In reply to comment #26) > (In reply to comment #25) > > Any reason not to just check the pipeline state with _get_state (..., 0) and > > proceed to shutdown the pipeline immediately without waiting for EOS if the > > pipeline state is < PLAYING? > > > > You've been too fast, I was thinking to do that right now :) (updated patch > following). > Anyway I think that setting the timeout is still needed to be sure cheese > doesn't hangs waiting for the eos (if it takes too much or doesn't propagate > correctly for other reasons). > well.. it seems that doing this leads to a more subtle bug in cheese-window.c: start button stays insensitive if I quickly stop video recording. Since I'm sure that video_saved_cb is being called correctly and setting the button as sensitive, someone else is setting sensitiveness right after.. I'll investigate more later since I'm going out now. Anyway, attaching the updated patch...
Created attachment 118303 [details] [review] force recording stop after timeout and check that the pipeline is playing before to send eos event still not marking the previous patch as obsolete because of the issue on previous comment.
Created attachment 118306 [details] [review] force recording stop after timeout and check that pipeline is playing before to send eos event fixes issue in comment #27: moved cheese_webcam_stop_recording a little further to set take_photo button sensitiveness right
Committed to svn. What are we supposed to do with this bug? I think the last patch should solve the original issue but as far as I can tell the issue from the original reporter is quite hard to reproduce and probably related to other issues not directly related to cheese..
(In reply to comment #19) > If it's not cheese, it's gstreamer, or the kernel, or the distro, or the > planet's alignment, but it seems there is a curse on me being unable to test it > further properly. At this rate I'll probably not be able to help gather more > info (I will have to give back the webcam soon). As far as I can tell you won't be able to provide any useful info anymore, right? Do you have another webcam for some test? Anyway, I believe the attached patch should solve each possibile issue with recording shutdown. Closing the bug as incomplete, reopen if you still have the issue with latest release or if you can provide more info. If you can confirm that is fixed that would be appreciated too :).
you are correct, I am not currently in a position to provide more testing/debug info anymore, so let's hope this was indeed fixed by your patches :)
https://bugs.launchpad.net/bugs/258110 is about the same issue and still in verification ... (though it seems the patch fixes teh issue with the mentioned hardware ... why was this bug marked invalid ?
(In reply to comment #33) > https://bugs.launchpad.net/bugs/258110 is about the same issue and still in > verification ... (though it seems the patch fixes teh issue with the mentioned > hardware ... > > why was this bug marked invalid ? > incomplete, not invalid. see comment #31 for explanation
hmm, weird. the launchpad bugwatcher sent me a mail about a status change to invalid, sorry for the noise :)