-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What could be causing this -- ffmpeg related, but also zimg, I believe -- ? #177
Comments
Your image has negative dimensions. |
FFMPEG started setting this field in FFmpeg/FFmpeg@d0aefc3 . There is probably a bug in the calculation. |
What does this mean in layman terms for an image/video?
What's weird to me is latest version ffmpeg-zscale works OK with a vanilla Windows 10 x64 install but on my slimmed down install is showing this error. Therefore I assume something I deleted or disabled on my install is also interfering but I can't imagine what does zimg/ffmpeg now needs from Windows that didn't need before [because previous version worked just fine]. Could you please explain a little bit about if zimg is depending on some protocol/library/whatever it expects to find in a Windows install in your latest version that didn't required before? Thanks for taking the time to answer! PS: I don't know programming but browsing commits to vf_zscale.c there's this commit made on a date which I suspect marked the beginning of the problem for me. I know I'm asking too much but could you please take a quick look at so maybe you can see something causing the problem I'm having? |
It means that FFMPEG has a bug.
It could be the result of a Windows API returning a different value that is consumed by FFMPEG in a buggy way.
I see that this commit introduces a call to |
Hmmm... not the files themselves, but I've observed and tested a weird behaviour that looks related to this! I used ffmpeg to generate a 4K test file so I wasn't getting weird results because of a malformed file. I'm using an AMD 5900x, 12 cores, 24 threads
|
Please report these findings to FFMPEG. Thanks. |
Calculation is fine. Look at changes after that, latest version correctly use doubles for active region calculation. |
Well, until a few days ago ffmpeg was a magic black box to me [still is], so my tests just tried to limit possible sources of problems... though not very well thought out, as you just pointed. I wasn't even considering cores to be a factor until recently. Anyways... I've made more tests, and once I realized CPU cores were factor, I made sure VMware Workstation was using 2 cores, so ffmpeg only detected 2 logical cores. I still need to test assigning more cores to VM and using vanilla Windows 10 to see what happens then, but it's being a PITA setting VM like that. Results so far seem to indicate [at least my modified Windows combined with] 'high-ish' CPU cores/threads have a problem with changes made to ffmpeg after May 12, 2022. Many-threads + specific target numbers chosen for height in zscale=size filter >> ERROR I've explained it better, or so I hope, at ffmpeg trac. |
I had the time to review vf_zscale.c in some more detail, and the problem is obvious:
Consider out_h=505, nb_threads=24:
The code crashes on some resolutions, because out_slice_end[N-2] is beyond the end of the image. Error 2050 is because out_slice_start[N-1] = out_slice_end[N-2], which is beyond the end of the image. Beside the logic error in this code, the benefit of running a filter with support=4*2160/505=17 (bicubic) in 21-line chunks is rather dubious. It appears that there was a check at some point to ensure the number of rows be at least 64, but it was deleted. |
Problem is just being hidden... Consider out_h=4158, nb_threads=64
Without the statement |
Do not insist on a fixed slice height, because that can still cause overflows in corner cases as described in this comment: sekrit-twc/zimg#177 (comment) Signed-off-by: Marton Balint <cus@passwd.hu>
Hi.
I'm asking it here, too, because I believe it may be related to some recent change in zimg that has cascaded down to ffmpeg and collided with my customized Wondows 10 x64 install.
This is my issue open at one of the current publishers of compiled ffmpeg binaries for windows. I'll post it here so I don't paste the whole thing.
GyanD/codexffmpeg#57
In short, it seems [to me] that recent changes in zimg now require something to be available in Windows that it didn't require before. So, using zscale for resizing image in ffmpeg throws an error in my customized OS install, an error that never appeared before... and what's weirder to me, it only happns to a limited set of files wich might be malformed... but the error doesn't happen in a vanilla Windows 10 install.
I hope this makes some sense, and I also hope is a matter than can be adressed here. I'm just a user without knowledge or experience to know how to deal with this.
The text was updated successfully, but these errors were encountered: