Continuous integration job for Windows/MSVC #52
Conversation
negate error code correctly
| path: src/main | ||
|
|
||
| - name: Generate visual studio project | ||
| run: .\FFVS-Project-Generator\project_generate.exe --rootdir=src/main --disable-everything --enable-ffmpeg --enable-decoder=vvc --enable-parser=vvc --enable-demuxer=vvc --enable-protocol=file --enable-protocol=pipe --enable-encoder=rawvideo --enable-muxer=rawvideo --enable-muxer=md5 |
There was a problem hiding this comment.
Thank you for the pr.
Could we use some macros for this?
So Linux and windows can share the same command line.
There was a problem hiding this comment.
Can do, although it is worth noting as I say above FFVS-Project-Generator actually interprets some arguments differently to the unix ./configure script. Specifically:
- It does not support commas, for example
--enable-muxer=rawvideo,md5does not work. --disable-everythingand--disable-allare synonymous, whereas in the unix version--disable-everythingdisables all components, but not all programs and other aspects of the build.- Some command line options such as
--disable-asmare not supported.
I actually kept the two separate because of this, but would you still like to try to have some flags shared? Maybe there could be a workflow-wide variable for shared flags and then job-specific variables. I will also put a comment warning anyone editing the workflow about this problem.
There was a problem hiding this comment.
Thank you for explaining. Considering the difference, we can keep these two command lines.
Seems some cases failed. it may be related to memory issues.
Maybe we can think about reducing worker number on windows. https://github.com/ffvvc/tests/blob/87ae9fed1283b1d101ef0c44609cb3739ed81779/tools/ffmpeg.py#L123
There was a problem hiding this comment.
Why do you think WPP_B_Sharp_2 and LTRP_A_ERICSSON_3 are failing? I see the other four fails result from the runner running out of memory, but these appear to complete successfully and then have a md5 mismatch. LTRP_A_ERICSSON_3 failed on my fork as well, where I didn't have any memory issues.
There was a problem hiding this comment.
There are two+ issues here.
- Memory allocation issue. We need to reduce memory in code. But the current quick solution is to reduce worker threads.
- Random failure. It may be related to valgrind issue for SAO filter. #26 and libavcodec/vvc_filter: Fix unintialized memory region at lc->sao_buffer #49 (comment).
Let us fix the first one and merge the PR. Then we can think about how to fix the second one.
There was a problem hiding this comment.
Let us fix the first one and merge the PR. Then we can think about how to fix the second one.
👍 Would you like me to make that change to ffvvc/tests or will you?
There was a problem hiding this comment.
Please help do this.
thank you
There was a problem hiding this comment.
Changes to enable control over number of threads have been made and PR is open: ffvvc/tests#1.
|
@frankplow thank you for the PR. Please continue to apply for the GSOC contributor |
The project has one important benefit, it can generate a solution file. so we can use visual studio to debug it.
It may be related to uninitialized variables. Not sure valgrind will capture it or not |
This PR adds CI for windows using FFVS-Project-Generator. The steps are generally similar to the existing linux CI jobs, with one significant difference: as FFVS-Project-Generator does not currently support disabling assembly optimisations (see ShiftMediaProject/FFVS-Project-Generator#62), the Windows build is currently performed with assembly enabled and assembled using NASM.
One test (LTRP_A_ERICSSON_3) is actually failing right now, and due to a mismatch rather than a timeout. I don't believe this is an issue with the CI configuration however. I would imagine the issue is in the assembly optimisations, rather than some OS/compiler-specific idiosyncrasy.
The solution generated by FFVS-Project-Generator feels a little fragile to me as I was setting this up. I had to do a fair bit of fiddling – some of the flags are interpreted slightly differently to the
./configurescript etc. I think in the long-term it may be better to perform MSVC builds using MSYS, which is also recommended in the FFmpeg compilation guide. This would also allow a matrix of compilers on windows as MinGW's Windows gcc could also be used. For now though, FFVS-Project-Generator seems to be working as a quick-and-dirty solution.This PR will close #33.