On 6/15/2021 5:18 AM, Michael Niedermayer wrote:
On Mon, Jun 14, 2021 at 02:50:32PM -0300, James Almer wrote:
On 6/14/2021 1:56 PM, Michael Niedermayer wrote:
On Fri, Jun 11, 2021 at 10:30:48PM +0200, Diederick Niehorster wrote:
Enabled discovering a DirectShow device's color range, space, primaries,
transfer characteristics and chroma location, if the device exposes that
information. Sets them in the stream's codecpars.
Signed-off-by: Diederick Niehorster <dcni...@gmail.com>
Co-authored-by: Valerii Zapodovnikov <val.zapod...@gmail.com>
Signed-off-by: Diederick Niehorster <dcni...@gmail.com>
---
libavdevice/dshow.c | 250 +++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 249 insertions(+), 1 deletion(-)
breaks build on mingw64
make
CC libavdevice/dshow.o
src/libavdevice/dshow.c: In function ‘dshow_get_device_media_types’:
src/libavdevice/dshow.c:415:23: warning: unused variable ‘ctx’
[-Wunused-variable]
struct dshow_ctx *ctx = avctx->priv_data;
^~~
src/libavdevice/dshow.c: In function ‘dshow_get_device_list’:
src/libavdevice/dshow.c:662:23: warning: unused variable ‘ctx’
[-Wunused-variable]
struct dshow_ctx *ctx = avctx->priv_data;
^~~
src/libavdevice/dshow.c: In function ‘dshow_cycle_formats’:
src/libavdevice/dshow.c:731:13: error: unknown type name ‘DXVA_ExtendedFormat’;
did you mean ‘DXVA2_ExtendedFormat’?
DXVA_ExtendedFormat *extended_format_info = NULL;
^~~~~~~~~~~~~~~~~~~
DXVA2_ExtendedFormat
src/libavdevice/dshow.c:744:41: error: ‘AMCONTROL_COLORINFO_PRESENT’ undeclared
(first use in this function)
if (v->dwControlFlags & AMCONTROL_COLORINFO_PRESENT)
^~~~~~~~~~~~~~~~~~~~~~~~~~~
$ grep -r AMCONTROL_COLORINFO_PRESENT /mingw64/x86_64-w64-mingw32/include/*
/mingw64/x86_64-w64-mingw32/include/dvdmedia.h:#define
AMCONTROL_COLORINFO_PRESENT 0x00000080
Can you see if you can update your mingw-w64 toolchain, or at least the
headers/crt? This is not the first time you get an error with new code.
Old mingw headers releases lacked a lot of API and are not representative of
what a sane toolchain is meant to have.
Assuming that ubuntu didnt fail to update its mingw installation on OS update
This is a standard installation for mingw64 from 18.04 LTS packages
That is unfortunate, but i guess not unexpected since mingw-w64 evolves
pretty fast and headers get new API with every release.
I think you are missing my point here as you are asking me to upgrade.
What would i achieve by upgrading ?
Getting a recent enough release of the headers + CRT. Old releases
lacked a lot of API, even stuff available in msvc for years. Even
nightly is way ahead of tagged releases.
Isnt that equivalent of not testing build with ubuntu 18 LTS anymore ?
Yes, but i was not aware you were using a distro package.
I think testing does make sense unless you belive theres something funky wrong
with my setup?
No, it's just three years old by now, but that's how LTS distros go, so...
And if you want to drop support for some specific versions of platforms,
question
would be which platforms would that affect and it would require a test in
configure not failure to build in a random source file. The later can be a pain
for novice users.
I guess a configure option to look for the API used by this patch would
be needed, making this new code optional.
Thanks
[...]
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
