00:03 <thardin> if chris sawyer could write rollercoaster tycoon in assembly then surely we could write a browser in assembly as well

00:04 <thardin> in fact I think such a thing even exists for one of those floppy disk distros. I recall there being one that's written entirely in assembly

00:04 <thardin> and it has network support

00:06 <kasper93> probably no js support, you wouldn't pass anime girl check

00:12 <thardin> you can probably make a working but not fast js implementation in asm

00:14 <thardin> anyway I feel the discussions the last year or so have clearly revealed a need to nail down what is within scope for this project. but such work also requires that enough developers understand that libre multimedia is more than just ffmpeg

00:15 <thardin> I sometimes wonder what we could be building if we didn't waste time reimplementing things

01:21 <kierank> thardin: not gonna happen

01:22 <kierank> There is a loud subsection that wants anything

03:34 <fflogger> [editedticket] atayeem: Ticket #11640 ([avfilter] Specific combination of timeclamp, fps, and count on showcqt causing crash) updated https://trac.ffmpeg.org/ticket/11640#comment:1

03:55 <softworkz> back home, here are some answers to questions that came up:

03:55 <softworkz> kasper93: "does softworkz guy use AI to generate this code and emails?" <= I've sent 2 or 3 AI generated emails and they were marked as such. There was no AI in volved in any other message. For code: the only AI generated "code" that I've submitted was the sed command (and comments) in common.mak plus the AVDict2 experiment (where it was stated as such). Anyway, large parts of the code that I'm submitting were written long before AI was even a

03:55 <softworkz> thing.

03:56 <softworkz> .

03:56 <softworkz> TheVibeCoder: "isnt codebot softworkz thing? just asking, looks little strange to me." <= it's not my invention, I've just adapted it. Please see here: https://ffmpeg.org/pipermail/ffmpeg-devel/2025-May/343806.html

03:56 <softworkz> .

03:56 <softworkz> jamrial: "why am i still seeing "rm fftools/resources/graph.html.gz fftools/resources/graph.css.min.gz fftools/resources/graph.css.min" at the end of compilation?" "i thought there were like two different patchsets that fixed this?" <= I won't push mine without review(s). Patchset: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=14814

03:56 <softworkz> BtbN: "Softworks like it this way for some reason, so argued a lot with all of them" <= it's how make is supposed to work - no more, no less. But for god's sake, if people think it's better to go the "workaround route" via the .SECONDARY target, then go for it. I won't object anymore if that will make everybody happy.

04:03 <softworkz> .

04:03 <softworkz> btw, I like some of the killer-feature/browser jokes :-)

04:30 <compnn> thardin, the asm web browser with os on floppy is this one https://www.kolibrios.org/en/

04:44 <compnn> thardin: re ffmpeg future. no one has a clue. everyone wants their pork project. some people just say accept everything (because why argue), and others want to control what gets in and gets deleted

04:46 <compnn> i think j-b said he wants to move game codecs into its own dir in libavcodec or so? too many files to scroll ? its not deleting anything. seems reasonable enough

04:46 <compnn> patch welcome ?

04:48 <compnn> https://x.com/awesomekling/status/1887853631174521246/photo/1

05:49 <fflogger> [newticket] free_movie_user: Ticket #11643 ([undetermined] Merge Error on new build(GyanD)) created https://trac.ffmpeg.org/ticket/11643

06:17 <wbs> haasn: I did manage to bisect the clange change related to your branch; the change is https://github.com/llvm/llvm-project/commit/7a086e1b2dc05f54afae3591614feede727601fa (or a later fixed version of it in 627746581b8fde4143533937130f420bbbdf9ddf)

06:18 <wbs> haasn: so even if this is a compiler fix, whether it's a bug or a language extension is a bit hazy - if possible it's probably best to not rely on it (e.g. memset the whole struct or something else if that makes it work with earlier compilers too)

07:38 <thardin> compnn: more structure in the tree sounds like a decent idea

07:39 <thardin> lavfi also. separate audio and video filters pls

07:41 <thardin> kierank: sadly

07:41 <thardin> lots of devs with junior mindset

07:46 <TheVibeCoder> thardin is nobel winner

07:48 <cone-928> ffmpeg Peter Ross master:93368029e36d: avcodec/g728_template: do_hybrid_window() template

07:48 <cone-928> ffmpeg Peter Ross master:a0b9d61fafe6: avcodec/g728_template: make hist parameter constant

07:48 <cone-928> ffmpeg Peter Ross master:a107340035d9: avcodec/g728dec: G.728 decoder

07:48 <cone-928> ffmpeg Peter Ross master:a3c900a0c489: avcodec/lpc_functions: compute_lpc_coefs: add starting lpc order and err cache parameters

07:48 <cone-928> ffmpeg Peter Ross master:52f62468aa1b: avformat/g728dec: raw G.728 demuxer

07:48 <cone-928> ffmpeg Peter Ross master:dee4edfa63dd: avformat/riff: G.728 muxing and demuxing

07:48 <cone-928> ffmpeg Peter Ross master:5a8c2b2b506c: avformat/aiff: G.728 muxing and demuxing

07:48 <cone-928> ffmpeg Peter Ross master:e6298e075943: avformat/rtp: G.728 muxing and demuxing

07:51 <thardin> no, just sysiphus pushing his boulder up the ffhill

08:50 <softworkz> kasper93: "this whole graph thing in ffmpeg is basically poor mans lavfi-preview" <= lavfi-preview is nice. I've done something similar in 2020 (https://gist.github.com/softworkz/33d2906e8e3c99bfbc31647398e245d5), yet not on the same conceptual path.

08:50 <softworkz> kasper93: The graphprint feature on the other hand is something very different. It is a built-in FFmpeg output format, while the others are applications of their own. The focus for the graphprint feature is on AVAILABILITY - i.e. that everybody can use it instantly without installation of pre-requisites or additional applications. It's meant to provide a quick and useful view for learning FFmpeg and also for understanding how FFmpeg sees and

08:50 <softworkz> executes complex command lines and for viewing the outcomes of filter format negotiation. I see no competition with lavfi-preview at all. Both are very useful but in different ways.

08:55 <TheVibeCoder> ban softworkz

08:55 <softworkz> why?

08:56 <TheVibeCoder> u evil

08:56 <softworkz> yea, that's true :-)

08:58 <softworkz> pleased to me you - hope you guess my name....

09:57 <llyyr> how can the focus be on availability if it requires you to have a browser? lol

09:58 <psykose> browsers are widely available

09:59 <TheVibeCoder> yea, browswer are everywhere

09:59 <psykose> even if it hard required chromium it would be more accessible than a random program :-)

09:59 <psykose> people hate hearing it but it's true

10:07 <haasn> Did FATE die? It's not showing my series from 2025-06-22

10:08 <haasn> wbs: that's a bit odd

10:08 <haasn> the only thing that strikes me as relevant is the zero init behavior on unions

10:09 <haasn> but we usually zero init as = {0}

10:09 <haasn> with the union not being the first field here

10:09 <wbs> haasn: well this change still applies here I think; previously it only zero initalized the first member of a union, and considered the rest of the union storage as uninitialized, which the optimizer then can make other assumptions based on

10:10 <haasn> but if I understand the wording correctly then it still applies here; the union field is implicitly zero-initialized which makes clang only initialize the first field explicitly

10:10 <haasn> yeah

10:11 <haasn> so to avoid it, the best thing we could do is to ensure that the first field covers the full size of the union

10:11 <haasn> or else, just try and avoid implicitly zero-initializing unions

10:11 <wbs> yeah, pretty much

10:11 <haasn> (the former is easily asserted with a sizeof(field) == sizeof(field.first))

10:11 <haasn> I'm leaning towards the former as a solution that avoids accidental errors

10:12 <wbs> clearly a thing where I'd consider it mostly a bug in the earlier versions, but a kinda annoying one, and clang <= 19 is in quite widespread use, so it's not really possible to just flat out refuse to support that either

10:37 <nevcairiel> with all the strict typing everyone invokes everywhere, unions always kinda puzzled me

10:37 <nevcairiel> here have this block of memory that can be any of these things, and we carry no information what it is

10:39 <wbs> another funny thing also is that unions are specified differently for C++; in C it's valid to e.g. use a union to get the bit representation of a float, but in C++ that's invalid

10:40 <pross> another reason to hate c++

10:40 <wbs> (in C++, unions only have one "active member" at a time, so it's more of a shared storage utility, not usable for reinterpreting things)

10:40 <wbs> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3065.pdf contains lots of other surprising gotachas between C and C++

10:44 <BtbN> softworkz: my only real concern is that it looks ugly. And I also only think of it as a cosmetic problem, so don't care all too much.

10:44 <BtbN> Only actual potential issue would be bug reports from people thinking it's unintended cause it looks "off"

10:44 <BtbN> If styling that line into our usual "RM ..." would be possible, that'd solve that at least

11:00 <softworkz> BtbN: I've been digging through related conversations from the past 20 years at the side of Gnu make development (ML archives and bug tracker) and the RM output came up 3 or 4 times. The final answer from Paul Smith (seemingly the main dev) about that RM output was something like: "you can take the source code and change it..."

11:00 <BtbN> I'm aware it can't be changed

11:00 <BtbN> thus I'd probably prefer just not making it appear

11:01 <softworkz> If you find it so important - okay, then let's do it your way (.SECONDARY)

11:01 <BtbN> like I said, it's a very minor thing

11:01 <BtbN> so I'm fine either way, just that I'd prefer it to not appear like that

11:02 <softworkz> not sure whether the output can be filtered in some way? but is that a good idea anyway?

11:02 <BtbN> Well, "not making it appear" would probably in the form of keeping the intermediates

11:03 <softworkz> Then let's do this. It's not worth to make this block progress.

11:04 <softworkz> It wasn't clear to me that many would find that output so disturbing..

11:04 <BtbN> Multiple people seem to feel strongly about that rm line being there

11:04 <softworkz> I don't want to fight against multiple :-)

11:04 <BtbN> It just doesn't seem like something that's worth any stress to me

11:05 <softworkz> Yup alright

11:06 <softworkz> Do you think the other changes in the patchset are alright? Then I'll update it to use .SECONDARY

11:06 <softworkz> https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=14814

11:06 <BtbN> I've spent the last week at home with a cold, somehow. So I didn't do any patch reading

11:08 <BtbN> not generating the .d files for those seems obviously ok to me

11:08 <softworkz> Oh, I'm sorry to hear that

11:09 <BtbN> second patch also looks sensible on first read

11:09 <softworkz> It's putting the commands into variables - simply

11:10 <softworkz> okay fine, I'll update it to use SECONDARY, then you can take a closer look - if possible