| Message ID | 20220708225404.23748-1-timo@rothenpieler.org |
|---|---|
| Headers | show |
| Series | ddagrab source filter, lavfi.c wrapped_avframe and dependent changes | expand |
> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of > Timo Rothenpieler > Sent: Saturday, July 9, 2022 12:54 AM > To: ffmpeg-devel@ffmpeg.org > Cc: Timo Rothenpieler <timo@rothenpieler.org> > Subject: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, lavfi.c > wrapped_avframe and dependent changes > > Since a bunch small stuff has changed since the last time I sent > these > one by one, here's the whole collection again. > I intend to push the whole lot within the next 48h, so they all make 48h? If I'm not mistaken, the first submission was just two days ago: avutil/hwcontext_d3d11va: fix texture_infos writes on non-fixed-size pools I hadn't seen that one before: avutil/hwcontext_d3d11va: update hwctx flags from input texture Please give me some time to take a look. Thanks, sw
> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of > Soft Works > Sent: Saturday, July 9, 2022 1:46 AM > To: FFmpeg development discussions and patches <ffmpeg- > devel@ffmpeg.org> > Cc: Timo Rothenpieler <timo@rothenpieler.org> > Subject: Re: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, > lavfi.c wrapped_avframe and dependent changes > > > > > -----Original Message----- > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of > > Timo Rothenpieler > > Sent: Saturday, July 9, 2022 12:54 AM > > To: ffmpeg-devel@ffmpeg.org > > Cc: Timo Rothenpieler <timo@rothenpieler.org> > > Subject: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, > lavfi.c > > wrapped_avframe and dependent changes > > > > Since a bunch small stuff has changed since the last time I sent > > these > > one by one, here's the whole collection again. > > I intend to push the whole lot within the next 48h, so they all > make > > 48h? > > If I'm not mistaken, the first submission was just two days ago: > > avutil/hwcontext_d3d11va: fix texture_infos writes on non-fixed-size > pools > > I hadn't seen that one before: > > avutil/hwcontext_d3d11va: update hwctx flags from input texture > > > Please give me some time to take a look. Could you please also explain which situations this is supposed to fix? Thank you, sw
On 09.07.2022 01:46, Soft Works wrote: > > >> -----Original Message----- >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of >> Timo Rothenpieler >> Sent: Saturday, July 9, 2022 12:54 AM >> To: ffmpeg-devel@ffmpeg.org >> Cc: Timo Rothenpieler <timo@rothenpieler.org> >> Subject: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, lavfi.c >> wrapped_avframe and dependent changes >> >> Since a bunch small stuff has changed since the last time I sent >> these >> one by one, here's the whole collection again. >> I intend to push the whole lot within the next 48h, so they all make > > 48h? > > If I'm not mistaken, the first submission was just two days ago: Yeah, and then a release deadline came up. > avutil/hwcontext_d3d11va: fix texture_infos writes on non-fixed-size pools > > I hadn't seen that one before: > > avutil/hwcontext_d3d11va: update hwctx flags from input texture Those were already discussed on IRC, and are basically fixing up a mess that was made when adding QSV interop. Right now it just trashes the heap without those patches. Just look at all the stuff happening in the qsv hwcontext. It relies on all of those flags being correct, but only did the bare minimum to ensure that. So this is a bunch of missing bits and pieces to at least not make it crash and burn.
> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of > Timo Rothenpieler > Sent: Saturday, July 9, 2022 1:49 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, > lavfi.c wrapped_avframe and dependent changes > > On 09.07.2022 01:46, Soft Works wrote: > > > > > >> -----Original Message----- > >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of > >> Timo Rothenpieler > >> Sent: Saturday, July 9, 2022 12:54 AM > >> To: ffmpeg-devel@ffmpeg.org > >> Cc: Timo Rothenpieler <timo@rothenpieler.org> > >> Subject: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, > lavfi.c > >> wrapped_avframe and dependent changes > >> > >> Since a bunch small stuff has changed since the last time I sent > >> these > >> one by one, here's the whole collection again. > >> I intend to push the whole lot within the next 48h, so they all > make > > > > 48h? > > > > If I'm not mistaken, the first submission was just two days ago: > > Yeah, and then a release deadline came up. > > > avutil/hwcontext_d3d11va: fix texture_infos writes on non-fixed- > size pools > > > > I hadn't seen that one before: > > > > avutil/hwcontext_d3d11va: update hwctx flags from input texture > > Those were already discussed on IRC, and are basically fixing up a > mess > that was made when adding QSV interop. This was my code which I had done in 2019 and Intel had later adopted it. One Part of the 5% differences where the deviated from my implementation was -- guess what: Setting of those flags... > Right now it just trashes the heap without those patches. > > Just look at all the stuff happening in the qsv hwcontext. > It relies on all of those flags being correct, but only did the bare > minimum to ensure that. > So this is a bunch of missing bits and pieces to at least not make it > crash and burn. I can submit the missing bit of differences as a patch. I thought it was no longer needed. The requirements have also changed over MSDK versions. The 8bit file mapping that I've shown recently exists in fact because an earlier MSDK version was requesting such texture. Anyway, when something is causing trouble, then it should be fixed in hwcontext_qsv. Thanks, sw
On 09.07.2022 02:01, Soft Works wrote: > I can submit the missing bit of differences as a patch. I thought > it was no longer needed. The requirements have also changed over > MSDK versions. The 8bit file mapping that I've shown recently exists > in fact because an earlier MSDK version was requesting such texture. > > Anyway, when something is causing trouble, then it should be fixed > in hwcontext_qsv. Settings those flags correctly isn't at all a bad idea though, and not fixing any issue I actively experienced. Just an oversight I noticed while reading the code. Fixing the heap overflow is the major issue and can really only be done in the d3d11 hwcontext. Look at the texture_flags array. It only ever gets initialized to the size of the initial pool size. With a non-fixed-size pool, that grows over time, that obviously is an issue, and will trash whatever comes after the hwcontext on the heap whenever more frames are requested than initially allocated. With a initial size of 0, that is... immediately. An entire other issue this does not address at all, but which also does not cause any memory corruption at least: QSV can't properly deal with a non-fixed-size pool. What happens if more fresh frames are allocated after the qsv hwctx has been derived? From the looks of it, it iterates and maps all the textures only once at init.
> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of > Timo Rothenpieler > Sent: Saturday, July 9, 2022 2:15 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, > lavfi.c wrapped_avframe and dependent changes > > On 09.07.2022 02:01, Soft Works wrote: > > I can submit the missing bit of differences as a patch. I thought > > it was no longer needed. The requirements have also changed over > > MSDK versions. The 8bit file mapping that I've shown recently > exists > > in fact because an earlier MSDK version was requesting such > texture. > > > > Anyway, when something is causing trouble, then it should be fixed > > in hwcontext_qsv. > > Settings those flags correctly isn't at all a bad idea though, and > not > fixing any issue I actively experienced. Just an oversight I noticed > while reading the code. > > Fixing the heap overflow is the major issue and can really only be > done > in the d3d11 hwcontext. > Look at the texture_flags array. > It only ever gets initialized to the size of the initial pool size. > With a non-fixed-size pool, that grows over time, that obviously is > an > issue, and will trash whatever comes after the hwcontext on the heap > whenever more frames are requested than initially allocated. > With a initial size of 0, that is... immediately. > > > An entire other issue this does not address at all, but which also > does > not cause any memory corruption at least: > > QSV can't properly deal with a non-fixed-size pool. > What happens if more fresh frames are allocated after the qsv hwctx > has > been derived? > From the looks of it, it iterates and maps all the textures only > once > at init. There's an allocator pattern which filters are using, so when using non-array textures it might be possible to have bigger pools than textures allocated. But that's just a "might". Please give me one or two days to respond with a better and more comprehensive answer. Right now, I'm deeply drowned into something else ;-) Thanks, sw
On 09.07.2022 02:28, Soft Works wrote: > > >> -----Original Message----- >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of >> Timo Rothenpieler >> Sent: Saturday, July 9, 2022 2:15 AM >> To: ffmpeg-devel@ffmpeg.org >> Subject: Re: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, >> lavfi.c wrapped_avframe and dependent changes >> >> On 09.07.2022 02:01, Soft Works wrote: >>> I can submit the missing bit of differences as a patch. I thought >>> it was no longer needed. The requirements have also changed over >>> MSDK versions. The 8bit file mapping that I've shown recently >> exists >>> in fact because an earlier MSDK version was requesting such >> texture. >>> >>> Anyway, when something is causing trouble, then it should be fixed >>> in hwcontext_qsv. >> >> Settings those flags correctly isn't at all a bad idea though, and >> not >> fixing any issue I actively experienced. Just an oversight I noticed >> while reading the code. >> >> Fixing the heap overflow is the major issue and can really only be >> done >> in the d3d11 hwcontext. >> Look at the texture_flags array. >> It only ever gets initialized to the size of the initial pool size. >> With a non-fixed-size pool, that grows over time, that obviously is >> an >> issue, and will trash whatever comes after the hwcontext on the heap >> whenever more frames are requested than initially allocated. >> With a initial size of 0, that is... immediately. >> >> >> An entire other issue this does not address at all, but which also >> does >> not cause any memory corruption at least: >> >> QSV can't properly deal with a non-fixed-size pool. >> What happens if more fresh frames are allocated after the qsv hwctx >> has >> been derived? >> From the looks of it, it iterates and maps all the textures only >> once >> at init. > > There's an allocator pattern which filters are using, so when using > non-array textures it might be possible to have bigger pools than > textures allocated. But that's just a "might". > Please give me one or two days to respond with a better and more > comprehensive answer. Right now, I'm deeply drowned into something > else ;-) That issue is entirely unrelated to the ddagrab filter. All it needs is the heap overflow fixed, since it very much does run into that. The other stuff are just follow ups I found while skimming through that code. So if you want more time to look into those, that's no big deal at all from my end. And the fix for the heap overflow is as straight forward as it gets.
Seems like the release was missed, and the heap overflow is still unfixed. In any case, I plan to push this within the next couple days if no objections are raised. The changes in the d3d11 hwcontext are minimal and otherwise entirely unrelated to the QSV hwcontext (if at all, it makes the situation with them slightly better by pure coincidence). Plus, they fix a very real heap overflow.
On 2022-07-14 07:21 pm, Timo Rothenpieler wrote: > Seems like the release was missed, and the heap overflow is still > unfixed. The release hasn't been tagged yet. > > In any case, I plan to push this within the next couple days if no > objections are raised. > > The changes in the d3d11 hwcontext are minimal and otherwise entirely > unrelated to the QSV hwcontext (if at all, it makes the situation with > them slightly better by pure coincidence). > Plus, they fix a very real heap overflow. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On 14/07/2022 15:56, Gyan Doshi wrote: > > > On 2022-07-14 07:21 pm, Timo Rothenpieler wrote: >> Seems like the release was missed, and the heap overflow is still >> unfixed. > > The release hasn't been tagged yet. > It's been branched though, and this isn't a patchset I'd feel comfortable porting to a release branch, however recent it may be. Given the lavfi.c change, it might also be for the better not to merge this immediately before a release anyway. Who knows what kind of unexpected side effects it might have in some edge cases. So probably for the better this way.
On 09.07.2022 00:53, Timo Rothenpieler wrote: > Since a bunch small stuff has changed since the last time I sent these > one by one, here's the whole collection again. > I intend to push the whole lot within the next 48h, so they all make it > in before 5.1 gets branched. > > Timo Rothenpieler (8): > fftools/ffmpeg: make debug_ts print raw filter output > avutil/hwcontext_d3d11va: fix mixed declaration and code > avutil/hwcontext_d3d11va: fix texture_infos writes on non-fixed-size > pools > avutil/hwcontext_d3d11va: update hwctx flags from input texture > avutil/hwcontext_d3d11va: add BGRA/RGBA10 formats support > avdevice/lavfi: output wrapped AVFrames > avdevice/lavfi: pass forward video framerate > avfilter: add vsrc_ddagrab I will push this series tonight, in about 8 hours from now. Last chance to delay this by reviewing or raising related concerns.
On Sun, 17 Jul 2022 at 12:37, Timo Rothenpieler <timo@rothenpieler.org> wrote: > > I will push this series tonight, in about 8 hours from now. > Last chance to delay this by reviewing or raising related concerns. Just FYI - this broke my nightly automated builds - which cross-compile on Linux for Windows. x86_64-w64-mingw32-gcc -I. -I./ --static -static -static-libstdc++ -static-libgcc -DPTW32_STATIC_LIB -D_WIN32_WINNT=0x0600 -I/opt/ffbuild/include -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1 -D__printf__=__gnu_printf__ -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -DOPJ_STATIC -DZLIB_CONST -DHAVE_AV_CONFIG_H -DBUILDING_avfilter --static -static -static-libstdc++ -static-libgcc -DPTW32_STATIC_LIB -D_WIN32_WINNT=0x0600 -I/opt/ffbuild/include --static -static -static-libstdc++ -static-libgcc -DPTW32_STATIC_LIB -D_WIN32_WINNT=0x0600 -std=c11 -fomit-frame-pointer -pthread -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include/freetype2 -I/opt/ffbuild/include -I/opt/ffbuild/include/libpng14 -I/opt/ffbuild/include/openjpeg-2.4 -I/opt/ffbuild/include/opus -I/opt/ffbuild/include/opus -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include/srt -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include -DLIBXML_STATIC -I/opt/ffbuild/include/libxml2 -I/opt/ffbuild/include -g -Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -Wstrict-prototypes -Wempty-body -Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign -Wno-unused-const-variable -Wno-bool-operation -Wno-char-subscripts -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=format-security -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -Werror=vla -Wformat -fdiagnostics-color=auto -Wno-maybe-uninitialized -MMD -MF libavfilter/vsrc_ddagrab.d -MT libavfilter/vsrc_ddagrab.o -c -o libavfilter/vsrc_ddagrab.o libavfilter/vsrc_ddagrab.c libavfilter/vsrc_ddagrab.c: In function 'init_dxgi_dda': libavfilter/vsrc_ddagrab.c:157:36: error: expected declaration specifiers or '...' before '*' token 157 | typedef DPI_AWARENESS_CONTEXT (*set_thread_dpi_t)(DPI_AWARENESS_CONTEXT); | ^ libavfilter/vsrc_ddagrab.c:158:5: error: unknown type name 'set_thread_dpi_t' 158 | set_thread_dpi_t set_thread_dpi; | ^~~~~~~~~~~~~~~~ libavfilter/vsrc_ddagrab.c:200:23: error: 'set_thread_dpi_t' undeclared (first use in this function); did you mean 'set_thread_dpi'? 200 | set_thread_dpi = (set_thread_dpi_t)dlsym(user32_module, "SetThreadDpiAwarenessContext"); | ^~~~~~~~~~~~~~~~ | set_thread_dpi libavfilter/vsrc_ddagrab.c:200:23: note: each undeclared identifier is reported only once for each function it appears in libavfilter/vsrc_ddagrab.c:200:40: error: expected ';' before 'GetProcAddress' 200 | set_thread_dpi = (set_thread_dpi_t)dlsym(user32_module, "SetThreadDpiAwarenessContext"); | ^ | ; libavfilter/vsrc_ddagrab.c:206:9: error: unknown type name 'DPI_AWARENESS_CONTEXT' 206 | DPI_AWARENESS_CONTEXT prev_dpi_ctx; | ^~~~~~~~~~~~~~~~~~~~~ libavfilter/vsrc_ddagrab.c:215:39: error: 'DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2' undeclared (first use in this function) 215 | prev_dpi_ctx = set_thread_dpi(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libavfilter/vsrc_ddagrab.c:215:24: error: called object 'set_thread_dpi' is not a function or function pointer 215 | prev_dpi_ctx = set_thread_dpi(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2); | ^~~~~~~~~~~~~~ libavfilter/vsrc_ddagrab.c:158:22: note: declared here 158 | set_thread_dpi_t set_thread_dpi; | ^~~~~~~~~~~~~~ libavfilter/vsrc_ddagrab.c:229:13: error: called object 'set_thread_dpi' is not a function or function pointer 229 | set_thread_dpi(prev_dpi_ctx); | ^~~~~~~~~~~~~~ libavfilter/vsrc_ddagrab.c:158:22: note: declared here 158 | set_thread_dpi_t set_thread_dpi; | ^~~~~~~~~~~~~~ [0m [91mlibavfilter/vsrc_ddagrab.c:233:24: warning: assignment to 'int' from 'void *' makes integer from pointer without a cast [-Wint-conversion] 233 | set_thread_dpi = NULL; | ^ libavfilter/vsrc_ddagrab.c:239:24: warning: assignment to 'int' from 'void *' makes integer from pointer without a cast [-Wint-conversion] 239 | set_thread_dpi = NULL; | ^ make: *** [ffbuild/common.mak:81: libavfilter/vsrc_ddagrab.o] Error 1
On 19.07.2022 09:25, Mark Himsley wrote: > On Sun, 17 Jul 2022 at 12:37, Timo Rothenpieler <timo@rothenpieler.org> wrote: >> >> I will push this series tonight, in about 8 hours from now. >> Last chance to delay this by reviewing or raising related concerns. > > Just FYI - this broke my nightly automated builds - which > cross-compile on Linux for Windows. > > x86_64-w64-mingw32-gcc -I. -I./ --static -static -static-libstdc++ > -static-libgcc -DPTW32_STATIC_LIB -D_WIN32_WINNT=0x0600 > -I/opt/ffbuild/include -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 > -D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1 > -D__printf__=__gnu_printf__ -D_POSIX_C_SOURCE=200112 > -D_XOPEN_SOURCE=600 -DPIC -DOPJ_STATIC -DZLIB_CONST -DHAVE_AV_CONFIG_H > -DBUILDING_avfilter --static -static -static-libstdc++ -static-libgcc > -DPTW32_STATIC_LIB -D_WIN32_WINNT=0x0600 -I/opt/ffbuild/include > --static -static -static-libstdc++ -static-libgcc -DPTW32_STATIC_LIB > -D_WIN32_WINNT=0x0600 -std=c11 -fomit-frame-pointer -pthread > -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include > -I/opt/ffbuild/include/freetype2 -I/opt/ffbuild/include > -I/opt/ffbuild/include/libpng14 -I/opt/ffbuild/include/openjpeg-2.4 > -I/opt/ffbuild/include/opus -I/opt/ffbuild/include/opus > -I/opt/ffbuild/include -I/opt/ffbuild/include > -I/opt/ffbuild/include/srt -I/opt/ffbuild/include > -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include > -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include > -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include > -DLIBXML_STATIC -I/opt/ffbuild/include/libxml2 -I/opt/ffbuild/include > -g -Wdeclaration-after-statement -Wall -Wdisabled-optimization > -Wpointer-arith -Wredundant-decls -Wwrite-strings -Wtype-limits > -Wundef -Wmissing-prototypes -Wstrict-prototypes -Wempty-body > -Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign > -Wno-unused-const-variable -Wno-bool-operation -Wno-char-subscripts > -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize > -Werror=format-security -Werror=implicit-function-declaration > -Werror=missing-prototypes -Werror=return-type -Werror=vla -Wformat > -fdiagnostics-color=auto -Wno-maybe-uninitialized -MMD -MF > libavfilter/vsrc_ddagrab.d -MT libavfilter/vsrc_ddagrab.o -c -o > libavfilter/vsrc_ddagrab.o libavfilter/vsrc_ddagrab.c > libavfilter/vsrc_ddagrab.c: In function 'init_dxgi_dda': > libavfilter/vsrc_ddagrab.c:157:36: error: expected declaration > specifiers or '...' before '*' token > 157 | typedef DPI_AWARENESS_CONTEXT > (*set_thread_dpi_t)(DPI_AWARENESS_CONTEXT); > | ^ > I'm honestly not sure what this is complaining about. Does it not know the DPI_AWARENESS_CONTEXT enum? Does it not know how tp typedef within a function body?
On 19.07.2022 13:34, Timo Rothenpieler wrote: > On 19.07.2022 09:25, Mark Himsley wrote: >> On Sun, 17 Jul 2022 at 12:37, Timo Rothenpieler >> <timo@rothenpieler.org> wrote: >>> >>> I will push this series tonight, in about 8 hours from now. >>> Last chance to delay this by reviewing or raising related concerns. >> >> Just FYI - this broke my nightly automated builds - which >> cross-compile on Linux for Windows. >> >> x86_64-w64-mingw32-gcc -I. -I./ --static -static -static-libstdc++ >> -static-libgcc -DPTW32_STATIC_LIB -D_WIN32_WINNT=0x0600 >> -I/opt/ffbuild/include -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 >> -D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1 >> -D__printf__=__gnu_printf__ -D_POSIX_C_SOURCE=200112 >> -D_XOPEN_SOURCE=600 -DPIC -DOPJ_STATIC -DZLIB_CONST -DHAVE_AV_CONFIG_H >> -DBUILDING_avfilter --static -static -static-libstdc++ -static-libgcc >> -DPTW32_STATIC_LIB -D_WIN32_WINNT=0x0600 -I/opt/ffbuild/include >> --static -static -static-libstdc++ -static-libgcc -DPTW32_STATIC_LIB >> -D_WIN32_WINNT=0x0600 -std=c11 -fomit-frame-pointer -pthread >> -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include >> -I/opt/ffbuild/include/freetype2 -I/opt/ffbuild/include >> -I/opt/ffbuild/include/libpng14 -I/opt/ffbuild/include/openjpeg-2.4 >> -I/opt/ffbuild/include/opus -I/opt/ffbuild/include/opus >> -I/opt/ffbuild/include -I/opt/ffbuild/include >> -I/opt/ffbuild/include/srt -I/opt/ffbuild/include >> -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include >> -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include >> -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include >> -DLIBXML_STATIC -I/opt/ffbuild/include/libxml2 -I/opt/ffbuild/include >> -g -Wdeclaration-after-statement -Wall -Wdisabled-optimization >> -Wpointer-arith -Wredundant-decls -Wwrite-strings -Wtype-limits >> -Wundef -Wmissing-prototypes -Wstrict-prototypes -Wempty-body >> -Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign >> -Wno-unused-const-variable -Wno-bool-operation -Wno-char-subscripts >> -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize >> -Werror=format-security -Werror=implicit-function-declaration >> -Werror=missing-prototypes -Werror=return-type -Werror=vla -Wformat >> -fdiagnostics-color=auto -Wno-maybe-uninitialized -MMD -MF >> libavfilter/vsrc_ddagrab.d -MT libavfilter/vsrc_ddagrab.o -c -o >> libavfilter/vsrc_ddagrab.o libavfilter/vsrc_ddagrab.c >> libavfilter/vsrc_ddagrab.c: In function 'init_dxgi_dda': >> libavfilter/vsrc_ddagrab.c:157:36: error: expected declaration >> specifiers or '...' before '*' token >> 157 | typedef DPI_AWARENESS_CONTEXT >> (*set_thread_dpi_t)(DPI_AWARENESS_CONTEXT); >> | ^ >> > > I'm honestly not sure what this is complaining about. > Does it not know the DPI_AWARENESS_CONTEXT enum? I added an explicit configure check for that type. Definitely odd, IDXGIOutput5 and it are both Windows 10 APIs, so I'd have expected them to always exist in tandem. You might want to update or repair your weird Windows SDK.
On Tue, 19 Jul 2022 at 12:34, Timo Rothenpieler <timo@rothenpieler.org> wrote: > > I'm honestly not sure what this is complaining about. Sorry: Maybe the my copy/paste was less than east to read? Maybe because mu copy/paste was from a make -j6 in Docker run from Jenkins? Maybe the problem is cross-compiling with MinGW? > Does it not know the DPI_AWARENESS_CONTEXT enum? > Does it not know how tp typedef within a function body? I don't think I can answer that. I'm building in a Docker container based on an Ubuntu 20.04 image. This was my configure: ./configure --extra-version=static_win_x86_64_202207191248 --extra-cflags=--static -static -static-libstdc++ -static-libgcc -DPTW32_STATIC_LIB -D_WIN32_WINNT=0x0600 --extra-libs=-static -lpthread -lm --pkg-config-flags=--static --cross-prefix=x86_64-w64-mingw32- --arch=x86_64 --target-os=mingw32 --prefix=/opt/ffbuild --enable-gpl --enable-version3 --enable-nonfree --disable-ffplay --disable-dxva2 --disable-w32threads --enable-libzimg --enable-libxml2 --enable-openssl --enable-libfreetype --enable-libsrt --enable-libmp3lame --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libopus --enable-libxvid --enable-libvpx --enable-libfdk-aac --enable-libopenjpeg --enable-libaom --enable-libx264 --enable-libx265 This was the last attempted compile and the failure again: x86_64-w64-mingw32-gcc -I. -I./ --static -static -static-libstdc++ -static-libgcc -DPTW32_STATIC_LIB -D_WIN32_WINNT=0x0600 -I/opt/ffbuild/include -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1 -D__printf__=__gnu_printf__ -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -DOPJ_STATIC -DZLIB_CONST -DHAVE_AV_CONFIG_H -DBUILDING_avfilter --static -static -static-libstdc++ -static-libgcc -DPTW32_STATIC_LIB -D_WIN32_WINNT=0x0600 -I/opt/ffbuild/include --static -static -static-libstdc++ -static-libgcc -DPTW32_STATIC_LIB -D_WIN32_WINNT=0x0600 -std=c11 -fomit-frame-pointer -pthread -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include/freetype2 -I/opt/ffbuild/include -I/opt/ffbuild/include/libpng14 -I/opt/ffbuild/include/openjpeg-2.4 -I/opt/ffbuild/include/opus -I/opt/ffbuild/include/opus -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include/srt -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include -I/opt/ffbuild/include -DLIBXML_STATIC -I/opt/ffbuild/include/libxml2 -I/opt/ffbuild/include -g -Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -Wstrict-prototypes -Wempty-body -Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign -Wno-unused-const-variable -Wno-bool-operation -Wno-char-subscripts -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=format-security -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -Werror=vla -Wformat -fdiagnostics-color=auto -Wno-maybe-uninitialized -MMD -MF libavfilter/vsrc_ddagrab.d -MT libavfilter/vsrc_ddagrab.o -c -o libavfilter/vsrc_ddagrab.o libavfilter/vsrc_ddagrab.c libavfilter/vsrc_ddagrab.c: In function 'init_dxgi_dda': libavfilter/vsrc_ddagrab.c:157:36: error: expected declaration specifiers or '...' before '*' token 157 | typedef DPI_AWARENESS_CONTEXT (*set_thread_dpi_t)(DPI_AWARENESS_CONTEXT); | ^ libavfilter/vsrc_ddagrab.c:158:5: error: unknown type name 'set_thread_dpi_t' 158 | set_thread_dpi_t set_thread_dpi; | ^~~~~~~~~~~~~~~~ libavfilter/vsrc_ddagrab.c:200:23: error: 'set_thread_dpi_t' undeclared (first use in this function); did you mean 'set_thread_dpi'? 200 | set_thread_dpi = (set_thread_dpi_t)dlsym(user32_module, "SetThreadDpiAwarenessContext"); | ^~~~~~~~~~~~~~~~ | set_thread_dpi libavfilter/vsrc_ddagrab.c:200:23: note: each undeclared identifier is reported only once for each function it appears in libavfilter/vsrc_ddagrab.c:200:40: error: expected ';' before 'GetProcAddress' 200 | set_thread_dpi = (set_thread_dpi_t)dlsym(user32_module, "SetThreadDpiAwarenessContext"); | ^ | ; libavfilter/vsrc_ddagrab.c:206:9: error: unknown type name 'DPI_AWARENESS_CONTEXT' 206 | DPI_AWARENESS_CONTEXT prev_dpi_ctx; | ^~~~~~~~~~~~~~~~~~~~~ libavfilter/vsrc_ddagrab.c:215:39: error: 'DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2' undeclared (first use in this function) 215 | prev_dpi_ctx = set_thread_dpi(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libavfilter/vsrc_ddagrab.c:215:24: error: called object 'set_thread_dpi' is not a function or function pointer 215 | prev_dpi_ctx = set_thread_dpi(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2); | ^~~~~~~~~~~~~~ libavfilter/vsrc_ddagrab.c:158:22: note: declared here 158 | set_thread_dpi_t set_thread_dpi; | ^~~~~~~~~~~~~~ libavfilter/vsrc_ddagrab.c:229:13: error: called object 'set_thread_dpi' is not a function or function pointer 229 | set_thread_dpi(prev_dpi_ctx); | ^~~~~~~~~~~~~~ libavfilter/vsrc_ddagrab.c:158:22: note: declared here 158 | set_thread_dpi_t set_thread_dpi; | ^~~~~~~~~~~~~~ libavfilter/vsrc_ddagrab.c:233:24: warning: assignment to 'int' from 'void *' makes integer from pointer without a cast [-Wint-conversion] 233 | set_thread_dpi = NULL; | ^ libavfilter/vsrc_ddagrab.c:239:24: warning: assignment to 'int' from 'void *' makes integer from pointer without a cast [-Wint-conversion] 239 | set_thread_dpi = NULL; | ^ make: *** [ffbuild/common.mak:81: libavfilter/vsrc_ddagrab.o] Error 1 I had hoped that if I included `--disable-indev=gdigrab` in my ./configure then I could get around this problem, but it seems not - the build continues to fail at the same place.
On Tue, 19 Jul 2022 at 13:20, Timo Rothenpieler <timo@rothenpieler.org> wrote: > I added an explicit configure check for that type. > Definitely odd, IDXGIOutput5 and it are both Windows 10 APIs, so I'd > have expected them to always exist in tandem. Thank you - that fixed the build for me. > You might want to update or repair your weird Windows SDK. I thought x86_64-w64-mingw32 was quite standard. Anyway - thanks :-)
On 20/07/2022 10:21, Mark Himsley wrote: > On Tue, 19 Jul 2022 at 13:20, Timo Rothenpieler <timo@rothenpieler.org> wrote: > >> I added an explicit configure check for that type. >> Definitely odd, IDXGIOutput5 and it are both Windows 10 APIs, so I'd >> have expected them to always exist in tandem. > > Thank you - that fixed the build for me. > >> You might want to update or repair your weird Windows SDK. > > I thought x86_64-w64-mingw32 was quite standard. You must have some rather old or odd version of it. I've tested this patch with both the very latest self built version from git and with the one bundled in Ubuntu 22.04. (And with MSVC). It worked in all of them. Keep in mind that the Windows SDK used and the compiler toolchain are only loosely related, and can be mixed in various ways. In any case, with the latest patch, this should hopefully work on all SDK versions (or not be compiled at all if support is missing) and not break backwards compat of the binary.
Since a bunch small stuff has changed since the last time I sent these one by one, here's the whole collection again. I intend to push the whole lot within the next 48h, so they all make it in before 5.1 gets branched. Timo Rothenpieler (8): fftools/ffmpeg: make debug_ts print raw filter output avutil/hwcontext_d3d11va: fix mixed declaration and code avutil/hwcontext_d3d11va: fix texture_infos writes on non-fixed-size pools avutil/hwcontext_d3d11va: update hwctx flags from input texture avutil/hwcontext_d3d11va: add BGRA/RGBA10 formats support avdevice/lavfi: output wrapped AVFrames avdevice/lavfi: pass forward video framerate avfilter: add vsrc_ddagrab Changelog | 1 + configure | 7 + doc/filters.texi | 68 ++ fftools/ffmpeg.c | 12 +- libavdevice/lavfi.c | 94 +-- libavdevice/version.h | 2 +- libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/version.h | 2 +- libavfilter/vsrc_ddagrab.c | 980 ++++++++++++++++++++++ libavfilter/vsrc_ddagrab_shaders.h | 120 +++ libavutil/hwcontext_d3d11va.c | 22 +- tests/ref/fate/filter-metadata-cropdetect | 3 +- 13 files changed, 1252 insertions(+), 61 deletions(-) create mode 100644 libavfilter/vsrc_ddagrab.c create mode 100644 libavfilter/vsrc_ddagrab_shaders.h