Since @Ray Molenkamp (LazyDodo) suggests, that this is issue with our implementation, I checked with libs from 2.93 and can't reproduce the issue. Can reproduce with stock ffmpeg libs though.

I will recompile ffmpeg, because I deleted libs by accident and check if this could be issue in sws_scale, I think I have changed interpolation in 3.0.

Yes, I tested this with upstream libs on my linux machine as well. So I think it is on our end too.

Let me know what you find with sws_scale. I will be busy with other tasks for a while now so I can't look into this for a while.

Just checked, ffmpeg -ss 00:00:05.00 -i a.avi -frames:v 1 a.png does do XXX->RGBA conversion, which seems to be OK. My commit I mentioned was 1f557867916b, but after reverting, issue persists.

I tried converting to some funny pixel formats like AV_PIX_FMT_RGB444LE which is 16bpp, this did resulted obviously in funny image (half size + funny color) but it was only 423px wide instead of 427px, so not quite sure what is going on there...

Also I have noticed, that need_aligned_ffmpeg_buffer(anim) returns true for this file, but this still doesn't quite lead me anywhere.

So I made 3 files:

• with size so it is memory aligned: ffmpeg -i a.avi -s 864x486 aligned.avi - Does not have this issue
• with size so it is not memory aligned: ffmpeg -i a.avi -s 865x486 not-aligned.avi - Does have this issue
• Just recoded, but not memory aligned:fmpeg -i a.avi recoded.avi - Does have this issue

So I think I have found the cause, but I am quite sad I can't reproduce it outside of Blender. I have inspected buffers in anim_movie.c:927-935 and buf_srcis already "incorrect". anim->pFrame buffer looks good to me too, so it must be sws_scale

Actually I was incorrectly assuming command that should do conversion to RGBA... double checked with how T80912 was debugged...

So ./ffmpeg.exe -ss 00:00:05.00 -i a.avi -vframes 1 -pix_fmt rgba test.png produced following output:

Not quite same as here, but I think good enough to blame ffmpeg

With the above command, I can repro with the the nightly ffmpeg from today, reporting it upstream may be the way to go here, we should probably trim that avi file a little though before we do, 200+ megs seems excessive

I'm way out of my comfort zone here, i haven't got the faintest idea what most of these values mean... but...

i tried some random files i had and they all come out fine and have this output from ffprobe.

Stream #0:0: Video: h264 (High), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn (default)

while the a.avi file has:

Stream #0:0: Video: mpeg4 (Simple Profile) (FMP4 / 0x34504D46), yuv420p, 854x480 [SAR 1:1 DAR 427:240], 2500 kb/s, 24 fps, 24 tbr, 24 tbn

get it be the wonky DAR value that is causing the problem?

Reported here https://trac.ffmpeg.org/ticket/9435.

I can check other formats, but I think this fails if x resolusion is not divisible by 32. As far as sws-scale is concerned in both cases above pixel format conversion is from YUV420P to RGBA.