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 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
Ubuntuaddicted |
Comment #1: Sun, 29 Dec 2013, 8:45 (GMT+1, DST) 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 BaertAdministrator |
Comment #2: Mon, 30 Dec 2013, 17:28 (GMT+1, DST) 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: 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) 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 BaertAdministrator |
Comment #5: Tue, 14 Jan 2014, 21:15 (GMT+1, DST) 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) 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 BaertAdministrator |
Comment #7: Mon, 20 Jan 2014, 2:34 (GMT+1, DST) 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: 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 BaertAdministrator |
Comment #9: Mon, 20 Jan 2014, 5:54 (GMT+1, DST) 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: 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 BaertAdministrator |
Comment #11: Mon, 20 Jan 2014, 21:45 (GMT+1, DST) 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: 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 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: 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 BaertAdministrator |
Comment #13: Tue, 21 Jan 2014, 1:45 (GMT+1, DST) 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 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: 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: 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 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 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 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) Hey there again, How are ya? |
Maarten BaertAdministrator |
Comment #16: Wed, 30 Jul 2014, 13:50 (GMT+1, DST) Quote: Gfurst
Hey there again, How are ya? 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) 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 BaertAdministrator |
Comment #18: Mon, 11 Aug 2014, 0:02 (GMT+1, DST) 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) Hello, sorry for lame question: 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 Last modified: Fri, 5 Feb 2016, 7:57 (GMT+1, DST) |
Mika |
Comment #20: Sun, 14 Jul 2019, 10:44 (GMT+1, DST) 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 BaertAdministrator |
Comment #21: Tue, 23 Jul 2019, 2:38 (GMT+1, DST) Quote: Mika
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. 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=1 option. 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 |
Comment #22: Wed, 24 Jul 2019, 13:13 (GMT+1, DST) 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 BaertAdministrator |
Comment #23: Sun, 28 Jul 2019, 17:51 (GMT+1, DST) Quote: Mika
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. What you describe: codec:other, libx264, bitrate:0, preset=veryfast,crf=15,keyint=1 ... isn't lossless. If you want actual lossless, try: codec:other, libx264, bitrate:0, preset=veryfast,crf=0,keyint=1,pixelformat=yuv444 or if your editing software supports H.264 RGB: codec:other, libx264rgb, bitrate:0, preset=veryfast,crf=0,keyint=1 The option crf=0 is what makes it lossless. keyint=1 turns every frame into a keyframe to make editing easier. Last modified: Sun, 28 Jul 2019, 17:52 (GMT+1, DST) |
Mika |
Comment #24: Sun, 28 Jul 2019, 20:05 (GMT+1, DST) 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. Last modified: Sun, 28 Jul 2019, 20:06 (GMT+1, DST) |
Maarten BaertAdministrator |
Comment #25: Wed, 11 Sep 2019, 10:52 (GMT+1, DST) Quote: Mika
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. Are you sure there are no other differences between the files? crf=0 should definitely look better. keyint is expressed in frames, not seconds. keyint=1 means every frame is a keyframe. If you want a keyframe every second at, say, 30 fps, you would use keyint=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. |
Mika |
Comment #26: Fri, 15 Nov 2019, 8:33 (GMT+1, DST) no, unfortunately, there is not. but you are free to test for yourselves and prove me wrong. Last modified: Fri, 15 Nov 2019, 8:33 (GMT+1, DST) |
Popgoesme700 |
Comment #27: Wed, 19 Aug 2020, 3:21 (GMT+1, DST) 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 BaertAdministrator |
Comment #28: Fri, 21 Aug 2020, 14:20 (GMT+1, DST) Quote: Popgoesme700
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. 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 |
Comment #29: Tue, 1 Jun 2021, 16:34 (GMT+1, DST) Thank for creating SSR! It's awesome tool. Last modified: Tue, 1 Jun 2021, 16:37 (GMT+1, DST) |
Librarianm4a1 |
Comment #30: Wed, 2 Jun 2021, 5:14 (GMT+1, DST) Should put on flathub, to install on flapk I couldn't get it to work on my system used on debian 9 |
Maarten BaertAdministrator |
Comment #31: Thu, 8 Jul 2021, 0:11 (GMT+1, DST) Quote: Double Den
Thank for creating SSR! It's awesome tool. |
Geremia |
Comment #32: Tue, 24 May 2022, 1:05 (GMT+1, DST) What custom codec option do I put to downmix to mono using the opus codec? "downmix-mono" doesn't work. |
Hexit78 |
Comment #33: Thu, 20 Oct 2022, 8:25 (GMT+1, DST) Hi, I need help to figure how to use the custom codec options. |
Mechputer |
Comment #34: Wed, 8 Nov 2023, 18:52 (GMT+1, DST) Is there a way to record constantly, but have it separate the video into several smaller files, based on either time and/or file size? Similarly to how you would in a security system? I'm running a simulation that I want to catch something I thought I saw in, but I don't want to physically sit around for several days waiting to see it occur. |