Custom codec options
Last updated 25 December 2018
SimpleScreenRecorder supports some codec options that are not displayed in the graphical interface because they are only useful for a small number of users and would just be confusing. These options can be set using the 'custom options' setting. The options should be separated by commas, for example option1=value1,option2=value2,option3=value3.
Options recognised by SimpleScreenRecorder
| Type | Name | Description |
|---|---|---|
video/audio |
threads |
The number of threads that will be used for encoding. Not all codecs support this. For video it defaults to the number of CPU cores, for audio it default to one. |
video/audio |
qscale |
The encoding quality (floating point number). Not all codecs support this, and the meaning is codec-dependent. Equivalent to the 'qscale' option for video or the 'aq' option for audio in ffmpeg. Only use this if you know what you're doing. |
video |
minrate |
The minimum bit rate (in kbps). Not very useful except for some very special cases. This setting wastes bandwidth with no real benefit, but it appears to be required to make some streaming services work well (e.g. Twitch). |
video |
maxrate |
The maximum bit rate (in kbps). The normal bit rate is usually interpreted as an average rather than a limit, so this option is useful for live streams where you don't want the bit rate to fluctuate too much. |
video |
bufsize |
Receiver buffer size for rate control (in kbit). Use this in combination with maxrate. This option tells the encoder how large the buffer of the receiver can be assumed to be for streaming. If you set this to the same value as maxrate, this corresponds to one second of buffered video (which is a sensible value). Most players buffer multiple seconds so that should be fine. Larger values give the encoder more freedom to temporarily increase the bit rate to values greater than maxrate, and then compensate for that by reducing the bit rate afterwards. This is useful because it improves the video quality. But if the value is too high, then players that don't buffer enough data will not be able to play the video smoothly. |
video |
keyint |
The keyframe interval, in number of frames (not seconds!). The default is codec-specific, for example 250 (= about 8 seconds at 30 fps). For streaming, it may be useful to use a lower value, such as 60 (= 2 seconds at 30 fps). Lower values decrease startup time, at the cost of some quality/bit rate. |
video |
pixelformat |
The pixel format that will be used by the encoder. Valid values are: nv12, yuv420, yuv422, yuv444, bgra, bgr, rgb. By default, SimpleScreenRecorder will pick the first format from this list that is supported by the encoder (which is almost always nv12 or yuv420). For high quality video, you may want to use a higher quality format like yuv444, but note that this will require more CPU power and a higher bit rate. |
audio |
sampleformat |
The sample format that will be used by the encoder. Valid values are: f32i, s16i, f32p, s16p. By default, SimpleScreenRecorder will pick the first format from this list that is supported by the encoder. The choice does not affect the audio quality in any significant way, so there is usually no reason to change this setting. |
If there is an option from ffmpeg/avconv that you need but isn't supported yet, feel free to contact me. Most options are trivial to add.
Private codec options
Some codecs have 'private' options that can also be set through SimpleScreenRecorder. The list below is incomplete - for the full list, you should run ffmpeg -h full or avconv -h full in a terminal.
| Codec | Name | Description |
|---|---|---|
libx264 |
preset |
Corresponds to the 'preset' setting for H.264. It changes the performance of the encoder, so it can be used to reduce the CPU usage. In constant quality mode, faster presets result in higher bit rates. In constant bit rate mode, faster presets result in lower image quality. |
libx264 |
tune |
Additional options on top of the encoding speed. A useful value is 'zerolatency', which will reduce the latency for live streams (at the cost of some quality/bit rate). |
libx264 |
crf |
Corresponds to the 'constant rate factor' setting for H.264. If it is set, the codec will use constant quality mode instead of constant bit rate mode, and the bit rate will be ignored. This is a great idea when recording to a file (so it is always enabled when you select H.264), but a bad idea for live streams since the bit rate will fluctuate a lot. |
Comments
This page used to have a comment section. It's closed now; what remains are the questions I answered. For questions and bug reports, please use GitHub.
Ubuntuaddicted · 29 December 2013, 08:45
i asked in the livestreaming section but how would we set the keyframe interval? twtich and hitbox are requiring a value of 2 for the keyframe interval.
Maarten Baert author · 30 December 2013, 17:28
That's a recommendation, not a requirement. I assume you mean 2 seconds, not 2 frames. libx264 seems to default to keyint=250, for 30fps that corresponds to about 8 seconds. This simply means that viewers may have to wait up to 8 seconds before they can start watching. For 2 seconds, you would need keyint=60 (keyint=2 would be insane).
I will add a keyint option, but it is not required to make streaming work :).
Ubuntuaddicted · 14 January 2014, 19:08
i see you added keyinit, THANK YOU. Do I need to update or something in order to use this custom codec option? I normally am notified with apt-get has updates and haven't seen any ssr updates lately.
Maarten Baert author · 14 January 2014, 21:15
Yes, I haven't released it yet (and it will probably take 1-2 months until it's ready). It's currently in the 'glinject-next' branch (because I didn't backport it), and that branch really isn't stable yet.
Ubuntuaddicted · 19 January 2014, 21:11
i just compiled from GIT and notice keyint is still not working. I would really appreciate it if you could incorporate this because I believe it's what's causing my black screen issues with hitbox. At some point during my stream, it freezes for a moment and then since there's no keyframe every 2 seconds i believe hitbox get's confussed and messes up. Twitch it works just fine without the keyint option but hitbox not so well.
I would really appreciate if you could code that in, don't worry about packaging it up or anything, i can just compile from source again once you incorporate it. THANKS
Maarten Baert author · 20 January 2014, 02:34
It is there, in the 'glinject-next' branch, as I said. Run
git checkout glinject-next, delete the build and build32 directories, and compile again :).Ubuntuaddicted · 20 January 2014, 03:50
looking with my current ssr directory that i pulled down from git, i don't see any folders anywhere named build or build32. could you maybe be really command by command specific please?
So far I cd'd into my ssr directory and ran the following
and that returned the following Branch glinject-next set up to track remote branch glinject-next from origin. Switched to a new branch 'glinject-next'
but I don't know what to do next
Maarten Baert author · 20 January 2014, 05:54
The directories build and build32 are created when you run simple-build-and-install. If you haven't done any compiling, they won't be there, and that's fine. Just run simple-build-and-install now. I made a small but important change a few hours back though, so you should first run
git pullto make sure that you are up-to-date.Ubuntuaddicted · 20 January 2014, 10:19
i did compile and install the latest from git however i didn't run your simple build and install script because I didn't want to mess up the version installed from the ppa. I wanted to have the ppa repo version installed AND the git version. i ran
I was able to run the git version from the command line after cd'ing into ~/ssr and using
so now I am wondering how to install the glinject-next branch and use that. Sorry I am new to git and compiling so I don't know how to do it BUT really want to get keyint working because of this horrible black screen issue when restarting my stream at hitbox due to their cutting alogrythm and how my stream doesn't contain a keyframe every 2 seconds like they expect.
Maarten Baert author · 20 January 2014, 21:45
It's a bad idea to have the PPA version installed while you're also compiling your own version, it will completely break OpenGL recording. It's much easier to just uninstall the PPA version temporarily (
sudo apt-get remove simplescreenrecorder simplescreenrecorder-lib simplescreenrecorder-lib:i386) and use simple-build-and-install instead. It does a bit more than just running configure and make (for example, you haven't enabled any optimizations, this will make SSR quite slow). It also compiles in a separate folder so the build files don't get mixed with the source files, like you did now ;). You can always just reinstall the PPA packages later, it won't mess up your system (after uninstalling your compiled version with simple-uninstall).You should probably run
git reset --hardandgit clean -fXfirst, this will delete the build files you just created. Then you can rungit checkout glinject-nextto switch to that branch, and run simple-build-and-install (after removing the PPA packages).Ubuntuaddicted · 20 January 2014, 22:03
ok, i'll remove the ppa version of ssr using the command you posted. i'll then delete the ~/ssr folder that was created from original git build and install. I will cd to the ssr folder where i did the original git pull and run the following commands
git reset --hardandgit clean -fXandgit checkout glinject-nextand then just issue./simple-build-and-installdoes that sound correct?
another thing I noticed was that I was getting a lot of VBV underflow errors in my log files and when I removed the tune=zerolatency from the custom codec options the VBV underflow errors disappeared.
I am hoping you did your own research about this keyframe interval requirement from twitch and hitbox because I happen to check out someone else's script they put together which just calls ffmpeg or avconv and they are using libx264 options of -g 2 -keyint_min 2. Then I did some more reading and found the following here http://www.encoding.com/advanced_configuration_options_for_the_libx264_video_codec
what I am trying to say is that I hope by me stating I wanted the private option of setting keyframe interval to 2 and then seeing your solution of keyint=60 thinking that is the way to achieve a keyframe interval of 2, is this correct OR should it be g=2 or even keyint_min=2.
Maarten Baert author · 21 January 2014, 01:45
Yes.
VBV underflow is not really an error, it's more like a warning. It means x264 wasn't able to stay below the bit rate and buffer size limits that you have set, but it doesn't break the video. I don't get any of these messages, maybe because I have a more up-to-date version of x264 (the version in Ubuntu is also 2 years old, like libav).
FFmpeg/libav option names are very inconsistent. The '-g' option sets the GOP size (the internal ffmpeg/libav option name is gop_size), which is mapped to 'keyint' in x264 (I checked the source code). 'keyint_min' is a separate option which I wouldn't use unless absolutely necessary, because it disables an important optimization called 'scenecut' (which stops the video from becoming blurry when there's a scene cut, by inserting a new keyframe). It's generally a bad idea to mess with x264 options unless you know it's really necessary. The defaults are chosen by experts, they usually know what works best.
I suspect that whoever wrote that script blindly copied the recommendations from Twitch without realizing that both -g and -keyint_min refer to the number of frames rather than the number of seconds. As I said, a keyframe interval of 2 frames makes no sense whatsoever, it's only one step better than keyint=1, which would make every frame a keyframe and essentially turn your video into a stream of JPEGs. Just for fun I tried to set keyint to 2, and the quality is terrible even at very high bit rates, which is pretty much what I expected.
Gfurst · 25 July 2014, 04:42
Hey there again, How are ya?
Is there custom options for costant rate factor for audio, such as mp3 or vorbis?
Best would be able to use vorbis with theora with both constant rate factors to something close to lossless, so it would reduce requirements while recording while maintaining an open-source format.
As diccussed previously I got no problem using libx264, but for optimal performance to use mp3 or vorbis with constant rate factor.
Thanks.
Maarten Baert author · 30 July 2014, 13:50
I haven't released it yet, but the git master branch has a 'qscale' option that does just this. Still, for vorbis you don't really need it. Vorbis is inherently variable bitrate, so 128kbps is actually 'a quality level that results in 128kbps for typical music'. Look at the table to the right on this page, it shows which bitrate corresponds to which quality level.
128kbps is almost always enough, but if you don't care about file size, feel free to use 256kbps instead.
Red1432 · 10 August 2014, 20:02
I just need help. All i want is the coding that i have to do get the libx264. Please help me, its all i need. Just for the video. Then I think It will work. Its the only part. Someone help. Its for livestreaming
Maarten Baert author · 11 August 2014, 00:02
Read this. :)
Mika · 14 July 2019, 10:44
just a quick question: is lossless mjpg recording possible with ssr? if not, which lossless codec to choose from in order to do precise cuts with avidemux later on? h.264 (lossless) unfortunately does not allow accurate cuts.
Maarten Baert author · 23 July 2019, 02:38
H.264 should definitely allow accurate cuts, if it doesn't its a limitation of the editing software, not the codec. In any case, H.264 lossless should work about as well for editing as mjpeg if you add the
keyint=1option. There are some other lossless alternatives (like huffyuv) but they don't compress as well as H.264.By the way, you may want to use libx264rgb instead of libx264, or use libx264 with
pixelformat=yuv444.Mika · 24 July 2019, 13:13
hi maarten,
there you go, i've only ever used avidemux with my h.264 screencasts (ssr default settings + crf 20) and cutting (without errors) is only possible on i-frame base in this mode. i wished accurate cutting was also possible with these final encodes.
now, i noticed something strange when recording losslessly (codec:other, libx264, bitrate:0, preset=veryfast,crf=15,keyint=1). i took stills of a scene from a lossless screencast vs lossy sc (h.264, crf 20, preset veryfast) and i could clearly spot artefacts in the lossless picture. the lossy one looks far superior. how is that possible after all?
apart from crf, bitrate and the keyinterval, the settings should be identical, i guess.
Maarten Baert author · 28 July 2019, 17:51
What you describe:
... isn't lossless. If you want actual lossless, try:
or if your editing software supports H.264 RGB:
The option
crf=0is what makes it lossless.keyint=1turns every frame into a keyframe to make editing easier.Mika · 28 July 2019, 20:05
thanks for clarifying.
actually, crf value was a typo, was 0 already.
zooming in and comparing the 2 pngs (lossless crf:0 vs lossy crf:20), the latter is definitely the winner - though it makes no sense to me?
regarding the keyinterval, what would be the drawback of leaving this at a default value of 1? this way, accurate cuts of at least 1sec intervals would be possible, after all.
Maarten Baert author · 11 September 2019, 10:52
Are you sure there are no other differences between the files?
crf=0should definitely look better.keyintis expressed in frames, not seconds.keyint=1means every frame is a keyframe. If you want a keyframe every second at, say, 30 fps, you would usekeyint=30. Note that the actual keyframes may not be exactly 30 frames apart though, since the encoder tries to align keyframes with scene changes whenever possible. So you can't really rely on this. The default keyframe interval is something like 250 frames I believe, which isn't very good for editing.Popgoesme700 · 19 August 2020, 03:21
Would you be able to support the h264_vaapi codec? Would be very greatful if you did decide to add it to the list of codecs... unless you already do so.
Maarten Baert author · 21 August 2020, 14:20
See here. VAAPI requires an unusual method to transfer video frames which SSR does not support. Also, since I don't have any hardware to test it with, it's hard for me to add support for this.
Double Den · 1 June 2021, 16:34
Thank for creating SSR! It's awesome tool.
Today I was recording my screen on Ubuntu 20.10, then my electric got cut off and my computer switched off..
After my electricity resumed, I booted back and nowI can see the .MP4 for still on my drive but I can't play it probably due to forced switch off.
My question is Is there any way to recover my 30 min footage from this .MP4 file.?
Can I fix it somehow..
Plz help..
Maarten Baert author · 8 July 2021, 00:11
See: https://github.com/MaartenBaert/ssr/issues/221