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 8.0 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
DauntlessOne4985 has quit [Read error: Connection reset by peer]
<haasn>
Lynne: why do I get [av1 @ 0x1391c180] Your platform doesn't support hardware accelerated AV1 decoding. spam when just ingesting av1? I'm passing -hwaccel none
minimal has joined #ffmpeg-devel
<wbs>
haasn: do you have dav1d enabled in your build?
<haasn>
oops, no :)
<haasn>
maybe with -hwaccel none it should error out with "no decoder available" though
<haasn>
instead of auto-trying vulkan hwaccel
<BtbN>
wbs: did you see my ping about the llvm-mingw build issues? I have now worked around it by passing --with-clang to the build script. My interpretation of the issues is that it was building llvm with gcc, but using lld to link, and that failed miserably.
<BtbN>
I would like to switch back to building clang with gcc though, since gcc is significantly faster at it
<BtbN>
(2h for a gcc based build vs. 3h for a clang based one)
<wbs>
BtbN: hmm, no, that doesn't ring a bell - can you give a link?
<BtbN>
I tried this with both a commit of llvm-mingw from a few weeks ago, when it was still the RC, and latest master. Both fail in the same way, even the ones that worked fine before. So not sure what changed.
<BtbN>
I had it succeed a build with lld installed on the system before as well. So I really don't get what triggered that break
<wbs>
BtbN: hmm, so on linux, building llvm with gcc, but linking with lld, fails? but if compiling with clang instead of gcc it succeeds?
<BtbN>
yeah
<wbs>
what base distro is that?
<BtbN>
Ubuntu 25.10
<BtbN>
You can straight up use my docker base image as a testbed
<wbs>
(btw, I don't see any ping of me anywhere in that thread)
<BtbN>
Like two weeks ago or so this _worked_, on the same base image
<BtbN>
wbs: I pinged you here
<wbs>
BtbN: oh, now i see
<wbs>
sorry, yeah I missed that ping
<BtbN>
This really can only be caused by something Ubuntu did in the last ~two weeks
<BtbN>
But yeah, if you want a pre-made env you can instantly reproduce it in, it's ghcr.io/btbn/ffmpeg-builds/base:latest
<wbs>
anyway, this is weird indeed. "luckily" it sounds squarely like an upstream llvm bug really (even though the llvm-mingw configuration of preferring lld, if it is available, is causing it somewhat). I'll see if I can reproduce it and report further upstream
<wbs>
ok, will try that
<BtbN>
I had similar experiences when trying to mix gcc+lld in my builds, for faster linking
<BtbN>
it just failed on absolutely random things that made no sense to me, so in the end I stuck to bfd
<wbs>
sounds like gcc has started doing something that (older?) lld doesn't like
<BtbN>
I'd assume neither gcc nor lld in Ubuntu 25.10 are all that old tho
<BtbN>
But yeah, likely Ubuntu updated gcc (or lld), and something in the new combo of versions clashes
<wbs>
yeah, so potentially not fixed in latest lld in that case either
<wbs>
anyway, on the topic of faster builds; I do recommend using the prebuilt binaries of llvm-mingw - since the last couple of versions, they're built with PGO, which makes them like 30% faster than before. it's a huge pain in the ass to build though, as you end up having to build LLVM ~3 times instead of just once
<wbs>
(it's possible to replicate in your own from-source builds by doing like "./build-all --full-lto ~/temp-stage1 /opt/llvm-mingw", but it takes a long time - too long to run all in once shot on public github actions)
<BtbN>
I do have access to a bunch of goodies from GitHub, including their "large" runners
<BtbN>
but I would screw over all my forks by using them :D
<wbs>
oh, nice - how does one get access to that? :P
<BtbN>
They just considered me a "Valuable contributor to Open Source", since I own a repo with nearly 10k stars. Gave me free unlimited premium copilot and a bunch of other stuff
<wbs>
oo, nice
Arcitec has quit [Quit: Arcitec]
Arcitec has joined #ffmpeg-devel
<JEEB>
yea, I think a lot of OSS maintainers get free premium
<BtbN>
Though every time I tried their Copilot stuff, I found it comically shit
<JEEB>
yea the real problem is getting the problem case minimized
<wbs>
but in order to report upstream, I don't want it to depend on "build on this third party image", and not on building with llvm-mingw build scripts, but just a plain cmake build of llvm, on base ubuntu + some minimal set of packages
<BtbN>
Yeah, what I mean is that I expect this to fail on any up to date Ubuntu 25.10 which has gcc and lld installed
<wbs>
yes, the bug reproduces nicely on plain ubuntu 25.10, in a setup to just build a small part of llvm
<wbs>
(unfortunately a large number of binaries _do_ build succesfully, so the reproducer to looking into the lld bug is essentially "all of the llvm source", which can be painful, but maybe it can be pinpointed to individual object files)
GewoonLeon has quit [Read error: Connection reset by peer]
GewoonLeon1 has joined #ffmpeg-devel
GewoonLeon1 is now known as GewoonLeon
GewoonLeon has quit [Client Quit]
GewoonLeon has joined #ffmpeg-devel
<BtbN>
wbs: how about using mold? :D
<BtbN>
Is that supported?
<wbs>
I think it should be fine
<BtbN>
In any case, an option to actively pick a linker would already help. Doesn't need a heuristic to auto-pick one.
GewoonLeon has quit [Ping timeout: 265 seconds]
<wbs>
yeah that's probably doable too
<wbs>
I'll try to whip something up for that tonight
<BtbN>
it's no rush, the base image with clang-built-clang is built now, and will likely last a few weeks
<wbs>
ok, maybe I'll wait for more investigation upstream then, before deciding on how to work around it
<BtbN>
I mean, an option to pick a linker is nice no matter that outcome
<BtbN>
mkver: the author of that PR did some crazy force-pushing, and it matched a commit already on master, which instantly auto-closed the PR, cause already merged
<haasn>
mkver: seems the author of that PR manually force pushed it to the latest master state
<haasn>
something like that, yeah
<haasn>
and I happened to own the last commit on master at the time
<BtbN>
Why the PR lists 400+ commits and not 0 in that case I can't tell
<mkver>
Ok, thanks for the info.
<BtbN>
It looks like the author flat out deleted their fork
Everything has quit [Read error: Connection reset by peer]
Everything has joined #ffmpeg-devel
Arcitec has quit [Remote host closed the connection]
<jamrial>
BtbN: add mkver to the org in forgejo
<BtbN>
Didn't I already do that?
<BtbN>
let me check
<BtbN>
ah, no 2FA. mkver please add 2FA to your account
<mkver>
Doesn't this require a smartphone?
<JEEB>
no
<JEEB>
you just need something that can generate those codes, on PCs there are multiple cli scripts as well as general support in passphrase systems like keepassxc
<BtbN>
It just kinda defeats the point if your second factor is on the same device
<ramiro>
haasn: a simple "ffplay /opt/samples/lena.jpg" prints the following "[ffplay_buffersink @ 0x7f465c024980] The "alpha_modes" option is deprecated: set the supported alpha modes". I haven't checked, but I suppose this is something related to your work on alpha_mode?