GNOME Bugzilla – Bug 613487
[ogg] films recorded with cheese won't play if they have audio
Last modified: 2012-03-09 15:17:13 UTC
When I record without the microphone activated in cheese I can record a video without any problems, but when I turn the microphone input on, totem won't play it. When I play it with totem the film freezes on the first image. I don't know if it's a problem with totem or cheese, but at least they are not compatible. It works with VLC though. I have Logitech Webcam C200 (I think).
Can you play back the video using: gst-launch playbin2 uri=file:///path/to/video.ogg ?
(In reply to comment #1) > Can you play back the video using: > gst-launch playbin2 uri=file:///path/to/video.ogg > ? That didn't help. Btw, the file extension is .ogv, but I don't think that should matter. Another thing I've noticed is that VLC thinks the video is 58:31 long, while it's actually about 01:10. My guess would be that cheese does the rendering a little wrong, and that VLC handles that small error a little better than GStreamer.
If it happens with gst-launch, then it's a GStreamer bug. Could you please make the movie with which you can reproduce this problem available?
Forgot to mention, I get an error message when I run gst-launch: " (gst-launch-0.10:10910): GLib-WARNING **: g_set_prgname() called multiple times Setting pipeline to PAUSED ... ERROR: Pipeline doesn't want to pause. ERROR: from element /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0: Invalid URI "/home/jp/Video/Webcam/Saxophone.ogv". Additional debug info: gsturidecodebin.c(889): gen_source_element (): /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0 Setting pipeline to NULL ... Freeing pipeline ... " (In reply to comment #3) > Could you please make the movie with which you can reproduce this problem > available? Sure, I just don't know where to upload it. I don't want to make a torrent.
It says "Invalid URI", you didn't follow the instructions. The command is: gst-launch playbin2 uri=file:///home/jp/Video/Webcam/Saxophone.ogv
(In reply to comment #5) > It says "Invalid URI", you didn't follow the instructions. > > The command is: > gst-launch playbin2 uri=file:///home/jp/Video/Webcam/Saxophone.ogv Oh, ok. Doesn't work either, it freezes.
http://download743.mediafire.com/nejtnvgw1zxg/yig5nnrjjgt/Saxophone.ogv
Freezes with latest GIT too
Let's move this to -base..
This file is muxed incorrectly. After running it through oggz-sort, it plays fine. Abridged output of oggz-dump: 00:00:00.000: serialno 1365625884, granulepos 0, packetno 0 *** bos: 42 bytes 00:00:00.000: serialno 0625435462, granulepos 0, packetno 0 *** bos: 30 bytes 00:00:00.000: serialno 1365625884, calc. gpos 0, packetno 1: 50 bytes 00:00:00.000: serialno 1365625884, granulepos 0, packetno 2: 2.552 kB 00:00:00.000: serialno 0625435462, calc. gpos 0, packetno 1: 45 bytes 00:00:00.000: serialno 0625435462, granulepos 0, packetno 2: 3.114 kB 00:00:00.033: serialno 1365625884, granulepos 1, packetno 3: 14.388 kB 00:00:00.066: serialno 1365625884, granulepos 2, packetno 4: 14.388 kB 00:00:00.100: serialno 1365625884, granulepos 3, packetno 5: 14.388 kB ... all the theora packets ... (with, by the way, no key frames) 00:01:11.700: serialno 1365625884, granulepos 2151, packetno 2153: 14.722 kB 00:01:11.733: serialno 1365625884, granulepos 2152, packetno 2154: 14.722 kB 00:01:11.766: serialno 1365625884, granulepos 2153, packetno 2155: 14.722 kB 00:00:00.000: serialno 0625435462, calc. gpos 0, packetno 3: 39 bytes 00:00:00.002: serialno 0625435462, calc. gpos 128, packetno 4: 31 bytes 00:00:00.015: serialno 0625435462, calc. gpos 704, packetno 5: 130 bytes ... followed by all the vorbis packets ... 00:01:11.768: serialno 0625435462, calc. gpos 3164992, packetno 5791: 123 bytes 00:01:11.791: serialno 0625435462, calc. gpos 3166016, packetno 5792: 125 bytes 00:01:11.814: serialno 0625435462, granulepos 3167040, packetno 5793: 113 bytes 00:01:11.828: serialno 0625435462, granulepos 3167652, packetno 5794 *** eos: 12 00:01:11.800: serialno 1365625884, granulepos 2154, packetno 2156 *** eos: 14.71
I've just looked at this, and Cheese (through oggmux) now seems to output correctly muxed video. However, it outputs video with insane bitrate (quality based, but with only keyframes - I assume that's to make it easy to edit). It also sends pages very quickly, leaading to substantial framing overhead (12% for Vorbis on my 320x240 output, compared to 1% for typical use). oggmux's max-page-delay is set to 10ms, which seems low. There's also no (apparent) way to select a lower fps, which would help here. This causes my computer to fail to keep up after a few seconds of recording, which might conceivably be a cause of bad muxing, if somehow the Vorbis side of the pipeline got stuck for some time. Doubtful though.
Created attachment 185504 [details] libcheese re-create video save bin I found a similar issue in cheese 2.32.0. If I record several videos in a row, cheese always failed to generate the thumbnails for the ogv files other than the first one. Furthermore, the ogv files except the first one could be as broken as the video in comment#7. However, I also found a trick to workaround this issue (see the attached patch for cheese): destroy the video save bin and re-create it again before recording another video. It looks like some gst element(?) has been contaminated after the first video recording. Any idea? My environment: openSUSE 11.4 gstreamer-0_10-0.10.32 gstreamer-0_10-plugins-base-0.10.32
Is there still something to do on the GStreamer side?
In cheese 2.32.0, it creates a video save bin for video recording and just links or unlinks the video save bin when necessary. However, only the first ogv file is muxed correctly when I record several videos in a row. Since the video save bin is untouched between gst_element_link() and gst_element_unlink (), I guess this bug is related to gstreamer.
How is cheese switching between the different output files? What exactly is it doing?
The video recording bits lie within cheese-camera.c: http://git.gnome.org/browse/cheese/tree/libcheese/cheese-camera.c?h=gnome-2-32 Cheese creates 4 bins: video_display_bin, camera_source_bin, photo_save_bin, and video_save_bin. video_display_bin and camera_source_bin are for the webcam input/output and basically won't be changed in the most of time. photo_save_bin and video_save_bin are for picture taking and video recording. Cheese links photo_save_bin by default. When the user presses the video recording button, cheese_camera_start_video_recording() will be invoked, and it changes the filename in video_file_sink and calls cheese_camera_change_sink() to switch photo_save_bin to video_save_bin. When the user presses "Stop Recording", cheese_camera_change_sink() will be called again and switches video_save_bin back to photo_save_bin. static void cheese_camera_change_sink (CheeseCamera *camera, GstElement *src, GstElement *new_sink, GstElement *old_sink) { CheeseCameraPrivate *priv = CHEESE_CAMERA_GET_PRIVATE (camera); gboolean is_playing = priv->pipeline_is_playing; cheese_camera_stop (camera); gst_element_unlink (src, old_sink); gst_object_ref (old_sink); gst_bin_remove (GST_BIN (priv->pipeline), old_sink); gst_bin_add (GST_BIN (priv->pipeline), new_sink); gst_element_link (src, new_sink); if (is_playing) cheese_camera_play (camera); } cheese_camera_change_sink() just changes the state of the pipeline and switch the sinks. Wonder if the change of video_file_sink affects video_save_bin.
When switching the bins are you making sure to provide correct newsegment events to the muxer and everything? If you don't it's not surprising that the output is broken, especially if multiple streams are muxed.
Sounds like a cheese bug. Thanks for your help!
let's reassign it to cheese then.
This is obsolete now that Cheese (in 3.0) uses camerabin.