After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 613487 - [ogg] films recorded with cheese won't play if they have audio
[ogg] films recorded with cheese won't play if they have audio
Status: RESOLVED OBSOLETE
Product: cheese
Classification: Applications
Component: general
git master
Other Linux
: Normal major
: 2.32
Assigned To: Cheese Maintainer(s)
Cheese Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2010-03-21 14:15 UTC by Jean-Philippe Green
Modified: 2012-03-09 15:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
libcheese re-create video save bin (1.04 KB, text/plain)
2011-04-08 09:13 UTC, Gary Ching-Pang Lin
Details

Description Jean-Philippe Green 2010-03-21 14:15:14 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).
Comment 1 Bastien Nocera 2010-03-21 15:33:09 UTC
Can you play back the video using:
gst-launch playbin2 uri=file:///path/to/video.ogg
?
Comment 2 Jean-Philippe Green 2010-03-21 17:09:06 UTC
(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.
Comment 3 Bastien Nocera 2010-03-21 17:33:05 UTC
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?
Comment 4 Jean-Philippe Green 2010-03-21 17:48:47 UTC
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.
Comment 5 Bastien Nocera 2010-03-21 18:07:03 UTC
It says "Invalid URI", you didn't follow the instructions.

The command is:
gst-launch playbin2 uri=file:///home/jp/Video/Webcam/Saxophone.ogv
Comment 6 Jean-Philippe Green 2010-03-21 18:12:38 UTC
(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.
Comment 8 Sebastian Dröge (slomo) 2010-03-21 19:07:56 UTC
Freezes with latest GIT too
Comment 9 Tim-Philipp Müller 2010-03-21 20:17:34 UTC
Let's move this to -base..
Comment 10 David Schleef 2010-12-04 23:27:32 UTC
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
Comment 11 Vincent Penquerc'h 2010-12-31 11:56:21 UTC
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.
Comment 12 Gary Ching-Pang Lin 2011-04-08 09:13:31 UTC
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
Comment 13 Sebastian Dröge (slomo) 2011-04-08 11:59:47 UTC
Is there still something to do on the GStreamer side?
Comment 14 Gary Ching-Pang Lin 2011-04-11 06:34:55 UTC
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.
Comment 15 Sebastian Dröge (slomo) 2011-04-14 07:10:09 UTC
How is cheese switching between the different output files? What exactly is it doing?
Comment 16 Gary Ching-Pang Lin 2011-04-14 07:54:20 UTC
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.
Comment 17 Sebastian Dröge (slomo) 2011-04-14 08:37:16 UTC
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.
Comment 18 Gary Ching-Pang Lin 2011-04-14 10:29:26 UTC
Sounds like a cheese bug. Thanks for your help!
Comment 19 Sebastian Dröge (slomo) 2011-04-14 11:00:19 UTC
let's reassign it to cheese then.
Comment 20 David King 2012-03-09 15:17:13 UTC
This is obsolete now that Cheese (in 3.0) uses camerabin.