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
Kimapr_ has quit [Remote host closed the connection]
Kimapr_ has joined #ffmpeg-devel
messier81 has joined #ffmpeg-devel
Kimapr_ has quit [Remote host closed the connection]
<BtbN>
hm, dealing with the output from graphics.capture is weird. The API does give sensible timestamps of each frame.
<BtbN>
But it only returns frames whenever the compositor actually renders one
<BtbN>
so capturing my editor for example results in 1fps content, each time the blinking cursor appears and disappears
<BtbN>
So it's as VFR as it gets
<BtbN>
not sure if I should just leave it at that, given the frames have perfect timestamps. Or duplicate frames to reach the users requested target rate
<BtbN>
It also has the same problem in reverse. If you capture a 144 fps game, the API _will_ give you 144 frames per second
<JEEB>
yea so essentially you as an API client are supposed to drop or dupe if you require a specific frame rate
<JEEB>
sounds like fps filter afterwards inserted is not a bad idea, if a specific rate is required
<BtbN>
it's just the question if I should even bother doing that in the capture filter, or just say "this outputs wild VFR, deal with it elsewhere"
<BtbN>
the later approach would make the filter a lot less messy
<JEEB>
my opinion is on the latter
<JEEB>
we have fps filter and IIRC it works even with hwframes?
<JEEB>
since it just drops or dupes
<BtbN>
I also have noticed an odd problem with this
<BtbN>
if I capture a still window, I get literally 0 FPS
<JEEB>
:D
<BtbN>
I do get an initial frame
<JEEB>
so yea, you then start needing to care about irl time
<BtbN>
But the problem with that is if there is no output, ffmpeg can't exit
<BtbN>
it will keep looping on the request_frame function until a frame comes out, and then exit
<BtbN>
until a frame appears, it is hard stuck
<JEEB>
does it get a signal that plz EOF then?
<JEEB>
as a filter
<BtbN>
I don't think a filter has any provisions to receive an EOF signal?
<JEEB>
I thought there was some method to tell a filter or the chain that it should flush and finish up
<BtbN>
hmm
<BtbN>
One thread is just literally busy looping on the request_frame function, which keeps returning 0
<JEEB>
but yea, not sure if there is one from API client (cli in this case for example) to the filter, in which case this is yet another case that we need something like that
<JEEB>
we already have the command interface for filters, so some infra already exists... but yea, not a fun problem
<BtbN>
It's not a super critical problem, since usually you capture something that changes
<BtbN>
I'm also not sure how to implement that VFR mode in general
<BtbN>
if I just "test if there is a frame, and if no, just return 0", something will literally busy-loop the request-frame function
<BtbN>
so I kinda do have to sleep, but I don't know how how long until the next frame
<jamrial>
ramiro: i wonder why the binary literals didn't generate compilation errors. they are from c23 and we use c17 or c11
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 256 seconds]
<Lynne>
compilers are a couple decades ahead of the C standards committee
<jamrial>
Lynne: so despite strictly asking for c17 compliance, gcc/clang just silently accept c23 features?
<Lynne>
yeah, until they update it so it respects this
<Lynne>
in which case stuff will break and will have to be fixed
<Lynne>
this is why I have Werror, a project which does not compile if a compiler is upgraded is utter junk
<ramiro>
jamrial: iirc gcc has supported binary literals as an extension for quite some time. I use them myself from time to time, but in ffmpeg we should try to reduce usage of these extensions.
<jamrial>
ramiro: i'd expect them to be accepted when requesting -std=g99 or such, but not strict c11/c17
<jamrial>
afaik, -stc=cxx should disable gcc extensions
<BtbN>
It's missing on the msvc side as well if the thing
<BtbN>
is
witchymary has quit [Remote host closed the connection]
witchymary has joined #ffmpeg-devel
witchymary has quit [Remote host closed the connection]
witchymary has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 258 seconds]
<fflogger>
[editedticket] m.feriati: Ticket #11240 ([tools] [Windows] Non-ASCII characters in "FFREPORT" may produce garbled filename or fail) updated https://trac.ffmpeg.org/ticket/11240#comment:14