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
av==9.1.1
wheels seem to be be not packaged properly for Windows and Python 3.8/9
#952
Comments
av==9.1.1
seems to be be not packaged properly for Windows and Python 3.8/9
For reference, here are the two CI runs after we pinned
|
av==9.1.1
seems to be be not packaged properly for Windows and Python 3.8/9av==9.1.1
wheels seem to be be not packaged properly for Windows and Python 3.8/9
There was a significant change in this release which is that the wheels bow use an FFmpeg built from source (same as the other platforms), sorry for the breakage. What intrigues me:
It sounds like there is a DLL missing, or clashing with another.. as I don't have access to a Windows machine this is going to be tricky to investigate. |
I just checked and CI definitely tested the 3.8 and 3.9 wheels on Windows: https://github.com/PyAV-Org/PyAV/runs/5783121554?check_suite_focus=true This leaves me wondering whether the wheels are actually broken or if we have a conflict with pytorch? |
Not only version specific, but also the "middle" ones. 3.7 and 3.10 are fine, which is especially peculiar.
I'll try to investigate on our side. @bjuncek are you aware of anything on our side that could cause this? |
Error persists even if we only setup the environment and not install anything form the PyTorch ecosystem. Thus, if there is a DLL conflict, it is not coming from us. Here are the envs: 3.7
3.8
3.9
3.10
Is there a "verbose mode" or the like to find which DLL breaks the import? |
Failure also happens if nothing but 3.8
3.9
|
I had a closer look at the DLLs contained in the av 9.1.0 vs 9.1.1 wheels and:
If I provide you with a wheel for a Python version of your choice would you be able to test it? Otherwise it means going through a full release process, potentially with no gain.. |
Yes, we could test if we had a wheel available. |
OK, the FFmpeg rebuild has completed (11 hours to cover all platforms..), and I've put together PR #954 to produce updated wheels. I'll keep you posted. |
Here are the wheels for Windows/64bit.. As github won't allow me to upload .whl files, nor to put them all in one big zip, I've had to put each in its .zip, sorry for the inconvenience! av-9.1.1-cp37-cp37m-win_amd64.whl.zip |
Hi @pmeier have you had a chance to check the wheels? The reason I'm asking is I'd like to cut a new release and would like to make sure the issue is fixed for you. |
I'll have some time in a couple of hours. Sorry for the delay. |
The issue persists:
|
Thanks for your feedback @pmeier so we're not quite done here.. It looks as though I'm going to need to find a way to spin up a Windows VM somehow, because the ImportError really doesn't tell us anything. I'm probably not going to be very online much for the coming week, but I'll get to the bottom of this before our next release - which I'll therefore postpone. |
No rush on our side. We pinned |
Good to know but it's still pretty annoying I introduced a regression! I really wanted to make sure we're not depending on any third-party binaries, so we can ensure all our platforms have consistent behaviour and security fixes. |
@uvjustin I really have no idea how to debug this as I don't have a Windows box, and even if I did I don't know what tool (equivalent to strace) I should use to figure out where the DLL loading breaks. Do you have any ideas here, as I could really use some help? |
Sure, I'll look into this |
OK, so after quite a bit of trouble I managed to install a Windows VM, using the image provided by Microsoft: https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/ I then installed Python 3.10, created a virtualenv, installed PyAV 9.1.1 from PyPI.. and it loads just fine? So it looks as though we're going to need more information about your environment, because so far I am unable to reproduce. |
Python 3.10 as well as 3.7 are fine. The wheels for Python 3.8 and 3.9 are not working. As for the environments, I posted our |
We are using a Windows Server 2019 image. Any idea how I could help debug this? Is there a way to find which DLL is causing this? |
I'm really not familiar enough with Windows to give you an answer, I was hoping I could trigger the error on a Windows VM so I could try and debug it, but unfortunately I'm not reproducing the error. Additionally I've put together a test which does:
.. across (Windows Server 2019, Windows Server 2022) x (Python 3.7, 3.8, 3.9, 3.10) and I haven't managed to get it to fail: |
Hmm, if GitHub Actions cleanly installs and imports the wheel, I'm back wondering if there is actually something wrong with our env. I'll think about it and get back to you. |
At this stage I see two main sources of potential differences:
|
When googling this the other day I found evidence of the latter. I can actually reproduce this on a conda env. |
I'll investigate on our side. |
OK I'm learning more than I care to here, which involves messing with gflags.exe and windbg.exe but here goes.. I've set up conda and I'm indeed able to trigger an error when using Python 3.9. AFAICT I can tell, it's not a deep dependency that's causing a problem, DLL loading seems to fail as soon as avformat-58-xxx.dll. Examining the output, the av.libs directory which contains the DLLs is not even being examined. This leads me to believe that conda's Python has been somehow modified, which interferes with the DLL search path! |
See adang1345/delvewheel#14 |
Interestingly enough, PyAV's What changed in 9.1.1 is that we no longer vendor the DLLs inside the |
I've just tested all 4 wheels using conda, and they all work, so I'm merging the PR! |
Our smoke tests are also passing 🎉 I'll do a full run with the test suite to see if everything else is still working and get back to you. |
Can confirm, with the new wheels our test suite is passing fine. Thanks a lot for the investigation and fix! |
PyAV 9.2.0 is on PyPI, and I have just checked that the wheels work on 3.7/3.8/3.9/3.10 using Conda, so we're all good here! |
Overview
av==9.1.1
wheel released a couple of hours ago seems to be not packaged properly for Windows and Python 3.8 and 3.9.Expected behavior
Import without issues.
Actual behavior
Investigation
CI runs:
Reproduction
Versions
The text was updated successfully, but these errors were encountered: