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)
