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 7.1.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
abdu91 has joined #ffmpeg-devel
abdu has quit [Ping timeout: 240 seconds]
<tmatth>
yes
jamrial has joined #ffmpeg-devel
jamrial has quit [Changing host]
jamrial has joined #ffmpeg-devel
<Lynne>
git master? enabled either glslang or shaderc?
thilo has quit [Ping timeout: 252 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
Anthony_ZO has joined #ffmpeg-devel
khrbtxyz has quit [Remote host closed the connection]
abdu91 has quit [Quit: Client closed]
derpydoo has joined #ffmpeg-devel
minimal has quit [Quit: Leaving]
<tmatth>
git master yeah, I hadn't explicitly enabled glslang though, giving that a try now
<Lynne>
yeah, it's not autodetected
<Lynne>
since we have ffv1 decoding though, I think we should start autodetecting it and enabling it maybe
<Lynne>
but spirv libs are a hot potato to link against
rvalue has quit [Read error: Connection reset by peer]
abdo has quit [Quit: Connection closed for inactivity]
tccq has joined #ffmpeg-devel
<tccq>
Hi, I have some questions about memory leaks using filter_complex. I am writing my own simple VV->V filter that simply forwards frames from each input depending on a timer. (ie. it sends 5s of input a and then 5s of b etc). But I am seeing super fast rising memory usage that only declines when ffmpeg is killed or exits. I am pretty sure that it has something to do with the frames themselves not getting completely freed. I am using
<tccq>
framesync, attempting to get ownership of the frame I intend to send on with either ff_framesync_get_frame or with a av_frame_clone+av_frame_make_writeable, and then passing them to ff_filter_frame, which I understand to take ownership of both the AVFrame structure and the underlying data. https://pastebin.com/cZzWAMgj Does anyone have any guesses about where the memory is leaking?
iive has joined #ffmpeg-devel
<BtbN>
"a = av_frame_clone(a);" straight up makes that frame leak forever
<BtbN>
you make an extra reference to its data, while overwriting the original one
<BtbN>
so it'll never be freed
<BBB>
for extlib wrappers where we're trying to wrap some options using AVOptions, we're typically using "silly" values to mean "default" or "not provided". would it be possible to use a flag for this?
<JEEB>
I think I tried to use an "invalid" value which the AVOption's actual range wouldn't permit to be set manually, which did work, but that would then also not let one "unset" an option
<BBB>
no, the range has to be extended for it to be fit
<BBB>
it's a detail, it's not a big deal
<tccq>
but ff_framesync_get_frame without the get arg just returns with '*rframe = frame;' without an allocation, so the frame structure is still held by the framesync structures.
<BBB>
but it'd be nice if there was a more generic way to say "this value was specified"
<JEEB>
yea
TheVibeCoder has joined #ffmpeg-devel
<TheVibeCoder>
when 8.0 will be released?
IndecisiveTurtle has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
<Sean_McG>
when it's ready
cone-829 has quit [Quit: transmission timeout]
<jamrial>
michaelni: should the new avdict flag be removed if that id3v2 change was reverted?
<jamrial>
it's recent enough we can get away with it
<TheVibeCoder>
why when it is ready and not when it is complete?
<jamrial>
oh, it's still used in lavf/metadata.c
<jamrial>
guess not then
___nick___ has quit [Ping timeout: 252 seconds]
TheVibeCoder has quit [Quit: Client closed]
<jkqxz>
Is there some way to verify that asm functions actually only use the instruction set they are allowed to? (Without a machine with the right properties to check.)
Traneptora has joined #ffmpeg-devel
<jkqxz>
Like some sort of naive idiot I used the sensible version of vpbroadcastd in an AVX2 function and only found out at the SIGILL, and now I'm wondering how you check for other cases of that.
<jamrial>
jkqxz: x86inc should warn you about that during compilation, but maybe it doesn't work for avx2?
<jamrial>
Gramner: ^ do you know?
<jkqxz>
I tried an AVX512 instruction (on ymms) with no AVX2 form and I see no warning for that either.
mkver has quit [Ping timeout: 244 seconds]
<another|>
is ffmpeg's copy of x86inc up-to-date?
<Lynne>
jkqxz: did you use the instruction macros or the native assembler instruction mnemonics?
<jkqxz>
It does ding me for using punpckldq on ymm if I declare avx rather than avx2, so it certainly works in some cases.
<jamrial>
another|: doesn't look like, compared to dav1d's at least
<jkqxz>
jamrial: I wrote "vpbroadcastd m10, eax".
<jamrial>
yeah, that's avx512
<jamrial>
so x86inc doesn't seem to have macros around some of these AVX only instructions, so it will not warn
<jkqxz>
I only wanted a constant, it's fine with "vpbroadcastd m10, [sixtyfour]". (Maybe that's faster anyway, but the code felt cleaner using the immediate.)
odrling has quit [Remote host closed the connection]
odrling has joined #ffmpeg-devel
<another|>
hmm.. that's actually not detected by x86inc
<Gramner>
x86inc only warns for legacy instructions (i.e. those that are templated for both sse/avx)
<Gramner>
that's not to say it wouldn't be useful for newer instructions, it's just that nobody implemented that
<jamrial>
EVEX_INSTR could be adapted for it. AVX_INSTR is already too bloated
<Gramner>
yeah, the reason it was done for the legacy ones is that they were all already conveniently macroed
cone-982 has joined #ffmpeg-devel
<cone-982>
ffmpeg Lynne master:bb3ce284d7cc: vulkan: use a single command buffer per command buffer pool
<cone-982>
ffmpeg Lynne master:36c6c66deb56: vulkan/rangecoder: minor cleanup
<ramiro>
haasn: I'm on vacation until early may, I'll have a better look at your changes then. hopefully subsampled formats will also have been supported by then :P
<ramiro>
haasn: about SWS_OP_SWAP_BYTES and SWS_OP_SHUFFLE, the "SHUFFLE_BYTES { .type = U32, .order = { 3, 2, 1, 0 }}" compromise sounds good. the only issue I can think of quickly is that we might end up with a lot of possible combinations, where only a few will be actually used by real converters. we may end up with a test dark spot, or with a more work being done to implement all combinations which might
<ramiro>
not all be needed.
fflogger has quit [Remote host closed the connection]