Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1884260 - cheese creates invalid and extremely long video files, each app restart making them longer
Summary: cheese creates invalid and extremely long video files, each app restart makin...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: cheese
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: David King
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F33FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2020-10-01 13:24 UTC by Kamil Páral
Modified: 2020-10-14 00:42 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-14 00:42:23 UTC
Type: Bug


Attachments (Terms of Use)
example broken video (3.62 MB, video/webm)
2020-10-01 13:43 UTC, Kamil Páral
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNOME Gitlab GNOME/cheese - issues 79 0 None None None 2020-10-05 12:48:04 UTC

Description Kamil Páral 2020-10-01 13:24:42 UTC
Description of problem:
I can record a video in Cheese just fine, but only the first time it is started (ever). Every time I quit Cheese and start it again, the video seems to be starting at a further and further future time. So after the first time you restart Cheese, your next video capture might be 1 minute long immediately after start. In my case, each capture is already at least 50 minutes long. So even if I capture 30 seconds of video, the video file is marked to be 50+ minutes long. The filesize is not large, but totem plays 50 minutes of a green color, and then at the very end finally the 30 seconds of the real video capture. This fake video length is also indicated in Cheese interface, the timestamp shows e.g. 50 minutes right after you hit the Record button.

There is some internal counter in Cheese which makes all future videos padded with invalid data and invalid video length.

Version-Release number of selected component (if applicable):
cheese-3.38.0-2.fc33.x86_64

How reproducible:
always

Steps to Reproduce:
1. start Cheese, create a video capture
2. restart Cheese, create a video capture, see that the video started at timestamp e.g. 30 seconds
3. restart Cheese, create a video capture, see that the video started at timestamp e.g. 1 minute 30 seconds
4. inspect the video files in ~/Videos/Webcam, play them in totem, see just green color for those invalid videos (the actual footage is at the end)

Additional info:
As a bonus problem, Cheese seems to freeze for me shortly after I stop recording for ~10 seconds, then the video output resumes. I assume the freeze might be getting longer with each app restart (it's computing something invalid).

Comment 1 Kamil Páral 2020-10-01 13:25:46 UTC
I propose this as a Final blocker due to violating:
"All applications that can be launched using the standard graphical mechanism after a default installation of Fedora Workstation on the x86_64 architecture must start successfully and withstand a basic functionality test. "
https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria#Default_application_functionality

Comment 2 Kamil Páral 2020-10-01 13:40:10 UTC
Actually, it seems to be pretty random, whether Cheese video output freezes completely and the video file contains nothing playable, or whether it unfreezes after ~10 seconds and captures the whole thing, but in a padded file.

Comment 3 Kamil Páral 2020-10-01 13:43:10 UTC
Created attachment 1718179 [details]
example broken video

I created an example video with a puppet show, enjoy!

The puppet show is just 1 minute long, but the actual video is 21 minutes long instead. In totem, you have to seek to the end to see it. Vlc can skip the 20 minutes of empty (green) frames automatically.

Comment 4 Kamil Páral 2020-10-01 13:43:42 UTC
While recording the video, this appeared in the journal:

Oct 01 15:34:06 phoenix cheese[5344]: Internal GStreamer error: code not implemented.  Please file a bug at https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/new.: ../gst-libs/gst/video/gstvideofilter.c(296): gst_video_filter_transform (): /GstCameraBin:camerabin/GstEncodeBin:video-encodebin/GstVideoConvert:videoconvert1:
                                      invalid video buffer received
Oct 01 15:34:11 phoenix cheese[5344]: Can't record audio fast enough: ../gst-libs/gst/audio/gstaudiobasesrc.c(841): gst_audio_base_src_create (): /GstCameraBin:camerabin/GstAutoAudioSrc:audiosrc/GstPulseSrc:audiosrc-actual-src-puls:
                                      Dropped 150381 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.
Oct 01 15:34:12 phoenix mailnag[2340]: INFO (2020-10-01 15:34:12): Checking 1 email account(s).
Oct 01 15:34:54 phoenix cheese[5472]: totem-video-thumbnailer couldn't get a picture from 'file:///tmp/2020-10-01-153406.webm'
Oct 01 15:34:54 phoenix cheese[5344]: could not generate thumbnail for /home/kparal/Videos/Webcam/2020-10-01-153406.webm (video/webm)
Oct 01 15:34:54 phoenix cheese[5344]: Icon 'video-webm' not present in theme Adwaita
Oct 01 15:34:56 phoenix nautilus[5492]: totem-video-thumbnailer couldn't get a picture from 'file:///tmp/2020-10-01-153406.webm'
Oct 01 15:35:21 phoenix pipewire[4349]: [W][000001301.865925][module-protocol-native.c:1006 on_before_hook()] client 0x557453866310: could not flush: Broken pipe
Oct 01 15:35:21 phoenix systemd[1837]: dbus-:1.2-org.gnome.Cheese@2.service: Succeeded.
Oct 01 15:35:21 phoenix systemd[1837]: dbus-:1.2-org.gnome.Cheese@2.service: Consumed 27.617s CPU time.

Comment 5 Lukas Ruzicka 2020-10-02 07:23:41 UTC
Hello, 
on my computer, I am only experiencing that Cheese either freezes totally or just the picture window freezes and the video making process can be stopped. If frozen totally, it even cannot be stopped. In either way, no useful video is recorded, VLC reports a stream about 6 hours long and the screen remains black. Audio, when recorded, is recorded just fine. 

Journalctl says:

When cheese starts:
~~~
Oct 02 09:10:24 platypus cheese[8741]: totem-video-thumbnailer couldn't get a picture from 'file:///tmp/2020-10-02-090834.webm'
Oct 02 09:10:24 platypus cheese[8714]: could not generate thumbnail for /home/lruzicka/Videos/Webcam/2020-10-02-090834.webm (video/webm)
Oct 02 09:10:24 platypus cheese[8714]: Icon 'video-webm' not present in theme Adwaita
Oct 02 09:10:25 platypus cheese[8759]: totem-video-thumbnailer couldn't get a picture from 'file:///tmp/2020-10-02-090911.webm'
Oct 02 09:10:25 platypus cheese[8714]: could not generate thumbnail for /home/lruzicka/Videos/Webcam/2020-10-02-090911.webm (video/webm)
Oct 02 09:10:25 platypus cheese[8714]: Icon 'video-webm' not present in theme Adwaita
~~~

When a video is initiated:
~~~
Oct 02 09:10:49 platypus cheese[8714]: Internal GStreamer error: code not implemented.  Please file a bug at https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/new.: ../gst-libs/gst/video/gstvideofilter.c(296): gst_video_filter_transform (): /GstCameraBin:camerabin/GstEncodeBin:video-encodebin/GstVideoConvert:videoconvert1:
                                       invalid video buffer received
~~~

When I want to play the video from Cheese (it calls for Totem):

~~~
Oct 02 09:11:10 platypus totem[8893]: Native Windows taller than 65535 pixels are not supported
Oct 02 09:11:10 platypus gnome-shell[2288]: meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed
Oct 02 09:11:10 platypus totem[8893]: Drawing a gadget with negative dimensions. Did you forget to allocate a size? (node slider owner GtkScale)
~~~

Comment 6 František Zatloukal 2020-10-05 11:28:21 UTC
Marking as AcceptedBlocker as per voting: https://pagure.io/fedora-qa/blocker-review/issue/136

Comment 7 Matthew Miller 2020-10-06 13:35:47 UTC
If there isn't an obvious fix, I propose we resolve this by removing cheese from the default installation for F33 and hopefully providing a zero-day update.

Comment 8 Wim Taymans 2020-10-13 10:20:36 UTC
I propose removing the pipewire device provider, then everything falls back to v4l2 and we can fix the timestamp issues later.

Comment 9 Wim Taymans 2020-10-13 10:26:34 UTC
What's needed:

- Make the pipewire device provider build optional upstream
- Make a new pipewire build with the make-device-provider-optional patch and
  disable the device provider.

I'll do that now, I can do this pretty quickly

Comment 10 Fedora Update System 2020-10-13 11:01:23 UTC
FEDORA-2020-cb78ff4ca5 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-cb78ff4ca5

Comment 11 Kamil Páral 2020-10-13 11:30:13 UTC
(In reply to Fedora Update System from comment #10)
> FEDORA-2020-cb78ff4ca5 has been submitted as an update to Fedora 33.
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-cb78ff4ca5

Yes, this fixes the problem.

Comment 12 Fedora Update System 2020-10-13 13:17:17 UTC
FEDORA-2020-80c42dde95 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 13 Fedora Update System 2020-10-13 13:26:21 UTC
FEDORA-2020-47014b6e90 has been pushed to the Fedora ELN stable repository.
If problem still persists, please make note of it in this bug report.

Comment 14 Kamil Páral 2020-10-13 14:01:15 UTC
We still need to track this for F33.

Comment 15 Adam Williamson 2020-10-13 16:42:59 UTC
Thanks a lot for the quick fix, Wim.

Comment 16 Fedora Update System 2020-10-14 00:42:23 UTC
FEDORA-2020-cb78ff4ca5 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.