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
<BtbN>
kasper93: also the reason why I avoided to use a lot of lavu functions is that mixed with C++ that can throw exceptions it's a rather annoying to make sure not to leak anything
<BtbN>
Kinda have to wrap everything in smart pointers
<kasper93>
using c from c++ shouldn't be an issue generally
<BtbN>
It's a lot of extra boilerplate, need to craft a smart pointer that calls the appropiate free function every single time
<BtbN>
Cause if a C++ memory allocation fails, it'll throw an exception, and be gone. If stuff is not in smart pointers then, it's leaked.
<JEEB>
and std::nothrow only helps with your code, not something in a library
<BtbN>
And I'm torn about using the lavu wchar to utf8 wrappers. Inlining them allows to avoid almost all memory allocations
<BtbN>
Using the lavu one would force me to wrap its output into a smart pointer as well
<Traneptora>
is this the only C++ module that would be using this code?
<BtbN>
kasper93: https://github.com/alvinhochun/mingw-w64-cppwinrt exists, but isn't the most actively maintained, and needs C++20 on top of it. It apparently also needs build system integration, calling an upstream generator .exe file to generate the bindings.
<BtbN>
So yeah, if we care about non-MSVC, which I do, cppwinrt isn't happening
<BtbN>
I don't think it's too big of a deal anyway. The runtime loading of functions neccesitates manual calling anyway, and it's really not a lot of winrt functions that are being called. I don't think it'd safe many lines of code, if any.
<BtbN>
And yes, the runtime loading is needed, cause otherwise FFmpeg built against this would not work on any but the latest Windows versions.
CoreX has joined #ffmpeg-devel
<BtbN>
People complained when I used SetThreadDpiAwarenessContext in ddagrab already, so it had to be runtime-loaded
<BtbN>
and that's a much older API compared to stuff like CreateDirect3D11DeviceFromDXGIDevice
<Traneptora>
BtbN: can you change that to struct ptherad_t { }; typedef struct pthread_t * pthread_t;
<Traneptora>
i.e. two statements
<BtbN>
I had just renamed the first ont
<BtbN>
works fine as well
<BtbN>
Pretty sure C++ will be unhappy about your approach as well
<BtbN>
cause then pthread_t is defined twice again
<BtbN>
once as struct, once as pointer
<BtbN>
It only works in C because the first type is "struct pthread_t", and not just pthread_t
<Traneptora>
ah, and in C++, "struct foo" is just an alias for "foo" once you define it?
<BtbN>
yeah, the whole "struct abc" is not a thing in C++
<Traneptora>
same with union and enum?
<BtbN>
yes
<BtbN>
you always define the type right away in C++
<Traneptora>
what if you do, e.g.: typedef struct { int bar; } pthread_t;
<Traneptora>
would that work
<BtbN>
I've just made it typedef struct w32pthread_t { ... } *pthread_t;
<Traneptora>
how do you do anonymous struct pointers then in C++?
<Traneptora>
e.g. struct foo; int bar(struct foo *baz); in a header file
<BtbN>
that works just fine
<Traneptora>
it's specifically the fact that "struct foo" and "foo" are aliased in C++, so there's a collision there that isn't in C?
<Traneptora>
we do this all over the codebase though, and in various header files
<BtbN>
I don't think they're aliased
<BtbN>
and no, we don't do that everywhere
<BtbN>
the problem is that it's a _pointer_ to the struct
<BtbN>
"typedef struct pthread_t { ... } pthread_t;" would be perfectly fine. "typedef struct pthread_t { ... } *pthread_t;" is not
<Traneptora>
... why does one create a collision and not the other one?
<BtbN>
Cause one just defines the type as the same thing twice, which is a normal thing to do
<BtbN>
and the later defines the same name as two different things in one line
<Traneptora>
is it cause in one case they're identical and in the other case, they're not?
<Traneptora>
ah okay
<Traneptora>
I see now
<Traneptora>
daily reminder that C++ is not a superset of C
<BtbN>
I have to say, writing C++ code is somewhat nicer than C, and it's much easier to write safe code
<BtbN>
As long as you don't try to use it like C, then it gets worse, cause exceptions can interrupt you anywhere, and if you then don't rely on RAII for your cleanup, you're boned.
<BtbN>
I still think C
<BtbN>
C++ would benefit from a try {} finally {}
GewoonLeon has joined #ffmpeg-devel
<fflogger>
[editedticket] SuRGeoNix: Ticket #10608 ([avcodec] AV1 decoder gets "Static surface pool size exceeded" issue with "-hwaccel d3d11va") updated https://trac.ffmpeg.org/ticket/10608#comment:1
<BtbN>
kasper93: we found what's actually going on with the messed up diffs. It seems to happen when you submit a review after the PR was force pushed, but your page having been loaded before the force-push
<BtbN>
or push in general
<BtbN>
Cause generally it DOES track where a comment was posted originally
<BtbN>
It saves an extract of the diff in the DB, and matches that against the new diff, and also shows that part on the PR overview
GewoonLeon has quit [Ping timeout: 256 seconds]
Meralex has quit [Quit: Meralex]
secondcreek has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
Kimapr has quit [Remote host closed the connection]
Kimapr has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]
jamrial has joined #ffmpeg-devel
<fjlogger>
[FFmpeg/FFmpeg] Pull request #20457 opened: WIP: Several improvements around early decoding latency and memory usage of unused inputs (https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20457) by haasn
MisterMinister has quit [Ping timeout: 255 seconds]