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
Anthony_ZO has joined #ffmpeg-devel
thilo has quit [Ping timeout: 248 seconds]
thilo has joined #ffmpeg-devel
Kei_N_ has joined #ffmpeg-devel
Kei_N has quit [Ping timeout: 276 seconds]
derpydoo has joined #ffmpeg-devel
jamrial has quit []
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 252 seconds]
tccq has quit [Remote host closed the connection]
secondcreek has quit [Remote host closed the connection]
secondcreek has joined #ffmpeg-devel
<Lynne>
/etc/firejail/ffmpeg.profile, "allow set_mempolicy, which is required to encode using libx265"
<Lynne>
cursed
IndecisiveTurtle has quit [Ping timeout: 268 seconds]
mkver has joined #ffmpeg-devel
<psykose>
it's cause of the x265->libnuma dep which automatically sets numa stuff
<psykose>
it's actually not required if not built with libnuma i think
System_Error has quit [Remote host closed the connection]
<kurosu>
jkqxz: not sure nowadays, but there used to be a global macro for the number of iterations
<kurosu>
Runtime selection, or even automatical determination until it has converged (à la Google benchmark)
<kurosu>
would have been better
System_Error has joined #ffmpeg-devel
MisterMinister has joined #ffmpeg-devel
pross has quit [Ping timeout: 276 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
cone-706 has joined #ffmpeg-devel
<cone-706>
ffmpeg Andreas Rheinhardt master:c8ce9de5a0c0: avcodec/tests/mjpegenc_huffman: Also test length counts
<cone-706>
ffmpeg Andreas Rheinhardt master:ff9f3fb60732: avcodec/mjpegenc_huffman: Avoid AV_QSORT to sort entries by length
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 265 seconds]
rvalue- is now known as rvalue
ngaullier has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
MisterMinister has quit [Ping timeout: 276 seconds]
<frankplow>
kurosu: You can set the number of iterations with --runs now
<kurosu>
Eh. Didn't make sense but in any case, first role is to check asm, with a benchmarking as a bonus. But for block-based/codec stuff, it remains artificial
<jkqxz>
I already wrote my own test harness for randomised testing and debug, so I did actually just want the benchmarking.
<jkqxz>
Is there a nice tool for debug of asm like this, btw?
<jkqxz>
gdb works but is really clumsy to break or step through things.
<Lynne>
printf debugging
<jkqxz>
I currently have a macro to extract the register state at points in the assembly which is then printed by the test code to examine; this works reasonably well, but I have to mess around with it manually.
cone-706 has quit [Quit: transmission timeout]
<Lynne>
ah, yeah, wbs wrote one for aarch64
<jkqxz>
Right, fair.
<Lynne>
but I usually just printf debug externally by writing to a pointer
<Lynne>
as for randomized testing, why? in general you write C and then you write asm that follows what the C version does
<Lynne>
float ops will be affected by reordering but that's intentional
<jkqxz>
To be sure that I haven't failed on some edge case rounding?
<kurosu>
(didn't make sense to not be able to set it)
System_Error has quit [Ping timeout: 264 seconds]
<kurosu>
(oops sorry, data off, my reply lagged)
<kurosu>
I have to admit, for debugging, I like Vscode debugger because I can add watches for the data type (u/int8/16/32/64). But I build that habit more because gdb alternative was the Motif app ddd
<frankplow>
lldb has nicer pretty-printing of vector registers than gdb IMO but, typically of lldb, you have to use these ridiculously verbose commands to get them
<haasn>
not all paths are implemented on x86 yet, hence the massive slowdowns in some cases where it falls back to scalar C code
lemourin has joined #ffmpeg-devel
<kasper93>
how do you even speed up something 61x
<jkqxz>
Normally by finding that the previous version of the thing was repeatedly doing the same thing lots of times for no reason, and then not doing that.
<haasn>
kasper93: turning a memcpy into a noop, I think
<haasn>
legacy swscale sucks at obscure formats like ya8 or gbrp
<haasn>
and the new code handles it generically in a very efficient way (e.g. the last conversion compiles down to a packed, a register clear, two register moves and a packed write)
<haasn>
a packed read*
ahmedhamed has joined #ffmpeg-devel
<haasn>
ramiro: updated my swscale5 branch with the latest changes; I also pushed a branch `swscale5_shuffle` that has my experiment introducing SWS_OP_SHUFFLE as a replacement for SWS_OP_SWAP_BYTES
<haasn>
but I no longer see a real reason to keep it around
<haasn>
one thing I still want to do is improve the packed_shuffle solver in the x86 backend to also allow taking care of pixel clearing at the same time, so rgba -> rgb0 can also be compiled down to a single vpshufb
<haasn>
but I think I'm at a point where I want to submit what I have to the ML again
minimal has joined #ffmpeg-devel
Anthony_ZO has quit [Ping timeout: 252 seconds]
philipl has quit [Quit: leaving]
philipl has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 252 seconds]
philipl has quit [Quit: leaving]
philipl has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]