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
<cone-870> ffmpeg Andreas Rheinhardt release/7.0:7050b247b28a: avcodec/vp8: Return error on error
<cone-870> ffmpeg Andreas Rheinhardt release/7.0:a08da68e0a38: avformat/movenc: Check av_malloc()
<cone-870> ffmpeg Andreas Rheinhardt release/7.0:2bfcc11f5145: avcodec/adts_parser: Don't presume buffer to be padded
<cone-870> ffmpeg Andreas Rheinhardt release/7.0:45765b7c2efa: avformat/flacdec: Reorder allocations to avoid leak on error
IndecisiveTurtle has quit [Ping timeout: 255 seconds]
thilo has quit [Ping timeout: 268 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
lexano has quit [Ping timeout: 260 seconds]
iive has quit [Quit: They came for me...]
Kei_N_ has joined #ffmpeg-devel
Kei_N has quit [Ping timeout: 255 seconds]
arch1t3cht9 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 252 seconds]
arch1t3cht9 is now known as arch1t3cht
kasper93 has quit [Ping timeout: 268 seconds]
lemourin has quit [Quit: The Lounge - https://thelounge.chat]
lemourin has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
psykose has quit [Remote host closed the connection]
psykose has joined #ffmpeg-devel
psykose has quit [Ping timeout: 268 seconds]
psykose has joined #ffmpeg-devel
<Lynne> JEEB: thanks, v3 is on the ML with some robustness improvements and fixes
<Lynne> the new channel layout entries are in a separate commit
mkver has quit [Ping timeout: 256 seconds]
cone-870 has quit [Quit: transmission timeout]
MisterMinister has quit [Ping timeout: 264 seconds]
jamrial has quit []
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 260 seconds]
<courmisch> 2
rvalue has quit [Ping timeout: 264 seconds]
rvalue has joined #ffmpeg-devel
cone-166 has joined #ffmpeg-devel
<cone-166> ffmpeg Rémi Denis-Courmont master:f88374658752: lavc/flacdsp: do not assume maximum R-V VL
<cone-166> ffmpeg Rémi Denis-Courmont release/7.0:2d514f5d481a: lavc/flacdsp: do not assume maximum R-V VL
AbleBacon has quit [Read error: Connection reset by peer]
derpydoo has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
<courmisch> the VVC MC patchset for R-V could use somebody else's opinion
rvalue has quit [Ping timeout: 252 seconds]
derpydoo has quit [Ping timeout: 268 seconds]
rvalue has joined #ffmpeg-devel
<courmisch> okay, maybe there is a way to do FLAC LPC33 with 128-bit vectors, but it's going to be tiiiiight
kurosu has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
derpydoo has joined #ffmpeg-devel
cone-166 has quit [Quit: transmission timeout]
kasper93 has joined #ffmpeg-devel
<JEEB> so, should we do a call for alternatives with regards to how to handle contributions in the future? so that we can then have a vote on it, since it's highly unlikely that anything will move before that.
IndecisiveTurtle has quit [Ping timeout: 260 seconds]
<JEEB> the alternatives for something like that which popped up previously were a) self-hosted gitlab since one of the community members said he could maintain it if he didn't have to actually pay for the hw/network etc b) sharing gitlab instance with videolan (since they already have someone maintaining it!) c) forgejo (when jdek checked the cli tools for this they were worse than gitlab's) d) keep to ML
<JEEB> *self-hosted forgejo
derpydoo has quit [Ping timeout: 260 seconds]
<JEEB> option c had the problem that it had no-one AFAIK noted they'd be ready to do the admin work
<JEEB> while a has that, and b of course would co-operate with videolan's existing infra, so less work in building stuff from the ground up
<JEEB> oh, and I guess e) would be github
IndecisiveTurtle has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
<courmisch> >> github
<courmisch> inb4 Dolby sends a takedown notice
<JEEB> ayup 8)
cone-474 has joined #ffmpeg-devel
<cone-474> ffmpeg Andreas Rheinhardt master:95faf45af16b: avformat/qoadec: Check ffio_ensure_seekback()
<cone-474> ffmpeg Andreas Rheinhardt master:6dc8d4eea828: avformat/westwood_vqa: Check ffio_ensure_seekback()
<cone-474> ffmpeg Andreas Rheinhardt master:b47116be45d9: avformat/oggdec: Check ffio_ensure_seekback()
<cone-474> ffmpeg Andreas Rheinhardt master:590fffe6adcf: avformat/gifdec: Check ffio_ensure_seekback()
<cone-474> ffmpeg Andreas Rheinhardt master:cf6d07522a37: avformat/dhav: Check ffio_ensure_seekback()
<cone-474> ffmpeg Andreas Rheinhardt master:d8cad01805be: avformat/dhav: Check amount read
<cone-474> ffmpeg Andreas Rheinhardt master:65763bffb6e2: avformat/mpegts: Don't use uninitialized value in av_log()
<cone-474> ffmpeg Andreas Rheinhardt master:50c25d1f0a55: avformat/matroskaenc: Check ff_put_wav_header() failure
<cone-474> ffmpeg Andreas Rheinhardt master:edc235e0761a: avformat/riffenc: Fix outdated comment
<cone-474> ffmpeg Andreas Rheinhardt master:8e27bd025f45: avformat/async,cache: Use more unique context names
compn has quit [Read error: Connection reset by peer]
compn has joined #ffmpeg-devel
<cone-474> ffmpeg Andreas Rheinhardt master:e9197db4f722: tests/checkasm/vvc_alf: Don't use declare_func_emms
<elenril> JEEB: IMO a plain vote is useless without a plan for who will be implementing the result
<JEEB> I agree, that's why I commented on the forgejo alternative being the one that got mentioned, but no-one had so far raised their hand for making that a thing
<elenril> and a more detailed report into 1) what problem(s) are we solving 2) what our priorities are 3) what options are there and how do they compare
<Lynne> sourcehut is at least not an option anymore
<elenril> was it ever?
<elenril> AFAIU it does not have an MR system, so I don't really see the point of it
kurosu has quit [Quit: Connection closed for inactivity]
<nevcairiel> sourcehut is like an alternative patchwork with an issue tracker, it is extremely barebones
<JEEB> but yea, for self-hosted gitlab instance BtbN had mentioned "I'd be happy to set up and maintain a Gitlab instance, as long as I'm not the one sitting on the cost.", so that alternative at least has someone with regards to the software setup/admin - although he did also mention that he did prefer reusing videolan infra & github to that alternative :D
<JEEB> elenril: I think the general idea is to decide on how we take in "patch-like contributions" in the future. at that point for me the minimum viable thing is to have the organization/repo setup done, credentials of maintainers added and a MR-like workflow being working. a more "complete" setup would be someone creating the CI automation files. but you will find not a lot of people will want to invest
<JEEB> their time on this before the general decision has been made that X is for now the thing that's being moved to.
<nevcairiel> in the time of containerized services, setting these up isn't that big of a deal if you have a machine to do it on, i would be happy to help with gitlab or gitea/forgejo if thats where we go
<JEEB> one thing that someone #elsewhere mentioned is that neither gitlab or forgejo have a good system for handling spam, so self-hosting would probably mean having to dedicate some manpower to that.
jamrial has joined #ffmpeg-devel
<Lynne> someone brought sourcehut up, but a lot of projects just left, and one of its key developers
IndecisiveTurtle has quit [Ping timeout: 256 seconds]
IndecisiveTurtle has joined #ffmpeg-devel
<BtbN> We absolutely could set up Github-CI right now. Everything is pushed there anyway, and it'd happily run along.
Kei_N has joined #ffmpeg-devel
<JEEB> yea quite true
<BtbN> The only way to really deal with spam is to do what Videolan is doing: Manually approve every new user
<JEEB> pretty much
Kei_N_ has quit [Ping timeout: 264 seconds]
Krowl has joined #ffmpeg-devel
<Lynne> an lpc function is broken
<Lynne> its written in inline asm
<Lynne> on x86
<Lynne> if there ever was a batman sign to summon me, its this
<jamrial> Lynne: go wild :p
<Lynne> looks easier than the window function, hopefully it won't be an oddysey
Kei_N_ has joined #ffmpeg-devel
Kei_N has quit [Ping timeout: 264 seconds]
AbleBacon has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
cone-474 has quit [Quit: transmission timeout]
Krowl has quit [Read error: Connection reset by peer]
<courmisch> autocorr_32_c: 9458.2
<courmisch> autocorr_32_rvv_f64: 1023.0
* courmisch looks at SSE and smirks
<haasn> is changing a field from uint16_t to int16_t an ABI break? (it was supposed to be signed)
<courmisch> it depends
<courmisch> a.k.a. yes
<courmisch> on most ABIs, 16-bit values are signedness-extended to register size
<courmisch> so unless you have a stack-based or a 16-bit calling convention...
<haasn> it's in a packed struct
<haasn> so there are no extra bits before the sign bit in the memory representation
<courmisch> okay well on most architectures, it will work but
<haasn> (well, a packed struct assuming the C compiler doesn't add unnecessary padding between uint16_t elements)
<courmisch> some architectures without native 16-bit signed loads might break
<courmisch> I mean, I am not sure if the ABI is allowed to assign semantics to the padding bits, but IIRC it does
<courmisch> s/does/is/
AbleBacon has quit [Remote host closed the connection]
<courmisch> if it's packed, then it can't break anything, but then again packed is not portable to begin with
AbleBacon has joined #ffmpeg-devel
<courmisch> it can break the API
<courmisch> but not the ABI, I mean
<haasn> hmm actually the question is irrelevant
Krowl has joined #ffmpeg-devel
<Lynne> courmisch: your checkasm test doesn't check the if(j==lag) branch
deus0ww has quit [Ping timeout: 240 seconds]
deus0ww has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
<courmisch> why is ff_vp9_subpel_filters using i16, when the values are i8
<courmisch> Lynne: this is 6 months old code that is being reposted, I don't remember the details, TBH :/
<Lynne> I don't think the bottom branch is even able to be triggered
<Lynne> for(j=0; j<lag; j+=2) cannot possibly result in j==lag at the end
<courmisch> Lynne: isn't that branch just a tail case for odd lags?
<Lynne> no, lag == 15 stops at 13
<courmisch> isn't that branch just a tail case for even lags?
<courmisch> you mean my test does not check skipping the branch?
<Lynne> oh, it is for even lags
<courmisch> yeah it's true, we should maybe add at least one odd value
<Lynne> but it makes zero difference whether its skipped or not
<courmisch> I thought it was some kind of manual unrolling. The RVV code does not have a special case for that
chainik has quit [Quit: (╯°□°)╯︵ ┻━┻]
<courmisch> I mean, i thought it was a tail to make up for manual unrolling in the main loop
<courmisch> IIRC, it is possible to roll the C code. I didn't check if it was faster or slower
chainik has joined #ffmpeg-devel
<courmisch> Lynne: so now, I seem to recall that I opted not to test odd cases since it was about testing assembler, not the C
<Lynne> okay, it does do *something*, it fails on fate-alac-16-lpc-orders
<Lynne> if your patch passes that test, its probably just unrolling tailcase
<courmisch> okay, now that I played the bad cop on VP9 and VVC MC patchset, we need a good cop
iive has joined #ffmpeg-devel
<Lynne> works
<Lynne> ...was this it?
<Lynne> I expected more from something lpc-related
<Lynne> my only issue is that I have to manually set the lag value in asm, somehow what I get as an argument is 8000 times more
<Lynne> x86inc does zero-extend int arguments, right?
<jamrial> no
<jamrial> use movsxdifnidn r#q, r#d
<courmisch> fix the parameter type to size_t
<jamrial> or do anything on that reg as a dword, to clear the upper 32 bits (if it can't be negative)
<courmisch> is it just me or is 500 KiB just for VVC MC optimisations is a bit much
<Lynne> jamrial: I ended up with lea lagq, [lagd*8], which should be the same (I had to mult by 8 anyway)
Krowl has quit [Read error: Connection reset by peer]
<jamrial> Lynne: shl lagd, 3?
<jamrial> might be faster than lea
<BtbN> hm, coverity seems to have taken the double-build okay enough
ccawley2011 has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
dionisis has quit [Quit: WeeChat 3.8]
<Lynne> jamrial: that works, does that zero-extend it somehow?
<jamrial> Lynne: yes, doing anything on 32bit regs clears the upper 32 bits
<Lynne> ah, good to know, thanks
<Lynne> autocorr_6_c: 125870.1
<Lynne> autocorr_6_sse2: 28715.1
<Lynne> everything with fma3 supports avx, right?
<jamrial> yeah
darkapex has quit [Remote host closed the connection]
darkapex has joined #ffmpeg-devel
mkver has quit [Ping timeout: 260 seconds]
mkver has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
dionisis has joined #ffmpeg-devel
<Lynne> patch sent, 8x gain on fma3
cone-549 has joined #ffmpeg-devel
<cone-549> ffmpeg Michael Niedermayer release/7.0:af25a4bfd250: Update for FFmpeg 7.0.1 release
<Lynne> (minor changes done locally - reduced #vector regs used to 3, forgot to remove testing code)
<jamrial> Lynne: https://pastebin.com/raw/2VNEZ7C3 i'm not seeing any gain here
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
<Lynne> jamrial: run with higher --runs
<jamrial> no difference
wcpan has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
wcpan has joined #ffmpeg-devel
Livio has quit [Ping timeout: 264 seconds]
<Lynne> multiple times?
<Lynne> the results are very noisy
<jamrial> i consistently see similar or worse results than c, regardless of seed and runs
<jamrial> i even forced len to be a fixed value rather than vary depending on seed
AbleBacon has quit [Read error: Connection reset by peer]
<Lynne> what are you running on?
<jamrial> win64
<Lynne> oh, try disabling vectorization
q66 has quit [Ping timeout: 260 seconds]
<Lynne> err, -O0
<jamrial> for what purpose?
<jamrial> these functions need to be faster than the c ones in a real world scenario, not with unoptimized debug compile time settings
<Lynne> to see the gains
<Lynne> and we don't rely on compilers optimizing, we have plenty of asm functions which may be slower than a compiler vectorizing
<jamrial> we don't vectorize
<jamrial> it's disabled in configure
<thardin> yoyo
<thardin> how are people doing?
<thardin> I have a set of UB pvatches in the works
<Lynne> jamrial: doesn't really stop all compilers
<Lynne> clang's vectorization is enabled by default and still runs
<jamrial> it stops mine
<jamrial> i use gcc
<Lynne> gcc can still do something on trivial loops, I'm sure, we disable tree vectorization
<jamrial> i just looked at the disass of the c version and i see mulsd and addpd only
<jamrial> no vectorization
ccawley2011 has quit [Read error: Connection reset by peer]
<Lynne> I can replicate even with default gcc here, though at 1.5x faster for SSE rather than 4x
q66 has joined #ffmpeg-devel
<Lynne> it may be vectorizing still, you can't tell just by mulsd and addpd
<Lynne> yup, it did vectorize in my case, add rax, 0x2
NotWarcop has joined #ffmpeg-devel
Warcop has quit [Ping timeout: 260 seconds]
<jamrial> Lynne: isn't that because the j==lag chunk in the c version increases i by 2?
<Lynne> no, that happens later on, that counter is r10 in my case