00:16 <Marth64> forgejo is pretty fast

00:18 <BtbN> depends on the server it runs on

00:19 <Marth64> true..i am just running it locally and had a positive first impression

00:22 <BtbN> FFmpegs stuff is also getting hit A TON by LLM scrapers.

00:22 <BtbN> Basically every time trac went down the last couple days, it was cause of that

04:13 <elenril> didn't you rangeban most of them?

08:12 <cone-216> ffmpeg Niklas Haas master:ee903c4786ed: tests/swscale: fix sscanf return value check

10:03 <cone-216> ffmpeg Martin Storsjö master:4b524649ff96: checkasm: Print benchmarks of C-only functions

10:04 <JEEB> BtbN: btw did you find the fedora git forge comparison useful?

10:07 <cone-216> ffmpeg Martin Storsjö release/7.1:10aaf84f855d: checkasm: Print benchmarks of C-only functions

11:35 <wbs> JEEB: BtbN: did someone find the actual comparison document? I only saw a lot of process documentation about their working group and planning on looking at it (and then that they had done it), but not much about the comparison and actual issues/points raised?

11:59 <wbs> beastd: any further comments on the updated fate-list-failing patch (https://patchwork.ffmpeg.org/project/ffmpeg/patch/20241209215004.72788-1-martin@martin.st/)? otherwise I'd go ahead and push that soon

12:10 <beastd> wbs: no more comments, fine for me!

12:10 <wbs> great, thanks!

12:11 <beastd> wbs: thank you! secretly i also wished for that functionality multiple times :)

12:11 <wbs> I've done the "cat *.rsp | cut | grep" sequence way way too many times manually, without bothering to automate it until now :P

12:12 <cone-216> ffmpeg Martin Storsjö master:1e76bd2f394a: fate: Add a target for listing failed tests

12:51 <thardin> is there a spec of fragmented mp4 somewhere that isn't apple's godawful online thing?

12:52 <thardin> oh wait that doesn't even specify fragmented mp4. wonderful

12:53 <wbs> thardin: c061988_ISO_IEC_14496-12_2012.pdf specifies most of it I would say

12:53 <wbs> as part of the whole spec, not separately explained as "how does fragmented mp4 work"

12:53 <wbs> but that doc would be my go-to reference on it

12:55 <thardin> fanks

12:56 <thardin> amazingly not even google will give a useful result for "fragmented mp4 specification"

12:58 <thardin> the mfro parsing is potentially slightly broken at the moment in that it doesn't check that it's actually mfro, so a useless seek is often performed

12:58 <elenril> >not even google

12:59 <elenril> google has been getting progressively less useful in the last decade

12:59 <elenril> clearly the world needs a distributed foss search engine

12:59 <thardin> yacy

12:59 <thardin> there's even a browser with yacy integration built in. I forget its name

13:00 <elenril> nobody's using it, so I'm assuming it doesn't work all that great

13:00 <thardin> I only revert to google when ddg or startpage don't help

13:00 <thardin> oh yeah searx too

13:01 <elenril> the results are still google though

13:02 <elenril> Lynne: any progress on the vulkan issue?

13:18 <BtbN> wbs: yeah, I read a bunch of "mini interviews" they did, in what their developers want, and then they evaluated which service fullfills which in what way.

13:19 <BtbN> The outcome of that basically is that Forgejo fullfills all of them while being much more lightweight and faster.

13:19 <wbs> hmm, ok

13:19 <BtbN> They did however not check for the availability of cli tools, which some ffmpeg devs have asked for a couple times

13:19 <BtbN> gitlab does have those

13:19 <wbs> I guess in our case, it's mostly a case of whether we want to host things ourselves vs piggyback on videolan's gitlab

13:20 <BtbN> Well, we can also host Gitlab ourselves

13:20 <wbs> yes, of course, but the fact that we could avoid is a small extra point on the gitlab side

13:21 <BtbN> There's apparently multiple people who are very against getting dependent on Videolan

13:21 <wbs> and then there's the whole tradeoff between small and nimble vs large and more featureful (and slow, both runtime and evolution), vs maturity of tools

13:24 <BtbN> My main pro-Forgejo argument is that Gitlab updates are very involved, but often critical.

13:24 <BtbN> While Forgejo updates look to be very straight forward

13:25 <wbs> I ran a gitlab setup (with the omnibus packaging) for maybe 7 years or so, with very little intervention needed, just apt-get upgrade regularly

13:26 <wbs> I think it required me to do something manually outside of that maybe once or twice

13:30 <elenril> gitlab is also owned by a corp

13:30 <wbs> yes, for better or worse

13:30 <elenril> which could be bought by microsoft at any time

13:36 <BtbN> Well, Forgejo has a community of which I can't judge the stability. So there could be another fork in a few years, or who knows.

13:58 <Lynne> forks often happen in federated projects, but pretty much all offer forwards and backwards compatibility by providing migrate/revert scripts for the database

14:00 <Lynne> all search engines are pretty awful these days, a lot of content is forever lost, even if I know the exact unique sequence of words to find a webpage and know for a fact they have scraped that website

14:01 <Lynne> yandex is the least bad one because they didn't (probably not enough resources) update their search algorithms and database

14:02 <Lynne> elenril: I'm looking at the code again, will send a patch once I figure out the one-line change I need to make my patch work

14:03 <Lynne> https://0x0.st/XhEk.diff if you'd like to check yourself if I've made obvious mistakes I somehow can't see

14:04 <elenril> you're missing strcpy((void*)(1 << 64), "hail satan");

14:04 <Lynne> works for the case where frame_params isn't called, but when it gets called, there's some change within vulkan that validation layers don't pick up, and drivers just give up on

14:05 <Lynne> how did you know that command? there's an extension to automatically call it in vulkan, but its been under NDA for years now

14:06 <elenril> it's been revealed to me in a dream

14:07 <elenril> BtbN: did the trac logger die?

14:08 <BtbN> hm, it got disconnected, but did not exit

14:08 <BtbN> so never got restarted

14:14 <elenril> mkver: just FYI I just sent patches to make refstruct public

14:14 <elenril> you may or may not care about that

14:21 <fflogger> [editedticket] MasterQuestionable: Ticket #11341 ([avcodec] Utilize multi-threading like "fre:ac" for some audio encodings) updated https://trac.ffmpeg.org/ticket/11341#comment:1

14:23 <another|> #l

14:26 <jamrial> mkver, elenril: re refcount, i wrote this some time ago https://github.com/jamrial/FFmpeg/commit/5be65e57383fcd496d4b2bb1091bdda3fd223472

14:26 <jamrial> not sure how useful it could be, but i thought it was nice to have the option

14:28 <elenril> I don't see the use case

14:28 <jamrial> originally i came up with it to create refcount objects for buffers allocated by APIs like those in lavu, but then i realized they would not allocate the extra needed bytes

14:38 <mkver> jamrial: There are several problems with this approach: It only cares about size, not alignment; it just presumes that the allocator matches our av_free(); and extern const size_t ff_refstruct_size does not work when done publically with DLLs on windows (not without the proper annotations anyway). Furthermore, it basically exposes implementation details. And I also don't see a usecase for it.

15:04 <jamrial> mkver: like i mentioned above, the usecase that prompted this is not even possible

16:02 <fflogger> [editedticket] w_boba: Ticket #11014 ([undetermined] ac3 demux and/or decode problem) updated https://trac.ffmpeg.org/ticket/11014#comment:4

17:01 <beastd> wbs, elenril, Lynne: Don't think there is one ideal "software forge" around, but from the ones I have looked at forgejo seems to be the best candidate.

17:05 <beastd> gitlab despite all its other problems it may have or not, has the problem that it is "open core". are there any open core success stories? (I mean for the open source community.)

20:07 <fflogger> [editedticket] chuckwoodchuck: Ticket #11330 ([ffmpeg] When recording, audio duration is shorter by the time it takes to spin up the video) updated https://trac.ffmpeg.org/ticket/11330#comment:3

21:22 <cone-741> ffmpeg Michael Niedermayer master:682d710bcb8d: avcodec/aac/aacdec_usac: Clean ics2->max_sfb when first SCE fails

21:22 <cone-741> ffmpeg Michael Niedermayer master:a518b5540de4: avcodec/aac/aacdec_usac: Dont leave type at a invalid value

22:55 <michaelni> jamrial, this IAMF timeout is still reproducable: https://issues.oss-fuzz.com/issues/42534313 (this was 67912 google renumbered everything for extra confusion) iam also not sure the new one has you in CC, as its no longer possible for us to change the CC (its a feature of the new system)

23:29 <jamrial> michaelni: i think i found where it's taking so long

23:30 <jamrial> a for loop of 42524428 iterations. but the problem is that it's not reading anything in it, so we can't do avio_feof() to abort