Discussion:
[PATCH] configure: force WINAPI_FAMILY to WINAPI_FAMILY_DESKTOP_APP to detect DVXA
(too old to reply)
Steve Lhomme
2015-07-23 06:45:24 UTC
Permalink
otherwise the API is hidden for Windows Phone / WindowsRT when in fact
it's there and working
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index a1901af..7feddfb 100755
--- a/configure
+++ b/configure
@@ -4264,7 +4264,7 @@ check_lib2 "windows.h psapi.h" GetProcessMemoryInfo -lpsapi

check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss

-check_type "windows.h dxva.h" "DXVA_PicParams_HEVC"
+check_type "windows.h dxva.h" "DXVA_PicParams_HEVC" -DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP
check_type "windows.h d3d11.h" "ID3D11VideoDecoder"
check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0600
--
2.4.5
Steve Lhomme
2015-07-23 06:50:19 UTC
Permalink
Post by Steve Lhomme
otherwise the API is hidden for Windows Phone / WindowsRT when in fact
it's there and working
This has no effect on Windows App Certification as it's all accessed
via COM objects and structures.
Post by Steve Lhomme
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index a1901af..7feddfb 100755
--- a/configure
+++ b/configure
@@ -4264,7 +4264,7 @@ check_lib2 "windows.h psapi.h" GetProcessMemoryInfo -lpsapi
check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss
-check_type "windows.h dxva.h" "DXVA_PicParams_HEVC"
+check_type "windows.h dxva.h" "DXVA_PicParams_HEVC" -DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP
check_type "windows.h d3d11.h" "ID3D11VideoDecoder"
check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0600
--
2.4.5
Martin Storsjö
2015-07-23 13:35:05 UTC
Permalink
Post by Steve Lhomme
otherwise the API is hidden for Windows Phone / WindowsRT when in fact
it's there and working
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index a1901af..7feddfb 100755
--- a/configure
+++ b/configure
@@ -4264,7 +4264,7 @@ check_lib2 "windows.h psapi.h" GetProcessMemoryInfo -lpsapi
check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss
-check_type "windows.h dxva.h" "DXVA_PicParams_HEVC"
+check_type "windows.h dxva.h" "DXVA_PicParams_HEVC" -DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP
check_type "windows.h d3d11.h" "ID3D11VideoDecoder"
check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0600
--
2.4.5
I don't get DXVA enabled at all in these configurations (winrt/winphone),
since DXVA2_ConfigPictureDecode isn't available either. It'd need to have
such an override of WINAPI_FAMILY when checking for
DXVA2_ConfigPictureDecode as well (and within libavcodec/dxva*, just like
for _WIN32_WINNT).

So I'm missing quite a bit on how this is supposed to work. E.g. which
exact SDK you've tested it with, since we're clearly not testing the same
thing.

// Martin
Steve Lhomme
2015-07-23 16:06:47 UTC
Permalink
Post by Martin Storsjö
Post by Steve Lhomme
otherwise the API is hidden for Windows Phone / WindowsRT when in fact
it's there and working
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index a1901af..7feddfb 100755
--- a/configure
+++ b/configure
@@ -4264,7 +4264,7 @@ check_lib2 "windows.h psapi.h" GetProcessMemoryInfo -lpsapi
check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss
-check_type "windows.h dxva.h" "DXVA_PicParams_HEVC"
+check_type "windows.h dxva.h" "DXVA_PicParams_HEVC"
-DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP
check_type "windows.h d3d11.h" "ID3D11VideoDecoder"
check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode
-D_WIN32_WINNT=0x0600
--
2.4.5
I don't get DXVA enabled at all in these configurations (winrt/winphone),
since DXVA2_ConfigPictureDecode isn't available either. It'd need to have
such an override of WINAPI_FAMILY when checking for
DXVA2_ConfigPictureDecode as well (and within libavcodec/dxva*, just like
for _WIN32_WINNT).
With this patch and one to call the proper link.exe, I get D3D11VA
enabled in the build using:
configure --toolchain=msvc --enable-cross-compile --target-os=win32
--arch=arm --extra-cflags="-DWINAPI_FAMILY=WINAPI_FAMILY_PHONE_APP"

It needs to be cross-compiled

The WINAPI_FAMILY cannot be deduced from the environment created by
Visual Studio. You just pick ARM but you still need to define what
kind of target it will be (Windows RT, Windows Phone) so it links to
the proper libs and restricts the API properly.
Post by Martin Storsjö
So I'm missing quite a bit on how this is supposed to work. E.g. which exact
SDK you've tested it with, since we're clearly not testing the same thing.
// Martin
_______________________________________________
libav-devel mailing list
https://lists.libav.org/mailman/listinfo/libav-devel
Martin Storsjö
2015-07-23 16:35:19 UTC
Permalink
Post by Steve Lhomme
Post by Martin Storsjö
Post by Steve Lhomme
otherwise the API is hidden for Windows Phone / WindowsRT when in fact
it's there and working
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index a1901af..7feddfb 100755
--- a/configure
+++ b/configure
@@ -4264,7 +4264,7 @@ check_lib2 "windows.h psapi.h" GetProcessMemoryInfo -lpsapi
check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss
-check_type "windows.h dxva.h" "DXVA_PicParams_HEVC"
+check_type "windows.h dxva.h" "DXVA_PicParams_HEVC"
-DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP
check_type "windows.h d3d11.h" "ID3D11VideoDecoder"
check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode
-D_WIN32_WINNT=0x0600
--
2.4.5
I don't get DXVA enabled at all in these configurations (winrt/winphone),
since DXVA2_ConfigPictureDecode isn't available either. It'd need to have
such an override of WINAPI_FAMILY when checking for
DXVA2_ConfigPictureDecode as well (and within libavcodec/dxva*, just like
for _WIN32_WINNT).
With this patch and one to call the proper link.exe, I get D3D11VA
configure --toolchain=msvc --enable-cross-compile --target-os=win32
--arch=arm --extra-cflags="-DWINAPI_FAMILY=WINAPI_FAMILY_PHONE_APP"
With the MSVC 2013 compiler, using the Windows 10 SDK from VS 2015 RC?

Note how the title of your mail says this is about DXVA, not about
D3D11VA - that made me think this actually was about DXVA...

So, both with and without this patch, I get D3D11VA enabled after
configure (but CONFIG_DXVA disabled), so that's why I'm confused about
what this patch actually tries to achieve.

The WINAPI_FAMILY only gets overridden within the test for
DXVA_PicParams_HEVC, which only controls whether the HEVC hwaccel for
DXVA2/D3D11VA is enabled, not whether those hwaccels are enabled as such.
So I do not understand how this patch is supposed to actually achieve the
thing that you say it does.

When I build, in that configuration, it fails when building
libavcodec/dxva2_mpeg2.o, since WINAPI_FAMILY still is
WINAPI_FAMILY_PHONE_APP; your patch only overrides it during one single
test within configure, not while actually building the source files. So I
don't see how you could possibly build the libavcodec/dxva* files in a
windows phone environment unless you actually modify them, to override
WINAPI_FAMILY in the same way as currently is done for _WIN32_WINNT.

Does your environment have some other changes (like some extra cl wrapper
scripts that set extra options) that aren't described? Because without
that, I really do not see how this would work.


// Martin
Derek Buitenhuis
2015-07-23 16:55:25 UTC
Permalink
Post by Martin Storsjö
With the MSVC 2013 compiler, using the Windows 10 SDK from VS 2015 RC?
This will never be a supported set up. Ever. It's a hack.

- Derek
Martin Storsjö
2015-07-23 17:03:40 UTC
Permalink
Post by Derek Buitenhuis
Post by Martin Storsjö
With the MSVC 2013 compiler, using the Windows 10 SDK from VS 2015 RC?
This will never be a supported set up. Ever. It's a hack.
Yeah, but if it makes the configure checks more robust/correct or actually
has an effect on the proper SDKs as well (or at least doesn't cause any
harm), I wouldn't mind. But here I don't see how it would fix anything at
all, except enabling the HEVC part of the dxva/d3d11va hwaccels (which
don't build as such here right now).

If there's something else added in the environments, so that the d3d11va
hwaccel does actually build (which it doesn't, for me, when targeting
windows phone), this patch would be correct for enabling HEVC. But before
going there, we need to solve the fact that the d3d11va doesn't compile at
all while targeting windows phone.

// Martin
Steve Lhomme
2015-07-23 17:07:17 UTC
Permalink
On Thu, Jul 23, 2015 at 6:55 PM, Derek Buitenhuis
Post by Derek Buitenhuis
Post by Martin Storsjö
With the MSVC 2013 compiler, using the Windows 10 SDK from VS 2015 RC?
This will never be a supported set up. Ever. It's a hack.
With VS 2015 RTM out, it should be enough by itself. I had problems
with the RC and I didn't dig too much on what was happening. I suspect
using the dynamic runtime of VS 2015 doesn't work on WP8.1 as it's not
installed on the system.
Post by Derek Buitenhuis
- Derek
_______________________________________________
libav-devel mailing list
https://lists.libav.org/mailman/listinfo/libav-devel
Steve Lhomme
2015-07-23 17:05:47 UTC
Permalink
Post by Martin Storsjö
Post by Steve Lhomme
Post by Martin Storsjö
Post by Steve Lhomme
otherwise the API is hidden for Windows Phone / WindowsRT when in fact
it's there and working
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index a1901af..7feddfb 100755
--- a/configure
+++ b/configure
@@ -4264,7 +4264,7 @@ check_lib2 "windows.h psapi.h"
GetProcessMemoryInfo
-lpsapi
check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss
-check_type "windows.h dxva.h" "DXVA_PicParams_HEVC"
+check_type "windows.h dxva.h" "DXVA_PicParams_HEVC"
-DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP
check_type "windows.h d3d11.h" "ID3D11VideoDecoder"
check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode
-D_WIN32_WINNT=0x0600
--
2.4.5
I don't get DXVA enabled at all in these configurations (winrt/winphone),
since DXVA2_ConfigPictureDecode isn't available either. It'd need to have
such an override of WINAPI_FAMILY when checking for
DXVA2_ConfigPictureDecode as well (and within libavcodec/dxva*, just like
for _WIN32_WINNT).
With this patch and one to call the proper link.exe, I get D3D11VA
configure --toolchain=msvc --enable-cross-compile --target-os=win32
--arch=arm --extra-cflags="-DWINAPI_FAMILY=WINAPI_FAMILY_PHONE_APP"
With the MSVC 2013 compiler, using the Windows 10 SDK from VS 2015 RC?
With the ARM compiler coming from VS 2015 RC that it puts in the MSVC
2013 Express folder. Using the WP8.1 SDK that came with VS 2015 RC.
Post by Martin Storsjö
Note how the title of your mail says this is about DXVA, not about D3D11VA -
that made me think this actually was about DXVA...
Yes and no. DVXA2 is not available on Windows Phone (no D3D9). But
since the code is shared between DXVA2 and D3D11 in libav, it's still
the dxva.h check.
Post by Martin Storsjö
So, both with and without this patch, I get D3D11VA enabled after configure
(but CONFIG_DXVA disabled), so that's why I'm confused about what this patch
actually tries to achieve.
With this patch and the right extra WINAPI_FAMILY and --disable-libavdevice
Post by Martin Storsjö
The WINAPI_FAMILY only gets overridden within the test for
DXVA_PicParams_HEVC, which only controls whether the HEVC hwaccel for
DXVA2/D3D11VA is enabled, not whether those hwaccels are enabled as such. So
I do not understand how this patch is supposed to actually achieve the thing
that you say it does.
I think I forgot the patch that goes in dxva2_internal.h, it also
forces the WINAPI_FAMILY
I'll submit the version I use.
Post by Martin Storsjö
When I build, in that configuration, it fails when building
libavcodec/dxva2_mpeg2.o, since WINAPI_FAMILY still is
WINAPI_FAMILY_PHONE_APP; your patch only overrides it during one single test
within configure, not while actually building the source files. So I don't
see how you could possibly build the libavcodec/dxva* files in a windows
phone environment unless you actually modify them, to override WINAPI_FAMILY
in the same way as currently is done for _WIN32_WINNT.
Does your environment have some other changes (like some extra cl wrapper
scripts that set extra options) that aren't described? Because without that,
I really do not see how this would work.
It has a ton more differences. I use a wrapper for cl.exe that
pretends to act mostly like gcc. Same thing with link, so that VLC
contribs build mostly unchanged.
That involves filtering/editing the commands passed to the compiler,
forcing some includes with default values of fixes. I won't submit any
of these to libav/ffmpeg. I'm just trying to avoid our local patches.

I know the code is working and I have it working on a device and it's
been used on other devices too. The fact that it will work stand-alone
in libav is less guaranteed. The restrictions on the API calls mean
some common calls need to be re-routed and disabled. That's the kind
of things we do in the forced header.
Post by Martin Storsjö
// Martin
_______________________________________________
libav-devel mailing list
https://lists.libav.org/mailman/listinfo/libav-devel
Martin Storsjö
2015-07-23 20:49:34 UTC
Permalink
Post by Steve Lhomme
Post by Martin Storsjö
So, both with and without this patch, I get D3D11VA enabled after configure
(but CONFIG_DXVA disabled), so that's why I'm confused about what this patch
actually tries to achieve.
With this patch and the right extra WINAPI_FAMILY and --disable-libavdevice
What's --disable-libavdevice needed for?
Post by Steve Lhomme
Post by Martin Storsjö
The WINAPI_FAMILY only gets overridden within the test for
DXVA_PicParams_HEVC, which only controls whether the HEVC hwaccel for
DXVA2/D3D11VA is enabled, not whether those hwaccels are enabled as such. So
I do not understand how this patch is supposed to actually achieve the thing
that you say it does.
I think I forgot the patch that goes in dxva2_internal.h, it also
forces the WINAPI_FAMILY
I'll submit the version I use.
Exactly, that was what was missing.
Post by Steve Lhomme
Post by Martin Storsjö
When I build, in that configuration, it fails when building
libavcodec/dxva2_mpeg2.o, since WINAPI_FAMILY still is
WINAPI_FAMILY_PHONE_APP; your patch only overrides it during one single test
within configure, not while actually building the source files. So I don't
see how you could possibly build the libavcodec/dxva* files in a windows
phone environment unless you actually modify them, to override WINAPI_FAMILY
in the same way as currently is done for _WIN32_WINNT.
Does your environment have some other changes (like some extra cl wrapper
scripts that set extra options) that aren't described? Because without that,
I really do not see how this would work.
It has a ton more differences. I use a wrapper for cl.exe that
pretends to act mostly like gcc. Same thing with link, so that VLC
contribs build mostly unchanged.
Just for the record, in case you wasn't familiar with the history of this
wrapper - I wrote the original proof of concept of it, which then Hugo
finished to make it actually build all of the vlc contribs.

I also said that such a wrapper shouldn't ideally be used with libav,
since libav supports MSVC out of the box, and adding such a wrapper only
complicates matters here (and slows down the build). If the wrapper
actually works with libav as well, that's of course good for vlc, and I
recall that Hugo wanted it to work to avoid having to intentionally skip
it for only some of the contribs.
Post by Steve Lhomme
That involves filtering/editing the commands passed to the compiler,
forcing some includes with default values of fixes.
Ok, so I guess that it (among other things) forces including a header
which first includes some headers (corecrt.h or something like that?) and
then overrides WINAPI_FAMILY to WINAPI_FAMILY_DESKTOP_APP, in order to get
all definitions visible, regardless of the targeted API subset?

The bug I found with the updated version of this patch (where the
configure test that you change still fails due to "Compiling Desktop
applications for the ARM platform is not supported.") is one symptom of
this.
Post by Steve Lhomme
I won't submit any of these to libav/ffmpeg.
Of course - you shouldn't.

But what you _should_ have been doing all along would be to test your
patches without this wrapper.

I understand that you don't want to test your patches at actual runtime
with builds without this wrapper, since it probably is quite deeply tied
in with how the contribs are hooked up. But you could at the very least
test to make sure that your patches at least compile at all in a vanilla
libav setup, without your own custom cl wrapper that nobody else will use.
Post by Steve Lhomme
I'm just trying to avoid our local patches.
Sure - that is good, but please understand that the patches you submit
must work with normal vanilla libav builds, not only with a custom build
env (and break in normal builds).
Post by Steve Lhomme
I know the code is working and I have it working on a device and it's
been used on other devices too. The fact that it will work stand-alone
in libav is less guaranteed. The restrictions on the API calls mean some
common calls need to be re-routed and disabled. That's the kind of
things we do in the forced header.
So can you summarize what the state of D3D11VA is at the moment, with
vanilla libav builds? It works for WINAPI_FAMILY_DESKTOP_APP, but probably
won't work if targeting WINAPI_FAMILY_APP (or _PHONE_APP)?

// Martin
Steve Lhomme
2015-07-24 07:21:12 UTC
Permalink
Post by Martin Storsjö
Post by Steve Lhomme
Post by Martin Storsjö
So, both with and without this patch, I get D3D11VA enabled after configure
(but CONFIG_DXVA disabled), so that's why I'm confused about what this patch
actually tries to achieve.
With this patch and the right extra WINAPI_FAMILY and
--disable-libavdevice
What's --disable-libavdevice needed for?
It's actually --disable-avdevice. For some reason it's enabled by
default. And doesn't build. I didn't investigate further.
Post by Martin Storsjö
Post by Steve Lhomme
Post by Martin Storsjö
The WINAPI_FAMILY only gets overridden within the test for
DXVA_PicParams_HEVC, which only controls whether the HEVC hwaccel for
DXVA2/D3D11VA is enabled, not whether those hwaccels are enabled as such. So
I do not understand how this patch is supposed to actually achieve the thing
that you say it does.
I think I forgot the patch that goes in dxva2_internal.h, it also
forces the WINAPI_FAMILY
I'll submit the version I use.
Exactly, that was what was missing.
Post by Steve Lhomme
Post by Martin Storsjö
When I build, in that configuration, it fails when building
libavcodec/dxva2_mpeg2.o, since WINAPI_FAMILY still is
WINAPI_FAMILY_PHONE_APP; your patch only overrides it during one single test
within configure, not while actually building the source files. So I don't
see how you could possibly build the libavcodec/dxva* files in a windows
phone environment unless you actually modify them, to override WINAPI_FAMILY
in the same way as currently is done for _WIN32_WINNT.
Does your environment have some other changes (like some extra cl wrapper
scripts that set extra options) that aren't described? Because without that,
I really do not see how this would work.
It has a ton more differences. I use a wrapper for cl.exe that
pretends to act mostly like gcc. Same thing with link, so that VLC
contribs build mostly unchanged.
Just for the record, in case you wasn't familiar with the history of this
wrapper - I wrote the original proof of concept of it, which then Hugo
finished to make it actually build all of the vlc contribs.
I also said that such a wrapper shouldn't ideally be used with libav, since
libav supports MSVC out of the box, and adding such a wrapper only
complicates matters here (and slows down the build). If the wrapper actually
works with libav as well, that's of course good for vlc, and I recall that
Hugo wanted it to work to avoid having to intentionally skip it for only
some of the contribs.
Yes, we can build all the useful contribs with it, as soon as the C
code is fixed for MSVC.

Only the contribs that use CMake are built a different way. And it's a
much cleaner solution, allowing IDE integration.
Post by Martin Storsjö
Post by Steve Lhomme
That involves filtering/editing the commands passed to the compiler,
forcing some includes with default values of fixes.
Ok, so I guess that it (among other things) forces including a header which
first includes some headers (corecrt.h or something like that?) and then
overrides WINAPI_FAMILY to WINAPI_FAMILY_DESKTOP_APP, in order to get all
definitions visible, regardless of the targeted API subset?
No, WINAPI_FAMILY is only overridden in rare cases. That allows the
compiler to hide whatever will not pass Windows store certification.
Only winapifamily.h is added. But with most headers your code will
include from the Windows SDK, it will be included anyway.
Post by Martin Storsjö
The bug I found with the updated version of this patch (where the configure
test that you change still fails due to "Compiling Desktop applications for
the ARM platform is not supported.") is one symptom of this.
Post by Steve Lhomme
I won't submit any of these to libav/ffmpeg.
Of course - you shouldn't.
But what you _should_ have been doing all along would be to test your
patches without this wrapper.
What I submitted were necessary patches, they are not sufficient.
Probably not even now. But without them, it's guaranteed not to work.
Post by Martin Storsjö
I understand that you don't want to test your patches at actual runtime with
builds without this wrapper, since it probably is quite deeply tied in with
how the contribs are hooked up. But you could at the very least test to make
sure that your patches at least compile at all in a vanilla libav setup,
without your own custom cl wrapper that nobody else will use.
Post by Steve Lhomme
I'm just trying to avoid our local patches.
Sure - that is good, but please understand that the patches you submit must
work with normal vanilla libav builds, not only with a custom build env (and
break in normal builds).
Yes I understand.
Post by Martin Storsjö
Post by Steve Lhomme
I know the code is working and I have it working on a device and it's been
used on other devices too. The fact that it will work stand-alone in libav
is less guaranteed. The restrictions on the API calls mean some common calls
need to be re-routed and disabled. That's the kind of things we do in the
forced header.
So can you summarize what the state of D3D11VA is at the moment, with
vanilla libav builds? It works for WINAPI_FAMILY_DESKTOP_APP, but probably
won't work if targeting WINAPI_FAMILY_APP (or _PHONE_APP)?
Right now the current master doesn't build out of the box because of
the link.exe issue.

It also doesn't build with VS2015 RTM (sans VS2013 involved) because
of -FIstdlib.h which doesn't exist there (at least on my new
installation).

With VS2015 RTM the 2013 arm toolchain it provides doesn't have
libcmt, which means -MD (and -MDd) have to be used. It is not the
default so should also be added to the extra cflags, or added in
configure (probably better, it should pick -MDd when used with
--enable-debug). I suppose they don't ship it to force the use of the
runtime DLL that's already provided on every phone.

Once -MD is set, it still doesn't build:

cl -I. -I/c/Users/Steve/Documents/Program/lavcodec/libav
-D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-Dstrtod=avpriv_strtod -Dsnprintf=avpriv_snprintf
-D_snprintf=avpriv_snprintf -Dvsnprintf=avpriv_vsnprintf
-D_WIN32_WINNT=0x0502 -DHAVE_AV_CONFIG_H -nologo -D_USE_MATH_DEFINES
-D_CRT_SECURE_NO_WARNINGS -Dinline=__inline -FIstdlib.h
-Dstrtoll=_strtoi64 -DWINAPI_FAMILY=WINAPI_FAMILY_PHONE_APP -MD -mcpu=
-marm -Z7 -W4 -wd4244 -wd4127 -wd4018 -wd4389 -wd4146 -wd4057
-wd4204 -wd4706 -wd4305 -wd4152 -wd4324 -we4013 -wd4100 -wd4214
-wd4273 -wd4554 -wd4701 -O2 -c -Folibavformat/4xm.o
/c/Users/Steve/Documents/Program/lavcodec/libav/libavformat/4xm.c
cl : Command line warning D9002 : ignoring unknown option '-mcpu='
cl : Command line warning D9002 : ignoring unknown option '-marm'
4xm.c
C:\Program Files (x86)\Windows
Kits\8.1\include\um\processthreadsapi.h(412) : error C4013: 'FlsAlloc'
undefined; assuming extern returning int
C:\Program Files (x86)\Windows
Kits\8.1\include\um\processthreadsapi.h(423) : error C4013:
'FlsGetValue' undefined; assuming extern returning int
C:\Program Files (x86)\Windows
Kits\8.1\include\um\processthreadsapi.h(423) : warning C4047: 'return'
: 'LPVOID' differs in levels of indirection from 'int'
C:\Program Files (x86)\Windows
Kits\8.1\include\um\processthreadsapi.h(435) : error C4013:
'FlsSetValue' undefined; assuming extern returning int
C:\Program Files (x86)\Windows
Kits\8.1\include\um\processthreadsapi.h(446) : error C4013: 'FlsFree'
undefined; assuming extern returning int
C:\Program Files (x86)\Windows Kits\8.1\include\um\combaseapi.h(1157)
: error C4013: 'CoCreateInstanceFromApp' undefined; assuming extern
returning int

I haven't investigated further. One thing that is wrong in this
command-line is forcing _WIN32_WINNT=0x0502. It should only be done
for files where it's necessary, just like we force the WINAPI_FAMILY
to unhide specific things.
Post by Martin Storsjö
// Martin
_______________________________________________
libav-devel mailing list
https://lists.libav.org/mailman/listinfo/libav-devel
Martin Storsjö
2015-07-24 08:41:04 UTC
Permalink
Post by Steve Lhomme
Post by Martin Storsjö
But what you _should_ have been doing all along would be to test your
patches without this wrapper.
What I submitted were necessary patches, they are not sufficient.
Probably not even now. But without them, it's guaranteed not to work.
Ok, but then _please_ say so in the patch description. It's quite
frustrating to try to understand how on earth the patches you send are
supposed to work, and to spend hours to try to figure this out.
Post by Steve Lhomme
Post by Martin Storsjö
I understand that you don't want to test your patches at actual runtime with
builds without this wrapper, since it probably is quite deeply tied in with
how the contribs are hooked up. But you could at the very least test to make
sure that your patches at least compile at all in a vanilla libav setup,
without your own custom cl wrapper that nobody else will use.
Post by Steve Lhomme
I'm just trying to avoid our local patches.
Sure - that is good, but please understand that the patches you submit must
work with normal vanilla libav builds, not only with a custom build env (and
break in normal builds).
Yes I understand.
Post by Martin Storsjö
Post by Steve Lhomme
I know the code is working and I have it working on a device and it's been
used on other devices too. The fact that it will work stand-alone in libav
is less guaranteed. The restrictions on the API calls mean some common calls
need to be re-routed and disabled. That's the kind of things we do in the
forced header.
So can you summarize what the state of D3D11VA is at the moment, with
vanilla libav builds? It works for WINAPI_FAMILY_DESKTOP_APP, but probably
won't work if targeting WINAPI_FAMILY_APP (or _PHONE_APP)?
Right now the current master doesn't build out of the box because of
the link.exe issue.
This is a minor inconvenience at best, which all other users of
libav/ffmpeg on msvc have managed to work around just fine based on the
public instructions.

Yes it's not perfect, but don't make it sound like it's an issue that
allows you to not care about how libav behaves without vlc's own wrapper.
Post by Steve Lhomme
It also doesn't build with VS2015 RTM (sans VS2013 involved) because
of -FIstdlib.h which doesn't exist there (at least on my new
installation).
Eh, wtf? Somehow I don't think that VS2015 RTM lacks stdlib.h. FWIW, this
seems to work just fine, for both x86 and arm, with VS2015 RTM for me.
Post by Steve Lhomme
With VS2015 RTM the 2013 arm toolchain it provides doesn't have
libcmt, which means -MD (and -MDd) have to be used. It is not the
default so should also be added to the extra cflags, or added in
configure (probably better, it should pick -MDd when used with
--enable-debug). I suppose they don't ship it to force the use of the
runtime DLL that's already provided on every phone.
Yes, you manually need to add -MD here. Ideally configure should maybe
detect that and add it automatically - currently it doesn't.
Post by Steve Lhomme
cl -I. -I/c/Users/Steve/Documents/Program/lavcodec/libav
-D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-Dstrtod=avpriv_strtod -Dsnprintf=avpriv_snprintf
-D_snprintf=avpriv_snprintf -Dvsnprintf=avpriv_vsnprintf
-D_WIN32_WINNT=0x0502 -DHAVE_AV_CONFIG_H -nologo -D_USE_MATH_DEFINES
-D_CRT_SECURE_NO_WARNINGS -Dinline=__inline -FIstdlib.h
-Dstrtoll=_strtoi64 -DWINAPI_FAMILY=WINAPI_FAMILY_PHONE_APP -MD -mcpu=
-marm -Z7 -W4 -wd4244 -wd4127 -wd4018 -wd4389 -wd4146 -wd4057
-wd4204 -wd4706 -wd4305 -wd4152 -wd4324 -we4013 -wd4100 -wd4214
-wd4273 -wd4554 -wd4701 -O2 -c -Folibavformat/4xm.o
/c/Users/Steve/Documents/Program/lavcodec/libav/libavformat/4xm.c
cl : Command line warning D9002 : ignoring unknown option '-mcpu='
cl : Command line warning D9002 : ignoring unknown option '-marm'
4xm.c
C:\Program Files (x86)\Windows
Kits\8.1\include\um\processthreadsapi.h(412) : error C4013: 'FlsAlloc'
undefined; assuming extern returning int
C:\Program Files (x86)\Windows
'FlsGetValue' undefined; assuming extern returning int
C:\Program Files (x86)\Windows
Kits\8.1\include\um\processthreadsapi.h(423) : warning C4047: 'return'
: 'LPVOID' differs in levels of indirection from 'int'
C:\Program Files (x86)\Windows
'FlsSetValue' undefined; assuming extern returning int
C:\Program Files (x86)\Windows
Kits\8.1\include\um\processthreadsapi.h(446) : error C4013: 'FlsFree'
undefined; assuming extern returning int
C:\Program Files (x86)\Windows Kits\8.1\include\um\combaseapi.h(1157)
: error C4013: 'CoCreateInstanceFromApp' undefined; assuming extern
returning int
I haven't investigated further. One thing that is wrong in this
command-line is forcing _WIN32_WINNT=0x0502. It should only be done
for files where it's necessary, just like we force the WINAPI_FAMILY
to unhide specific things.
There's a reason for this being set (in general), there's this descriptive
comment in configure:

# The MSVC 2010 headers (Win 7.0 SDK) set _WIN32_WINNT to
# 0x601 by default unless something else is set by the user.
# This can easily lead to us detecting functions only present
# in such new versions and producing binaries requiring windows 7.0.
# Therefore explicitly set the default to XP unless the user has
# set something else on the command line.
check_${pfx}cpp_condition stdlib.h "defined(_WIN32_WINNT)" ||
add_${pfx}cppflags -D_WIN32_WINNT=0x0502

Since the way configure checks for functions, and if they are found in the
SDK, they will be used, one would easily end up with binaries that only
work on the latest windows version, while for desktop most people want a
few versions backwards compatibility. So unless you've specificed
_WIN32_WINNT manually, we set it to this old version.

When targeting arm and/or winrt, you manually need to set this to a higher
version, like 0x0602. (Normally you'd only want to set this to a higher
value for specific parts, like for dxva/d3d11va, but for winrt/winphone,
setting it to 0x0602 is ok because code for winrt/winphone won't ever run
on an older windows version than this.)

All these parameters you need to set are covered in e.g.
https://wiki.libav.org/Platform/WindowsPhone. I just retested these
instructions with VS2015 RTM, and they work just fine. (The
--disable-dxva2 might not be needed any longer, I'll recheck that and
update the page accordingly.)

Works fine, except that d3d11va doesn't build correctly until your patch
for forcing WINAPI_FAMILY to WINAPI_FAMILY_DESKTOP_APP is applied - I've
used --disable-d3d11va for the fate instances at
https://fate.libav.org/arm-msvc-11-winrt-gaspp/20150723095235 since a few
months since d3d11va was added - we discussed this on irc and you said
you'd look at the issue soon.

Improvements to configure to automatically figure out some of these
parameters to avoid having to set them manually are welcome of course.

// Martin
Steve Lhomme
2015-07-25 07:17:33 UTC
Permalink
Post by Martin Storsjö
Post by Steve Lhomme
Post by Martin Storsjö
But what you _should_ have been doing all along would be to test your
patches without this wrapper.
What I submitted were necessary patches, they are not sufficient.
Probably not even now. But without them, it's guaranteed not to work.
Ok, but then _please_ say so in the patch description. It's quite
frustrating to try to understand how on earth the patches you send are
supposed to work, and to spend hours to try to figure this out.
Post by Steve Lhomme
Post by Martin Storsjö
I understand that you don't want to test your patches at actual runtime with
builds without this wrapper, since it probably is quite deeply tied in with
how the contribs are hooked up. But you could at the very least test to make
sure that your patches at least compile at all in a vanilla libav setup,
without your own custom cl wrapper that nobody else will use.
Post by Steve Lhomme
I'm just trying to avoid our local patches.
Sure - that is good, but please understand that the patches you submit must
work with normal vanilla libav builds, not only with a custom build env (and
break in normal builds).
Yes I understand.
Post by Martin Storsjö
Post by Steve Lhomme
I know the code is working and I have it working on a device and it's been
used on other devices too. The fact that it will work stand-alone in libav
is less guaranteed. The restrictions on the API calls mean some common calls
need to be re-routed and disabled. That's the kind of things we do in the
forced header.
So can you summarize what the state of D3D11VA is at the moment, with
vanilla libav builds? It works for WINAPI_FAMILY_DESKTOP_APP, but probably
won't work if targeting WINAPI_FAMILY_APP (or _PHONE_APP)?
Right now the current master doesn't build out of the box because of
the link.exe issue.
This is a minor inconvenience at best, which all other users of libav/ffmpeg
on msvc have managed to work around just fine based on the public
instructions.
Yes it's not perfect, but don't make it sound like it's an issue that allows
you to not care about how libav behaves without vlc's own wrapper.
I do care. The problem is that to build all the contribs we have tons
of tweaks to call configure. It is hard to know which have an
influence for just libav. The only thing I'm sure of is the patch
files we still need to keep in place where this tweaks are not enough.
Specifically the stuff here:
https://github.com/robUx4/vlc/tree/wip/contrib/src/ffmpeg

I'll probably submit the near_field patch too which is just field
renaming because "near" is a reserved keyword in MSVC.

Up until yesterday I didn't have a reliable way to build VLC and its
contribs for WP8. So standalone libav may still a bit far off. I just
started working on it while I was doing one of the 1/2h VLC
compilations.
Post by Martin Storsjö
Post by Steve Lhomme
It also doesn't build with VS2015 RTM (sans VS2013 involved) because
of -FIstdlib.h which doesn't exist there (at least on my new
installation).
Eh, wtf? Somehow I don't think that VS2015 RTM lacks stdlib.h. FWIW, this
seems to work just fine, for both x86 and arm, with VS2015 RTM for me.
Strange, I did a repair and it's still not there. It is in VS2013
though. I'll see if that's an issue when I try to build everything
with just VS2015. For now a non-free VS2013 is the way to go or VS2015
RTM Community using the VS2013 shell.
Post by Martin Storsjö
Post by Steve Lhomme
With VS2015 RTM the 2013 arm toolchain it provides doesn't have
libcmt, which means -MD (and -MDd) have to be used. It is not the
default so should also be added to the extra cflags, or added in
configure (probably better, it should pick -MDd when used with
--enable-debug). I suppose they don't ship it to force the use of the
runtime DLL that's already provided on every phone.
Yes, you manually need to add -MD here. Ideally configure should maybe
detect that and add it automatically - currently it doesn't.
Is there a way with gcc to tell whether you want static or dynamic
runtime ? For Windows Phone it should always be dynamic anyway. That
can be deduced from the WINAPI_FAMILY selected.
Post by Martin Storsjö
Post by Steve Lhomme
cl -I. -I/c/Users/Steve/Documents/Program/lavcodec/libav
-D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-Dstrtod=avpriv_strtod -Dsnprintf=avpriv_snprintf
-D_snprintf=avpriv_snprintf -Dvsnprintf=avpriv_vsnprintf
-D_WIN32_WINNT=0x0502 -DHAVE_AV_CONFIG_H -nologo -D_USE_MATH_DEFINES
-D_CRT_SECURE_NO_WARNINGS -Dinline=__inline -FIstdlib.h
-Dstrtoll=_strtoi64 -DWINAPI_FAMILY=WINAPI_FAMILY_PHONE_APP -MD -mcpu=
-marm -Z7 -W4 -wd4244 -wd4127 -wd4018 -wd4389 -wd4146 -wd4057
-wd4204 -wd4706 -wd4305 -wd4152 -wd4324 -we4013 -wd4100 -wd4214
-wd4273 -wd4554 -wd4701 -O2 -c -Folibavformat/4xm.o
/c/Users/Steve/Documents/Program/lavcodec/libav/libavformat/4xm.c
cl : Command line warning D9002 : ignoring unknown option '-mcpu='
cl : Command line warning D9002 : ignoring unknown option '-marm'
4xm.c
C:\Program Files (x86)\Windows
Kits\8.1\include\um\processthreadsapi.h(412) : error C4013: 'FlsAlloc'
undefined; assuming extern returning int
C:\Program Files (x86)\Windows
'FlsGetValue' undefined; assuming extern returning int
C:\Program Files (x86)\Windows
Kits\8.1\include\um\processthreadsapi.h(423) : warning C4047: 'return'
: 'LPVOID' differs in levels of indirection from 'int'
C:\Program Files (x86)\Windows
'FlsSetValue' undefined; assuming extern returning int
C:\Program Files (x86)\Windows
Kits\8.1\include\um\processthreadsapi.h(446) : error C4013: 'FlsFree'
undefined; assuming extern returning int
C:\Program Files (x86)\Windows Kits\8.1\include\um\combaseapi.h(1157)
: error C4013: 'CoCreateInstanceFromApp' undefined; assuming extern
returning int
I haven't investigated further. One thing that is wrong in this
command-line is forcing _WIN32_WINNT=0x0502. It should only be done
for files where it's necessary, just like we force the WINAPI_FAMILY
to unhide specific things.
There's a reason for this being set (in general), there's this descriptive
# The MSVC 2010 headers (Win 7.0 SDK) set _WIN32_WINNT to
# 0x601 by default unless something else is set by the user.
# This can easily lead to us detecting functions only present
# in such new versions and producing binaries requiring windows 7.0.
# Therefore explicitly set the default to XP unless the user has
# set something else on the command line.
check_${pfx}cpp_condition stdlib.h "defined(_WIN32_WINNT)" ||
add_${pfx}cppflags -D_WIN32_WINNT=0x0502
Since the way configure checks for functions, and if they are found in the
SDK, they will be used, one would easily end up with binaries that only work
on the latest windows version, while for desktop most people want a few
versions backwards compatibility. So unless you've specificed _WIN32_WINNT
manually, we set it to this old version.
When targeting arm and/or winrt, you manually need to set this to a higher
version, like 0x0602. (Normally you'd only want to set this to a higher
value for specific parts, like for dxva/d3d11va, but for winrt/winphone,
setting it to 0x0602 is ok because code for winrt/winphone won't ever run on
an older windows version than this.)
All these parameters you need to set are covered in e.g.
https://wiki.libav.org/Platform/WindowsPhone. I just retested these
instructions with VS2015 RTM, and they work just fine. (The --disable-dxva2
might not be needed any longer, I'll recheck that and update the page
accordingly.)
From what I see `--disable-dxva2` can be removed it's correctly
detected as not available.
Post by Martin Storsjö
Works fine, except that d3d11va doesn't build correctly until your patch for
forcing WINAPI_FAMILY to WINAPI_FAMILY_DESKTOP_APP is applied - I've used
--disable-d3d11va for the fate instances at
https://fate.libav.org/arm-msvc-11-winrt-gaspp/20150723095235 since a few
months since d3d11va was added - we discussed this on irc and you said you'd
look at the issue soon.
Improvements to configure to automatically figure out some of these
parameters to avoid having to set them manually are welcome of course.
And a D3D11VA configuration/setup example.
Post by Martin Storsjö
// Martin
_______________________________________________
libav-devel mailing list
https://lists.libav.org/mailman/listinfo/libav-devel
Hendrik Leppkes
2015-07-25 07:24:44 UTC
Permalink
Post by Steve Lhomme
https://github.com/robUx4/vlc/tree/wip/contrib/src/ffmpeg
I'll probably submit the near_field patch too which is just field
renaming because "near" is a reserved keyword in MSVC.
I build with MSVC every day, and it never seemed to complain about
this. Is this a ARM/Phone specific problem or something?

- Hendrik
Steve Lhomme
2015-07-26 08:08:52 UTC
Permalink
Post by Steve Lhomme
Post by Martin Storsjö
Post by Steve Lhomme
Post by Martin Storsjö
But what you _should_ have been doing all along would be to test your
patches without this wrapper.
What I submitted were necessary patches, they are not sufficient.
Probably not even now. But without them, it's guaranteed not to work.
Ok, but then _please_ say so in the patch description. It's quite
frustrating to try to understand how on earth the patches you send are
supposed to work, and to spend hours to try to figure this out.
Post by Steve Lhomme
Post by Martin Storsjö
I understand that you don't want to test your patches at actual runtime with
builds without this wrapper, since it probably is quite deeply tied in with
how the contribs are hooked up. But you could at the very least test to make
sure that your patches at least compile at all in a vanilla libav setup,
without your own custom cl wrapper that nobody else will use.
Post by Steve Lhomme
I'm just trying to avoid our local patches.
Sure - that is good, but please understand that the patches you submit must
work with normal vanilla libav builds, not only with a custom build env (and
break in normal builds).
Yes I understand.
Post by Martin Storsjö
Post by Steve Lhomme
I know the code is working and I have it working on a device and it's been
used on other devices too. The fact that it will work stand-alone in libav
is less guaranteed. The restrictions on the API calls mean some common calls
need to be re-routed and disabled. That's the kind of things we do in the
forced header.
So can you summarize what the state of D3D11VA is at the moment, with
vanilla libav builds? It works for WINAPI_FAMILY_DESKTOP_APP, but probably
won't work if targeting WINAPI_FAMILY_APP (or _PHONE_APP)?
Right now the current master doesn't build out of the box because of
the link.exe issue.
This is a minor inconvenience at best, which all other users of libav/ffmpeg
on msvc have managed to work around just fine based on the public
instructions.
Yes it's not perfect, but don't make it sound like it's an issue that allows
you to not care about how libav behaves without vlc's own wrapper.
I do care. The problem is that to build all the contribs we have tons
of tweaks to call configure. It is hard to know which have an
influence for just libav. The only thing I'm sure of is the patch
files we still need to keep in place where this tweaks are not enough.
https://github.com/robUx4/vlc/tree/wip/contrib/src/ffmpeg
I'll probably submit the near_field patch too which is just field
renaming because "near" is a reserved keyword in MSVC.
Up until yesterday I didn't have a reliable way to build VLC and its
contribs for WP8. So standalone libav may still a bit far off. I just
started working on it while I was doing one of the 1/2h VLC
compilations.
Post by Martin Storsjö
Post by Steve Lhomme
It also doesn't build with VS2015 RTM (sans VS2013 involved) because
of -FIstdlib.h which doesn't exist there (at least on my new
installation).
Eh, wtf? Somehow I don't think that VS2015 RTM lacks stdlib.h. FWIW, this
seems to work just fine, for both x86 and arm, with VS2015 RTM for me.
Strange, I did a repair and it's still not there. It is in VS2013
though. I'll see if that's an issue when I try to build everything
with just VS2015. For now a non-free VS2013 is the way to go or VS2015
RTM Community using the VS2013 shell.
I did a fresh install on a fresh install of Windows 10, just selecting
VC++ and he WP 8.1 development options in the installer of VS 2015
Community. It doesn't have stdlib.h in the Microsoft Visual Studio
14.0 include folder. It does exist in the in the Microsoft Visual
Studio 12.0 include folder.
Post by Steve Lhomme
Post by Martin Storsjö
Post by Steve Lhomme
With VS2015 RTM the 2013 arm toolchain it provides doesn't have
libcmt, which means -MD (and -MDd) have to be used. It is not the
default so should also be added to the extra cflags, or added in
configure (probably better, it should pick -MDd when used with
--enable-debug). I suppose they don't ship it to force the use of the
runtime DLL that's already provided on every phone.
Yes, you manually need to add -MD here. Ideally configure should maybe
detect that and add it automatically - currently it doesn't.
Is there a way with gcc to tell whether you want static or dynamic
runtime ? For Windows Phone it should always be dynamic anyway. That
can be deduced from the WINAPI_FAMILY selected.
Post by Martin Storsjö
Post by Steve Lhomme
cl -I. -I/c/Users/Steve/Documents/Program/lavcodec/libav
-D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-Dstrtod=avpriv_strtod -Dsnprintf=avpriv_snprintf
-D_snprintf=avpriv_snprintf -Dvsnprintf=avpriv_vsnprintf
-D_WIN32_WINNT=0x0502 -DHAVE_AV_CONFIG_H -nologo -D_USE_MATH_DEFINES
-D_CRT_SECURE_NO_WARNINGS -Dinline=__inline -FIstdlib.h
-Dstrtoll=_strtoi64 -DWINAPI_FAMILY=WINAPI_FAMILY_PHONE_APP -MD -mcpu=
-marm -Z7 -W4 -wd4244 -wd4127 -wd4018 -wd4389 -wd4146 -wd4057
-wd4204 -wd4706 -wd4305 -wd4152 -wd4324 -we4013 -wd4100 -wd4214
-wd4273 -wd4554 -wd4701 -O2 -c -Folibavformat/4xm.o
/c/Users/Steve/Documents/Program/lavcodec/libav/libavformat/4xm.c
cl : Command line warning D9002 : ignoring unknown option '-mcpu='
cl : Command line warning D9002 : ignoring unknown option '-marm'
4xm.c
C:\Program Files (x86)\Windows
Kits\8.1\include\um\processthreadsapi.h(412) : error C4013: 'FlsAlloc'
undefined; assuming extern returning int
C:\Program Files (x86)\Windows
'FlsGetValue' undefined; assuming extern returning int
C:\Program Files (x86)\Windows
Kits\8.1\include\um\processthreadsapi.h(423) : warning C4047: 'return'
: 'LPVOID' differs in levels of indirection from 'int'
C:\Program Files (x86)\Windows
'FlsSetValue' undefined; assuming extern returning int
C:\Program Files (x86)\Windows
Kits\8.1\include\um\processthreadsapi.h(446) : error C4013: 'FlsFree'
undefined; assuming extern returning int
C:\Program Files (x86)\Windows Kits\8.1\include\um\combaseapi.h(1157)
: error C4013: 'CoCreateInstanceFromApp' undefined; assuming extern
returning int
I haven't investigated further. One thing that is wrong in this
command-line is forcing _WIN32_WINNT=0x0502. It should only be done
for files where it's necessary, just like we force the WINAPI_FAMILY
to unhide specific things.
There's a reason for this being set (in general), there's this descriptive
# The MSVC 2010 headers (Win 7.0 SDK) set _WIN32_WINNT to
# 0x601 by default unless something else is set by the user.
# This can easily lead to us detecting functions only present
# in such new versions and producing binaries requiring windows 7.0.
# Therefore explicitly set the default to XP unless the user has
# set something else on the command line.
check_${pfx}cpp_condition stdlib.h "defined(_WIN32_WINNT)" ||
add_${pfx}cppflags -D_WIN32_WINNT=0x0502
Since the way configure checks for functions, and if they are found in the
SDK, they will be used, one would easily end up with binaries that only work
on the latest windows version, while for desktop most people want a few
versions backwards compatibility. So unless you've specificed _WIN32_WINNT
manually, we set it to this old version.
When targeting arm and/or winrt, you manually need to set this to a higher
version, like 0x0602. (Normally you'd only want to set this to a higher
value for specific parts, like for dxva/d3d11va, but for winrt/winphone,
setting it to 0x0602 is ok because code for winrt/winphone won't ever run on
an older windows version than this.)
All these parameters you need to set are covered in e.g.
https://wiki.libav.org/Platform/WindowsPhone. I just retested these
instructions with VS2015 RTM, and they work just fine. (The --disable-dxva2
might not be needed any longer, I'll recheck that and update the page
accordingly.)
From what I see `--disable-dxva2` can be removed it's correctly
detected as not available.
Post by Martin Storsjö
Works fine, except that d3d11va doesn't build correctly until your patch for
forcing WINAPI_FAMILY to WINAPI_FAMILY_DESKTOP_APP is applied - I've used
--disable-d3d11va for the fate instances at
https://fate.libav.org/arm-msvc-11-winrt-gaspp/20150723095235 since a few
months since d3d11va was added - we discussed this on irc and you said you'd
look at the issue soon.
Improvements to configure to automatically figure out some of these
parameters to avoid having to set them manually are welcome of course.
And a D3D11VA configuration/setup example.
Post by Martin Storsjö
// Martin
_______________________________________________
libav-devel mailing list
https://lists.libav.org/mailman/listinfo/libav-devel
Hendrik Leppkes
2015-07-26 08:17:23 UTC
Permalink
Post by Steve Lhomme
Post by Steve Lhomme
Post by Martin Storsjö
Post by Steve Lhomme
Post by Martin Storsjö
But what you _should_ have been doing all along would be to test your
patches without this wrapper.
What I submitted were necessary patches, they are not sufficient.
Probably not even now. But without them, it's guaranteed not to work.
Ok, but then _please_ say so in the patch description. It's quite
frustrating to try to understand how on earth the patches you send are
supposed to work, and to spend hours to try to figure this out.
Post by Steve Lhomme
Post by Martin Storsjö
I understand that you don't want to test your patches at actual runtime with
builds without this wrapper, since it probably is quite deeply tied in with
how the contribs are hooked up. But you could at the very least test to make
sure that your patches at least compile at all in a vanilla libav setup,
without your own custom cl wrapper that nobody else will use.
Post by Steve Lhomme
I'm just trying to avoid our local patches.
Sure - that is good, but please understand that the patches you submit must
work with normal vanilla libav builds, not only with a custom build env (and
break in normal builds).
Yes I understand.
Post by Martin Storsjö
Post by Steve Lhomme
I know the code is working and I have it working on a device and it's been
used on other devices too. The fact that it will work stand-alone in libav
is less guaranteed. The restrictions on the API calls mean some common calls
need to be re-routed and disabled. That's the kind of things we do in the
forced header.
So can you summarize what the state of D3D11VA is at the moment, with
vanilla libav builds? It works for WINAPI_FAMILY_DESKTOP_APP, but probably
won't work if targeting WINAPI_FAMILY_APP (or _PHONE_APP)?
Right now the current master doesn't build out of the box because of
the link.exe issue.
This is a minor inconvenience at best, which all other users of libav/ffmpeg
on msvc have managed to work around just fine based on the public
instructions.
Yes it's not perfect, but don't make it sound like it's an issue that allows
you to not care about how libav behaves without vlc's own wrapper.
I do care. The problem is that to build all the contribs we have tons
of tweaks to call configure. It is hard to know which have an
influence for just libav. The only thing I'm sure of is the patch
files we still need to keep in place where this tweaks are not enough.
https://github.com/robUx4/vlc/tree/wip/contrib/src/ffmpeg
I'll probably submit the near_field patch too which is just field
renaming because "near" is a reserved keyword in MSVC.
Up until yesterday I didn't have a reliable way to build VLC and its
contribs for WP8. So standalone libav may still a bit far off. I just
started working on it while I was doing one of the 1/2h VLC
compilations.
Post by Martin Storsjö
Post by Steve Lhomme
It also doesn't build with VS2015 RTM (sans VS2013 involved) because
of -FIstdlib.h which doesn't exist there (at least on my new
installation).
Eh, wtf? Somehow I don't think that VS2015 RTM lacks stdlib.h. FWIW, this
seems to work just fine, for both x86 and arm, with VS2015 RTM for me.
Strange, I did a repair and it's still not there. It is in VS2013
though. I'll see if that's an issue when I try to build everything
with just VS2015. For now a non-free VS2013 is the way to go or VS2015
RTM Community using the VS2013 shell.
I did a fresh install on a fresh install of Windows 10, just selecting
VC++ and he WP 8.1 development options in the installer of VS 2015
Community. It doesn't have stdlib.h in the Microsoft Visual Studio
14.0 include folder. It does exist in the in the Microsoft Visual
Studio 12.0 include folder.
Its in the Windows SDK folder.

- Hendrik
Steve Lhomme
2015-07-26 08:27:20 UTC
Permalink
Post by Hendrik Leppkes
Post by Steve Lhomme
Post by Steve Lhomme
Post by Martin Storsjö
Post by Steve Lhomme
Post by Martin Storsjö
But what you _should_ have been doing all along would be to test your
patches without this wrapper.
What I submitted were necessary patches, they are not sufficient.
Probably not even now. But without them, it's guaranteed not to work.
Ok, but then _please_ say so in the patch description. It's quite
frustrating to try to understand how on earth the patches you send are
supposed to work, and to spend hours to try to figure this out.
Post by Steve Lhomme
Post by Martin Storsjö
I understand that you don't want to test your patches at actual runtime with
builds without this wrapper, since it probably is quite deeply tied in with
how the contribs are hooked up. But you could at the very least test to make
sure that your patches at least compile at all in a vanilla libav setup,
without your own custom cl wrapper that nobody else will use.
Post by Steve Lhomme
I'm just trying to avoid our local patches.
Sure - that is good, but please understand that the patches you submit must
work with normal vanilla libav builds, not only with a custom build env (and
break in normal builds).
Yes I understand.
Post by Martin Storsjö
Post by Steve Lhomme
I know the code is working and I have it working on a device and it's been
used on other devices too. The fact that it will work stand-alone in libav
is less guaranteed. The restrictions on the API calls mean some common calls
need to be re-routed and disabled. That's the kind of things we do in the
forced header.
So can you summarize what the state of D3D11VA is at the moment, with
vanilla libav builds? It works for WINAPI_FAMILY_DESKTOP_APP, but probably
won't work if targeting WINAPI_FAMILY_APP (or _PHONE_APP)?
Right now the current master doesn't build out of the box because of
the link.exe issue.
This is a minor inconvenience at best, which all other users of libav/ffmpeg
on msvc have managed to work around just fine based on the public
instructions.
Yes it's not perfect, but don't make it sound like it's an issue that allows
you to not care about how libav behaves without vlc's own wrapper.
I do care. The problem is that to build all the contribs we have tons
of tweaks to call configure. It is hard to know which have an
influence for just libav. The only thing I'm sure of is the patch
files we still need to keep in place where this tweaks are not enough.
https://github.com/robUx4/vlc/tree/wip/contrib/src/ffmpeg
I'll probably submit the near_field patch too which is just field
renaming because "near" is a reserved keyword in MSVC.
Up until yesterday I didn't have a reliable way to build VLC and its
contribs for WP8. So standalone libav may still a bit far off. I just
started working on it while I was doing one of the 1/2h VLC
compilations.
Post by Martin Storsjö
Post by Steve Lhomme
It also doesn't build with VS2015 RTM (sans VS2013 involved) because
of -FIstdlib.h which doesn't exist there (at least on my new
installation).
Eh, wtf? Somehow I don't think that VS2015 RTM lacks stdlib.h. FWIW, this
seems to work just fine, for both x86 and arm, with VS2015 RTM for me.
Strange, I did a repair and it's still not there. It is in VS2013
though. I'll see if that's an issue when I try to build everything
with just VS2015. For now a non-free VS2013 is the way to go or VS2015
RTM Community using the VS2013 shell.
I did a fresh install on a fresh install of Windows 10, just selecting
VC++ and he WP 8.1 development options in the installer of VS 2015
Community. It doesn't have stdlib.h in the Microsoft Visual Studio
14.0 include folder. It does exist in the in the Microsoft Visual
Studio 12.0 include folder.
Its in the Windows SDK folder.
Ah yes. That's explains why it's not in the WP8(.1) SDK, as the
functions defined in stdlib.h are not available there. That's also a
reason why they moved it from the C runtime to the OS SDK.

Strangely they kept <cstdlib> in the same place...
Post by Hendrik Leppkes
- Hendrik
_______________________________________________
libav-devel mailing list
https://lists.libav.org/mailman/listinfo/libav-devel
Martin Storsjö
2015-07-26 08:35:13 UTC
Permalink
Post by Steve Lhomme
Post by Hendrik Leppkes
Its in the Windows SDK folder.
Ah yes. That's explains why it's not in the WP8(.1) SDK, as the
functions defined in stdlib.h are not available there. That's also a
reason why they moved it from the C runtime to the OS SDK.
Strangely they kept <cstdlib> in the same place...
Those (stdc++) are part of msvcp*.dll, which still aren't a system
component.

// Martin
Martin Storsjö
2015-07-26 08:34:03 UTC
Permalink
Post by Steve Lhomme
I did a fresh install on a fresh install of Windows 10, just selecting
VC++ and he WP 8.1 development options in the installer of VS 2015
Community. It doesn't have stdlib.h in the Microsoft Visual Studio
14.0 include folder. It does exist in the in the Microsoft Visual
Studio 12.0 include folder.
Yes, but it exists in the Windows 10 SDK in the ucrt directory. This is
due to how the CRT now is mostly defined in ucrtbase, which is considered
a Windows 10 system component.

Note how VS 2015 RTM didn't include the full Windows 10 SDK (yet), but the
CRT headers are under Windows 10. If you set up the environment using the
"command prompt" bat files, the include path is set up correctly, but if
you set it up manually (as I assume you're doing) you need to set up a
weird combo of Windows 8 and 10 SDKs in the include path.

// Martin
Steve Lhomme
2015-07-26 08:48:15 UTC
Permalink
Post by Steve Lhomme
I did a fresh install on a fresh install of Windows 10, just selecting
VC++ and he WP 8.1 development options in the installer of VS 2015
Community. It doesn't have stdlib.h in the Microsoft Visual Studio
14.0 include folder. It does exist in the in the Microsoft Visual
Studio 12.0 include folder.
Yes, but it exists in the Windows 10 SDK in the ucrt directory. This is due
to how the CRT now is mostly defined in ucrtbase, which is considered a
Windows 10 system component.
Note how VS 2015 RTM didn't include the full Windows 10 SDK (yet), but the
CRT headers are under Windows 10. If you set up the environment using the
"command prompt" bat files, the include path is set up correctly, but if you
set it up manually (as I assume you're doing) you need to set up a weird
combo of Windows 8 and 10 SDKs in the include path.
VS2015 RTM install the command prompt shortcuts for VS 2015 (with W10
SDK) and VS 2012, including one specific for phone development (not
found in 2015 out of the box), targeting WP8. There is nothing for
2013 targeting WP8.1, although the .bat files to call are there.

What a mess.
// Martin
_______________________________________________
libav-devel mailing list
https://lists.libav.org/mailman/listinfo/libav-devel
Martin Storsjö
2015-07-26 09:22:46 UTC
Permalink
Post by Steve Lhomme
Post by Steve Lhomme
I did a fresh install on a fresh install of Windows 10, just selecting
VC++ and he WP 8.1 development options in the installer of VS 2015
Community. It doesn't have stdlib.h in the Microsoft Visual Studio
14.0 include folder. It does exist in the in the Microsoft Visual
Studio 12.0 include folder.
Yes, but it exists in the Windows 10 SDK in the ucrt directory. This is due
to how the CRT now is mostly defined in ucrtbase, which is considered a
Windows 10 system component.
Note how VS 2015 RTM didn't include the full Windows 10 SDK (yet), but the
CRT headers are under Windows 10. If you set up the environment using the
"command prompt" bat files, the include path is set up correctly, but if you
set it up manually (as I assume you're doing) you need to set up a weird
combo of Windows 8 and 10 SDKs in the include path.
VS2015 RTM install the command prompt shortcuts for VS 2015 (with W10
SDK) and VS 2012, including one specific for phone development (not
found in 2015 out of the box), targeting WP8. There is nothing for
2013 targeting WP8.1, although the .bat files to call are there.
What a mess.
Indeed, setting up the env for WP8.1/MSVC2013 is a mess, with no
shortcuts (and I haven't seen any bat file that does it either).

// Martin
Steve Lhomme
2015-07-26 09:37:51 UTC
Permalink
Post by Steve Lhomme
Post by Steve Lhomme
I did a fresh install on a fresh install of Windows 10, just selecting
VC++ and he WP 8.1 development options in the installer of VS 2015
Community. It doesn't have stdlib.h in the Microsoft Visual Studio
14.0 include folder. It does exist in the in the Microsoft Visual
Studio 12.0 include folder.
Yes, but it exists in the Windows 10 SDK in the ucrt directory. This is due
to how the CRT now is mostly defined in ucrtbase, which is considered a
Windows 10 system component.
Note how VS 2015 RTM didn't include the full Windows 10 SDK (yet), but the
CRT headers are under Windows 10. If you set up the environment using the
"command prompt" bat files, the include path is set up correctly, but if you
set it up manually (as I assume you're doing) you need to set up a weird
combo of Windows 8 and 10 SDKs in the include path.
VS2015 RTM install the command prompt shortcuts for VS 2015 (with W10
SDK) and VS 2012, including one specific for phone development (not
found in 2015 out of the box), targeting WP8. There is nothing for
2013 targeting WP8.1, although the .bat files to call are there.
What a mess.
Indeed, setting up the env for WP8.1/MSVC2013 is a mess, with no shortcuts
(and I haven't seen any bat file that does it either).
If you need one:
https://github.com/robUx4/vlc-msvc/blob/vs15/scripts/setup-env.bat

It's borrowed from the VS2015 batch files that have a "store" option
to force linking with store versions of the .lib to avoid linking with
unavailable code (and use the right DLL entries on the phone).

I have yet to see if VS2015 has been clean of their bogus/weird batch
files though before switching to that.
// Martin
_______________________________________________
libav-devel mailing list
https://lists.libav.org/mailman/listinfo/libav-devel
Martin Storsjö
2015-07-24 05:44:19 UTC
Permalink
Post by Steve Lhomme
I know the code is working and I have it working on a device and it's
been used on other devices too. The fact that it will work stand-alone
in libav is less guaranteed. The restrictions on the API calls mean
some common calls need to be re-routed and disabled. That's the kind
of things we do in the forced header.
Even if you aren't submitting the forced header that you are using, it'd
be useful if you could list all the things that needs to be
rerouted/disabled for D3D11VA to be usable in a winphone app, so that
others would know where to start, if they'd need to do the same.

// Martin
Continue reading on narkive:
Loading...