[FFmpeg-devel] [FFmpeg-cvslog] lavfi/vf_scale: pass the thread count to the scaler

[Michael Niedermayer]

On Mon, Sep 06, 2021 at 07:23:13AM +0000, Anton Khirnov wrote:
> ffmpeg | branch: master | Anton Khirnov <anton at khirnov.net> | Wed Jul  7 18:42:15 2021 +0200| [60515a6d610491f030aaa4cf230d0367a85e2d4b] | committer: Anton Khirnov
> 
> lavfi/vf_scale: pass the thread count to the scaler
> 
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=60515a6d610491f030aaa4cf230d0367a85e2d4b
> ---

This breaks a few things:
I appologize for not noticing this earlier


./ffmpeg -i ~/tickets/4746/proresalphablock-small.avi -vf format=rgba64be,scale=alphablend=checkerboard,format=rgb48 -qscale 2 rgba64BEcheck.avi

This no longer shows a checkerboard, input file should not matter as
long as it has some transpareancy


./ffmpeg -y -bitexact -i ~/videos/mm-short.mpg -vframes 30 -bitexact -vcodec zmbv -pix_fmt pal8 -an file-zmbv.avi
-rw-r----- 1 michael michael 1189614 Sep  7 11:02 file-zmbv.avi
-rw-r----- 1 michael michael 1166552 Sep  7 11:02 file-zmbv-old.avi

The file changes even though bitexact is used


Heres another unexplained difference (no pal8/bgr8/yuv410 here)
./ffmpeg -i ~/tickets/4301/untitled.split.2_new.split.1.cut.avi -bitexact -vf hqdn3d=5:4:7:6 -qscale 1 hqdn.avi
-rw-r----- 1 michael michael 69374 Sep  7 11:05 hqdn.avi
-rw-r----- 1 michael michael 69346 Sep  7 11:06 hqdn-oldscale.avi
If i look at the framecrc of this, it differs too:
0,          0,          0,        1,    55543, 0xd89e9187
0,          1,          1,        1,     8053, 0xcd4c9008, F=0x0ate=  40.5kbits/s speed=N/A    
vs.
0,          0,          0,        1,    55501, 0xba057084
0,          1,          1,        1,     8068, 0xc2e79f6e, F=0x0ate=  40.5kbits/s speed=N/A    


Heres another thread number output difference with bitexact (yuv410 here)
./ffmpeg -y -i ~/tickets/1012/IV50_random_points.avi -bitexact -threads 5 file1012-5.avi
./ffmpeg -y -i ~/tickets/1012/IV50_random_points.avi -bitexact -threads 3 file1012-3.avi
-rw-r----- 1 michael michael 209766 Sep  7 11:13 file1012-3.avi
-rw-r----- 1 michael michael 208906 Sep  7 11:13 file1012-5.avi


This seems bgr24  / yuv420 producing differences
./ffmpeg -i ~/tickets/3757/testinput_small.avi -vcodec mpeg1video -bf 8 -b_strategy 2 -q:v 3 -an -y -bitexact -vframes 30 bstrategy2.mpg
-rw-r----- 1 michael michael 225280 Sep  7 11:17 bstrategy2.mpg
-rw-r----- 1 michael michael 221184 Sep  7 11:17 bstrategy2-old.mpg


yuv422p10le / yuv422p
./ffmpeg -i ~/tickets/3434/ProRes_FromHaali.mkv -vframes 27 -bitexact file-3434.mkv
-rw-r----- 1 michael michael 13786 Sep  7 11:20 file-3434.mkv
-rw-r----- 1 michael michael 13815 Sep  7 11:20 file-3434-oldscale.mkv


./ffmpeg -i ~/tickets/3516/YCbCrK.jpg -bitexact file-3516.jpg
-rw-r----- 1 michael michael 98747 Sep  7 11:23 file-3516.jpg
-rw-r----- 1 michael michael 87045 Sep  7 11:23 file-3516-old.jpg
This also replicates the "deprecated pixel format used, make sure you did set range correctly" warning on each context
its probably better to only show it for the first context or something
The 2nd slice and later look more spicy color wise, maybe something has not
been set in them the same as in the first

I have 7 more testcases which are different, but i guess alot if not all will
be duplicates. Ill retest once these are fixes or if you prefer i can also
write reports like above for all i found.

I suggest to temporary revert 60515a6d610491f030aaa4cf230d0367a85e2d4b so its
easier to test the fixes

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20210907/5a962c97/attachment.sig>