X264-params=keyint=250 preset=medium profile=high pix_fmt=yuv420p tune=zerolatency b=2000K 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 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.
For x264 tune=zerolatency was a MUST, otherwise the latency doubled.unfortunately it brings down the quality a bit. I tried using both libx264 and nvenc_h264(Turing). 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. Most of the testing I did locally on this machine and also between my other PC in home, connected via Gigabit LAN. CPU: Ryzen 3700X, videocard: NVIDIA RTX2080 Superįfmpeg version git-4cfcfb3 Copyright (c) 2000-2020 the FFmpeg developers
0 kommentar(er)
