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.0 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
thilo has quit [Ping timeout: 256 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
AbleBacon has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
lexano has quit [Ping timeout: 256 seconds]
mkver has quit [Ping timeout: 272 seconds]
cone-299 has joined #ffmpeg-devel
<cone-299>
ffmpeg Michael Niedermayer master:8789c550faf4: avcodec/qsvdec: Check av_image_get_buffer_size() for failure
<cone-299>
ffmpeg Michael Niedermayer master:4ed4f9a6c0a9: avcodec/jpeg2000dec: remove ST=3 case
<jamrial>
do we really need 9216 test in checkasm for vvc_alf alone?
<mkver>
I have noticed that since switching to a threaded architecture, the hashes of some damaged files have become random even when using no time limit at all. This is because which of the pooled frames gets reused by ff_get_buffer is now random.
Luna_Usagi has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
mkver has quit [Ping timeout: 256 seconds]
Krowl has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
<Lynne>
michaelni: the output number of samples stays the same, I think what may be happening is decoding continues after the time limit but none of the frames are output
Livio has quit [Ping timeout: 272 seconds]
ccawley2011 has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
mkver has quit [Ping timeout: 268 seconds]
<ePirat>
jamrial, since when is the "single line block" thing a rule in FFmpeg?
<jamrial>
for as long as i remember
<ePirat>
I saw it done in some files but iirc not consistently in IMHO its a terrible practice…
<ePirat>
and its not mentioned in the code formatting conventions
<ePirat>
so either such a weird convention should be mentioned there or we should not complain about this IMHO
Krowl has joined #ffmpeg-devel
<ePirat>
jamrial, I can send a patch to add it to "Code formatting conventions" on the website if you want
AbleBacon has joined #ffmpeg-devel
<jamrial>
ePirat: yeah, that'd be good
<courmisch>
I am a bit confused about merge rules
<courmisch>
the doc says to wait 3 days normally
<courmisch>
but I see lots of noncritical changes merged in a single day
<courmisch>
so what's the correct waiting time then
<Lynne>
if you as a maintainer think something is important, you merge it, particularly when its a technical issue you don't think anyone else could review
SystemError has quit [Remote host closed the connection]
<courmisch>
eh
<courmisch>
I would actually like people to review my patches
<Lynne>
I'll try to, once I start writing risc-v
<courmisch>
so you know my totally-not-bugs "features" would not need to be totally-not-fixed patched-out
<courmisch>
I know my code is always perfect but
mkver has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
cone-422 has joined #ffmpeg-devel
<cone-422>
ffmpeg sunyuechi master:aa9dbd91cfde: lavc/vp9dsp: R-V ipred vert
<cone-422>
ffmpeg Rémi Denis-Courmont master:a3e45063c0b1: lavc/flacdsp: fix CPU requirement for 32-bit LPC
<cone-422>
ffmpeg sunyuechi master:0cc866149943: lavc/vp9dsp: R-V V ipred hor
<cone-422>
ffmpeg sunyuechi master:b82d9f55d121: lavc/vp9dsp: R-V mc copy
<cone-422>
ffmpeg Rémi Denis-Courmont master:7b47099bc080: lavc/flacdsp: R-V V flac_wasted32
Krowl has quit [Read error: Connection reset by peer]
<Sean_McG>
I'd like to learn how to write VSX-intrinsic acceleration for things like flac_{wasted32,lpc}, etc. Would anyone be willing to teach/mentor me through that?
<JEEB>
intrinsics would mean that it's part of the C code, so you'd be having a specific C file and some function pointer stuff?
<BtbN>
I also doubt intrinsics would be accepted over asm, unless there is a really good reason for them
<JEEB>
so basically some DSP struct, and an init function that defaults to the plain C function, and then calls the arch-specific init where specific extensions etc can be checked for
<JEEB>
wonder how the PPC dir stuff looks like in avcodec?
<JEEB>
(I guess VSX is powerpc stuff?)
<Sean_McG>
powerpc doesn't usually do raw ASM, just look at any of the ppc/ directories
<Sean_McG>
at least not for AltiVec, which is the predecessor to VSX
<JEEB>
yea
ccawley2011 has quit [Ping timeout: 260 seconds]
<courmisch>
intrinsics are anathematic
* Sean_McG
shrugs, it's how IBM recommends it to be done
<courmisch>
Well, I mean, all ISA vendors recommend intrinsics.
<courmisch>
That does not make them right.
<courmisch>
It's really just marketing for telling people that they don't need to do Scary Arcane Assembler
<JEEB>
I think the real question whether there is a proper assembler like nasm/gas for the architecture
<Sean_McG>
gas runs just fine on power*
<JEEB>
(or whatever was the assembler used for arm?)
ccawley2011 has joined #ffmpeg-devel
<Sean_McG>
oh you were speaking more generically
<JEEB>
yea. just whether there is a usable looking assembler, like with ARM/aarch64 we have one it seems
<JEEB>
but yea, FLAC IIRC already had SIMD for it, so you could check any possible DSP contexts or whatever
<courmisch>
and the other group that insists on intrinsics are arch porters who live in a parallel universe whence you can transpile intrinsics
<JEEB>
yea, there is a FLACDspContext
<JEEB>
that should have function pointers defined
<Sean_McG>
I'm not sure I like having to deal with things like Secure PLT in a language like ASM
<JEEB>
libavcodec/flacdsp.c
<courmisch>
PLT is made by the linker, not the assembler
<JEEB>
yea, within that you have ff_flacdsp_init, which indeed defaults to the C functions
<JEEB>
and then it has #if ARCH_ARM elif RISCV elif X86
<Sean_McG>
JEEB: it seemed like a good place to start
<Sean_McG>
for someone who wants to learn it
<JEEB>
and those then are functions provided by a file that gets compiled for that arch, and which provides its own initialization function
<courmisch>
but eh, I am not the PPC maintainer. Maybe they like horror movies
<JEEB>
that then would override those function pointers for which you have a function implemented
* Sean_McG
laughs
<courmisch>
though I must say that I don't think it's any easier to learn intrinsics than plain ASM, simply because most ISA specs document the ASM rather than the intrinsic
<JEEB>
it seems like there's already some VSX stuff in FFmpeg, since there already is a purpose built HAVE_VSX provided by configure
<Sean_McG>
aye
<JEEB>
and yea, existing stuff seems to be C
<JEEB>
and there is a macro PPC_VSX to check if the CPU flags contain VSX
<JEEB>
so, uh, I think this more or less confirms how VSX optimizations are written atm
<JEEB>
add a new file in relevant Makefile with HAVE_VSX, that implements the DSP init function for that architecture, and possibly the actual SIMD since this would then probably be C? (although asm is generally preferable if there is a usable assembler available)
<JEEB>
and then in case the CPU flags contain VSX, set in that init function the function pointer accordingly
<JEEB>
which would then automagically mean that those overridden ones would get utilized instead of the C stuff
<Sean_McG>
nice, thanks
* JEEB
did something like this some... 12 years ago
<JEEB>
back during my GSoC project, one of the extra things was trying to figure out asm 8)
MrZeus has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
MrZeus has quit [Read error: Connection reset by peer]
<thardin>
about 1 hour of formal verification work on lavu/common.h and I've already found UB
<thardin>
in av_clipl_int32_c()
<JEEB>
:D
<thardin>
signed overflow. assert a + 0x80000000u ≤ 9223372036854775807;
<thardin>
which obviously it won't if a > INT64_MAX - 0x80000000
IndecisiveTurtle has quit [Ping timeout: 260 seconds]
<thardin>
I don't even know what that nonsense is doing. it's cursed. but maybe eva can make sense of it if I cast to uint64_t
MrZeus has joined #ffmpeg-devel
<thardin>
0 alarms generated by the analysis.
<thardin>
yääää
<Lynne>
formal verification is nice, which software do you use?
<thardin>
frama-c
<thardin>
currently I'm not really verifying any of the behavior of the functions since that requires using the weakest predicate (WP) plugin
MrZeus has quit [Ping timeout: 255 seconds]
<jamrial>
thardin: maybe should be (a+0x80000000ULL)?
<thardin>
maybe?
<thardin>
I forget the rules
<thardin>
ULL isn't really portable I think
<jamrial>
UINT64_C() then
<thardin>
a+UINT64_C(0x80000000) seems to work
<thardin>
yeah
<jamrial>
at least in my env, UINT64_C(x) translates to xULL anyway
mkver has quit [Ping timeout: 246 seconds]
<thardin>
patchset sent
<jkqxz>
Lynne: What is the logic for preferring preprocessor over enum constants?
<jkqxz>
It could also be because you can have more direct control of the type (INT32_C(123), etc), but again these are inty things and the largest is 64 so not relevant.
<Lynne>
jkqxz: I think enums should be used when there's some grouping between values, but they seemed unrelated to me at the time
<Lynne>
I don't have an opinion now
<Lynne>
I do wish the patch was a genuine attempt at doing this, rather than a hack to get dx12 encoding
<jkqxz>
What do you think is wrong with it?
<Lynne>
huh, the version of the code in april doesn't look too bad
<Lynne>
it definitely mustn't NIH its own picture types though
<Lynne>
the API needs to have proper namespacing
<jkqxz>
Sounds like you want to review on the ML!
<Lynne>
I did point that out last time
mkver has joined #ffmpeg-devel
<jkqxz>
The picture types come from the VAAPI code because you need something which distinguishes KEY from INTRA_ONLY in AV1 (or IDR from I in H.264, or IDR from CRA in H.265).
<jkqxz>
It had the H.264 names because that was first. Would you feel it was more virtuous if it used the AV1 names?