GNOME Bugzilla – Bug 699845
screen recording fails (dualhead?)
Last modified: 2019-02-12 09:25:16 UTC
Can't get screen recording to work. When I hit the shortcut, I get the following error: Recording to /home/jimmac/Videos/Screencast from 7.5.2013 17:32:16.webm Window manager warning: Log level 16: Error in recording pipeline: Internal data flow error. Please advise on how to provide useful data to resolve the issue. I'm guessing the issue either comes from the fact I have two giant screens (2x 2560x1440) or the fact I'm using the nvidia binary blob.
It works fine here (using nvidia blob and 2 monitors). The error message is a bit odd. Do you have jhbuild or a system install? Does it work for you with just one screen (easy way to confirm your theory).
This is the system shell coming from f19 alpha. I have the exact same OS on two other machines, where everything works as it should. I have just tried disabling one extra screen and indeed, things work fine like that. Is the recorder grabbing all screens? I would have actually thought just recording the primary display to be a more reasonable behavior.
(In reply to comment #2) > This is the system shell coming from f19 alpha. I have the exact same OS on two > other machines, where everything works as it should. > > I have just tried disabling one extra screen and indeed, things work fine like > that. Huh odd. Did you change the pipeline? VP8 should be able to handle that size just fine. "VP8 uses 14 bits for width and height, so the maximum resolution is 16384x16384 pixels." > Is the recorder grabbing all screens? Yes. > I would have actually thought just recording the primary display to be a more reasonable behavior. Hmmm ... yeah that but isn't that inconistent with screenshooting?
Same problem here. I use 3 1920x1080 screens and it fails. If I disable one of them, it works as expected. Could it be that some component in the pipeline fails at above 4096 pixels? How about a dconf setting for selecting the display(s) recorded? P.S. I'm using the radeon drivers.
And fails here for me with 3 1920x1080 monitors. rbellamy@eanna i ~ % sudo pacman -Qs gnome-shell$ local/gnome-shell 3.14.3-2 (gnome) The next generation GNOME Shell rbellamy@eanna i ~ % sudo pacman -Qs gnome-session local/gnome-session 3.14.0-1 (gnome) The GNOME Session Handler rbellamy@eanna i ~ % sudo pacman -Qs gstreamer0.10-plugins local/gstreamer0.10-bad-plugins 0.10.23-8 (gstreamer0.10-plugins) GStreamer Multimedia Framework Bad Plugins (gst-plugins-bad) local/gstreamer0.10-base-plugins 0.10.36-3 (gstreamer0.10-plugins) GStreamer Multimedia Framework Base Plugins (gst-plugins-base) local/gstreamer0.10-ffmpeg 0.10.13-2 (gstreamer0.10-plugins) Gstreamer FFMpeg Plugin local/gstreamer0.10-good-plugins 0.10.31-6 (gstreamer0.10-plugins) GStreamer Multimedia Framework Good Plugins (gst-plugins-good) local/gstreamer0.10-ugly-plugins 0.10.19-14 (gstreamer0.10-plugins) GStreamer Multimedia Framework Ugly Plugins (gst-plugins-ugly) root@eanna i ~ # journalctl -ab -o short-monotonic _COMM=gnome-session | grep '\*\*' [70542.572975] eanna gnome-session[1183]: ** (gnome-shell:1277): WARNING **: Error in recording pipeline: Internal data flow error. [70556.307138] eanna gnome-session[1183]: ** (gnome-shell:1277): CRITICAL **: shell_recorder_close: assertion 'recorder->state != RECORDER_STATE_CLOSED' failed https://bugzilla.redhat.com/show_bug.cgi?id=1025899
Same issue in gnome 3.16. Also 3x 1920x1080 monitors (one of them in pivot mode). Can somebody adjust the Version field?
I'm still experiencing this issue with gnome 3.18. triple 1920x1080 monitors; if I unplug one it works as expected.
*** Bug 764683 has been marked as a duplicate of this bug. ***
Still a problem with gnome-shell 3.22 (2 monitors, one is 2560x1440 (primary) and the laptop is 1600x900)
Still a problem with 3.30.2 (2 monitors, one is 3840x2160 (primary) and the secondary is 1920x1080)
Found a new RedHat issue tracking this, as the last one was closed due to its related Fedora version hitting EOL. https://bugzilla.redhat.com/show_bug.cgi?id=1364106
I believe I have found the issue: https://github.com/GStreamer/gst-plugins-good/blob/35ab185d752fb610aa26002c1aa03cf2fd954b7d/gst/matroska/webm-mux.c#L48-L49 WebM, at least according to GStreamer, appears to be limited to frame sizes between 16 and 4096 pixels in either dimension. This appears to be an arbitrary limitation on the format placed by GStreamer itself. The actual limitations of WebM are more along the lines of the codec which is used. For VP8, that's 16384x16384, while for VP9, it's 65536x65536. Changing gnome-shell's default pipeline to use matroskamux instead of webmmux makes it capable of encoding my 5760x2160 desktop space. It's super slow, though, so I think I'm going to want to change that to use vp8enc instead, just for my own personal build.
(In reply to Christopher Snowhill from comment #12) > I believe I have found the issue: > > https://github.com/GStreamer/gst-plugins-good/blob/ > 35ab185d752fb610aa26002c1aa03cf2fd954b7d/gst/matroska/webm-mux.c#L48-L49 > > WebM, at least according to GStreamer, appears to be limited to frame sizes > between 16 and 4096 pixels in either dimension. This appears to be an > arbitrary limitation on the format placed by GStreamer itself. Thanks for looking into this, and even more so for fixing it: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/merge_requests/80