-1

I am streaming(live chat) with FFmpeg using the following parameters.

ffmpeg -f dshow -rtbufsize 100M -i video="device":audio="device" \
-c:v libx264 -crf 30 -preset ultrafast -tune zerolatency \
-c:a aac -f mpegts udp://127.0.0.1:1234

Unexpectedly, when CRF is lowered from 30 to 20, step-by-step. The stream quality decreases dramatically. When the CRF is about 20, sudden changes in the picture (like a head movement), seems to make the image green, gray or very distorted. I tried using CRF 30, and the problems seems to be gone. Why is this happening ?

I don't think it is a bandwidth issue given that I am on localhost. Also I didn't change anything based on I-frames.

Edit: I checked the file sizes given CRF 20 and CRF 30 on libx265.

10 Second video.

CRF 20: 1.7M

CRF 30: 350kb

Is 1.7M really bad for a 10 second stream that localhost or any other live streaming sevice can't handle ?

Max Paython
  • 1,595
  • 2
  • 13
  • 25
  • 1
    *I don't think it is a bandwidth issue given that I am on localhost.* --> confirm by saving to file and checking. – Gyan Aug 09 '19 at 09:20
  • @Gyan Please check the edit. – Max Paython Aug 12 '19 at 13:40
  • You've reported file sizes but your original issue is with quality. How's the quality of 20 vs 30? – Gyan Aug 12 '19 at 14:08
  • @Gyan Of course 20 is much better, however I don't need that much quality in a live chat program. Still I would use the best one possible. That's why I am delving into it. – Max Paython Aug 12 '19 at 14:22
  • @Gyan Take note that when saving to a file, both qualities are acceptable, it's when live decoding, 20 crf gives green, blurry, gray image. (during sudden movement, as I experienced) – Max Paython Aug 12 '19 at 14:29
  • So, not an encoding issue; either network transmission or the decoder at the receiver. Likely to be network. – Gyan Aug 12 '19 at 14:51

1 Answers1

0

I don't know what the resolution is, but it seems to be a performance issue for encoding. CRF=20 can also be used up to MAX 20 Mbps as a criterion of 720p. As a suggestion, do not use CRF but specify proper bitrates according to resolution. 720p -> 2.5Mbps 1080p -> 4Mbps

And 'dshow' is not very fast capture either. You have to take it into consideration. I recommand DX10's swap-chain. It's super fast capturer.

mtbig
  • 1
  • Resolution is 640x480. And I added the filesizes on the edit. Also where can I find more information about DX10 swap-chain ? Is it available on DX11 and 12 (and better performance) ? – Max Paython Aug 12 '19 at 13:42
  • If you use that resolution, it's hard for you to get into trouble. I think you'd better look at the encoding options. And refer to this link.;; https://learn.microsoft.com/ko-kr/windows/win32/api/dxgi/nf-dxgi-idxgiswapchain-getbuffer – mtbig Aug 13 '19 at 07:36
  • and I recommand replace [CRF] to [-b:v 840k] (range: 750k~1000k) – mtbig Aug 13 '19 at 07:45
  • and if you really want to use CRF, use this value [24] (range: 23~25) – mtbig Aug 13 '19 at 07:47