Maarten Baert's website

Game Maker / C++ projects

Home Model Creator ExtremePhysics Game Maker DLLs SimpleScreenRecorder Quadcopters   Recent comments Search

Last modified: Thu, 4 Dec 2014
Refresh

Custom codec options


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 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: yuv420, yuv422, yuv444, bgra, bgr. By default, SimpleScreenRecorder will pick the first format from this list that is supported by the encoder (which is almost always 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

Ubuntuaddicted

Comment #1: Sun, 29 Dec 2013, 8:45 (GMT+1, DST)

Quote


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

Administrator

Comment #2: Mon, 30 Dec 2013, 17:28 (GMT+1, DST)

Quote


Quote: Ubuntuaddicted

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.

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

Comment #3: Wed, 1 Jan 2014, 2:27 (GMT+1, DST)

Quote


Quote: Maarten Baert
Quote: Ubuntuaddicted

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.

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 :).

i don't know if it's suppose to be 2 seconds or 2 frames, I just know that twitch and hitbox have added within their streaming instructions that it's best to use "2" for the keyframe interval. I know it's not required and the stream will still work, just thought if it was easy to add than that would be great. Thanks!

Ubuntuaddicted

Comment #4: Tue, 14 Jan 2014, 19:08 (GMT+1, DST)

Quote


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

Administrator

Comment #5: Tue, 14 Jan 2014, 21:15 (GMT+1, DST)

Quote


Quote: Ubuntuaddicted

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.

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

Comment #6: Sun, 19 Jan 2014, 21:11 (GMT+1, DST)

Quote


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

Administrator

Comment #7: Mon, 20 Jan 2014, 2:34 (GMT+1, DST)

Quote


Quote: Ubuntuaddicted

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

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

Comment #8: Mon, 20 Jan 2014, 3:50 (GMT+1, DST)

Quote


Quote: Maarten Baert

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 :).

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

git checkout glinject-next

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

Administrator

Comment #9: Mon, 20 Jan 2014, 5:54 (GMT+1, DST)

Quote


Quote: Ubuntuaddicted
Quote: Maarten Baert

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 :).

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

git checkout glinject-next

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

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 pull to make sure that you are up-to-date.

Ubuntuaddicted

Comment #10: Mon, 20 Jan 2014, 10:19 (GMT+1, DST)

Quote


Quote: Maarten Baert

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 pull to make sure that you are up-to-date.

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

./configure --prefix=$HOME/ssr
make
make install

I was able to run the git version from the command line after cd'ing into ~/ssr and using

simplescreenrecorder --logfile

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

Administrator

Comment #11: Mon, 20 Jan 2014, 21:45 (GMT+1, DST)

Quote


Quote: Ubuntuaddicted
Quote: Maarten Baert

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 pull to make sure that you are up-to-date.

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

./configure --prefix=$HOME/ssr
make
make install

I was able to run the git version from the command line after cd'ing into ~/ssr and using

simplescreenrecorder --logfile

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.

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 --hard and git clean -fX first, this will delete the build files you just created. Then you can run git checkout glinject-next to switch to that branch, and run simple-build-and-install (after removing the PPA packages).

Ubuntuaddicted

Comment #12: Mon, 20 Jan 2014, 22:03 (GMT+1, DST)

Quote


Quote: Maarten Baert

You should probably run git reset --hard and git clean -fX first, this will delete the build files you just created. Then you can run git checkout glinject-next to switch to that branch, and run simple-build-and-install (after removing the PPA packages).

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 --hard and git clean -fX and git checkout glinject-next and then just issue ./simple-build-and-install
does 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

Quote

Frame-type options:
g <integer>
Keyframe interval, also known as GOP length. This determines the maximum distance between I-frames. Very high GOP lengths will result in slightly more efficient compression, but will make seeking in the video somewhat more difficult. Recommended default: 250

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.

Last modified: Mon, 20 Jan 2014, 23:01 (GMT+1, DST)

Maarten Baert

Administrator

Comment #13: Tue, 21 Jan 2014, 1:45 (GMT+1, DST)

Quote


Quote: Ubuntuaddicted

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 --hard and git clean -fX and git checkout glinject-next and then just issue ./simple-build-and-install
does that sound correct?

Yes.

Quote: Ubuntuaddicted

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.

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).

Quote: Ubuntuaddicted

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

Quote

Frame-type options:
g <integer>
Keyframe interval, also known as GOP length. This determines the maximum distance between I-frames. Very high GOP lengths will result in slightly more efficient compression, but will make seeking in the video somewhat more difficult. Recommended default: 250

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.

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.

Last modified: Tue, 21 Jan 2014, 1:49 (GMT+1, DST)

Ubuntuaddicted

Comment #14: Tue, 21 Jan 2014, 3:20 (GMT+1, DST)

Quote


Quote: Maarten Baert

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.

thanks for responding so quickly and explaining the libx264 options, it might explain why him and others using his script are having a grey screen issue on twitch.

Back to me compiling the glinject-next branch. Here's the entire terminal output of all the commands you suggested I run
http://pastebin.com/HvDSCggR
and apparently it failed because now I have no ssr installed anywhere. Can you please help?

Ok, i deleted all the ssr folders and ~/.ssr folder from my system and started from complete scratch but it still errors out. Here's the output of starting from scratch
http://pastebin.com/DmbrqVW9

and yes I ran the following command first (actually installed all the dependencies yesterday)

sudo apt-get install build-essential cmake pkg-config qt4-qmake libqt4-dev libavformat-dev \
libavcodec-dev libavutil-dev libswscale-dev libasound2-dev libpulse-dev libjack-jackd2-dev \
libgl1-mesa-dev libglu1-mesa-dev libx11-dev libxext-dev libxfixes-dev g++-multilib ia32-libs

UPDATE: i hadn't read the README.md file and noticed I was missing some symlinks. So after adding the following the build and install script worked just fine

Quote

cd /usr/lib/i386-linux-gnu
sudo ln -s libGLU.so.1 libGLU.so
sudo ln -s libX11.so.6 libX11.so
sudo ln -s libXext.so.6 libXext.so
sudo ln -s libXfixes.so.3 libXfixes.so
sudo ldconfig

I am happy to report that by checking the log I am in fact now streaming with keyint=60 and it's streaming beautifully to hitbox. I didn't check twitch yet but I am sure if it works on hitbox it will work on twitch.

Last modified: Tue, 21 Jan 2014, 20:51 (GMT+1, DST)

Gfurst

Comment #15: Fri, 25 Jul 2014, 4:42 (GMT+1, DST)

Quote


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

Administrator

Comment #16: Wed, 30 Jul 2014, 13:50 (GMT+1, DST)

Quote


Quote: Gfurst

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.

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

Comment #17: Sun, 10 Aug 2014, 20:02 (GMT+1, DST)

Quote


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

Administrator

Comment #18: Mon, 11 Aug 2014, 0:02 (GMT+1, DST)

Quote


Quote: Red1432

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

Read this. :)

Wojtasjd

Comment #19: Fri, 5 Feb 2016, 6:45 (GMT+1, DST)

Quote


Hello, sorry for lame question:
Ubuntu 14.04.3 LTS 64-bit with installed SSR 0.3.6 according to the instruction for Ubuntu: http://www.maartenbaert.be/simplescreenrecorder/#download
I've wanted HW accel. encoding with NVENC so I compiled FFmpeg ( http://developer.download.nvidia.com/compute/redist/ffmpeg/1511-patch/FFMPEG-with-NVIDIA-Acceleration-on-Ubuntu_UG_v01.pdf )

ffmpeg -encoders | grep 264

ffmpeg version N-78313-g6632802 Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04)
  configuration: --enable-nonfree --enable-nvenc --enable-nvresize --extra-cflags=-I../cudautils --extra-ldflags=-L../cudautils --enable-gpl --enable-libx264
  libavutil      55. 17.100 / 55. 17.100
  libavcodec     57. 24.101 / 57. 24.101
  libavformat    57. 24.100 / 57. 24.100
  libavdevice    57.  0.101 / 57.  0.101
  libavfilter     6. 28.100 /  6. 28.100
  libswscale      4.  0.100 /  4.  0.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc    54.  0.100 / 54.  0.100
 V..... libx264              libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (codec h264)
 V..... libx264rgb           libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 RGB (codec h264)
 V..... nvenc                NVIDIA NVENC h264 encoder (codec h264)
 V..... nvenc_h264           NVIDIA NVENC h264 encoder (codec h264)

but there is no nvenc_h264 in SSR video codec list
How to resolve this?
Thanks.

Last modified: Fri, 5 Feb 2016, 7:57 (GMT+1, DST)

Write a comment