Open alkazar opened 4 years ago
I was actually able to do this with the following command:
ffmpeg -video_size 1920x1080 -framerate 25 -f x11grab -i :0.0+0,0 -f pulse -ac 2 -i 1 output.mkv
Someone also managed to stream to youtube with ffmpeg using this: https://gist.github.com/olasd/9841772
Using ffmpeg
causes graphical glitches and results in severly reduced game performance.
Did you try using the NVENC encoder? That's the build in hardware encoder on Nvidia cards which is also used for recording in Nvidia's Windows software: https://wiki.archlinux.org/index.php/FFmpeg#NVIDIA_NVENC/NVDEC
I recently tried this again with NVENC using the following command line:
ffmpeg -f pulse -i 0 -f x11grab -framerate 60 -s 1920x1080 -i :0.0 -c:v h264_nvenc -preset:v llhq -profile:v high -pix_fmt nv12 -b:v 15M -acodec aac out.mp4
This worked much better performance-wise, but I still saw flashing artifacts as shown in the attached screenshot.
Also, AMD and Intel users won't be able to use NVENC.
AMD has AMF/VCE. Intel has QuickSync. Both are supported by OBS. Are we able to make OBS run in the background and implement or use some overlay to control it? It has a websocket plugin, so that may be implemented into the steam buddy.
OBS just uses ffmpeg in the background, which supports all of these. It would probably require some fiddling to figure out how to figure out how to use the correct encoder.
I understand that OBS may be too much to implement for just recording. So here some quick search later about accelerating ffmpeg.
All acceleration and NVENC: https://trac.ffmpeg.org/wiki/HWAccelIntro
Intel QSV (QuickSync Video): https://trac.ffmpeg.org/wiki/Hardware/QuickSync https://stackoverflow.com/questions/45181730/ffmpeg-encode-x264-with-amd-gpu-on-windows
AMD VCE/AMF: https://trac.ffmpeg.org/wiki/Hardware/VAAPI
-------- Ursprüngliche Nachricht -------- Von: Wouter Wijsman notifications@github.com Datum: 10.06.20 11:28 (GMT+01:00) An: gamer-os/steam-buddy steam-buddy@noreply.github.com Cc: Jakub kubo6472@gmail.com, Comment comment@noreply.github.com Betreff: Re: [gamer-os/steam-buddy] add ability to record gameplay (#44)
OBS just uses ffmpeg in the background, which supports all of these. It would probably require some fiddling to figure out how to figure out how to use the correct encoder.
From discord, just capturing it here so we don't forget:
Samsagax: For those that want to try, you'll need:
Then:
run sls: $ ./sls -c ../sls.conf
run ffmpeg with appropriate drivers and options (i. e.):
VCODEC="libx264"
VCODEC_OPTIONS="-preset ultrafast -tune zerolatency"
VSIZE="1920x1080"
ACODEC="libmp3lame"
ACODEC_OPTIONS=""
FPS=60
ffmpeg -f x11grab -framerate ${FPS} -i :0 -f alsa -ac 2 -i pulse -vcodec ${VCODEC} ${VCODEC_OPTIONS} -acodec ${ACODEC} ${ACODEC_OPTIONS} -video_size ${VSIZE} -flush_packets 0 -f mpegts "srt://localhost:8080?streamid=uplive.sls.com/live/test"
Samsagax: Then you can access the stream by: $ ffplay -fflags nobuffer -i "srt://[ip of your gameros]:8080?streamid=live.sls.com/live/test" Samsagax: Or in OBS just add a media source with that same url [8:25 PM] Samsagax: performance will vary greatly depending on codec and your particular hardware. So, the fps may vary [8:25 PM] castrojo: oh man, dude put the command example on the steambuddy page as a reminder [8:25 PM] castrojo: "Copy and paste this on your other machine to watch the stream"
Also might be neat to just embed the video right in the steambuddy page.
Here is a working setup for streaming on lan to be picked up to OBS running on a second machine. This is the poor man's setup without a capture card in two machines, you play in the GamerOS one and on the second one, setup OBS with your scene and stream to your preferred stream service.
Basic setup: You'll need libva drivers for your card (libva-mesa) for intel/amd or vdpau/nvenc for nvidia cards. (use video codec accordingly) on the GamerOS machine compile and run SLS:
$ ./sls -c ../sls.conf
Then run the relevant ffmpeg command:
VCODEC="libx264"
VCODEC_OPTIONS="-preset ultrafast -tune zerolatency"
VSIZE="1920x1080"
ACODEC="libmp3lame"
ACODEC_OPTIONS=""
FPS=60
ffmpeg \
-f x11grab -framerate ${FPS} -i :0 \
-f alsa -ac 2 -i pulse \
-vcodec ${VCODEC} ${VCODEC_OPTIONS} \
-acodec ${ACODEC} ${ACODEC_OPTIONS} \
-video_size ${VSIZE} \
-flush_packets 0 \
-f mpegts "srt://localhost:8080?streamid=uplive.sls.com/live/test"
Then on the client side (the second machine with OBS) you can test the stream with:
$ ffplay -fflags nobuffer -i "srt://[ip of your gameros]:8080?streamid=live.sls.com/live/test"
Or with OBS set a Media Source and point it to the same URL.
ffmpeg
is smart enough to pick up hardware acceleration given the correct encoder is selected, so if the relevant libraries are in place, then nothing else is needed. Codecs should be an option for the user and it's specific options too (but they are too hard to set up in a friendly way, maybe need to set them up as a command-like string).
The name of the stream in SLS (and consequently the client side) is configurable with the relevant option inside sls.conf
file. Maybe we should provide our own.
More than one stream is possible with different inputs on the same server.
Also for recording just need to set a file instead of the srt output (and obviously srt server is not needed).
Now let's talk configurables for ffmpeg: it's a plethora of things. I'm thinking of a friendly way of doing it but the issue is with codec options.
So this is what I have in mind and would be great to have some feedback:
A single page on steam-buddy to configure the ffmpeg line:
VCODEC="libx264"
(default), but can be any of the x264 family, they are supported by the TS muxer and have little overhead. Their variants are mostly for hardware encoding (like nvenc or libav) and their codec options are not the same, so maybe that should be changed if the user chooses other vcodec.VCODEC_OPTIONS="-preset ultrafast -tune zerolatency"
(default) fastest for streaming, but maybe for screen recording produces large files.VSIZE="1920x1080"
(current default) maybe this can be omited, in that case, we could add a check button to use the default of "same as input" and omit the -video_size
option entirely. That way demux and encode should be faster, but writing/streaming can be taxing on bandwidth. It's a balancing act that we should leave up to the user (same as FPS below).ACODEC="libmp3lame"
(default) we can use this as is the best for performance and quality, we can however use something with no compression.ACODEC_OPTIONS=""
(default, empty) this is the same as VCODEC_OPTIONS
and is here just for completeness sake. Depending on what the user selects in ACODEC
this can be useful.FPS=60
(current default) same as with -video_size
we could just leave it alone and add a check for same as input
and omit the -framerate
option entirely and set it if the user unchecks it and puts a value there. The same tradeoff applyes between time/space/bandwith as with -video_size
.I think OBS is the optimal solution.
OTOH: https://youtu.be/GRTs5On4Mqw -this is a recording from the desktop with OBS installed and connected to gameros. It's plausible that OBS would be unnecessary...
Requirements:
I tested a command-line recording software called
byzanz
that I thought could be used to implement this feature, but it was unstable and couldn't record more than a few seconds at a time before crashing.Any other command-line screen recording software available for Linux?