CBR yielded worse quality, just for a little more stable bitrate.
VBR mode turns out to be decent and the bitrate didn't fluctuate that much for my scenario. Also there is much more headroom to the CPU for the muxing and transmitting the stream, which in long term will probably mean more stable stream and no buffering whatsoever. The latency was on par with x264 with zerolatency tune and the picture really benign. The hardware encoder definitely shines in this situation. On the other hand, nvenc was doing much better. X264-params=keyint=250 preset=medium profile=high pix_fmt=yuv420p tune=zerolatency b=2000K h264_nvenc X264-params=nal-hrd=cbr:force-cfr=1:keyint=250 preset=medium profile=high pix_fmt=yuv420p tune=zerolatency minrate=2000K maxrate=2000K bufsize=4000k b=2000Kįfmpeg -f dshow -i video="Cam Link 4K" -vcodec libx264 -x264-params keyint=250 -preset medium -profile high -pix_fmt yuv420p -tune zerolatency -b:v 2000K -f mpegts udp://127.0.0.1:5000
#Using obs studio to record ffmpeg free#
It's really individual for each case, so I will provide the basic configuration that I used.feel free to experiment.įfmpeg -f dshow -i video="Cam Link 4K" -vcodec libx264 -x264-params nal-hrd=cbr:force-cfr=1:keyint=250 -preset medium -profile high -pix_fmt yuv420p -tune zerolatency -b:v 2000K -minrate 2000K -maxrate 2000K -bufsize 4000k -f mpegts udp://127.0.0.1:5000 This turns out to be very ugly looking picture, especially when the target bitrate is set very low.īest stable results for a high motion footage was manually tweaking the crf and crf_max values, and also restricting the maxrate and bufsize, in order to keep the bitrate somewhat stable. As far as the picture is stable everything is good, but when something starts moving then it drastically decreases the target crf in order to encode all the motions. It seems that x264 is trying to reach best possible crf value for the provided bitrate. I tried using both libx264 and nvenc_h264(Turing).įor x264 tune=zerolatency was a MUST, otherwise the latency doubled.unfortunately it brings down the quality a bit. So far so good, mpegts will be the stream container, we just have to tweak some of the encoder settings. Also keep in mind that when playing mpegts/mjpeg streams in VLC, you have to include ?pkt_size=1316 after the stream URL on the encoder/muxing side. your best bet is using mpeg2video codec inside it. Using the older container mjpeg is the only one that has low latency in VLC, but it doesn't support h264.
I tried using VLC, as OBS also support VLC libraries, but it turns out that VLC has some demuxing latencies for mpegts. OBS demuxer adds huge latency to such stream and VLC wouldn't even play it. The mpeg2video container also supports h.264, but only ffplay plays the stream properly with low latency. I tried different containers, but it seems that only mpegts is working good for h.264. That's why to begin with, I started experimenting with ffmpeg, ffprobe, ffplay tools. So first of all, as you might know, OBS heavily relies on ffmpeg. So never really tried pushing the stream over longer distance and affected by packet loss.
#Using obs studio to record ffmpeg Pc#
Most of the testing I did locally on this machine and also between my other PC in home, connected via Gigabit LAN. I am using:ĬPU: Ryzen 3700X, videocard: NVIDIA RTX2080 Superįfmpeg version git-4cfcfb3 Copyright (c) 2000-2020 the FFmpeg developers I want to share my experience with you guys. For video content I just used live camera footage and the bitrate I was aiming for was I was mostly focusing on just video stream, adding audio might increase the latency a bit - feel free to experiment. My goal was to achieve low latency, decent quality and low bitrate stream from one pc to another over the network. I have been doing some tests lately - streaming h.264 over the network using udp.
0 kommentar(er)
