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
<BtbN>
Actually, seems like that is just flat out not possible out of the box
<Lynne>
BtbN: tagging in general, or file name scanning, or commit name scanning?
<BtbN>
There's only a premade action to label based on which files changed
<BtbN>
That action has open prs since 2021 to add also matching the title, but it was never merged.
<BtbN>
kasper93: It simply already does exactly what you describe. That's why it calculates the hash of all filenames and uses it as key. It'll only upload if the key does not exist on the cache storage.
<BtbN>
If your approach also does not work, it simply means the hash somehow changed
<kasper93>
If it takes 1m32s then it clearly doesn't work
<kasper93>
and my approach probably has syntax error, I don't know if I used format correctly
System_Error has quit [Remote host closed the connection]
<kasper93>
and hash is the same
<kasper93>
Cache restored from key: fate-suite-7360513f69e36c09a3ef48de7eac7e4cb1244c6509f9609d4b38a7dcbab44709
<kasper93>
Cache saved with key: fate-suite-7360513f69e36c09a3ef48de7eac7e4cb1244c6509f9609d4b38a7dcbab44709
<kasper93>
I agree that it's not expected, because generally those save actions shouldn't override the existing entry
<BtbN>
Does the explicit save one maybe need a flag to not upload the same key?
System_Error has joined #ffmpeg-devel
<BtbN>
Nah, it just plain always uploads and does indeed need such an if
<BtbN>
Though it still seems weird, will need to read it's code tomorrow
indecisiveturtle has quit [Ping timeout: 260 seconds]
indecisiveturtle has joined #ffmpeg-devel
MisterMinister has quit [Remote host closed the connection]
MisterMinister has joined #ffmpeg-devel
TheVibeCoder has joined #ffmpeg-devel
<fflogger>
[newticket] err2zero: Ticket #11679 ([tools] Segmentation fault when processing malformed AVI files with CFHD codec due to null function pointer call in buffer management.) created https://trac.ffmpeg.org/ticket/11679
<fflogger>
[newticket] err2zero: Ticket #11680 ([tools] Double-free memory corruption in DSS (Digital Speech Standard) format demuxer during cleanup phase, leading to program abort.) created https://trac.ffmpeg.org/ticket/11680
<fflogger>
[newticket] err2zero: Ticket #11681 ([undetermined] Segmentation fault in binary seek function when processing malformed MPEG files due to null pointer dereference in index_entries array access.) created https://trac.ffmpeg.org/ticket/11681
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 276 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
<fflogger>
[editedticket] mkver: Ticket #11679 ([tools] Segmentation fault when processing malformed AVI files with CFHD codec due to null function pointer call in buffer management.) updated https://trac.ffmpeg.org/ticket/11679#comment:1
<fflogger>
[editedticket] mkver: Ticket #11680 ([tools] Double-free memory corruption in DSS (Digital Speech Standard) format demuxer during cleanup phase, leading to program abort.) updated https://trac.ffmpeg.org/ticket/11680#comment:1
j45 has quit [Ping timeout: 248 seconds]
j45 has joined #ffmpeg-devel
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
<fflogger>
[editedticket] mkver: Ticket #11681 ([undetermined] Segmentation fault in binary seek function when processing malformed MPEG files due to null pointer dereference in index_entries array access.) updated https://trac.ffmpeg.org/ticket/11681#comment:1
<fflogger>
[newticket] ianshade: Ticket #11682 ([avcodec] The vmix (VMX1) decoder does not decode interlaced files) created https://trac.ffmpeg.org/ticket/11682
<kierank>
mkver: much respect for your patiene
<kierank>
patience*
<kierank>
TheVibeCoder: you could learn a few things from mkver
<TheVibeCoder>
?
<kierank>
patient enough to reply to all those troll tickets about avconv, saying libav is dead
<greenjeans>
Just stopping by to give kudos and a big thanks to devs of ffmpeg! been using it this week to make myself a very simple audio (and now video too) player and it works great!
<Lynne>
this bot is fast, the page hadn't even finished refreshing when the message came through
ccawley2011 has quit [Ping timeout: 244 seconds]
ccawley2011 has joined #ffmpeg-devel
<Traneptora>
do we want to send a message for PRs sync'd and commented, or just opened?
<BtbN>
I turned of the sync-notifications here
<BtbN>
sadly can't do that for the mail notifications
<Lynne>
let them drown
<BtbN>
Nicolas is gonna have a hard reality check here, in that literally everybody but him is depserate to finally move on from the ML.
<BtbN>
Pretty much the only discussion was the exact what and where, I haven't seen a single person but him oppose the move in general.
<Lynne>
I get the feeling michaelni is thinking that a significant amount of developers will remain on the ml
<BtbN>
It'll just not be from one day to the next
<Lynne>
the floodgates haven't even opened and we're getting serious PRs on the instance
<BtbN>
I also find it very borderline just using "that monolithic thing" as an apparent insult. Cause if the single ML server goes down, it's just as gone as Forgejo.
<JEEB>
yea
<BtbN>
the git repo itself is distributed no matter what
<BtbN>
Even issues and PRs are "distributed" in the same fashion to everyone who has e-mail notifications enabled.
lexano has quit [Ping timeout: 252 seconds]
<TheVibeCoder>
push now
<TheVibeCoder>
without reviews
<TheVibeCoder>
do not wait
<TheVibeCoder>
push now
* another|
pushes TheVibeCoder on the ignore list
<TheVibeCoder>
Thanks
<TheVibeCoder>
your welcome
<another|>
It'd be easier if you wouldn't change nicks all the time
lexano has joined #ffmpeg-devel
<kasper93>
BtbN: one thing you can argue about "that monolithic thing" is that with email patches are distributed to everyones inbox, with web forge you get them mostly as a PR in "one place"
<kasper93>
of course this is git, you can mirror this to any other place
<BtbN>
Well, like I said, Forgejo also distributes all communication to your inbox
<BtbN>
and the patches themselves are in at least one more git repo
<haasn>
I still have my patches on my machine
<haasn>
so the bus factor (as it were) is still 2
<BtbN>
That's what I meant
<BtbN>
Yes, with a ML the patches themselves are distributed a lot more
<haasn>
which is far more than sufficient for something as transient as an unreviewed patch
<kasper93>
I agree with you, I'm trying to play devils advocate
<BtbN>
But that seems like a terrible argument to just remain stuck on MLs forever
<kasper93>
and it seems thier streaming services are using this, because I've seen it first from some guy reporting an different issue with some chinese file
<JEEB>
yea I see it mentioned on bilibili's blag
<JEEB>
also nice that there's official test content
<TheVibeCoder>
cant encode anything
<TheVibeCoder>
says no model
<TheVibeCoder>
is this AI crap?
<JEEB>
lol, they have specified specific neural networks for each profile?
<JEEB>
since -nn_type says 0 for main profile, 1 for LC profile
<jamrial>
grim
<JEEB>
but there is a model.bin in that repo
<JEEB>
78.1KiB so not exactly LLM or stable diffusion sizes
<BtbN>
I _think_ you can just write forgejo/upload-artifact@v4
<kasper93>
also, I kinda wanted to stress test things, we can not merge this, we can make it run once a day/week only on merges to master, whatever works best
<BtbN>
An issue it also creates is fights for runners
<BtbN>
Cause right now we have exactly one amd64 and one aarch64 one
<kasper93>
technically it could configure with coverage intrumetation and build once, it shouldn't alter the result of the tests
<kasper93>
thanks for the tip about upload action fork