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
<haasn>
ramiro: right, I used to mask out unused components from the swizzle mask but I reverted that because the past matching logic for swizzles required an exact match on the mask
<haasn>
I can revert it now that we match swizzles per component
<haasn>
at this point I'm not sure why I even still define the swizzles as a union, might as well just get rid of the uint8_t mask, it's no longer referenced in the code
<ramiro>
haasn: thanks. I'm still using swscale4, so the patch doesn't apply, but I assume it does get better
<haasn>
one thing you may need to be aware of in swscale5 is that I changed the order in which I stripe the kernel over the image
<haasn>
I first process the main (block-aligned) image part in a single loop, then handle the last (unpadded) column in a separate loop
<haasn>
mostly to reduce the loop overhead for the common (properly aligned/padded) case
<haasn>
shouldn't matter if your impl is well-behaved (without side effects)
<ramiro>
haasn: that looks like a good change. it will make it easier for me to replace the main/safe part with a single function.
<ramiro>
also good catch about the last row. I had that issue with legacy swscale and some subsampled yuv code (I think it had odd height or something like that).
<haasn>
ramiro: wdym replace main part?
<haasn>
you want to hard-code a loop but not bother handling the tail in your hard-coded loop?
<haasn>
that seems like it will be bad, because to handle the tail you need to process another entire block_w/h chunk
<haasn>
I guess what we really want is the support for a variable block size implementation
<haasn>
so you can e.g. define a function that uses 8 vector regs, one that uses 4 vector regs, and one that uses 2 vector regs and so on
<haasn>
and then we can dynamically choose the largest block size for processing to avoid wasted work / needing a memcpy
<haasn>
but I somehow doubt the performance gain will be worth the headache there :)
<haasn>
ramiro: side note, checkasm may be .. tricky for JIT backends
<haasn>
it may end up testing for every possible combination of cpu flags unless you can guaranteed a stable function pointer return :)
<haasn>
I guess we can just wrap it in one layer of indirection to guarantee that
<Lynne>
you can always do what lavu/tx does and checkasm the user-facing ABI with enough testcases to go through all combinations
<Lynne>
ah... you probably don't expose the actual function pointer
<haasn>
we technically do but the ABI is implementation defined
<haasn>
(this is needed to pass vector registers directly between kernels)
<ramiro>
haasn: I specifically want to avoid having to do functions with smaller and smaller chunks. there will be one main function (which will internally take care of the horizontal/vertical loops) which will be as fast as possible. the rest will run the c code. (or do the memcpy, but I'd have to check some benchmarks and the amount of extra code needed)
<ramiro>
we currently have some converters that will try to do smaller and smaller chunks until they have hand-written scalar code for 1 pixel, and I don't think it's worth it to do that. it takes much more time and effort to write and test
<haasn>
Right, then at least we may need to think about mixing together backends
<haasn>
Pretty annoying either way
<haasn>
I would be happy if the benchmarks show that the jit loop is not faster enough to warrant the effort
delewis has quit [Remote host closed the connection]
<fflogger>
[editedticket] MasterQuestionable: Ticket #11528 ([avcodec] High sizzle problem when playing 5.6MHz DSD (.dsf) audio file) updated https://trac.ffmpeg.org/ticket/11528#comment:3
Guest87 has joined #ffmpeg-devel
Guest87 has quit [Client Quit]
martinr1 has joined #ffmpeg-devel
martinr1 has quit [Ping timeout: 252 seconds]
derpydoo has quit [Ping timeout: 244 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
martinr1 has joined #ffmpeg-devel
cone-824 has quit [Quit: transmission timeout]
martinr1 has quit [Ping timeout: 252 seconds]
derpydoo has joined #ffmpeg-devel
martinr1 has joined #ffmpeg-devel
martinr1 has quit [Ping timeout: 244 seconds]
av500 has quit [Read error: Connection reset by peer]
martinr1 has joined #ffmpeg-devel
martinr1 has quit [Ping timeout: 248 seconds]
martinr1 has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
<mkver>
jamrial: Why did you not ping the cbs/movenc patches before applying them?
cone-439 has joined #ffmpeg-devel
<cone-439>
ffmpeg Andreas Rheinhardt master:2ac2485c1f90: avcodec/mjpegenc: Don't allocate unnecessarily much memory
<jamrial>
enough time passed after the last iteration with no comments
<mkver>
No comment just means that no one has looked at it yet; I wanted to take a look, but then it was already pushed.
<jamrial>
ah
<jamrial>
sorry, you commented on the previous iterations pretty fast, so i assumed you had no comments for this one
<mkver>
No, I was just busy with my mpvenc work.
Traneptora has quit [Quit: Quit]
Traneptora has joined #ffmpeg-devel
<Lynne>
jamrial: I'm trying to port vp9 to use cbs_vp9, but I'm running into threading issues
<Lynne>
I'm guessing cbs wasn't quite build for multithreading in mind
<jamrial>
why port it?
<Lynne>
guess why -_-
abdu93 has quit [Quit: Client closed]
<Lynne>
vulkan needs even _more_ fields exposed, and adding them one by one was harder than simply adding cbs_vp9 and gradually switching everything to use the new header structs
<Lynne>
besides, cbs is simply better, and that's a fact
abdu93 has joined #ffmpeg-devel
<jamrial>
vvc doesn't seem to have threading issues and it uses cbs
<Lynne>
how come it doesn't need an update_thread_context function?
<JEEB>
we may have had a libtheora decoder at some point, but I don't recall it from recent times
<JEEB>
yea even in 2009 there seems to have been just the encoder
<BBB>
poor skal, everytime webp makes it to hackernews, it's b/c of exploits and not b/c of it being technically great. I guess that's a sign of success/adoption?
<kasper93>
it generates fuzzer for each configured encoder
<kasper93>
so, yes, it is fuzzed
<JEEB>
ok, then it makes sense
jamrial has quit [Ping timeout: 248 seconds]
<JEEB>
BBB: yea if a library implementing a format you had something to do with gets widely enough utilized, it will be poked at in order to find a hole into a system
jamrial has joined #ffmpeg-devel
Anthony_ZO has quit [Ping timeout: 252 seconds]
<Lynne>
I wish I could say something nice about it
<fflogger>
[editedticket] MasterQuestionable: Ticket #11525 ([avdevice] Better frame dropping logic for live streams to avoid unjustifiable freezing?) updated https://trac.ffmpeg.org/ticket/11525#comment:14
abdu9 has joined #ffmpeg-devel
<BtbN>
Why does the dude keep changing CLOSED issue titles to something completely different? My god
Milardo has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
Milardo has quit [Ping timeout: 240 seconds]
Milardo has joined #ffmpeg-devel
<fflogger>
[editedticket] catap: Ticket #11525 ([avdevice] Better frame dropping logic for live streams to avoid unjustifiable freezing?) updated https://trac.ffmpeg.org/ticket/11525#comment:16
Milardo has quit [Ping timeout: 240 seconds]
Milardo has joined #ffmpeg-devel
Milardo has quit [Ping timeout: 240 seconds]
cone-262 has quit [Quit: transmission timeout]
mkver has quit [Ping timeout: 245 seconds]
<fflogger>
[newticket] LinAGKar: Ticket #11532 ([undetermined] Raw bitstream export/import makes video stuttery) created https://trac.ffmpeg.org/ticket/11532
<fflogger>
[editedticket] catap: Ticket #11525 ([avdevice] Better frame dropping logic for live streams to avoid unjustifiable freezing?) updated https://trac.ffmpeg.org/ticket/11525#comment:18
<fflogger>
[editedticket] catap: Ticket #11525 ([avdevice] Better frame dropping logic for live streams to avoid unjustifiable freezing?) updated https://trac.ffmpeg.org/ticket/11525#comment:19
martinr1 has joined #ffmpeg-devel
<fflogger>
[editedticket] MasterQuestionable: Ticket #11525 ([avdevice] Better frame dropping logic for live streams to avoid unjustifiable freezing?) updated https://trac.ffmpeg.org/ticket/11525#comment:20
martinr1 has quit [Ping timeout: 244 seconds]
Grimmauld has quit [Quit: Client closed]
faidz has quit [Ping timeout: 268 seconds]
<fflogger>
[editedticket] MasterQuestionable: Ticket #11531 ([ffmpeg] [Regression] AAC audio in RTSP no more muxed with "-c copy") updated https://trac.ffmpeg.org/ticket/11531#comment:3