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
<Compn>
i think there was a discussion about inline asm , forgot if it was on irc or the list
<Compn>
and why we still use it :D
<JEEB>
kurosu: x86_64 inline asm should not be a thing
<JEEB>
so lol if someone added a PR
<TheVibeCoder>
more likely intrinsics ?
<kurosu>
it was just to expose the condition for x86 32 bits of 6 GPRs. If there's .asm code for it, let the shim compile to code without such issues
<kurosu>
And the inline ATT asm can probably go
<haasn>
Is there a reason nullenc.c uses ff_interleave_packet_passthrough instead of the default interleave packet? it can cause filter graphs to get imbalanced when feeding both a complex vf and a complex af into -f null
<JEEB>
> It avoids the overhead of the packet list; furthermore, using ff_interleave_packet_per_dts() is wrong for the null muxer anyway, because said muxer accepts packets without timestamps, which ff_interleave_packet_per_dts() can't handle.
<haasn>
BtbN: how are permissions handled in forgejo? can I see somewhere the list of people with push access to a repo? who has permission to merge PRs? what about approving PRs?
<BtbN>
haasn: I don't know how the merge-bot works, if it's a literal bot or just a workflow running on a cron, but something like that is absolutely possible. Someone just needs to implement it
<haasn>
I also don't know, but I imagine we need to implement our own
<haasn>
I was moreso asking if forgejo has a good API for scripting something like this without too much effort
<haasn>
(or even has the built-in ability to schedule auto-merged based on conditions)
<BtbN>
I mean, it has the "auto merge once all required checks passed", which includes CI and a configurable amount of approvals
indecisiveturtle has quit [Ping timeout: 252 seconds]
<haasn>
could we create a CI job that auto-passes after 3 days without activity
indecisiveturtle has joined #ffmpeg-devel
<haasn>
(or perhaps 12 hours if the PR is marked with the security tag)
<haasn>
I imagine having open discussions also inhibits this auto merge?
<BtbN>
CI jobs on PRs only run on pushes
<BtbN>
And such a job would make it outright impossible to merge the PR prior to 3 days
<BtbN>
It'd have to be a new feature in Forgejo itself
<BtbN>
It also raises the question what happens if the PR still applies cleanly by then after a rebase, but is broken nontheless, i.e. some internal API changed in the meantime or something
<haasn>
this is where merge trains would help :/
<BtbN>
So the mechanism would have to involve an automatic rebase and full CI run at the very least, which suddenly gets very complicated
<haasn>
to be fair, that's no less brittle than the status quo ("rebase and fast-forward" also does not re-run CI)
<BtbN>
Yeah, if there is any doubt, rebase first (there is a button for it), and wait for CI
<BtbN>
can even hit the rebase button, wait a minute for CI to pick it up, and then click "merge when checks pass"
<haasn>
that's my usual workflow on gitlab
Compn has quit [Ping timeout: 248 seconds]
<haasn>
it doesn't have a "rebase and merge" button at all afaict
<haasn>
only a "rebase" button which then turns into "merge when CI passes"
<BtbN>
I could disable the rebase and merge button, and turn it into FF Only
<BtbN>
Then you would always need to explicitly rebase
<BtbN>
but I imagine that could get annoying fast, and you could spend a day rebasing, running CI, getting stuff pushes in the meantime, and having to start over
<haasn>
that's something a merge bot would definitely approve
<haasn>
improve*
<haasn>
because it would be capable of automatically rebasing, waiting for CI, retrying after conficts, and so on
<BtbN>
Yeah, but we'd first need to disable any and all manual pushing
<BtbN>
and then ONLY merge PRs via the bot
<BtbN>
We'd basically have built our own merge-train that way
<haasn>
yup
<BtbN>
instead of merging anything, merging means setting a label
<BtbN>
and a bot works through all PRs with the label one by one, rebasing it, testing the result, applying it or rejecting it on failure
<BtbN>
But as long as there are still numerous people who only push directly, for lack of a Forgejo account, that's impossible to sensibly implement
<ePirat>
BtbN, for some reason when I remove the new label it appears as if ffmpeg-devel did it, not me, is that expected?
<ramiro>
Lynne: I am going to submit a proposal for stf for the swscale aarch64 backend. is it ok if I copy part of your project's description, since it's almost the same thing?
<ePirat>
Yalda, why?
<ramiro>
Lynne: (also it seems you still have to write the milestones)
<Yalda>
ePirat: he is having a meltdown and calling me an idiot, without explicitly saying my name, for approving haasn's logging fix PR. which yes, I did read, and no I do not just click "approve".
<Yalda>
effectively calling me an idiot at least
<ePirat>
where?
<Yalda>
> Pushing without approval avfilter/vf_vignette: use AVFilterContext for logging
<Yalda>
in ML. I'm responding now
<Yalda>
He is gatekeeping
<Yalda>
over a trivial PR
<ePirat>
I didnt even get that email
<Yalda>
good honestly lol, it's a waste of disk and brain CPU
<ePirat>
this was a trivial change, what huge time could he even have invested looking into the code…
<Yalda>
literally wtf does he even do
<TheVibeCoder>
vibe code session
<Yalda>
I am not the biggest contributor fine. but besides bully people he is useless
<BtbN>
I don't remember the last time he has actually done review or non-hateful feedback
<ePirat>
supposedly maintains avfilter but hasnt done much on it in a long time…
<ePirat>
BtbN, same…
<ePirat>
I always hope he doesnt care about my patches due to his overly condescending reviews
<BtbN>
I have legitimately stopped reading his mails, it's pointless
<haasn>
I'm still nervous as long as he has push access
<BtbN>
the whole "look, I can make a stupid PR and no magic stopped me" thing was the last straw for me to care about what he has to say
<haasn>
because if he reverts a commit I believe the status quo is that the revert stands, to prevent revert wars
<haasn>
sadly nobody else in the TC seems to be currently active
<haasn>
at least I tried to have a TC vote against his (imo petty) objection
<JEEB>
huh, how did I miss that
<BtbN>
I have very weird mails from mailman since a couple days, and for the life of me can't figure out what triggers them
<BtbN>
Like, it keeps sending me a "Your mail to "Mailman" is held for Moderation", and I have no clue what is sending mails to mailman@ffmpeg.org
indecisiveturtle has quit [Ping timeout: 248 seconds]
pross has quit [Server closed connection]
pross has joined #ffmpeg-devel
<kurosu>
kasper93: for the change to vc1 dsp, I think the proper change is to stop building that file, as I think there is a nasm replacement
<kurosu>
lots of thinking here, but nevermind, I'm just cautious as I can't check myself
<kasper93>
kurosu: it's not in fact built when not needed. But there is fate-checkheaders targe, which basically compiles all .h as standalone compilation unit
<kasper93>
to find out issues like missing headers and what not
<kasper93>
it's only affected in this target
<kurosu>
ok, maybe going a bit above what you expected. I'm not sure of the value/"use case" (compiling for a Win32 target without nasm installed?)
<kurosu>
And I wrote the file I'm proposing to remove
<BtbN>
kasper93: I forced off the LTO SVT-AV1 is doing, lld seems to work now
<BtbN>
But I wonder if it's all that much faster with THAT many static objects
<kasper93>
does svt force enable lto?
<BtbN>
yes
<kasper93>
hmm
<BtbN>
it does not really consider static linking in its build system, it barely works
<kasper93>
did you try how much time does it take with lld?
<kasper93>
With bfd it was "Successful in 1h24m24s"
<kasper93>
kinda stupid
<BtbN>
On my local PC it somehow never took anything close to that
<BtbN>
so i'm a bit confused why it does take THAT long on the Forgejo runners
<BtbN>
kasper93: on my builds on GitHub, building FFmpeg takes 10~15 minutes, that's full compile and link, with bfd, with LTO enabled in SVT-AV1.
<BtbN>
So I'm quite baffled what's going on for linking to take 40+ minutes suddenly
ngaullier has quit [Ping timeout: 252 seconds]
<ePirat>
that seems unusually slow
<kasper93>
kurosu: ah, I didn't understand, you mean to completely remove this
<kasper93>
I would defer to another pr such change
<kasper93>
ePirat: note that this is `fate-build` target, which is building all examples/tests binaries
<kasper93>
that's a lot more linking than normal
<BtbN>
maybe it'd be a lot faster if we switched to --enable-shared for it?
<BtbN>
Then it only has to deal with the "huge ball of static libs" once
<kasper93>
though it seems suprisingly slow anyway
<BtbN>
like this it has to process all of them for every single thing it links
<kasper93>
probably would help, but I would also test lld on forgejo, just for my amusment
<BtbN>
need to add -fuse-ld=lld to ldflags and ldexeflags
<kasper93>
still linking all shared libs will add up
<kasper93>
BtbN: I know, but wasn't working yesterday, is the image updated now?
<BtbN>
GitHub should be done building new images by now
HarshK23 has joined #ffmpeg-devel
<BtbN>
"./build.sh win64 gpl 0.65s user 1.65s system 1% cpu 2:18.68 total" that's with lld. Let's re-try with bfd
<kasper93>
btw. I like this warning
<kasper93>
h264chroma.c:54:18: warning: ‘size’ is used uninitialized [-Wuninitialized]
<kasper93>
for (int size = 0; size < 4; size++) {
<kasper93>
like...
<BtbN>
Does it shadow another variable with the same name?
<kasper93>
no
<BtbN>
make followed by "make install" still sometimes double-links for me, due to the weird "remove intermediates" thing
<BtbN>
"./build.sh win64 gpl 0.57s user 1.65s system 1% cpu 2:23.72 total" this is with bfd. Only marginally slower really
<kurosu>
kasper93: yes, but ok about another pr
<BtbN>
"./build.sh linux64 gpl 0.67s user 1.62s system 2% cpu 1:35.98 total" linux bfd vs. "./build.sh linux64 gpl 0.55s user 1.65s system 2% cpu 1:26.74 total" linux mold