The video picture during streaming is not smooth

[knyazevdev]

In all versions after jibri:stable-9258 the picture quality has dropped a lot - resolution and bitrate are still the same, but the picture itself has artifacts.

You can see it even on https://meet.jit.si/ - now any stream there gives a bad picture.

If necessary, I can record video on stable-9258 version and on the current one for comparison.

Can you tell me what is the reason and what can be done?

[saghul]

What settings are you using on Jibri?

[knyazevdev]

https://meet.jit.si/ - we don't change anything here - you can visit the service and see the video problems

Experimentally, we have determined that the problem does not exist on stable-9258 and earlier.

What settings are you using on Jibri?

Please specify exactly what settings are required

[saghul]

https://meet.jit.si/ - we don't change anything here - you can visit the service and see the video problems

Can you please record a video of what you observe so we can see the problem?

[knyazevdev]

Yeah, I'll do it tomorrow.

[knyazevdev]

Video on old version jibri:stable-9258 - https://www.youtube.com/live/ADDGdPocY10

Video on last stable version jibri:stable - https://www.youtube.com/live/Uj4EZltW2Co

You can see that the active movements have become less smooth. https://meet.jit.si/ has the same problem.

The ffmpeg settings are exactly the same.

[saghul]

We did change the default ffmpeg settings, @bgrozev did not that long ago.

Were you overriding them?

[knyazevdev]

I compared the settings in the logs - they are almost the same, only the libx264 versions differ

jibri:stable-9258

LoggingUtils$Companion$OutputLogger$1.invoke$lambda$0#42: [libx264 @ 0x55a971b9d740] 264 - core 160 r3011 cde9a93 - H.264/MPEG-4 AVC codec - Copyleft 2003-2020 - http://www.videolan.org/x264.html - options: cabac=1 ref=1 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=2 psy=1 psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=12 lookahead_threads=12 sliced_threads=1 slices=12 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=1 keyint=60 keyint_min=6 scenecut=40 intra_refresh=0 rc_lookahead=0 rc=crf mbtree=0 crf=18.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 vbv_maxrate=8000 vbv_bufsize=16000 crf_max=0.0 nal_hrd=none filler=0 ip_ratio=1.40 aq=1:1.00

jibri:stable

LoggingUtils$Companion$OutputLogger$1.invoke$lambda$0#42: [libx264 @ 0x55dae305f380] 264 - core 164 r3095 baee400 - H.264/MPEG-4 AVC codec - Copyleft 2003-2022 - http://www.videolan.org/x264.html - options: cabac=1 ref=1 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=2 psy=1 psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=12 lookahead_threads=12 sliced_threads=1 slices=12 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=1 keyint=60 keyint_min=6 scenecut=40 intra_refresh=0 rc_lookahead=0 rc=crf mbtree=0 crf=18.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 vbv_maxrate=8000 vbv_bufsize=16000 crf_max=0.0 nal_hrd=none filler=0 ip_ratio=1.40 aq=1:1.00

core 160 r3011 cde9a93 and core 164 r3095 baee400

Also the order of ffmpeg arguments has changed a bit

jibri:stable-9258

-y -v info -f x11grab -draw_mouse 0 -r 30 -s 2560x1440 -thread_queue_size 4096 -i :0.0+0,0 -f pulse -thread_queue_size 4096 -i default -acodec aac -strict -2 -ar 44100 -b:a 128k -af aresample=async=1 -c:v libx264 -preset veryfast -maxrate 8000k -bufsize 16000k -pix_fmt yuv420p -r 30 -crf 18 -g 60 -tune zerolatency -timestamp now -f flv

jibri:stable

-y -v info -f x11grab -draw_mouse 0 -r 30 -s 2560x1440 -thread_queue_size 4096 -i :0.0+0,0 -f pulse -thread_queue_size 4096 -i default -acodec aac -strict -2 -ar 44100 -b:a 128k -af aresample=async=1 -c:v libx264 -pix_fmt yuv420p -r 30 -crf 18 -preset veryfast -tune zerolatency -g 60 -maxrate 8000k -bufsize 16000k -timestamp now -f flv

[knyazevdev]

Do you have any ideas on how to solve the problem? Do you agree that the video is worse?

[knyazevdev]

The problem is actual, I suspect that the reason is different versions of ffmpeg: 5 and 4.

It would be great if this problem will be solved in new builds

[bgrozev]

@knyazevdev this is the change @saghul is referring to. For streaming, it should only rearrange the params like you found
#560
#562

I just tested the different order of params, and it doesn't make a difference (I get the same number of bytes for my test input). I also compared the ffmpeg included in the stable-9258 image (4.3.6-0+deb11u1) against the one from stable-9955 (5.1.6-0+deb12u1) and I see no difference (the file is 1 byte larger). My test input is mostly screensharing so differences in framerate are hard to notice.

To be honest, I don't see an obvious difference between your two videos. I trust you that it's there, but it would be nice to have a more objective way to test. I've been testing with the same y4m file as input like this:
ffmpeg -y -v info -i jibri-test-input.y4m -r 30 -c:v libx264 -pix_fmt yuv420p -r 30 -crf 18 -preset veryfast -tune zerolatency -g 60 -maxrate 8000k -bufsize 16000k -timestamp now -f flv stable-9258.flv

[knyazevdev]

Thanks for the detailed response and diving into the issue.

I will try to compare the quality via a test file. Maybe it will turn out that already ffmpeg receives a picture with bad quality