GNOME Bugzilla – Bug 669066
Minor, but significant, tweaks to the recorder
Last modified: 2012-02-03 17:14:38 UTC
Now that recording is working because of the PBO patch on my Intel system, I came up with this set of patches that make it work more safely and efficiently. If someone is really trying to get optimium recordings, they'd need to tweak the pipeline for their available CPU resources and recording script.
Created attachment 206475 [details] [review] ShellRecorderSrc: Set as GST_FORMAT_TIME We need to indicate that our GStreamer source produces timestamped frames, instead of the default, which is to produce a stream of bytes. This is needed for correctness, and to avoid warnings for some pipelines.
Created attachment 206476 [details] [review] ShellRecorder: improve the default pipeline The default pipeline was fairly aggressive about quality, and could be too expensive for some computers. Decrease the quality setting for the vp8 codec from 10 to 8, and increase the speed setting from 2 to 7. (Basically, quality affects the visual fidelity of the end result, while speed affects how much CPU the encoder uses to get a high compression ratio at that quality level.) Remove videorate from the pipeline, since the GStreamer VP8 encoder can handle variable-framerate streams. This means that we won't spend CPU encoding duplicate frames added by videorate.
Created attachment 206477 [details] [review] ShellRecorder: drop frames to keep from running the user out of memory. Once we're buffering more than 3/4's of the "half of memory" target for total buffer usage, start dropping frames.
Created attachment 206478 [details] [review] ShellRecorder: drop frames to approximate the target framerate Instead of adding every rendered frame into the recording, drop frames and only buffer and record enough frames to match the target framerate. Increase the default frame rate from 15 to 30, since now that we're actually enforcing framerate, it's noticeable that 15fps is not smooth.
*** Bug 576133 has been marked as a duplicate of this bug. ***
Review of attachment 206475 [details] [review]: Makes sense.
Review of attachment 206476 [details] [review]: Yeah this makes sense and result isn't visually that much worse then the old pipeline (in terms of artifacts).
Review of attachment 206477 [details] [review]: This makes sense as well, just killing the system and saying "sorry your system is to slow" is not really a great user experience.
Review of attachment 206478 [details] [review]: Looks good.
Attachment 206475 [details] pushed as 025784f - ShellRecorderSrc: Set as GST_FORMAT_TIME Attachment 206476 [details] pushed as d4a26fb - ShellRecorder: improve the default pipeline Attachment 206477 [details] pushed as f2cc5cf - ShellRecorder: drop frames to keep from running the user out of memory. Attachment 206478 [details] pushed as 60d8683 - ShellRecorder: drop frames to approximate the target framerate
Wow, this works much better now on my X301 Thinkpad with GM45 Intel GPU. FYI, you can make recording even smoother recording with these settings: org.gnome.shell.recorder file-extension 'flv' org.gnome.shell.recorder framerate 30 org.gnome.shell.recorder pipeline 'ffenc_flashsv ! queue ! flvmux' The advantage is that this is a screen recording optimized codec. Recording in bgr24 it’s lossless and it’s easier to edit than high-profile codecs. Its bitrate is much larger but it’s less compute intense during recording and editing. And it supports VFR. A good intermediary format. Byzanz supports it too for this reason. Perhaps you could suggest this alternative pipeline in the dconf key description?
(In reply to comment #11) > Wow, this works much better now on my X301 Thinkpad with GM45 Intel GPU. The speed boost is due to https://bugzilla.gnome.org/show_bug.cgi?id=669065 > FYI, you can make recording even smoother recording with these settings: > > org.gnome.shell.recorder file-extension 'flv' > org.gnome.shell.recorder framerate 30 > org.gnome.shell.recorder pipeline 'ffenc_flashsv ! queue ! flvmux' > > The advantage is that this is a screen recording optimized codec. Recording in > bgr24 it’s lossless and it’s easier to edit than high-profile codecs. Its > bitrate is much larger but it’s less compute intense during recording and > editing. And it supports VFR. > > A good intermediary format. Byzanz supports it too for this reason. > > Perhaps you could suggest this alternative pipeline in the dconf key > description? Well the main reasons for using webm are: 1) Not patent encumbered (so distros can use it as is) 2) Results are easily share able due to widespread support (inkl. in the web) For special needs the pipeline can be configured and there is nothing preventing a GUI tool from being written to aid the user while doing so (can have checkboxes to add sound etc.) ... A lossless codec has the downside that it uses way to much diskspace (and I don't know the patent situation for the codec you suggested). So I am not sure that adding alternative pipelines in the schema descriptions is really helpful.