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 6.1.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
rvalue has quit [Ping timeout: 264 seconds]
Traneptora has quit [Quit: Quit]
rvalue has joined #ffmpeg-devel
lexano has quit [Ping timeout: 256 seconds]
Traneptora has joined #ffmpeg-devel
thilo has quit [Ping timeout: 260 seconds]
thilo has joined #ffmpeg-devel
Guest14 has joined #ffmpeg-devel
Guest14 has quit [Quit: Client closed]
nico37 has joined #ffmpeg-devel
nico37 is now known as nico373
nico373 has quit [Quit: Client closed]
qeed has quit [Quit: Leaving]
mkver has joined #ffmpeg-devel
real6ws has joined #ffmpeg-devel
mkver has quit [Ping timeout: 255 seconds]
jamrial has quit []
flectori has joined #ffmpeg-devel
\\Mr_C\\ has quit [Remote host closed the connection]
flectori has quit [Remote host closed the connection]
qeed has joined #ffmpeg-devel
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 268 seconds]
SystemError has joined #ffmpeg-devel
stack_overflow has quit [Ping timeout: 255 seconds]
AbleBacon has quit [Read error: Connection reset by peer]
jarthur has joined #ffmpeg-devel
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
real6ws has quit [Quit: Leaving]
Kei_N_ has quit [Ping timeout: 255 seconds]
Kei_N has joined #ffmpeg-devel
Kei_N has quit [Ping timeout: 268 seconds]
Mister_D has quit [Remote host closed the connection]
MisterMinister has joined #ffmpeg-devel
Kei_N has joined #ffmpeg-devel
odrling has quit [Remote host closed the connection]
<jkqxz>
elenril: What is thread_queue_size meant to do as an input option?
<jkqxz>
I'm trying to fix the problem that fixed-size frame pools fall over after e0da916b8f5b079a4865eef7f64863f50785463d because ffmpeg has lied to lavc about how many frames it will hold on it.
<jkqxz>
I made <https://0x0.st/H5lg.diff> which works for the default case, but reading thread_queue_size from the input options appears to be wrong so if the default is not used then it can still fall over.
<jkqxz>
(In particular, even with "-thread_queue_size 3" all queues (from the print in queue_alloc()) are made with size 8, suggesting that something is wrong.)
<jkqxz>
Easy test for this is playing MPEG-2 on any hardware with exposed array textures forcing fixed-size pools (DXVA2, D3D11, VAAPI). Others fail as well, but e.g. H.264 usually gets lucky with the number of reference frames.
derpydoo has quit [Ping timeout: 264 seconds]
lexano has joined #ffmpeg-devel
<elenril>
jkqxz: it's not implement for input currently
<elenril>
i.e. does nothing
* Sean_McG
waves
<cone-482>
ffmpeg Michael Niedermayer master:22845fbb80b7: doc: Add infra.txt
Kei_N has quit [Ping timeout: 268 seconds]
Kei_N has joined #ffmpeg-devel
<Sean_McG>
JEEB: so I tried like you said and made an archlinux Docker container with latest Arch and now I am even more confused -- FATE with ubsan enabled is succeeding even for tests where I know there is UB!
<JEEB>
\o/
<Sean_McG>
my thoughts exactly
<Sean_McG>
.... it just occurred to me... I probably need to run it with THREADS=<something other than 1>
<Sean_McG>
hmmm nope... I refuse to believe this is a Heisenbug
<jkqxz>
elenril: What is the best route to finding the size of the queue used on the output of a decoder?
<mkver>
Sean_McG: UBSan simply logs an error if there is UB; add -fno-sanitize-recover=undefined to cflags to make the test fail.
<Sean_McG>
oh! cheers.
<jkqxz>
mkver: I was imagining using more macro magic to make the switch simple; something like "#define H264_SEI_TYPES SEI_LIST_ENTRY(BUFFERING_PERIOD, H264, SEIBufferingPeriod) \ more SEI_LIST_ENTRY(...)", then "#define SEI_LIST_ENTRY(type, codec, struct) case type: call with struct type;", then "switch (type) { COMMON_SEI_TYPES; H264_SEI_TYPES; ... }".
<mkver>
jkqxz: I wanted to use an X macro for it.
<jkqxz>
But I think I like your last option more, the simplicity of it in avoiding anything extra appearing in the template (beyond moving the closing parenthesis) is nice.
<mkver>
a) or b)?
<jkqxz>
(b)
<mkver>
Ok, will implement.
<jkqxz>
The extra function indirection is hidden in the code and always inlined away, so as you say the only downside is that __func__ is strange but we never use it anyway.
<Sean_McG>
OK yeah here we go, thanks mkver -- I'm seeing failures now
<jkqxz>
Oh, you can preserve the name of the real function too, since it's only used in SEI_MESSAGE_RW. Then gdb breakpoints land in exactly the right place rather than one step away.
<Sean_McG>
Lynne: nevermind the request to ubitux -- I've now confirmed the same behaviour (and then some!) for gcc+ubsan on Arch
dykai has joined #ffmpeg-devel
dykai has quit [Client Quit]
dykai has joined #ffmpeg-devel
<mkver>
Speaking of ubitux: What happened to him? Why are his FATE boxes inactive?
<kierank>
he was working on the prores issue a few days ago
* sdc
quick question, I accidentally sent a new email with a patch addressing some feedback I received, should I reply to the original email thread still
<kierank>
jdek: ah didn't know you had linkedin, could have tagged you
<jdek>
I didn't know I had linkedin
<jdek>
sdc: if you've addressed all the comments in the thread, should be fine to leave as-is
<sdc>
sounds good, thank you
derpydoo has joined #ffmpeg-devel
dykai has quit [Ping timeout: 272 seconds]
cone-482 has quit [Quit: transmission timeout]
ravenJPL has joined #ffmpeg-devel
<Lynne>
elenril: in print_sdp(), you shadow j
invertedguy0485 has quit [Remote host closed the connection]
invertedguy0485 has joined #ffmpeg-devel
invertedguy0485 has quit [Remote host closed the connection]
rvalue has quit [Ping timeout: 264 seconds]
Teukka has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Teukka has joined #ffmpeg-devel
AbleBacon has joined #ffmpeg-devel
dykai has joined #ffmpeg-devel
rishadbaniya has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 268 seconds]
Kei_N has quit [Read error: Connection reset by peer]
<jdek>
wbs: I do think could overflow in real-world. The first beta check on the overall filter decision only checks lines 1 and 4. Honestly I'm not sure.
<jdek>
also if line 3 was just = line 2 it looks like something which a decoder could output(?) though all cases which trigger the overflow there are going to be quite extreme
<jdek>
BBB: oh, I didn't even know I had samples access.
MisterMinister has joined #ffmpeg-devel
<wbs>
jdek: ok, I guess the asm is just broken then, for this apparently rare case
<jdek>
they should have made the check d0 + d1 + d2 + d3 < beta << 1
<jdek>
would have been cheaper to compute + more reliable
<jdek>
in any case, I wrote 12bit x86 asm earlier
<jdek>
will submit tomorrow
<jdek>
its probably not amazing but i dont know x86 so
<jdek>
was surprised x86 doesnt have a rounding shfit