michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 8.0 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<kasper93>
BtbN: vsrc_gfxcapture.h is missing inlcudes
<kasper93>
error: unknown type name 'AVClass'
<kasper93>
error: unknown type name 'uint64_t'
<kasper93>
and so on
<BtbN>
Isn't it just missing in the skipheaders thing? It intentionally doesn't have any includes, since it's shared between C++ and C, which might need different ones
<BtbN>
so it relies on the correct stuff being included before it
<kasper93>
#20190 would catch it :)
<jamrial>
why not check for __cplusplus and include the right things?
<jamrial>
BtbN: in fact, you're including vsrc_gfxcapture.h within extern "C", so i guess you can safely include the needed headers in it
<kasper93>
unless our headers are failing with cpp, which may be the case for some
<BtbN>
I don't fully understand why the header needs to include anything. Isn't it fairly standard for such headers to depend on being included last?
<kasper93>
I think policy in ffmpeg is that headers should be self-contained and include things they use, instead of realying on include order later.
<BtbN>
Then I'll need to make this header C++ aware, and remove it from inside of the extern "C" block
<BtbN>
cause it needs to include different things depending on C vs. C++
<BtbN>
But isn't that what SKIPHEADERS is for?
<jamrial>
how so? it defines a few enums, a struct, and some function prototypes
<BtbN>
It uses stdint types
<BtbN>
which use a different header in C++
<kasper93>
you can safely include <stdint.h> in either c or c++
<BtbN>
the more fun thing will be the actual C++ header
<BtbN>
cause it'll be compiling that with a C compiler
<BtbN>
maybe it'll have to be renamed to hpp?
<kasper93>
if you indeed need c++ headers, this test won't work. Either you have .hpp like you said to compile it with c++ or just skip, if this is not compatible.
<BtbN>
I think gcc itself is cool with just consuming C++ with gcc
<jamrial>
checkheaders will ignore hpp headers i think
<BtbN>
Well, right now it's just .h
<BtbN>
but not sure how other compilers deal with C++ passed to the C compiler
<BtbN>
Yeah... ./libavfilter/vsrc_gfxcapture_winrt.h:26:1: error: unknown type name ‘namespace’
<jamrial>
that one should not be tested by checkheaders
<jamrial>
since it's a c++ header
<jamrial>
so add it to skipheaders or rename it to hpp
<kasper93>
+1
<BtbN>
checkheaders could also learn about .hpp
<BtbN>
Though probably not worth the effort for one singular file
<Lynne>
haasn: ping about adding the color temperature option in libplacebo
<Lynne>
does anyone with a windows machine happen to have or doesn't mind installing davinci resolve?
<Lynne>
the new version has prores raw support and I'd like to get a conformation what it outputs matches the apple decoder
<kasper93>
BtbN: can't you make sure to not pollute namespace with pthread?
<BtbN>
seemingly no, the C++ standard headers include pthread.h several layers deep
<kasper93>
which ones?
<BtbN>
But only sometimes? They don't for me. But they do on that fate instance
<jamrial>
they do for me using mingw-w64 package from msys2
<jamrial>
which i assume is the same as that instance
<BtbN>
it's coming from #include <mutex>
<BtbN>
Which makes some sense
<wbs>
libgcc/libstdc++ can be configured with either "posix threads" or "win32 threads". earlier, you'd only get working c++11 threads with posix threads, but since GCC 13 or so, the win32 threads configuration should be equally featureful
<BtbN>
I guess my local mingw must be in win32 mode then
<wbs>
potentially, or there are other aspects involved as well
<kasper93>
don't include <mutex> then?
<BtbN>
And not do locking?
<BtbN>
Mutexes are somewhat essential for this code
<kasper93>
use ffmpeg wrappers
<BtbN>
And NIH an entire set of C++ wrappers for them? I'd rather not.
<BtbN>
Using ffmpeg/pthread thread functions in C++ is a minefield, since almost every function call and memory allocation can throw an exception, and each such exception without a lock-guard that auto-frees is an instant deadlock
<BtbN>
So while using them is probably possibly, it would be extremely ugly and likely inflate the code with 100+ extra lines just to deal with exceptions left and right
<wbs>
a RAII wrapper for a mutex should be like <10 lines of code though?
<BtbN>
Plus one for the cond var, ...
<BtbN>
Properly dealing with the cond vars in C++ without proper predicates is also annoying
<wbs>
right, mutex+condvar makes it a bit more
<BtbN>
I just don't see any downsides to just using std::thread and not needing to invent anything extra
<BtbN>
It's Win32-only code. In the end it always ends up calling the same OS functions
<wbs>
in any case, it sounds like a reasonable thing to use both threads+sync primitives from the same vendor, be that compat/w32pthread.h or the C++ library
<BtbN>
I'd basically have to write an entire C++ compat layer for pthreads first, to use pthreads or our wrapper for them
<BtbN>
And I just don't see the point
<BtbN>
I'd be re-implementing std::thread, which already is sitting on top of pthreads, or win32 thread, depending on toolchain config
<kasper93>
I agree, I was commenting to use our wrapper to have consistent threading backend
<BtbN>
Yeah, it'd be nice to use it. But there's problems with doing it.
<BtbN>
And what other "threading backend" than Win32 OS threads even is there? It's not like Linux, where there could be multiple.
<BtbN>
So I really don't see the issue.
<kasper93>
yea
<BtbN>
Even on Linux... what else but pthreads is there?
<BtbN>
Manually spinning up threads with syscalls?
<kepstin>
iirc both the modern "nptl" threads on linux and the old linuxthreads stuff in the end work using the clone syscall - and both implemented (at least partially) the posix threading apis.
<kepstin>
that is admittedly just with glibc, although i'm pretty sure e.g. musl's threads are very similar.
<jamrial>
BtbN: can confirm it builds now
<BtbN>
With the PR I assume?
<jamrial>
yes
<BtbN>
The issue will only arrise if ffmpeg is configures opposite to the toolchain
<BtbN>
pthread-toolchain and pthreads in FFmpeg will compile
<BtbN>
but if they're opposite, no matter which direction, it'll fail
<mkver>
There is an "[vost#0:0/rawvideo @ 0x124e0d740] Error submitting a packet to the muxer: No space left on device" in the stderr output of that box's hevc-conformance-IPRED_C_Mitsubishi_3 test; other tests have similar.
<BtbN>
if CC==LD, and -lstdc++ is on the linker commandline, it'll remove it and link with CXX instead
<BtbN>
That fixes compatibility with other stdc++ like libc++
_whitelogger has joined #ffmpeg-devel
<BtbN>
it's only an issue if you mix threading APIs, so if someone wants to write C++ with pure pthread for some reason, it's still useful
<BtbN>
If you'd rather revert it, feel free. But the changes have zero impact on existing C code
<jamrial>
nah
<jamrial>
it's fine, it was just a suggestion
<BtbN>
also keep in mind that std::thread support on mingw is still relatively recent
<BtbN>
so if some other filter needs to use C++ but doesn't have the luxury of needing super up to date mingw anyway, it could be forced to use the pthread API