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: it crashes in msys shell consistently, probably because it sets SEM_NOGPFAULTERRORBOX | SEM_FAILCRITICALERRORS and this changes deinint
<kasper93>
though app verifier catches issues in all cases
<BtbN>
Well, if the 32 bit library is broken, it'd be Microsoft.
<BtbN>
But then it wouldn't work with clang
<BtbN>
So maybe the gcc 32 bit build uses some old mingw version and they have a bug. Will need to try and make a 32 bit build myself tomorrow
<BtbN>
What sets that where? If the Winrt stuff does that on its own, I'm not sure what to do about it.
Kimapr has quit [Remote host closed the connection]
wyatt8740 has quit [Ping timeout: 260 seconds]
<kasper93>
msys shell requests error reporting to parent process to catch error signals
<kasper93>
and dts is spammed on ever other frame it looks like
<kasper93>
dts errors*
witchymary has joined #ffmpeg-devel
<BtbN>
The filter only outputs pts to begin with.
<BtbN>
I have so far never seen doubled up timestamps, and I logged them a lot
<kasper93>
try `-f null -` it spams a lot
<BtbN>
Does that maybe convert to a bad timebase?
<BtbN>
I've only seen the usual frame was late spam in higher log levels. But never non monotonous pts
Kimapr_ has quit [Remote host closed the connection]
GewoonLeon has quit [Read error: Connection reset by peer]
GewoonLeon has joined #ffmpeg-devel
av500 has joined #ffmpeg-devel
kasper93 has quit [Ping timeout: 245 seconds]
av500 has quit [Client Quit]
av500 has joined #ffmpeg-devel
av500 has quit [Quit: Konversation terminated!]
av500 has joined #ffmpeg-devel
<JEEB>
ok, so it was not something as dumb as missing freeing the packet list on the root level. time to check now if it' ssomething dumb on the layer where I added another queue
av500 has quit [Quit: Konversation terminated!]
<JEEB>
OK, pretty sure that wa sit
av500 has joined #ffmpeg-devel
av500 has quit [Client Quit]
av500 has joined #ffmpeg-devel
GewoonLeon1 has joined #ffmpeg-devel
GewoonLeon has quit [Ping timeout: 260 seconds]
GewoonLeon1 is now known as GewoonLeon
<JEEB>
ok, it was not as simple as just missing a avpriv_packet_list_free
<JEEB>
will have to soon start moving towards a travel location where I will have an hour or so to debug until I will be moving fast for 13 and a half hours :)
av500 has joined #ffmpeg-devel
av500 has quit [Client Quit]
desmond-netint has quit [Remote host closed the connection]
av500 has joined #ffmpeg-devel
av500 has quit [Quit: Konversation terminated!]
av500 has joined #ffmpeg-devel
wbs_ is now known as wbs
<haasn>
Lynne: p010le is not renderable on nvidia?
<haasn>
R10X6 has only transfer_dst, no renderable/storable
<haasn>
ditto for the planar variants
<haasn>
so what are we supposed to do, render to r16_unorm and vkCmdCopyImage?
<haasn>
it doesn't even have BLIT_DST
<haasn>
and vkCmdCopy* does not allow format change
<haasn>
so they want us to, what, copy via CPU?
<haasn>
alias to a texel storage buffer and use a compute shader to downshift?
<haasn>
(or more likely, just alias storage to an R16_UNORM buffer and render to it as normal)
GewoonLeon has quit [Read error: Connection reset by peer]
GewoonLeon1 has joined #ffmpeg-devel
av500 has quit [Quit: Konversation terminated!]
av500 has joined #ffmpeg-devel
GewoonLeon1 is now known as GewoonLeon
GewoonLeon1 has joined #ffmpeg-devel
APic has quit [Ping timeout: 248 seconds]
GewoonLeon has quit [Ping timeout: 260 seconds]
GewoonLeon1 is now known as GewoonLeon
EPic_ has joined #ffmpeg-devel
av500 has quit [Quit: Konversation terminated!]
av500 has joined #ffmpeg-devel
APic has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
EPic_ has quit [*.net *.split]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
<haasn>
seems like we can just alias to r16_unorm since the images are created mutable
GewoonLeon has quit [Read error: Connection reset by peer]
GewoonLeon1 has joined #ffmpeg-devel
Guest71 has joined #ffmpeg-devel
<kasper93>
BtbN: it looks like async shutdown job is not joined correctly
<kasper93>
graphicscapture.dll!00007FFDCDA73233: LogHr(1) tid(5ecc) 800704C7 The operation was canceled by the user.
<kasper93>
thread is canceled
<kasper93>
which leads to memory leaks and sometimes crash
GewoonLeon1 has quit [Ping timeout: 260 seconds]
<BtbN>
I'm joining it as hard as I can though. That something weird is going on on shutdown is clear, given the need to dlopen the graphics capture dll
<ePirat>
JEEB, jamrial, did some more testing, seems to be an issue with h265 in mp4/mov
<JEEB>
yea, try -tag:v hvc1
<JEEB>
FFmpeg defaults to hev1
rossy has quit [Ping timeout: 244 seconds]
rossy has joined #ffmpeg-devel
<ePirat>
JEEB, indeed that makes it work
<ePirat>
JEEB, was that always needed?
<another|>
AFAIK, yes
<JEEB>
ePirat: yea. there IIRC was a very brief point in time when hvc1 was the default
<ePirat>
how come there are two tags for the same codec
<JEEB>
in the mp4 nal unit video spec (14496-15) there usually are multiple identifiers specified for the same format, with various limitations
<JEEB>
hev1 was utilized as the default in the past since it was the less limited one; it let you put parameter sets both out of band as well as in-band in the packets
<JEEB>
while with the hvc1 identifier you're pinky promising that all parameter sets are in the extradata
<JEEB>
IIRC apple used to support more identifiers with H.264 but with HEVC they specifically only support hvc1
NullSound has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<BtbN>
How do you actually test for those error states? Just run it in msys?
<kasper93>
BtbN: CoInitializeEx should work the same way, don't matter much which one you use
<BtbN>
One idea I'd have to counteract the random background thread issue would be to just initialize it in single threaded mode
<BtbN>
our capture thread does nothing else but, well, capture. So that should still be plenty fast
<BtbN>
Maybe then deleting all objects actually cleans up properly...
<Lynne>
haasn: you need to copy each plane's normal representation via vkcmdcopyimage
<haasn>
Lynne: just creating the image view as R16_UNORM survives validation layers here
<haasn>
since it has mutable_format_bit
<haasn>
I will prefer that solution as it is 0copy
<kasper93>
BtbN: right now, the frame pool is leaked, (or frames from the pool)
<BtbN>
How do you see that?
<Lynne>
haasn: no guarantees that the space between each yuv plane is 0
<Lynne>
this will fail with intel, since it requires alignment between each plane
<Lynne>
unless by r16_unorm you mean plane 0->r16
<galad>
JEEB: I think Apple only ever supported "avc1" in mov/mp4, the ones that requires a complete set of parameters in the extradata, I don't think they ever supported "avc3"
<haasn>
Lynne: each plane individually ofc
<Lynne>
by what I mentioned, you need to use r10x_unorm
<Lynne>
and r10x_g10x_ for the second plane
<kasper93>
BtbN: run it in debugger with app verifier
<haasn>
or aliasing the whole thing as g16_r16b16_420_2plane_unorm instead of g10x6_r10x6b10x6_unorm_2plane_420
<BtbN>
All I get then is it being angry when I unload some HMODULE
<BtbN>
I'd guess it's angry at unloading the graphicscapture.dll, but it's not immediately obvious which DLL it means
<kasper93>
run it in debugger
<BtbN>
I am...
<BtbN>
"VERIFIER STOP 0000000000000900: pid 0x17C0: A heap allocation was leaked.", pointing at a FreeLibrary() call
<BtbN>
problem with windbg is that it can't read gcc symbols
<BtbN>
It does point into winrt::Windows::Graphics::Capture::implementation::Direct3D11CaptureFramePool::Recreate
<BtbN>
Which should have never been called, so must be some internal call
<kasper93>
build with pdb
<BtbN>
Well, the entire backtrace is outside of FFmpeg code
<BtbN>
I think all it's saying with that backtrace is "This is the allocation that leaked"? And it's likely pointing to the initial creation of the Direct3D11CaptureFramePool.
<kasper93>
BtbN: are you sure those frame are not attached to some avpackets or something else, during uninit still?
<BtbN>
no
<BtbN>
they never leave the wgc thread
<BtbN>
the frame and texture gotten from the API are turned into a D3D11 Texture, and that texture is rendered into a AVFrame gotten from a hwframesctx
<kasper93>
and those d3d11 textures are freed?
<BtbN>
Well, if they weren't, the D3D11 AVFrame stuff would be busted
<BtbN>
And so far I have been unable to locally reproduce that handles leak
<BtbN>
it reproduces fine when stuff is built on my static builds though...
<BtbN>
very perplexing
mkver has joined #ffmpeg-devel
<BtbN>
RO_INIT_SINGLETHREADED also makes no difference. Those weird threads still are interrupted in the end
<BtbN>
Yeah no, no idea why it's leaking stuff
<BtbN>
I have at this point checked 10 times or more. The code is not leaking a ComPtr anywhere
<BtbN>
even explicitly calling ICloseable::Close on the frames does not help
Kwiboo- is now known as Kwiboo
<kierank>
ml archives broke for me
<kierank>
Internal Server Error
<kierank>
The server encountered an internal error or misconfiguration and was unable to complete your request.
<kierank>
Please contact the server administrator at root@ffmpeg.org to inform them of the time this error occurred, and the actions you performed just before this error.
<kierank>
More information about this error may be available in the server error log.
<kasper93>
Close isnot refcounted, maybe it's called in wrong order or on wrong thread
<BtbN>
Of course Close is refcounted? It's a COM Object
<BtbN>
I think I might have found it, but it'll need some restructuring to test
<kasper93>
BtbN: IUnknown is refcounded and Release(), I don't think Close itself is
<BtbN>
The ICloseable interface is of course also refcounted
<BtbN>
and the ComPtr will release it correctly
<BtbN>
And I don't think Closing is even strictly neccesary on the frames, once they get released they're freed no matter what
<kasper93>
I'm talking about IClosable object, not interfaces
<BtbN>
I think the problem is that the capture thread just exits after it has called Close() on the frame queue and capture session
<BtbN>
but it has to keep spinning events until they're both done
<BtbN>
the problem now is that there isn't really a way to tell when they're done
<BtbN>
that's why a random sleep helps
<kasper93>
CreateFreeThreaded() pool is not requiring dispatch queue, you would get frames from thier thierd
<kasper93>
thread
<BtbN>
The dispatch queue is always required
<BtbN>
otherwise the "window closed" event doesn't fire, and during cleanup it also relies on it
<kasper93>
> Creates a frame pool where the dependency on the DispatcherQueue is removed and the FrameArrived event is raised on the frame pool's internal worker thread.
<BtbN>
yes, but the capture session and everything else still needs it, so it's pointless
<kasper93>
not really pointless, if you struggle to manage lifetime of it
<BtbN>
Well, there just is no API to manage it
<BtbN>
hence random sleeps
<BtbN>
Using a free threaded one would actually make that _even worse_
<BtbN>
Cause now you really can only wait for an arbitrary amount of time after calling Close and hope the thread it created in the background is done.
<BtbN>
If you are pumping all the events yourself you can at least kinda wait for them to drain
<BtbN>
but you still have to implement some mechanism of "If no event for X amount of time, assume drained"
<kasper93>
Close is not async, I would assume it synchronizes the "thread".
<BtbN>
Well, the fact that the thread is still there and kicking after calling it says otherwise
<kasper93>
if you pumping messages yourself, you need to figure this part out
<BtbN>
Again: It's not _my thread_
<BtbN>
The thread it's complaining about is some internal thread graphicscapture.dll created internally
<BtbN>
You seem to be mixing up unrelated things
<kasper93>
because event loop disapeared from it
<BtbN>
They seem to be unrelated to the event loop
<kasper93>
you said that's the problem, no?
mkver has joined #ffmpeg-devel
<BtbN>
Yes, because the current flow is "Call Close() on session and pool, and then immediately initialize dispatch queue shutdown"
<BtbN>
If I call Close, and then keep Pumping messages for a second and then initialize dispatch queue shutdown, it exits cleanly
<BtbN>
so Close() seems in fact to be async, with no way to wait for its Asynchonicity to finish
<kasper93>
I don't think Close() is async, DispatchQueue is async, because you need to drain it cleanly, no?
<kasper93>
no, DispatchQueue, no problem.
<kasper93>
what kind of events arrive after Close() is called?
<BtbN>
Again: The Dispatch queue is needed
<BtbN>
otherwise no events are dispatched
<BtbN>
And also again: Not having one would not solve this
<BtbN>
I just tried what kind of events arrive after calling Close(), and the answer is none. It sits forever in GetMessage()
<BtbN>
Which makes this even more baffling
<kasper93>
How does CreateFreeThreaded() work then? If "dependency on the DispatcherQueue is removed"?
<BtbN>
It removes it for the frame pool
<BtbN>
but the capture session still very much needs it
<BtbN>
otherwise its events aren't processes, and it has no free threaded equivalent
<kasper93>
yes, and the problem is with leaking frame pool, no?
<BtbN>
How would having the frame pool create its own dispatch queue internally help with leaking it?
<BtbN>
It would make it _even harder_ to wait for it to finish that internal thread
<kasper93>
I would assume, if it's internal you don't need to wait for it.
<BtbN>
I do, if I don't, it crashes on RoUninit
<BtbN>
That's why I used to have this random "sleep for 1 second before RoUninit" before I migrated this all to a self-controlled thread
<BtbN>
In the debugger I can see the threads it started exiting. "warning: graphicscapture.dll!00007FFDC3F833DF: LogHr(4) tid(e50) 800704C7 Der Vorgang wurde durch den Benutzer abgebrochen."
<BtbN>
it logs that twice
<BtbN>
and it does so a random amount of time after Close() is called
<BtbN>
if I call close(), then log that I'm about to sleep for a second, those thread exited logs come after the "I'm about to sleep" log
<BtbN>
So that stuff really does happen async in the background, with no obvious way to wait for it
<kasper93>
so, you confirm that memory leak is fixed if you add sleep?
<BtbN>
The App verifier is still complaining about a leak, even after sleeping
<BtbN>
so I'm out of ideas what to do
<BtbN>
the API seems fundamentally flawed in that regard
<BtbN>
it seems to expect to be inside of a UI application, where this arbitrary split-second asynchronicity is never a problem, cause they're never going to call Co/RoUninit instantly
<kasper93>
uninit should synchronize internal threads, either way, most applications wouldn't even call rouninit
<BtbN>
Yeah, it should. But it clearly doesn't.
<BtbN>
like, I _can_ fix the leak warning by using a FreeThreaded frame pool
<BtbN>
but then I'm back to the crash on RoUninit lol
<kasper93>
have you considered reporting this issue? It should be easy to create small app to reproduce
<BtbN>
I mean, I probaby should. But this is Microsoft.
<BtbN>
The free threaded pool is clearly better though
<BtbN>
I wonder if there is some way to query if it's done
<BtbN>
like, AddRef+Release returns its ref count
<BtbN>
so I'm thinking to just call that until I hold the only ref or something like that
<Lynne>
mkver: any comments on the id3v2 flac PR yet?
<wbs>
kasper93: that's not a pthreads replacement, and personally I'm not a fan of it
<wbs>
it tries to play clever in using lower level syscalls and whatever, to be faster than proper public apis etc
<BtbN>
"This project uses some undocumented NT system calls and is not guaranteed to work on some Windows versions. The author gives no warranty for this project. Use it at your own risk."
<BtbN>
But winpthreads could definitely use some love
<wbs>
yes, definitely
<BtbN>
what on earth are those condvars
<BtbN>
that looks horribly inefficient
<wbs>
there's actually a patchset up that I should review, that would make winpthread's testsuite be run by anyone - it seems like it hasn't been run in a decade or two
<kasper93>
there is also stdc threads. I don't recal who implements it currently
<kasper93>
I know msvc does at least...
<wbs>
kasper93: c11 threads?
<kasper93>
ye
<wbs>
msvc implements those? I thought nobody really implemented that api
<kasper93>
yes, they do. Last time I checked (some time ago) it was the only usable imple on windows.
<wbs>
BtbN: even if using mingw/gcc that defaults to winpthreads, ffmpeg still uses its own w32pthreads - unless you pass configure options to make it prefer pthreads though
<BtbN>
Need to find a way to force libstdc++ to use native windows thread in a pthread env
<BtbN>
Cause that's some needless overhead now that it supports it
<kasper93>
I'm not sure something like that is implemented
<BtbN>
It has its own configure options I can pass, so it's not impossible
BBB_ is now known as BBB
<kasper93>
let me know if you find something, I would like to also patch those meme mpv builds accordingly
<wbs>
just skip the --enable-threads=posix option when configuring gcc
<wbs>
or am I misunderstanding what you're referring to here?
<BtbN>
I want libstdc++ to use native threads while the toolchain is in pthreads mode
<BtbN>
a bunch of the dependencies need pthread mode, so I can't just fully switch
<wbs>
what do you refer to with "pthread mode" other than the thread backend for libgcc/libstdc++?
<wbs>
the fact that gcc automatically links winpthreads without needing a -lpthreads or similar?
<BtbN>
"gcc -v" saying "Thread model: posix"
<BtbN>
Cause that's what all the configure scripts check for
<wbs>
oh god
<kasper93>
hmm?
<wbs>
(the whole setup of how winpthreads are used as a dependency for libgcc is quite nasty as well; in particular for DLLs - when linking the winpthreads DLL, it would link in libgcc - but this may be built at a point before libgcc is built, so winpthreads provides its own copies of the functions it may need from libgcc)