integrating in UWP ffmpeg build #3
Comments
The releases provided here are by default just regular win32 builds. However libvpx is one of the few dependencies that doesnt need any changes when compiling UWP so it should? be fine. However the supplied project file has a specific UWP build configuration that you can try building yourself to see if it makes any difference.
The UWP build of ffmpeg that the default configure script supports is only really tested by ffmpeg devs without any dependencies. Which is why im working on just creating a UWP configuration in the SMP FFmpeg repo (which you already noticed) which is almost done (at time of writing) |
|
Yeah I built libvpx_winrt.lib but when I try to link it into the UWP ffmpeg build I still get a compiler error |
No ETA at present (although it potentially could be done sooner rather than later) as it depends on how I prioritise stuff. Of course donations are always welcome (theres a link on the repo landing page) as I admit it does make good motivation to get stuff done. I can probably look at just selectively generating project dependencies with the FFVS project generator so that the currently unsupported dependencies are just ignored, which would be the fastest way of getting it up and running. |
|
i couldn't find a donate link, could you direct me? I found but the paypal link isn't working |
|
Its the badge on the github front page (link). I guess i didnt make it it visible enough. |
|
got it - sorry i was looking at a different page |
|
thanks |
|
OK, So I have updated FFVS Project Generator to now be able to generate WinRT/UWP configurations. So feel free to test if it works for you.
So give that a try and let me know how it works for you |
|
thanks. When trying to build the winrt debug dll for libavutil I'm getting: |
|
Thats rather strange as i compiled all the configurations on my pc during testing and they all worked. Looking at the error they shouldnt have worked which is why its strange i didnt pick it up. Anyway, a new fix has been pushed to FFVS that should hopefully fix that one. If you have anymore issues let me know. |
|
I pulled origin master from FFVS and now when I try to build avutil I'm getting: |
|
Hmm , sorry i did a rebase and things got messed. Try force pulling the latest version now. For convenience I will point out that FFVS generates a file called "ffmpeg_with_latest_sdk.bat" that if run will open the solution using the latest sdk detected on the host system. |
|
Thanks - I force pulled FFVS, regenerated the solution (running project_generate.exe --enable-libvpx), ran the latest_sdk.bat file and avutil builds fine so I built the solution and got 2 errors:
|
|
I compiled that exact configuration on my pc and didnt get any errors (i only checked 32bit), sure enough change to x64 and i can reproduce. Interestingly from the error line it seems like your nasm install is not working correctly as there shouldn't be a obj file in at "D:\ffmpeg-src\source\FFmpeg\SMP\flac_dsp_gpl.obj" (unless you changed the intermediate directory) as it should be in "D:\ffmpeg-src\source\FFmpeg\SMP\obj\DebugDLLWinRT\x64\libavcodec\x86\flac_dsp_gpl.obj" Not that this should affect the ability to build. For the moment the solution is to change your configure line to enable gpl:
|
|
Pushed a fix for the non-gpl case. |
|
I'm still getting the same error with the non-GPL build. There isn't a file at
calling
|
|
I cant reproduce this at all on my end. When generating a new project with just "--enable-libvpx" the input file "libavcodec\x86\flac_dsp_gpl.asm" is no longer included in the project when using the latest FFVS. Can you confirm that your project file does not include this asm file. |
|
`D:\ffmpeg-src\source\FFVS-Project-Generator\bin>cd.. D:\ffmpeg-src\source\FFVS-Project-Generator>git pull D:\ffmpeg-src\source\FFVS-Project-Generator>git checkout master D:\ffmpeg-src\source\FFVS-Project-Generator>git fetch D:\ffmpeg-src\source\FFVS-Project-Generator>cd bin D:\ffmpeg-src\source\FFVS-Project-Generator\bin>project_generate.exe --enable-libvpx ... D:\ffmpeg-src\source\FFmpeg\SMP\libavcodec.vcxproj does contain:
|
|
Check to make sure that your FFVS code matches the latest version found at repo. I didnt do any forced pushes or anything but make sure that they match. |
|
Sorry, my fault, I forgot to rebuild the ffvs project before running the executable. It's working - thanks so much for this, I really appreciate it. And thanks for getting it done so quickly as well. There are a few warnings, like:
also, when including libpx - do I need to include the libvpx_winrt.dll file or is it packaged into the avcodec_winrt.dll automagically? |
|
The warnings are not an issue. These are from ffmpeg code which has been like that for ages without issue. As for libvpx.dll. If your just using the vpx functionality directly through ffmpeg then all you need is the avcodec_winrt.dll to be linked to your software. However you will need to distribute the libvpx_winrt.dll as it will be needed at run time (unless you compile using DLLStaticDeps configuration in which case all you need to distribute is the ffmpeg dll) |
|
I dunno if it's of interest to you or not but the bindings generated with |
This reverts commit 360e906. This causes ASan errors: [ RUN ] VP9/TestVectorTest.MD5Match/1 ================================================================= ==837858==ERROR: AddressSanitizer: stack-buffer-overflow on address 0xffff82ecad40 at pc 0x000000c494d4 bp 0xffffe1695800 sp 0xffffe16957f8 READ of size 16 at 0xffff82ecad40 thread T0 #0 0xc494d0 in vpx_d117_predictor_32x32_neon (test_libvpx+0xc494d0) #1 0x1040b34 in vp9_predict_intra_block (test_libvpx+0x1040b34) #2 0xf8feec in decode_block (test_libvpx+0xf8feec) #3 0xf8f588 in decode_partition (test_libvpx+0xf8f588) #4 0xf7be5c in vp9_decode_frame (test_libvpx+0xf7be5c) ... Address 0xffff82ecad40 is located in stack of thread T0 at offset 64 in frame #0 0x103fd3c in vp9_predict_intra_block (test_libvpx+0x103fd3c) This frame has 2 object(s): [32, 64) 'left_col.i' <== Memory access at offset 64 overflows this variable [96, 176) 'above_data.i' Change-Id: I058213364617dfe1036126c33a3307f8288d9ae0
vpx_highbd_8_sub_pixel_variance4x4_neon
vpx_highbd_8_sub_pixel_variance4x8_neon
vpx_highbd_10_sub_pixel_variance4x4_neon
vpx_highbd_10_sub_pixel_variance4x8_neon
vpx_highbd_12_sub_pixel_variance4x4_neon
vpx_highbd_12_sub_pixel_variance4x8_neon
all cause heap overflows of the form:
[ RUN ] NEON/VpxHBDSubpelVarianceTest.Ref/24
=================================================================
==450528==ERROR: AddressSanitizer: heap-buffer-overflow on address
0xffff8311a571 at pc 0x0000010ca52c bp 0xffffc63e96b0 sp 0xffffc63e96a8
READ of size 8 at 0xffff8311a571 thread T0
#0 0x10ca528 in load_unaligned_u16q vpx_dsp/arm/mem_neon.h:176:3
#1 0x10ca528 in highbd_var_filter_block2d_bil_w4
vpx_dsp/arm/highbd_subpel_variance_neon.c:49:21
#2 0x10ca528 in vpx_highbd_10_sub_pixel_variance4x8_neon
vpx_dsp/arm/highbd_subpel_variance_neon.c:257:1
...
0xffff8311a571 is located 0 bytes to the right of 113-byte region
[0xffff8311a500,0xffff8311a571)
allocated by thread T0 here:
#0 0x5f18b0 in malloc (test_libvpx+0x5f18b0)
#1 0xce4f90 in vpx_memalign vpx_mem/vpx_mem.c:62:10
#2 0xce4f90 in vpx_malloc vpx_mem/vpx_mem.c:70:40
#3 0xa4ad44 in (anonymous namespace)::SubpelVarianceTest<unsigned
int (*)(unsigned char const*, int, int, int, unsigned char
const*, int, unsigned int*)>::SetUp() test/variance_test.cc:586:14
Bug: webm:1796
Change-Id: I39f7f936bae2bcbbe1f803fb10375ec02d1c1277
vpx_highbd_8_sub_pixel_avg_variance4x4_neon
vpx_highbd_8_sub_pixel_avg_variance4x8_neon
vpx_highbd_10_sub_pixel_avg_variance4x4_neon
vpx_highbd_10_sub_pixel_avg_variance4x8_neon
vpx_highbd_12_sub_pixel_avg_variance4x4_neon
vpx_highbd_12_sub_pixel_avg_variance4x8_neon
all cause heap overflows of the form:
i[ RUN ] NEON/VpxHBDSubpelAvgVarianceTest.Ref/33
=================================================================
==535205==ERROR: AddressSanitizer: heap-buffer-overflow on address
0xffff95bb0b89 at pc 0x00000116dabc bp 0xffffd09f6430 sp 0xffffd09f6428
READ of size 8 at 0xffff95bb0b89 thread T0
#0 0x116dab8 in load_unaligned_u16q vpx_dsp/arm/mem_neon.h:176:3
#1 0x116dab8 in highbd_var_filter_block2d_bil_w4
vpx_dsp/arm/highbd_subpel_variance_neon.c:49:21
#2 0x116dab8 in vpx_highbd_8_sub_pixel_avg_variance4x4_neon
vpx_dsp/arm/highbd_subpel_variance_neon.c:543:1
...
0xffff95bb0b89 is located 0 bytes to the right of 73-byte region
[0xffff95bb0b40,0xffff95bb0b89)
allocated by thread T0 here:
#0 0x5f18b0 in malloc (test_libvpx+0x5f18b0)
#1 0xce4a40 in vpx_memalign vpx_mem/vpx_mem.c:62:10
#2 0xce4a40 in vpx_malloc vpx_mem/vpx_mem.c:70:40
#3 0xa52238 in (anonymous namespace)::SubpelVarianceTest<unsigned
int (*)(unsigned char const*, int, int, int, unsigned char
const*, int, unsigned int*, unsigned char
const*)>::SetUp()
test/variance_test.cc:586:14
...
This is the same issue as:
e33d4c2 disable vpx_highbd_*_sub_pixel_variance4x{4,8}_neon
They have highbd_var_filter_block2d_bil_w4 in common.
Bug: webm:1796
Change-Id: I3ed70d0ba22e127720542612ea9f6665948eedfc
First of all thanks a lot for this.
Do you have any idea about how to use this in a UWP build of ffmpeg?
https://trac.ffmpeg.org/wiki/CompilationGuide/WinRT
../../../configure \ --toolchain=msvc \ --disable-programs \ --disable-d3d11va \ --disable-dxva2 \ --disable-opencl \ --arch=x86_64 \ --enable-shared \ --enable-libvpx \ --enable-cross-compile \ --target-os=win32 \ --extra-cflags="-MD -DWINAPI_FAMILY=WINAPI_FAMILY_APP -D_WIN32_WINNT=0x0A00 -I/d/ffmpeg-src/libvpx/include" \ --extra-ldflags="-APPCONTAINER WindowsApp.lib libvpx.lib -L/d/ffmpeg-src/libvpx/lib/x64" \ --prefix=../../../Build/Windows10/x64just gives me
C compiler test failed.(excluding the libvpx stuff it builds ok)
Are the releases built for UWP or is that something I need to do myself? Do you have any ideas on how to get ffmpeg to link it in? Thanks.
The text was updated successfully, but these errors were encountered: