Improving performance
This article is just a list of things you can do to improve the performance of SimpleScreenRecorder (or in some cases the computer in general) so you can record at a decent frame rate.
Choose a different video codec
Some video codecs are really efficient, and other are really slow. The H.264 codec is by far the fastest one, especially if you pick the 'superfast' or 'ultrafast' profile. You may have to install extra packages to get H.264 support (for Ubuntu: sudo apt-get install libavcodec-extra-53 libavformat-extra-53).
It's a good idea to choose a fast profile (which will result in large files), and afterwards re-encode the video with a slower profile to make the file smaller. You can use the avconv/ffmpeg command line tool for re-encoding. There are also GUI programs that can do this, for example Handbrake.
Use uncompressed audio
Audio is much smaller than video, so it doesn't matter as much whether it's compressed or not. So you might want to switch to uncompressed audio, and re-encode it afterwards.
Reduce the resolution
If you don't need a high resolution, try scaling the video down before it is encoded (enable scaling on the input page). This will reduce the CPU time required to encode the video.
It's even better if you can make the video source itself smaller. For example, if you're recording a game, you may want to switch it from fullscreen to windowed mode and resize the window so it matches the final video resolution that you want. For example, if you're going to upload your video to YouTube, and 480p is good enough, resize your window to 854x480. (More YouTube resolutions here.)
Reduce the recording frame rate
In most cases, the processing effort required to encode video is roughly proportional to the frame rate, as is the file size. Reducing the frame rate from e.g. 60 to 30 FPS will have a significant effect on CPU usage. This may allow the recorded application to run more smoothly, resulting in better overall video smoothness, even though the video frame rate may be lower.
Reduce the frame rate of the application that you want to record
If you're recording at 30 frames per second, it doesn't make much sense to run the application that you want to record at 60 frames per second (or even higher). If you use OpenGL recording, you can check Limit application frame rate to make the application frame rate match the video frame rate. Most modern video games are frame rate independent (even if you slow down the frame rate, the game world will still run at the same speed), so this works pretty well. It will typically make the video smoother as well, because no frames need to be dropped.
Make sure you have enough memory
SimpleScreenRecorder may in some cases need 300MB-800MB of memory if you're recording at a high resolution (depending on which codec you are using). If your computer suddenly becomes unusably slow, this may be because you're running out of physical RAM and the kernel is moving memory into swap space (on your hard drive). You can run the command 'free' in a terminal to see how much memory is available (ignore the first line, the number you should care about is free + buffers + cache).
Use OpenGL recording if possible
OpenGL recording won't necessarily result in a higher frame rate, but it eliminates tearing and reduces the probability that a frame will be missed or that the same frame will be shown twice. The result is usually better even if the frame rate is a bit lower.
Use a non-compositing window manager
Compositing window managers have a number of advantages, but high frame rates isn't one of them. Games typically run at a lower frame rate when a compositing window manager is used (where 'lower' ranges from 'almost unnoticeable' to 'twice as slow' depending on what window manager, drivers and hardware you use). Note that the actual frame rate visible on screen may be lower than the frame rate reported by the application, because the application and window manager are competing for GPU resources. If the application is using all available GPU processing power, the window manager may not be able to actually display the generated frames sufficiently quickly.
If you are using the KDE window manager (KWin), you can press Shift+Alt+F12 to enable/disable compositing.
If you are using Xfce, you can disable compositing with the Window Manager Tweaks application (under the 'Compositor' tab).
If you are using LXDE, you are already using Openbox, which is a non-compositing window manager - you don't have to do anything.
If you are using something else, you have to stop it and run a non-compositing window manager like Openbox instead. I don't recommend doing this if you're not familiar with the terminal, because it's possible that your graphical interface won't work properly anymore (you can fix this by rebooting).
You can temporarily replace your window manager with Openbox by pressing Ctrl+Alt+F1, logging in, running DISPLAY=:0.0 openbox --replace, and pressing Ctrl+Alt+F7 (or F8). But if you do that, you will probably have to log out (or reboot) afterwards to get your original window manager back. And obviously you need to install Openbox first (on Ubuntu: sudo apt-get install openbox).
Comments
Aegis |
Comment #1: Wed, 7 Aug 2013, 20:34 (GMT+1, DST) That command line you have for installing H.264 didn't seem to work for me. Try this instead: sudo apt-get install ubuntu-restricted-extras |
Farox |
Comment #2: Tue, 10 Sep 2013, 13:57 (GMT+1, DST) I have ported this wonderfull program to Pandora Handheld. Thanks a lot |
Arfink |
Comment #3: Sat, 22 Feb 2014, 22:31 (GMT+1, DST) I'm having some performance difficulties. I am using Linux Mint 13 LTS (which is closely based on Ubuntu) and trying to record Minecraft. The game runs at 60 FPS on my computer normally, but when recording it slows down to 15 FPS. I have 8gb of RAM and a quad core processor so this really shouldn't be happening. For program settings, I am recording OpenGL at 8mp because I have tons of extra ram. I don't run out when I'm running the game. I am encoding to H.264 and uncompressed audio. Recording to MKV file. I have been running my system monitor while the game runs and have not seen any CPU cores hitting 100% and I'm not suddenly using a lot of swap. Any ideas? |
Maarten BaertAdministrator |
Comment #4: Sun, 23 Feb 2014, 16:42 (GMT+1, DST) Quote: Arfink
I'm having some performance difficulties. I am using Linux Mint 13 LTS (which is closely based on Ubuntu) and trying to record Minecraft. The game runs at 60 FPS on my computer normally, but when recording it slows down to 15 FPS. I have 8gb of RAM and a quad core processor so this really shouldn't be happening. The number of cores doesn't say very much. Most smartphones also have quad-core CPUs now, but they are still ~10 times less powerful than a high-end i7. What processor do you have? This is probably not the cause, but I'd like to know it anyway. Also, make sure that you are using the latest version of SSR (v0.2.0). Quote: Arfink
For program settings, I am recording OpenGL at 8mp because I have tons of extra ram. That doesn't make much sense, it won't increase the resolution or anything, it will just reserve more memory that will never be used. If 2MP is enough, you shouldn't use more than that. What GPU are you using? This is relevant for OpenGL recording. Quote: Arfink
I don't run out when I'm running the game. I am encoding to H.264 and uncompressed audio. Recording to MKV file. I have been running my system monitor while the game runs and have not seen any CPU cores hitting 100% and I'm not suddenly using a lot of swap. Any ideas? What preset are you using? The default 'superfast'? Where are you storing the file (hard disk, USB stick, network drive)? Your storage location needs to be fast enough to store the file as it is generated, this can be a problem for network disks. You said that the FPS dropped to 15 fps. Is this the number you see in Minecraft, or is it what SSR says? What is the 'FPS in' and 'FPS out' that you are seeing? By the way, try disabling vsync in Minecraft if it was enabled. |
Ubuntuaddicted |
Comment #5: Sun, 23 Mar 2014, 0:52 (GMT+1, DST) Holy cow, opengl recording is way different. I don't see the instructions on how to use opengl recording. I want to record minecraft using opengl recording. UPDATE: ok, i used the main menu editor within xubuntu to get the full command which is ran to start minecraft, i pasted that (it was sh -c "XMODIFIERS= java -Xmx2048M -Xms512M -cp /usr/share/minecraft/minecraft.jar net.minecraft.bootstrap.Bootstrap") into the command box within ssr, i check marked limit application frame rate and hit launch now. then everything worked just fine. it recorded minecraft at 25,000 just like i wanted. i was only doing a local recording tonight but i may try the dual ssr another day. Last modified: Sun, 23 Mar 2014, 3:37 (GMT+1, DST) |
Maarten BaertAdministrator |
Comment #6: Sun, 23 Mar 2014, 15:32 (GMT+1, DST) Quote: Ubuntuaddicted
Holy cow, opengl recording is way different. I don't see the instructions on how to use opengl recording. I want to record minecraft using opengl recording. UPDATE: ok, i used the main menu editor within xubuntu to get the full command which is ran to start minecraft, i pasted that (it was sh -c "XMODIFIERS= java -Xmx2048M -Xms512M -cp /usr/share/minecraft/minecraft.jar net.minecraft.bootstrap.Bootstrap") into the command box within ssr, i check marked limit application frame rate and hit launch now. then everything worked just fine. it recorded minecraft at 25,000 just like i wanted. i was only doing a local recording tonight but i may try the dual ssr another day. If you are using glinject-next, you can also use the command 'ssr-glinject' to run your programs. You can modify your launcher so it will execute this: ssr-glinject sh -c "XMODIFIERS= java -Xmx2048M -Xms512M -cp /usr/share/minecraft/minecraft.jar net.minecraft.bootstrap.Bootstrap You can run it like this all the time, the new GLInject library doesn't do anything unless you start SSR. So you can enable it all the time and just start SSR whenever you want to record something. PS: I don't understand why your command is so complex, I just use java -jar Minecraft.jar and I never had any problems :). |
Gfurst |
Comment #7: Tue, 27 May 2014, 23:04 (GMT+1, DST) Hey there, firstly, thanks for the program, I've tried more than a few times to get a working good screencast tool, but never got it right, bug free and with quality. And a additional tip, there are lot of codecs available, I think that is somewhat confusing, maybe it could show only codecs currently available on the system, and leave documented in the help pages the full list, and maybe how to get them. Last modified: Tue, 27 May 2014, 23:06 (GMT+1, DST) |
Maarten BaertAdministrator |
Comment #8: Wed, 28 May 2014, 1:23 (GMT+1, DST) Quote: Gfurst
Here I would like some help trying to improve performance, specially on openGL apps such as minecraft. Sure, read this: Quote: Gfurst
And a additional tip, there are lot of codecs available, I think that is somewhat confusing, maybe it could show only codecs currently available on the system, and leave documented in the help pages the full list, and maybe how to get them. That's why I keep the simple codecs (H.264, VP8, ...) separate from the full list that you get when you choose 'other'. If you use 'other', I assume that you know what you are doing :). The simple list will clearly tell you if a codec is not installed, and the full list only contains codecs that you actually have installed - so what you're asking is already the case. It is possible that some codecs are incompatible with SSR of course, and there are a lot of codecs that aren't actually real codecs (like the MD5 or the NULL codec), but I can't easily tell them apart in SSR since it's not my list of codecs. |
Gfurst |
Comment #9: Wed, 28 May 2014, 22:32 (GMT+1, DST) Quote: Maarten Baert
Sure, read this: Hey Maarten, thanks for clearing that up, I'll test up with those settings. Quote: Maarten Baert
That's why I keep the simple codecs (H.264, VP8, ...) separate from the full list that you get when you choose 'other'. If you use 'other', I assume that you know what you are doing :). The simple list will clearly tell you if a codec is not installed, and the full list only contains codecs that you actually have installed - so what you're asking is already the case. It is possible that some codecs are incompatible with SSR of course, and there are a lot of codecs that aren't actually real codecs (like the MD5 or the NULL codec), but I can't easily tell them apart in SSR since it's not my list of codecs. Oh that explains it, I've tried some codecs which didn't work, and thought it was because they weren't installed( i didn't even know). In the area for the parameters options for the encoder, will that take any option available to the codec? As you said, constant quality factor isn't always intuitive to users, I'm just wondering if they could be applied to other codecs like theora, vorbis and lame. |
Maarten BaertAdministrator |
Comment #10: Thu, 29 May 2014, 3:28 (GMT+1, DST) Quote: Gfurst
For example, if I take the parameters from the Handbrake GUI( it will have a lot of options presented in a intuitive way and a text area showing the cli equivalent), and paste them will it work? No, you can only use options from this list, or what ffmpeg calls 'private' codec options. This includes most of the x264 options, but not all. Quote: Gfurst
As you said, constant quality factor isn't always intuitive to users, I'm just wondering if they could be applied to other codecs like theora, vorbis and lame. Not all codecs have a mode like that, and even if they do, it's not always implemented very well. The only codec where the constant quality mode actually works great is x264. |
Rightwingrb |
Comment #11: Sun, 10 Aug 2014, 16:46 (GMT+1, DST) OK so I'm a little bit fuzzy on how to use the OpenGL recording feature. I have a pretty good understanding of how the program works when selecting a window to record (which is how I have been recording for months). I am running Ubuntu 14.04 LTS and recording Minecraft. Which check boxes should I have checked and what should I be entering in the "Command:" and "Working Directory:" lines? Thank you for your assistance |
Maarten BaertAdministrator |
Comment #12: Mon, 11 Aug 2014, 0:00 (GMT+1, DST) Quote: Rightwingrb
OK so I'm a little bit fuzzy on how to use the OpenGL recording feature. I have a pretty good understanding of how the program works when selecting a window to record (which is how I have been recording for months). I am running Ubuntu 14.04 LTS and recording Minecraft. Which check boxes should I have checked and what should I be entering in the "Command:" and "Working Directory:" lines? Thank you for your assistance Recording Minecraft is easy. You just have to put the launch command in the 'command' field. For example, java -jar Minecraft.jar. The working directory should be set to the path of the Minecraft.jar file (that's the Minecraft launcher). |
Master X |
Comment #13: Mon, 19 Jan 2015, 4:26 (GMT+1, DST) Hello there, So I got OpenGL working for recording Minecraft on my desktop by looking here and it seems to work excellently. It's fast and it doesn't skip frames, which is awesome. Simple Screen Recorder is just what I needed to record. Is there a way to improve the quality of the resolution, though? I recorded a video that was a little over 4 minutes long and it looked kind of fuzzy when I tried to watch it. Thanks |
Maarten BaertAdministrator |
Comment #14: Thu, 22 Jan 2015, 23:33 (GMT+1, DST) Quote: Master X
Hello there, So I got OpenGL working for recording Minecraft on my desktop by looking here and it seems to work excellently. It's fast and it doesn't skip frames, which is awesome. Simple Screen Recorder is just what I needed to record. Is there a way to improve the quality of the resolution, though? I recorded a video that was a little over 4 minutes long and it looked kind of fuzzy when I tried to watch it. Thanks Which codec were you using? SSR will choose the resolution when you first start the recording, so if you start recording a small Minecraft window and then switch to fullscreen, SSR will be stuck on the old resolution. If you want to avoid this, you should either resize the window to its final size before you start recording, or you should enable scaling in SSR and enter the desired resolution manually. |
Shaneroach |
Comment #15: Fri, 30 Jan 2015, 18:54 (GMT+1, DST) Thanks so much for this. I was going to have to learn how to run ffmpg or avwhatsis from the command line and it was intimidating. I guess it is normal to have the game play seem to get tearing but for the playback to look fine? I have a gtx 660 and i5 at 3.4Ghz and was wondering which would be the better to upgrade to get better performance? The processor doesn't seem to be breathing all THAT hard once everything is up and running, 30-50% ranges on all cores once it gets leveled out... I have to imagine my bottleneck is the graphics card? Basically, any hardware advice appreciated. I have been shopping mother boards too and it is getting difficult for me to decide which pin set to go for if I get a better board... All of this is motivated by wanting to game and record games. Thanks again. |
Maarten BaertAdministrator |
Comment #16: Sat, 31 Jan 2015, 1:10 (GMT+1, DST) Quote: Shaneroach
I guess it is normal to have the game play seem to get tearing but for the playback to look fine? With OpenGL recording, yes. The recording is never affected by tearing, even when v-sync is off. Quote: Shaneroach
I have a gtx 660 and i5 at 3.4Ghz and was wondering which would be the better to upgrade to get better performance? The processor doesn't seem to be breathing all THAT hard once everything is up and running, 30-50% ranges on all cores once it gets leveled out... I have to imagine my bottleneck is the graphics card? Basically, any hardware advice appreciated. I have been shopping mother boards too and it is getting difficult for me to decide which pin set to go for if I get a better board... All of this is motivated by wanting to game and record games. Depends on the game, the resolution and the frame rate. Minecraft is definitely not GPU-limited on a GTX 660 (unless you're running it with some crazy mods). What kind of performance are you getting now, and what are you trying to reach? OpenGL recording performance under SSR is mainly limited by PCI Express throughput, and the fact that SSR is currently stalling the GPU pipeline (which is a huge problem for modern GPU-intensive games). I'm working on improving the latter issue and I've seen very noticeable performance gains, at least on my GTX 660 (I expect similar gains on AMD, not sure about Intel though). It's not ready yet, the code currently can't handle resolution changes, multiple windows and a few other edge cases, but it should be out soon. Pretty much every modern desktop will give you PCI Express 3.0 with 16 lanes, which is more than enough for SSR even at high resolutions and frame rates. This can be a problem with some laptops though, I've seen (current!) models that use PCI Express 2.0 with just 4 lanes, which is literally 8 times less, and the impact is very noticeable. If your CPU is not maxed out, there's no point in upgrading it. Usually CPU usage is only important if you want to do live streaming (because then you need better compression, so you can't use the 'superfast' or 'ultrafast' presets). |
Ynnebbenny |
Comment #17: Mon, 2 Feb 2015, 12:13 (GMT+1, DST) Hi, In Windows I used Camstudio and then Virtualdub for joining the videos without having to re encode them. Can I put in a pie in the sky request that SSR has a built in video append option as well as the sound export import option. This would allow simple video editing without having to re encode and lose further video quality. Thanks for considering my request. Regards Benny shoot.the.cat (at) gmail.com |
Shaneroach |
Comment #18: Tue, 3 Feb 2015, 15:33 (GMT+1, DST) Quote: Maarten Baert
Depends on the game, the resolution and the frame rate. Minecraft is definitely not GPU-limited on a GTX 660 (unless you're running it with some crazy mods). What kind of performance are you getting now, and what are you trying to reach? Playing Team Fortress II and trying to get 1080P and 60 frames which is the new max it would seem for Youtube videos. The other wrinkle I forgot to mention is I am using a webcam at the same time, and it certainly seems to be a major offender in destroying the recording. I tried dropping some of the stats on TFII, and while it seems to work well when recording just TFII, trying to play that and run the webcam still doesn't work. On Linux I am not sure there is a way to monitor the workload on the video card? I don't necessarily want to upgrade if it is basically just an issue with getting the SSR code to deal with multiple apps running, but if you imagine it might help, a GTX 980 IS on my list of things to get pretty soon, so... |
Maarten BaertAdministrator |
Comment #19: Wed, 4 Feb 2015, 22:43 (GMT+1, DST) @Ynnebbenny: Appending without re-encoding is always a pain and only works for some very specific codecs. My advice: use the 'high quality intermediate' settings and just re-encode to a lower bit rate after editing. Avidemux shouldn't have a problem with SSR files unless you are doing something weird - which format and codecs are you using? If Avidemux doesn't work for you, give Kdenlive a try - it's a bit unstable but pretty powerful, and it works fine with files from SSR (my usual settings: MKV+H.264+Vorbis). SSR is not a video editor, I have no plans to add video editing features. @Shaneroach: I think you will see a decent performance boost for TF2 once my improvements are out. Also, you may be able to reduce the impact of your webcam by switching it to a lower resolution (I assume your webcam doesn't cover your entire screen, so there's no need for 1080p or even 720p). I don't think upgrading your CPU or GPU would make a significant difference, since it sounds like you're just limited by PCI express speed and the fact that the current OpenGL capture code is inefficient. Last modified: Wed, 4 Feb 2015, 22:53 (GMT+1, DST) |
Ynnebbenny |
Comment #20: Mon, 9 Feb 2015, 12:01 (GMT+1, DST) Quote: Maarten Baert
@Ynnebbenny: Appending without re-encoding is always a pain and only works for some very specific codecs. My advice: use the 'high quality intermediate' settings and just re-encode to a lower bit rate after editing. Avidemux shouldn't have a problem with SSR files unless you are doing something weird - which format and codecs are you using? If Avidemux doesn't work for you, give Kdenlive a try - it's a bit unstable but pretty powerful, and it works fine with files from SSR (my usual settings: MKV+H.264+Vorbis). SSR is not a video editor, I have no plans to add video editing features. Hi Maarten thanks for your response. Actually Avidmux has started to play ball. I dont know what its suddenly working. I love the h.264 codec and was exporting those out. I'm guessing it may have something to do with the sound compression codecs I was using. |
Maarten BaertAdministrator |
Comment #21: Mon, 9 Feb 2015, 22:38 (GMT+1, DST) Quote: Ynnebbenny
Hi Maarten thanks for your response. Actually Avidmux has started to play ball. I dont know what its suddenly working. I love the h.264 codec and was exporting those out. I'm guessing it may have something to do with the sound compression codecs I was using. Losless H.264 is supported. Just set CRF to 0. But I don't recommend it. The 'high quality intermediate' profile is near-lossless (i.e. you will not be able to tell the difference between this and true lossless after you've re-encoded it another time), but it is much faster and takes less space. |
Master X |
Comment #22: Thu, 12 Feb 2015, 17:58 (GMT+1, DST) Thanks. It turned out that all I needed to do was set the constant rate factor to 0 and the quality was instantly improved. I guess it turned out fuzzy because the constant rate factor was set to the default at 23. |
Maarten BaertAdministrator |
Comment #23: Thu, 12 Feb 2015, 23:07 (GMT+1, DST) Quote: Master X
Thanks. It turned out that all I needed to do was set the constant rate factor to 0 and the quality was instantly improved. I guess it turned out fuzzy because the constant rate factor was set to the default at 23. You don't need to go all the way to zero. 10 or 15 is still really good, but the files are much smaller and encoding is faster. Last modified: Thu, 12 Feb 2015, 23:07 (GMT+1, DST) |
Shaneroach |
Comment #24: Sat, 14 Feb 2015, 17:43 (GMT+1, DST) Regarding compositing, it appears Gnome turns it off when you go full screen, so I guess the work around is go full screen and set the game to the size you intend to record for. It would appear the folks at Gnome have some sort of philosophical objection to folks being able to turn it off manually. http://lwn.net/Articles/479939/ |
Remminaman |
Comment #25: Sat, 14 Feb 2015, 21:52 (GMT+1, DST) Utter Awesomeness! However, I'm using SSR in a virtualised environment and I want to get the best deal. I'm using SSR on Mint Quiana (no issues there) and trying to record remmina sessions for (Windows Server) virtual machines that sit on another host. Remmina renders them nicely, but it seems I'm getting a lot of chop recording those windows. Can you provide any tips on how to optimise? Thanks, your worship :-) |
Maarten BaertAdministrator |
Comment #26: Sun, 15 Feb 2015, 15:06 (GMT+1, DST) Quote: Remminaman
Utter Awesomeness! However, I'm using SSR in a virtualised environment and I want to get the best deal. I'm using SSR on Mint Quiana (no issues there) and trying to record remmina sessions for (Windows Server) virtual machines that sit on another host. Remmina renders them nicely, but it seems I'm getting a lot of chop recording those windows. Can you provide any tips on how to optimise? Thanks, your worship :-) Is the recording more choppy than what you see on your display? Or does running SSR make your display choppy? I don't think remote desktop clients do anything abnormal that could interfere with SSR, but in my experience all remote desktop protocols are somewhat slow. |
Momrocker |
Comment #27: Wed, 24 Jun 2015, 14:43 (GMT+1, DST) I'm pretty confused at this point. I've been trying to record Half-Life 2 using SSR just with the basic rectangle grab and whenever I'm recording it seems like SSR is lowering the framerate of my entire screen. I have cl_showfps on in HL2 so it's showing that my fps is staying at a stable exact 60fps the entire time I'm recording but if I do a simple test of walking left and right without recording, then hit my recording hotkeys and keep doing the same motion there's a visible drop in framerate that translates over to my recordings even though the game still says it's running at the same framerate. I'm using Ubuntu 14.10 so maybe it's a Unity problem? I don't know, but I'm using ultrafast, h.264, crf 25 (doesn't seem to change performance anyways), and uncompressed audio, which as far as I can tell is the fastest settings possible, and System Monitor is showing that it's not really pushing my cpu or memory too hard. I'm stumped, any input on why this might be happening would be appreciated. |
Maarten BaertAdministrator |
Comment #28: Sun, 28 Jun 2015, 11:08 (GMT+1, DST) Quote: Momrocker
I'm pretty confused at this point. I've been trying to record Half-Life 2 using SSR just with the basic rectangle grab and whenever I'm recording it seems like SSR is lowering the framerate of my entire screen. I have cl_showfps on in HL2 so it's showing that my fps is staying at a stable exact 60fps the entire time I'm recording but if I do a simple test of walking left and right without recording, then hit my recording hotkeys and keep doing the same motion there's a visible drop in framerate that translates over to my recordings even though the game still says it's running at the same framerate. I'm using Ubuntu 14.10 so maybe it's a Unity problem? I don't know, but I'm using ultrafast, h.264, crf 25 (doesn't seem to change performance anyways), and uncompressed audio, which as far as I can tell is the fastest settings possible, and System Monitor is showing that it's not really pushing my cpu or memory too hard. I'm stumped, any input on why this might be happening would be appreciated. The part that's slowing down your game isn't SSR itself, it's most likely the X server or your GPU driver which can't keep up. Some things you can try: |
Ubu Rex |
Comment #29: Mon, 6 Jul 2015, 2:59 (GMT+1, DST) Thank you for this nifty application! A powerful improvement could be a scheduler, maybe using cron or crontab, enabling us to start and stop the record any time. PS |
Momrocker |
Comment #30: Mon, 13 Jul 2015, 1:03 (GMT+1, DST) After trying everything else possible I did actually install and test openbox to see if it was the compositing causing issues, and it was. After that I installed KDE and with compositing disabled I'm getting perfect recordings with SSR. So, for anyone who's having similar issues as I was, don't overlook the compositing window manager, that can hugely impact your framerates. |
Mex |
Comment #31: Fri, 29 Jan 2016, 23:27 (GMT+1, DST) Hi, I would like to say many thank you for this wonderful program. And I wont ask you if it could be possible to add a timer funktion for start and stop recording? |
Blackpoll |
Comment #32: Mon, 25 Apr 2016, 23:43 (GMT+1, DST) Greetings, I will be recording powerpoint slides on my desktop and uploading to Vimeo Pro and I'm wondering what the best settings are in SSR? They recommend: H.264 video I understand the audio recommendations but not the video bit rate conversion with SSR. The constant rate factor and the preset and how that translates is confusing into what Vimeo is recommending. Here is a link to their guidelines for better clarity: https://vimeo.com/help/compression I'll be selecting a rectangle to record which takes up most of my computer screen but not all of it. thanks! Last modified: Mon, 25 Apr 2016, 23:45 (GMT+1, DST) |
Rjekker |
Comment #33: Tue, 25 Apr 2017, 21:29 (GMT+1, DST) Hi, I have started to use simplescreenrecorder on my Ubuntu machine. I need these video's to be in a resolution of 1280x720. To make things simple I switch my main monitor to that resolution and then record the entire screen. Everything seems to go smoothly from there. But strangely when editing the videos I find that their actual resolution is 1280x736 (!). So I have to scale them down to fit with the rest of my content. If I open the video's in VLC and ask for the codec information it tells me this: Resolution: 1280x736 (wrong res) While recording, simplescreenrecorder itself tells me the resolution in and out is 1280x720. So now the question is: where do the 16 extra pixels come from? I tried encoding with the default H.246 and with MPEG-4, but that makes no difference. Any idea what might cause this? Thanks, Reindert |
Maarten BaertAdministrator |
Comment #34: Mon, 1 May 2017, 13:07 (GMT+1, DST) Quote: Blackpoll
Greetings, I will be recording powerpoint slides on my desktop and uploading to Vimeo Pro and I'm wondering what the best settings are in SSR? They recommend: H.264 video I understand the audio recommendations but not the video bit rate conversion with SSR. The constant rate factor and the preset and how that translates is confusing into what Vimeo is recommending. Here is a link to their guidelines for better clarity: https://vimeo.com/help/compression I'll be selecting a rectangle to record which takes up most of my computer screen but not all of it. thanks! Just use the default SSR settings, they will be fine. The Vimeo recommendations are for regular real-life videos, not powerpoint slides, so their recommended bitrate is excessively high for your use case. SSR will by default use a 'constant quality' mode which means that the bitrate will be whatever is necessary to get sufficient quality. Quote: Rjekker
Hi, I have started to use simplescreenrecorder on my Ubuntu machine. I need these video's to be in a resolution of 1280x720. To make things simple I switch my main monitor to that resolution and then record the entire screen. Everything seems to go smoothly from there. But strangely when editing the videos I find that their actual resolution is 1280x736 (!). So I have to scale them down to fit with the rest of my content. If I open the video's in VLC and ask for the codec information it tells me this: Resolution: 1280x736 (wrong res) While recording, simplescreenrecorder itself tells me the resolution in and out is 1280x720. So now the question is: where do the 16 extra pixels come from? I tried encoding with the default H.246 and with MPEG-4, but that makes no difference. Any idea what might cause this? Thanks, Reindert I can't reproduce this here, I just get 1280x720 no matter what I do. Can you send me a short video file which contains the problem? Last modified: Mon, 1 May 2017, 13:11 (GMT+1, DST) |
Glassmenagerie |
Comment #35: Thu, 7 Sep 2017, 0:06 (GMT+1, DST) Hi Maarten, I want to create a DVD from a file made with Simple Screen Recorder. Which DVD burning software would you suggest and what would the Simple Screen Recorder codec settings need to be I want to play the DVD on a Windows PC. This Windows PC will probably not have VLC or any after market software installed. Thanks ! I've been using your software for several years now and am very glad to have it installed on my Ubuntu system. Best Regards, |
Maarten BaertAdministrator |
Comment #36: Sun, 29 Oct 2017, 2:44 (GMT+1, DST) Quote: Glassmenagerie
Hi Maarten, I want to create a DVD from a file made with Simple Screen Recorder. Which DVD burning software would you suggest and what would the Simple Screen Recorder codec settings need to be I want to play the DVD on a Windows PC. This Windows PC will probably not have VLC or any after market software installed. Thanks ! I've been using your software for several years now and am very glad to have it installed on my Ubuntu system. Best Regards, DVD codecs are standardized. It doesn't matter what you use in SSR, you will have to transcode it to DVD format anyway (SSR can't do this directly). So just use a high quality format so you don't lose too much detail in the conversion (for example, H.264 with crf 20). |
Ssr-user |
Comment #37: Fri, 26 Apr 2019, 15:16 (GMT+1, DST) hi maarten, well, here is what i try to achieve: record as .mkv in the 'best' possible way already (in regards to my hardware), in order to avoid an additional long video transcoding process - but, at the same time, still have the option to burn a pal dvd later on (with minimal quality loss during transcoding). so i went for these options which work very well on my machine mkv, 60fps, h.264 + crf 20 + veryfast preset + uncompressed audio the setting i am unsure about - which optimal mkv framerate to go with initially (for best possible pal dvd conversion)? 50fps or 60fps > 25fps? p.s.: i can barely notice a benefit in framerates while recording with the compositor enabled / disabled under kde plasma? on the contrary, i even read an advice to not disable it (except for old hardware) so to avoid screen tearing effects! is that true? Last modified: Fri, 26 Apr 2019, 15:17 (GMT+1, DST) |
Csias40 |
Comment #38: Sat, 27 Apr 2019, 19:40 (GMT+1, DST) Hi, I am trying to record a presentation that I will lose access to in a month. I did this with one and it works great, but I have to set it up when I leave because my computer records outside noises, too. My question: is there a way to set a recording time so it will cut up when the presentation is over? I know how long it is, but sometimes I have to leave for longer, and it would be nice if it would cut off when the presentation was over instead of recording for 6 hours (these presentations are about 3 hours long. Just wondered if it was possible, or if there is a way to make it possible... Thanks so much! |
Maarten BaertAdministrator |
Comment #39: Sun, 12 May 2019, 18:15 (GMT+1, DST) Quote: Ssr-user
hi maarten, well, here is what i try to achieve: record as .mkv in the 'best' possible way already (in regards to my hardware), in order to avoid an additional long video transcoding process - but, at the same time, still have the option to burn a pal dvd later on (with minimal quality loss during transcoding). so i went for these options which work very well on my machine mkv, 60fps, h.264 + crf 20 + veryfast preset + uncompressed audio the setting i am unsure about - which optimal mkv framerate to go with initially (for best possible pal dvd conversion)? 50fps or 60fps > 25fps? p.s.: i can barely notice a benefit in framerates while recording with the compositor enabled / disabled under kde plasma? on the contrary, i even read an advice to not disable it (except for old hardware) so to avoid screen tearing effects! is that true? Since your screen runs at 60 Hz, recording at anything other than 60 fps will likely just results in some frames being duplicated or dropped. So it makes sense to record at the same frame rate as your screen. So unless you can change your screen to 50 Hz I would stick to 60 fps. The exception would be if you disable vsync in your compositor as well as the application being recorded, and configure the application to run at a much higher frame rate than your recording frame rate. But this will likely cause tearing. Whether disabling the compositor will introduce screen tearing depends on your GPU driver as well as the application being recorded. The only way to eliminate screen tearing completely is to use OpenGL recording. Quote: Csias40
Hi, I am trying to record a presentation that I will lose access to in a month. I did this with one and it works great, but I have to set it up when I leave because my computer records outside noises, too. My question: is there a way to set a recording time so it will cut up when the presentation is over? I know how long it is, but sometimes I have to leave for longer, and it would be nice if it would cut off when the presentation was over instead of recording for 6 hours (these presentations are about 3 hours long. Just wondered if it was possible, or if there is a way to make it possible... Thanks so much! This is a common feature request, but it hasn't been implemented yet. |