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
halloy5771 has quit [Read error: Connection reset by peer]
<cone-800>
ffmpeg Andreas Rheinhardt master:3792cf52afc1: avcodec/{x86,mips}/xvididct_init: Remove redundant checks
<cone-800>
ffmpeg Andreas Rheinhardt master:476c70164e0f: avcodec/mpeg_er: Don't zero ThreadFrame* unnecessarily
<cone-800>
ffmpeg Andreas Rheinhardt master:ca36689b39f2: avcodec/mpeg4videodec: Set [yd]c_scale_table during init
<cone-800>
ffmpeg Andreas Rheinhardt master:6ce86c9c110d: avcodec/mpeg4videodec: Permute quant matrices directly upon IDCT reinit
<cone-800>
ffmpeg Andreas Rheinhardt master:728ef2245c8f: avcodec/vc1: Remove write-only qs_last
<cone-800>
ffmpeg Andreas Rheinhardt master:4e2bac279d2b: avcodec/vc1: Remove unused topleft,bottomright fields
<cone-800>
ffmpeg Andreas Rheinhardt master:545724f61e65: avcodec/mpeg4video: Pass parameters directly
<cone-800>
ffmpeg Andreas Rheinhardt master:f82a75333a0a: avcodec/mpegvideo: Move [fb]_code to Mpeg4Dec and MPVEncContext
<cone-800>
ffmpeg Andreas Rheinhardt master:2f971c7fda17: avcodec/ituh263dec: Fix indentation
<cone-800>
ffmpeg Andreas Rheinhardt master:1d5f660ff662: avcodec/mpegvideo_dec: Notify users of reinit
<cone-800>
ffmpeg Andreas Rheinhardt master:763b7ceb31f4: avcodec/rv34: Simplify updating thread context
<cone-800>
ffmpeg Andreas Rheinhardt master:554b52b1b3f6: avcodec/mpeg12dec: Remove disabled frame-threading code
<cone-800>
ffmpeg Andreas Rheinhardt master:1f0af6b5925e: avcodec/mpeg12dec: Don't reinit upon aspect ratio change
<cone-800>
ffmpeg Andreas Rheinhardt master:53a012145af6: avcodec/mpeg12dec: Reinit upon chroma_format change
<cone-800>
ffmpeg Andreas Rheinhardt master:88ce3dade6f6: avcodec/svq1enc: Remove always-false check
<cone-800>
ffmpeg Andreas Rheinhardt master:65015003f5c4: avcodec/svq1enc: Allocate buffers during init
<cone-800>
ffmpeg Andreas Rheinhardt master:839155324e00: avcodec/mpegvideo_dec: Move memcpy'ing ctx to mpeg4videodec.c
<cone-800>
ffmpeg Andreas Rheinhardt master:bd6e6495aebc: avcodec/mpegvideo: Move clear_context() to mpeg4videodec.c
<cone-800>
ffmpeg Andreas Rheinhardt master:dfb4477191d5: avcodec/mpeg4videodec: Don't set chroma matrices unnecessarily
<cone-800>
ffmpeg Andreas Rheinhardt master:2d4d7df10ccc: avcodec/mpeg4videodec: Keep skipped_last_frame in sync between threads
<cone-800>
ffmpeg Andreas Rheinhardt master:c37fb99abbd7: avcodec/h263dec: Always output next, not current pic when flushing
<cone-800>
ffmpeg Andreas Rheinhardt master:2865ebd1fb62: avcodec/mpeg4videodec,h263dec: Only set skipped_last_frame for !vop_coded
<cone-800>
ffmpeg Andreas Rheinhardt master:bc81a797c472: avcodec/mpeg4videodec: Move setting has_b_frames to mpeg4video_parser.c
<cone-800>
ffmpeg Andreas Rheinhardt master:505510acdad5: avcodec/mpegvideo: Move parent to MPVEncContext
<mkver>
The Makefile got pretty chatty; and also a bit creepy (the following is based upon an out-of-tree build): rm ffmpeg_g fftools/resources/*, followed by make ffmpeg_g generates these resources, links ffmpeg_g and deletes several of the resources (it also prints the recipe including the "# Must start with a tab in the real Makefile" comment). Another make ffmpeg_g then generates several of these resources again (and prints the
<mkver>
comment again), although ffmpeg_g should be new.
ChitraMicrosoft has quit [Quit: Client closed]
<fflogger>
[newticket] programmerjake: Ticket #11591 ([avcodec] closed captions side data gets corrupted by mpeg2 encoder) created https://trac.ffmpeg.org/ticket/11591
Anthony_ZO has joined #ffmpeg-devel
<jamrial>
mkver: i'm getting "rm fftools/resources/graph.html.gz fftools/resources/graph.css.min.gz fftools/resources/graph.css.min" at the end of compilation
<mkver>
And when you make ffmpeg_g immediately afterwards?
<jamrial>
no, but i reverted the last patch locally
<mkver>
I get "rm fftools/resources/graph.html.gz fftools/resources/graph.css.min.gz fftools/resources/graph.css.c fftools/resources/graph.css.min fftools/resources/graph.html.c" at the end of the compilation and when I just make again, I get "rm fftools/resources/graph.html.gz fftools/resources/graph.css.min.gz fftools/resources/graph.css.min"
<mkver>
Further makes do nothing, as expected.
<jamrial>
BtbN: can you point the guy what comments remain unadressed?
halloy5771 has joined #ffmpeg-devel
halloy5771 has quit [Read error: Connection reset by peer]
halloy5771 has joined #ffmpeg-devel
<BtbN>
I just scrolled over the latest iteration, and saw at least 2 unanswered mails with issues
AtleoS has quit [Remote host closed the connection]
AtleoS has joined #ffmpeg-devel
<ramiro>
mkver: thanks for the mpeg cleanup work! I don't know if you realize it, but one of the things this helps with is that people (like me) who read source code to understand how codecs work have a much easier time with the cleanup you're doing. many of your patches clear up some "what the *?" moments I've hit in the past.
<mkver>
Glad to hear this.
<mkver>
(Was the fact that the MPEG-4 decoder could parse the header twice one of those wtf moments?)
<mkver>
What is the easiest way to easiest way to extract closed captions from frame side data in a FATE test? Do we have something better than the lavfi device?
<ramiro>
just one thing though :). the way you've sent your latest patchsets (with patch 1 as the subject) makes it a little harder to understand the patchset. sometimes they touch more areas than what patch 1 did. do you think you could write a (very small) overview of the changes that the whole patchset does?
<mkver>
I'll try it.
<ramiro>
thanks!
ChitraMicrosoft has joined #ffmpeg-devel
<ramiro>
mkver: stuff like "why is this variable in the general context and not only the encoder?". you cleared that up. or "why do we qsort the huffman table?". or "why do we generate the entire huffman table in the decoder when we only need to decode it?" (I can't find the commit anymore, but it was something like that)
<ramiro>
mkver: one more thing you might want to look at for jpeg: while decoding huffman tables from dht, we accept codes that are all 1s. this is helpful for my glitch art stuff, but I don't think this is entirely correct. at least libjpeg-turbo doesn't seem to like it (function jpeg_make_d_derived_tbl(), below the comment "We also validate that the counts represent a legal Huffman code tree").
<mkver>
The JPEG spec disallows using the all 1 codes (they would often lead to 0xFF escapes).
<ramiro>
I will keep the broken behaviour in ffglitch (and my ascii jpeg project http://jpeg.ffglitch.org/ascii/ :). but it would be best to fix it in ffmpeg itself.
<mkver>
Fix? Actually, FFmpeg strives to accept broken/spec-incompliant files.
<ramiro>
I do prefer it that way. chrome won't show my jpeg poems, but ffmpeg will....
ChitraMicrosoft2 has joined #ffmpeg-devel
_whitelogger has joined #ffmpeg-devel
Kwiboo- has joined #ffmpeg-devel
haihao has quit [Quit: WeeChat 4.1.1]
mkver has quit [Ping timeout: 265 seconds]
Kwiboo has quit [Ping timeout: 268 seconds]
halloy5771 has quit [Read error: Connection reset by peer]
halloy5771 has joined #ffmpeg-devel
aaabbb has joined #ffmpeg-devel
System_Error has quit [Ping timeout: 264 seconds]
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 276 seconds]
cone-800 has quit [Quit: transmission timeout]
System_Error has joined #ffmpeg-devel
jamrial has quit []
ChitraMsft has joined #ffmpeg-devel
ChitraMsft52 has joined #ffmpeg-devel
ChitraMsft52 has quit [Client Quit]
ChitraMsft has quit [Client Quit]
ChitraMsft has joined #ffmpeg-devel
ChitraMsft has quit [Client Quit]
AtleoS has quit [Ping timeout: 252 seconds]
witchymary has quit [Read error: Connection reset by peer]
witchymary has joined #ffmpeg-devel
ChitraMicrosoft5 has joined #ffmpeg-devel
ChitraMicrosoft8 has joined #ffmpeg-devel
ChitraMicrosoft8 has quit [Client Quit]
ChitraMicrosoft5 has quit [Client Quit]
ChitraMicrosoft2 has quit [Ping timeout: 240 seconds]
ChitraMicrosoft has quit [Ping timeout: 240 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
halloy5771 has quit [Read error: Connection reset by peer]
halloy5771 has joined #ffmpeg-devel
halloy5771 has quit [Read error: Connection reset by peer]
halloy5771 has joined #ffmpeg-devel
softworkz has joined #ffmpeg-devel
Thul has quit [Ping timeout: 276 seconds]
halloy5771 has quit [Read error: Connection reset by peer]
softworkz has quit [Read error: Connection reset by peer]
softworkz has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
<softworkz>
BtbN: You said "it is/was a huge patchset, and reviewing it is annoying with that Github-Forwarder" - can you please explain what the actual problem is with the patch e-mails? They are created with git format-patch like any other patch sent to the ML
<softworkz>
To everybody who participated in the talks: Was it pushed too eagerly? There were 15 revisions and 3 reminders, asking whether anybody needs more time. When there's absolutely no response, what should I do? Tell me! Say I shall send 5 or 10 reminders, then I'll do it. Say I shall wait 4 weeks then I'll do it. Just say something.
<softworkz>
mkver: Regarding the "rm..." output at the end, this appears to be default behavior to delete intermediate files after build, but I can change it so that they are kept (and no rm)
<softworkz>
BtbN: In case you have only every looked at the cover letter messages [0/X] - what you see there is a "range-diff", i.e. a diff to the previous revision of the patchset. But that's not for reviewing. The individual patches are exactly the same like all other patches.
ngaullier has joined #ffmpeg-devel
Anthony_ZO has quit [Remote host closed the connection]
<BBB>
softworkz: if you're asking for opinions, I think the speed is ok (although open review comments are not). but when multiple people tell you something's wrong, you should really be open to listening. this is not how professional colleagues interact
<BBB>
(and they are right: libraries should never ever ever ever open external applications under any circumstances. there are no exceptions)
<wbs>
BBB: in this case it was the ffmpeg tool, not the libraries themselves
<BBB>
ah; still don't think it should open external applications, but it's not a flashing red flag anymore
<BtbN>
softworkz: it highly encourages huge patchsets, that are a royal pain to review as a whole
<BBB>
softworkz: when discussing technical features, it's ok to be wrong or have disagreements. colleagues learn to discuss technically and not take things personally. we learn, accept mistakes, change opinions where needed and accept compromise where necessary. sometimes you don't get your way. that's ok
<BtbN>
it would have likely been a lot better to submit the whole thing as multiple patchsets, one after another, as independent as possible.
<BtbN>
Cause sitting down and spending hours and hours to review a humongous set at least makes me not even consider reviewing it, since I don't have that time at the moment
<BtbN>
Calling system() is _always_ a huge red flag, and a massive no-go, BBB
<BtbN>
It invokes a shell, which is susceptible to all kinds of environment-based manipulation
<BtbN>
If it's bash, you can even inject functions via env vars, which then take precedence over normal commands
<BBB>
I agree system is bad, but michael suggested using fork/exec, which has no shell but is still a terrible idea
<BtbN>
It's at least not a gigantic security problem sitting right there
<BtbN>
But likely still way too complex than it's worth
<BtbN>
just write the URLs to a file or something if you want an easy way to collect them all
<BBB>
agreed
<BtbN>
And the commit message of the specific commit adding it also makes it seem highly immature.
<BtbN>
Though it's the only reason I noticed it being there, since I saw the message in git log and was wondering what this is
<BtbN>
the system() calls I mean
<softworkz>
BBB: Thanks for your opinion on the speed, I really value such feedback. But why are you repeating those false claims about open review comments?
<BtbN>
There are flat out unanswered mails reporting comments on the ML.
<BtbN>
So it's not false claims.
<softworkz>
BBB: "libraries should never ever ever ever..." -> but this was not a library, it was fftools code
<softworkz>
BtbN: " it highly encourages huge patchsets, that are a royal pain to review as a whole" -> I had split the previous patchset already, but it was only 10 commits, then Stefano asked me to separate and it ended up being 15
HarshK23 has joined #ffmpeg-devel
<BtbN>
it ended up being 15 after separating it? hmm?
<michaelni>
i think part of this can be summarized as: "its not our fault we didnt review a patch with the subject "Now, make it a Killer-Feature!" that was posted _12_ times over 1 month it must be someone elses fault" ;)
<softworkz>
Thanks for your reasonable opinion. You must see that it started with very aggressive mails shouting at me to revert - I just wanted to talk about it in a reasonable way, but this wasn't possible with the ones who had commented.
<BtbN>
The patch was a 15/15 or something, in a huge set. I did in fact not even see that line once until it was pushed
<BtbN>
The problem also isn't the commit message, but the code in the commit
<michaelni>
yes but that commit message didnt trigger anyone to look what it is about ?
<BBB>
michael you know well that I only review video codecs
softworkz_ has joined #ffmpeg-devel
softworkz is now known as Guest7581
Guest7581 has quit [Killed (platinum.libera.chat (Nickname regained by services))]
softworkz_ is now known as softworkz
<Lynne>
softworkz: you've been refusing to use proper submission procedures, tried to introduce your own, you've pushed bad patches and did not even consider that calling external programs from a binary directly was inherently bad
<Lynne>
I don't think you deserve your push privileges
<softworkz>
Sorry I was disconnected, could you please repeat in case I missed anything
<BBB>
I don't want to review all of ffmpeg, it would kill me. I don't know how you do it
<BtbN>
Well, I never reviewed the whole patchset. If I had, I'd have for sure at least pointed out that commit message and hard-NAKed any system() usage
<BBB>
I think the commit message is funny ;) but probably not ideal for a larger opensource project
<softworkz>
I had assumed that it has been seen
<BtbN>
That seemingly nobody saw it is definitely a bit odd
<Lynne>
softworkz: last month you even had to publicly ask on the mailing list about a policy which pretty much everyone understood
<BtbN>
It really might be just "HUGE patchset that's not in my area of expertise, maybe later (read: never)"
softworkz_ has joined #ffmpeg-devel
softworkz is now known as Guest659
Guest659 has quit [Killed (zirconium.libera.chat (Nickname regained by services))]
softworkz_ is now known as softworkz
<softworkz>
Originally, I had planned to change it, btw
<softworkz>
Lynne: you've been refusing to use proper submission procedures => In which way exactly?
<Lynne>
mailing lists
<softworkz>
Lynne: you've pushed bad patches => Which ones please?
<Lynne>
"killer feature"
<michaelni>
BtbN, yes, i think that noone saw this is a bit concerning and not softworkz fault. because that commit had a catchy title. maybe we all got trained on ignoring click bait like things ;)
<Lynne>
michaelni: it goes both ways
<BtbN>
At least I simply never made it to that subject, since I concluded much earlier that I can't review such a big patchset
<Lynne>
sure, no one saw it, but in the first place, such a patch should have never been sent
<softworkz>
Lynne: I submitted to ML - what exactly was wrong?
<BtbN>
Nothing was inherently wrong, but a 15 patches or so strong set, with 15 big patches is just not very review-friendly
<Lynne>
softworkz: kludgy github submission on your end where you dump huge patches and race to push them
<softworkz>
Lynne: So the bad patches I pushed was only one and it was about the title not the patch. Does this justify stating that I am pushing bad patches????
<BtbN>
It's not about the title. It's about the contents of it...
<BBB>
for me some of softworkz' patches end up in spam, but that's not just him. romain beauxis also, and david rosca. there's also some guy called clusterf (..) who ends up in my spam
<BtbN>
The title is Odd, but if the patch didn't call system(), we wouldn't have most of this discussion now
<BBB>
nuo mi, that's concerning
<softworkz>
Lynne: It's none of your business how my patches are created. This doesn't have an influence on the size either
<softworkz>
BBB: I also have that spam problem with some patches
<Lynne>
wrong, its all OUR business as we have to review them
<galad>
BBB: gmail puts every michael's email in spam, so 🤷♂️
<softworkz>
Lynne: The result. But not where it comes from. The patches are created with git format-ptch - like all others
<BtbN>
I just have the ML sieve filters in front of the spam one
<BBB>
I think I manually trained gmail to not put michael's patches in spam for me
<Lynne>
now you're trying to blame us on a bad patch when you should have known better to make it
<BtbN>
so no ML patches ever get sorted into spam
<BBB>
BtbN: oh maybe I should do that, how do I order them?
<BtbN>
I just... put them in front in the text file :D
<BBB>
oh, not gmail
<BBB>
sad
<softworkz>
BtbN: Could you please reference the review comments that I would not have addressed?
<BBB>
let's all chill a bit... softworkz, you asked for feedback, the best I can tell you is that combative attitude is never a good long-term approach. find compromise. you'll make friends and get much further (long-term)
<BBB>
just revert the final patch and move on and be happy. it's ok
<BtbN>
are the ones I noticed on a quick scroll-through
<BtbN>
i.e. non-LGTM reviews, or outright error reports, with nothing addressing them
<softworkz>
BtbN: All three messages have been fully addressed!!
<BtbN>
Where?
<BtbN>
I'm pretty confident I do not have a "spam-filter eating your mails"-problem, and I see no replies to those
<softworkz>
The first one is the out-of-tree build issue. I have addressed it in V4 and another oot error from Michael in V7. These issues brought me even so far to add a CI build so that it doesn't happen again
<BtbN>
well, at least a reply to them would have been nice then, even if it's just "addressed/fixed in vX", or just re-sending that specific patch with the fix for the comment
<BtbN>
Cause in the way that thread works and looks, it's completely unreadable to me
<softworkz>
I had replied to Michael and included it in the cover letter with "Thanks, Michael"
<BtbN>
doesn't help that it mostly looks like this
<softworkz>
The second and third messages are from Stefano. All were addressed and replied, but sometimes I answered in a different commit's message saying, "I have addressed all others etc."
<softworkz>
Finally, Stefano was okay with all those and this went over many more revisions.
<BtbN>
I'm also generally ok with all but the usage of system(). And would suggest to maybe use sensible commit messages that actually convey what the patch does in the future.
rvalue has quit [Read error: Connection reset by peer]
<softworkz>
How can you come and look at a V3 e-mail and blame me for not having addressed the review comments? That's not acceptable to discredit me in that way!
microchip_ has quit [Ping timeout: 245 seconds]
rvalue has joined #ffmpeg-devel
<BtbN>
You really want me to work my way through literally hundreds of mails, to ascertain the state of review?
<BtbN>
Sorry, but I just don't have that time
<softworkz>
No. But then do not make false statement!
<BtbN>
No, I make a statement of what I see
<haasn>
Lynne: I have a very strange issue; when writing to a shader storage buffer allocated by ff_vk_get_pooled_buffer(), even with a trivial shader that just writes 1 to the first element, I don't see any results on the host _unless_ I enable debug layers
<haasn>
then it magically works
<haasn>
I checked and the memory type is marked as coherent
<softworkz>
BtbN: This is ridiculous and you know that!
<haasn>
if I write with vk->CmdFillBuffer(exec->buf, sum_vk->buf, 0, sum_vk->size, 0xF); it works
<haasn>
I tried adding a memoryBarrierShared() to the shader, no difference
<BtbN>
There is nothing ridiculous about this. That huge thread is unreadable.
<BtbN>
Yes, it's an inherent problem of mailing lists that working with large sets is rather painful
<haasn>
I also have a memory barrier from storage_write@compute_stage -> host_read@host_stage
<BtbN>
but just hiding behind some Github-Forwarding-Tool and then blaming everyone else for not reviewing properly is not how things work
<haasn>
this also appears to be a regression of some sort because the same shader was working in the past
<BtbN>
Gotta deal with what we got and make it as accessible as possible
<haasn>
I'll try to gather more info but I was hoping you may have a clue where to start looking
<BtbN>
It would have went a long way already to re-send the whole set once in the middle somewhere, without making the thread deeper and deeper
<softworkz>
You look at V3 even thought there is V15? This has nothing to do with confusion!
<BtbN>
Yes, everyone else did everything wrong, just not you. I'm done with this discussion.
<softworkz>
This is the only thing that has upset me today. First from James and now from you
<softworkz>
And everybody start to believe this bullshit
<softworkz>
Not ok
rvalue has quit [Ping timeout: 248 seconds]
Flat_ has joined #ffmpeg-devel
<softworkz>
Before accussing me, please be sure that it's true!
<softworkz>
This is not asked to much
<softworkz>
This should go without saying
<softworkz>
Everything else from today, I'm good with - but that - NOT
Flat has quit [Ping timeout: 272 seconds]
<BtbN>
It's _your_ gigantic thread of patches. You can't just point fingers at everyone else if people get lost in it. If you want to work like that, you also need to put in the work to maintain it and make it usable.
<BtbN>
Nobody is maliciously doing anything. You should instead be wondering why multiple people missed something you consider resolved.
<michaelni>
BtbN, what MUA are you using that makes this thread hard to follow?
<BtbN>
Thunderbird
<michaelni>
iam using mutt
<BtbN>
But It's hard to follow no matter what client to use
<BtbN>
It's like 20 or 30 layers deep, with deeper layers addressing random comments from upper layers, with no clear indication that they do
<michaelni>
would it be easier if new revissions are not replies within the same thread ?
<BtbN>
and apparently it's my fault I didn't study the thread enough
<BtbN>
Yes, a lot
<BtbN>
like the sws patchset for example
<michaelni>
so then lets consider requiring new revissions to be new threads
<BtbN>
As a general rule it seems a bit over the top, usually common sense worked fine enough so far
<BBB>
softworkz: "<softworkz> And everybody start to believe this bullshit" <- that. you can't talk to colleagues like that
<BBB>
you asked what you did wrong. that is what you're doing wrong
<BBB>
don't be so aggressive
<BtbN>
Like, no needs to re-send a 20-mails long patchset, if one comment was addressed that caused two lines of change in that patch
<BtbN>
just send a v2 as reply to the comment it addresses or something
<BtbN>
But at some point the complexity of the threads gets high enough that a re-send is warranted
<BtbN>
meaning, a v2 of that one patch. Not the whole set.
<BtbN>
This is also part of what I see as a problem of that GitHub tool. I highly assume that's beyond its capabilities
<BtbN>
hence the super deep thread of complete re-sends
rvalue- is now known as rvalue
<softworkz>
When I would have mistakenly and falsely accused somebody, I would apologize. Since you are justt trying to distract from the only real mistake from today, I'm getting more explicit in language, yet
<BtbN>
Nobody is accusing anybody of anything...
<softworkz>
You did
<softworkz>
Repeatedly
<BtbN>
No, and if you see it as that, there is no point to discuss anything
<BBB>
and he's wondering why people ignore him... *sigh*. good luck guys, I've got work to do and kids to take care of <3
<BBB>
is the final patch reverted yet? or do I have to do the honors?
<softworkz>
I see it as that. You did and James did. In a discrediting way. That's how I see it. But well. Then let's stop this here.
<softworkz>
BBB: Reverted hours ago already
<BtbN>
imo reverting is not neccesary. Just stub out the function that calls system() with a printf for now, and it can be cleaned up properly without haste
<BBB>
cool, tnx for that
<BtbN>
ah, nvm then
<softworkz>
No. This is the show-graph feature - not a print some path that you can copy paste to open in the browser feature
<softworkz>
You have that already without the last patch
<BtbN>
You just have to understand the we discuss patches and and code here. Generally there is no interest in a personal fight of any kind, the primary interest is good code.
<BtbN>
Don't mistake criticizing code or the process as a personal attack
<softworkz>
This is not about criticising code - what you did.
<softworkz>
Like I said, I'm good with everything else
<BtbN>
I used what little time I had to try and make sense of that thread. Apparently I did not, and all I get as response for that are borderline insults
<BtbN>
Specially since I clearly wasn't the only one with that problem, you maybe should instead wonder if there isn't a bigger issue elsewhere
Thulinma has joined #ffmpeg-devel
<BtbN>
i.e. that huge thread being absolutely unparseable in any reasonable amount of time.
<softworkz>
Regarding the threading, I'm sorry about it. I never knew that this was happening
<BtbN>
Nothing to be sorry about it, it's just something to learn and improve
<BtbN>
Like I said, simply re-sending the whole thing every one in a while as a fresh top-level thread would already go a long way
<BtbN>
*once
<softworkz>
This is the implementation from Git guys and I'm using Outlook - that's why I never questioned it
<softworkz>
But I will fix that
<softworkz>
I agree that this is totally wrong
<BtbN>
Like, what I usually see and do in such bigger threads is 1) address every comment right then and there, so it's obvious how and where it was addressed. Even if it's just a "fixed in v2" or even "fixed locally" for trivial fixes
<softworkz>
I didn't even understand what you were saying by "long commits" etc.
<softworkz>
I thought you meant that 15 commits would be too much
<BtbN>
Yeah, longer commits are usually harder to review. As are long threads of commits.
<BtbN>
And this is a longer thread of long commits even
<softworkz>
No, what I mean: It wasn't clear to me that all revisions are the same thread. I always thought each would be a new thread
<BtbN>
ah
<softworkz>
I would have sworn that it was separate earlier. Let me check the ML from 3 years ago
<softworkz>
...or whatever - I'll just get it fixed.
<BtbN>
Can the tool re-send individual patches, rather than the whole set
<BtbN>
for example, often times there's no need to re-send everything all the time. Just send a v2 of the one patch that was changed to address a comment, as reply to that comment.
<softworkz>
No, you force-push to your PR branch and then it sends all with a new revision automatically
<BtbN>
And once enough of that has accumulated, a complete v2 or 3 or whatever can be sent
<softworkz>
In that case, Stefano often asked me to make changes to a specific commit which meant that many subseqent ones were changed as well, so that would have only causes inapplicable patch sets
<softworkz>
Yea, maybe I sent revisions a bit too often
Thulinma has quit [Ping timeout: 276 seconds]
<softworkz>
But 4 of them alone were about builds from Michael, so I had to resubmit to test it again
<softworkz>
And there were splits and squashes (requested by Stefano)...
<BtbN>
those obviously will require a full re-send, no doubt there
<BtbN>
but the rest just confirms my general feeling towards that tool
<BtbN>
it's convenient for the one submitting the patch, and makes life harder for everyone on the ML for anything that's not just 1~2 patches
<softworkz>
I think Stefano's reviews were excellent - just as it should be and I am very thankful for the way he handled it
<softworkz>
Just as a side-note
<michaelni>
softworkz, you can also just post a link to a updated version in a git repo when the changes are just minor. But i, myself never had an issue with full reposts, i just mark all but the last as read
mkver has quit [Ping timeout: 260 seconds]
<softworkz>
it's convenient for the one submitting the patch, and makes life harder for everyone on the ML for anything that's not just 1~2 patches => In the light of the threading I agree
<softworkz>
michaelni: Ok, will do next time!
<BtbN>
Even if it posted it as a new thread each iteration, the general problem that it causes too many full iterations still remains
<BtbN>
Since it can't re-post individual patches that got changed in response to comments
softworkz has quit [Read error: Connection reset by peer]
<BtbN>
At least to me it's _a lot_ easier to parse a patch thread if under each patch in there, there's a small thread with a few iterations of that patch, in near-linear order
<BtbN>
rather than 10+ iterations of the whole set, each potentially only changing a few lines in one patch
softworkz has joined #ffmpeg-devel
<BtbN>
It's easy to follow the discussions about that one patch then.
jamrial has joined #ffmpeg-devel
<michaelni>
For discussions yes, for testing, the individual reposts are harder because they often dont apply cleanly with the following patches
<softworkz>
BtbN: "Even if it posted it as a new thread each iteration, the general problem that it causes too many full iterations still remains" => no. really not, because I would sent the exact same patchsets when using the command line. That's no difference at all
<BtbN>
When using the commandline, you could have just sent one lone patch of the whole thing, as reply to a comment
<softworkz>
BtbN: I've never done that. (before ffstaging)
<softworkz>
Anyway I'm also seeing it just very rarely from anybody on the ML...
<BtbN>
Obviously needs to be done within reason. Like, if the changes there ripple through the whole following patches, it's rather problematic.
<BtbN>
It's pretty common, specially if you include how single-patch submissions are handled
<BtbN>
But even in bigger patchsets, it's being done
mkver has joined #ffmpeg-devel
<softworkz>
Yes, but not that often. From the 15 revisions there weren't really many where a single patch could have been sent. It was often about which change is made in which commit and I was permanently moving individual changes from one commit to another...
<softworkz>
...and splitting and squashing
<softworkz>
At the end, I sent a bit too often maybe, it was because I always thought it would be the last one :-)=
<BtbN>
It might already help to just collect changes for a bit, and in the meantime just link to where the new patch(es) are, and then at some point send a bigger new revision
microchip_ has joined #ffmpeg-devel
<BtbN>
Though you might have already done that anyway
<softworkz>
It was complicated because many commits were about the same files and Stefano wanted these re-shaping of the commits (which made sense). And also I tried not to invalidate previous reviews of certain parts, to avoid the need to re-review.
<softworkz>
Looking back, it would have made sense to cut off the graph printing commits. But I had already cut them off from the previous patchset, and initialliy this one was just about a few cleanup things before the graph printing. And then the first part became larger and larger
minimal has quit [Quit: Leaving]
Thulinma has joined #ffmpeg-devel
<cone-687>
ffmpeg Nuo Mi master:87b0561c8812: build: fix windows build issue introduced by 45bea45
<ramiro>
softworkz: it should be possible to have a script (sh, python, or even powershell) that monitors a folder and opens any new html files created there. ffmpeg could output a timestamped file to that folder, and the script opens it automatically. the user will need to remember to load the script and keep it running (and they'll notice they forgot to load the script when the browser doesn't open on a new
<ramiro>
ffmpeg invocation). what do you think about this solution?
<softworkz>
ramiro: Yes, that's something that I had thought about myself and even commented in that direction. But nobody wanted to talk about it. And many said that FFmpeg should not launch a browser (in any way). That's why I gave up on it then because it had become clear that the behavior itself is not wanted and it's not just about the technical implementation
<softworkz>
From some...
<softworkz>
for others it was just about the system() call
<ramiro>
but in this case it won't be ffmpeg launching a browser, but a script that the user runs explicitly.
<softworkz>
I'm not the one who needs to be convinced about it :-)
BradleyS has joined #ffmpeg-devel
<softworkz>
I had hoped that Michael's message would lead to a reasonable discussion, but there didn't seem to be any interest
<softworkz>
All were just shouting "revert" - nobody wanted to talk about it
<kierank>
Lol
<ramiro>
softworkz: reverting was the correct course of action. there is discussion going on. people are offering alternative solutions and discussing them.
<haasn>
Lynne: re: my earlier, it's not a regression, seems I was just always testing with debug layers enabled in the past...
<ramiro>
softworkz: also, be careful with generalized statements about "everybody" or "nobody", it's rarely true, and it doesn't help with the discussion.
<softworkz>
ramiro: right, but that's how it appeared to me
<softworkz>
ramiro: reverting was the correct course of action. there is discussion going on. people are offering alternative solutions and discussing them. => Sorry, but that case is closed and done for me. I have painstakingly taken care to do everything in the right way, I applied all requested review changes, even those that I had questioned in my responses - just so that nobody can come and blame me for doing something wrong - and the exact opposite
<softworkz>
has happened, some have gone crazy and fictioned even more incorrect of unjustified things, made incorrect claims that were discrediting me. That's a chapter that I am not willing to continue.
TheVibeCoder has joined #ffmpeg-devel
TheVibeCoder has quit [Client Quit]
TheVibeCoder has joined #ffmpeg-devel
<TheVibeCoder>
anybody working on APAC decoder?
JEEB has joined #ffmpeg-devel
<kierank>
Incredible levels of playing the victim
<kierank>
Oscar winning
System_Error has quit [Remote host closed the connection]
<haasn>
Lynne: found the issue
tufei_ has quit [Remote host closed the connection]
<haasn>
disabling VK_EXT_DESCRIPTOR_BUFFER_EXTENSION_NAME makes it work
tufei_ has joined #ffmpeg-devel
<haasn>
doesn't seem like a driver bug since it affects both nvidia and amd
System_Error has joined #ffmpeg-devel
ChitraMicrosoft has joined #ffmpeg-devel
softworkz has quit [Quit: Leaving]
<TheVibeCoder>
another valuable dev left
<TheVibeCoder>
toxic community
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
ChitraMicrosoft has quit [Quit: Client closed]
ChitraMicrosoft has joined #ffmpeg-devel
tufei__ has joined #ffmpeg-devel
<haasn>
Lynne: I'm trying to look into it but I don't see anything wrong with the code or the descriptor write, it seems to be writing the correct descriptor to the correct location in memory
<haasn>
do you know if git master validation layers support descriptor buffers?
tufei_ has quit [Remote host closed the connection]
<haasn>
JEEB: btw, you never replied to the TC thread about log output format
<haasn>
Lynne: even if I disable all descriptors except a single shader storage buffer, it still doesn't work unless I disable descriptor buffers
<JEEB>
haasn: yea, I hadn't gotten to it yet. I saw the couple of initial responses but haven't kept up with it if there were other ones. Will try to catch up with it / respond after I finish dealing with this dead box.
* JEEB
seems to have 7 as his lucky number. two boxes now died at around the 7 year mark (due to non-CPU/non-disk related issues).
System_Error has quit [Ping timeout: 264 seconds]
<haasn>
test with ./ffmpeg -v debug -init_hw_device vulkan=vk,debug=1 -f lavfi -i smptehdbars -vf format=yuva444p,hwupload,blackdetect_vulkan=pix_th=1 -vframes 10 -f null -
<haasn>
if you change it to debug=0 it start printing picture_black_ratio:0.000000 for every frame
<haasn>
JEEB: ow, what died?
<haasn>
also I have never, ever, ever seen a CPU die
<haasn>
I'm convinced they actually come from the future
<JEEB>
haasn: one of the servers I hosted a whole bunch of stuff on :D my guess is either the PSU or something on the motherboard
<JEEB>
powers on, XY minutes go by and it shows up in management as shut down
<kasper93>
my intel cpu died twice on x99 platform. Both RMAed and replaced
<kasper93>
but x99 was cursed
<TheVibeCoder>
is here anybody with afconvert utility available from Terminal?
System_Error has joined #ffmpeg-devel
<ePirat>
TheVibeCoder, yes
<JEEB>
haasn: also you should be able to skip lavfi input device and just not have inputs, `-filter_complex "smptehdbars,format=yuva444p,hwupload,blackdetect_vulkan=pix_th=1"` and it should auto-map the video output
<JEEB>
a thing I TIL'd when checking out BtbN's windows capture filter
<haasn>
neat
<ePirat>
yeah
<haasn>
can we get a short form of -filter_complex:v
<haasn>
-vfc
<ePirat>
TIL -filter_complex:v is a thing
<haasn>
or actually why are -filter_complex and -vf even different? isn't the latter syntax also valid for the former?
<TheVibeCoder>
ePirat: can you locate if your afconvert is using APAC relevant library, assuming your OS version is >= 10.15
<JEEB>
haasn: -vf/af add per output specific filter chains, filter_complex at least previously was one common filter chain
<haasn>
ah
<BtbN>
only filter_complex can do the "no inputs" filter stuff
<BtbN>
vf always wants to connect a simple chain
<JEEB>
yea
<galad>
TheVibeCoder: afconvert help lists APAC too, so I guess it supports it (on macOS 15)
<TheVibeCoder>
thanks, can you find APAC path of relevent lib/binary ?
<TheVibeCoder>
ePirat: you need filter_is_ready() only if it does nothing of like: sending frame to outlink, requesting frame on inlink, ack of EOF.
<ePirat>
this filter just throws an assertion in fftools for me when using with a file that has both video/audio
<TheVibeCoder>
yes
<TheVibeCoder>
that can happen if you do nothing after EOF is reached
<TheVibeCoder>
but first try to remove is_ready() call before ff_filter_frame()
<ePirat>
just did and still get the same assert triggered
<TheVibeCoder>
is asserts right at start?
<TheVibeCoder>
use ashowinfo before and after filter
<ePirat>
it works with FF_FILTER_FORWARD_STATUS_BACK_ALL in the sense that then I just miss all the video frames after the audio ended…
<ePirat>
it happens at the end
<TheVibeCoder>
how many inputs and outputs your filter have?
<TheVibeCoder>
for 1->1 case its trivial code
<ePirat>
2, one audio, one video.
<TheVibeCoder>
for N->N case you need to loop over all active inputs and loop over all active outputs, so that at least you do some work in each activate call
<TheVibeCoder>
so single activate call should: either push >= 1 frame(s) to one of outlinks, or request frames on active inputs and for EOF case it becomes tricky
<TheVibeCoder>
because if you ack EOF on one of inputs and send or not it to output you still need to do some work
<ePirat>
so even when I handle EOF for one input and send that, I still should do work for the other still active input?
<ePirat>
in the same call
<ramiro>
mkver: on patch 14's commit message: "The earlier code allowed callers to use arbitrary crap" <= you could probably say "arbitrary values" instead :)
<TheVibeCoder>
so if EOF happens on one of inputs and you do not forward EOF to all outputs but only on some of them, you then need to call filter_is_ready() so that asserts is not triggered, then active will be called again, but make sure that you do something different in next call otherwise you will get infinite loop
<ePirat>
ok, will try that, thanks
<ePirat>
writing proper activate functions is really hard…
<TheVibeCoder>
yea, this complexity is somehow part of every filter that uses .activate and making it more friendly and future proof would be very big task
<ePirat>
I tried to just not use activate with fixed inputs (1 audio, 1 video) and filter_frame, but that just has the same issues as using FF_FILTER_FORWARD_STATUS_BACK_ALL, that it misses all remaining video frames…
<ePirat>
interestingly it was fine in older ffmpeg versions
<ePirat>
so maybe some framework bug somewhere
<TheVibeCoder>
you do not have much control when not using .activate
<TheVibeCoder>
also in your noop filter code, you use same variable to loop over input and output
<TheVibeCoder>
if one output depends on certain input than that should be reflected in .activate function
<TheVibeCoder>
i think i have N->N filter in librempeg its audio only - clap, but I tested it with 1->1 case only i think
<TheVibeCoder>
it would be nice to have AV->AV filter to remove A/V silence/black frames or add silence/black frames if pts gaps are present
<TheVibeCoder>
ePirat: just add printfs in activate to debug/track what calls are executed inside .activate block
<kepstin>
if your filter does anything other than "one input, do something to the input, immediately generate one output" you should use activate, tbh.
<TheVibeCoder>
so you can easily locate when case happens when asserts is triggered because that case needs is_ready() call
<TheVibeCoder>
kepstin: yes, its one big complex machine, you need probably write full visualization what is done in each step inside activate call, and have all cases covered
<kepstin>
yeah, i'm somewhat familiar with that from the work i did on the fps filter.
<TheVibeCoder>
another possible problem is that you can get EOF and last frame at same time and sometimes you can get only EOF, last frame was in previous .activate call, was bitten by this recently
<kepstin>
the original design of the fps filter with filter_frame/request_frame did a fun thing where it would generate all the frames needed to fill a timestamp gap in a single call, and i hit a problem where video files with extremely large timestamp gaps would cause it to use a ton of memory (i was seeing it get oom-killed occasionally)
<kepstin>
and yeah, eof indication is separate from last frame, that needed special handling in the fps filter too :/
<TheVibeCoder>
yes, that should be hopefully resolved in 99.999% cases with .activate()
<ramiro>
haasn: for ff_sws_img_shift(), I found it weird that both the argument and the result are passed by value. sure, it's inline so the compiler probably optimizes it all away, but it's still weird. the dereference to make a copy as input argument may pass unnoticed. what about ff_sws_img_shift(const SwsImg *img, const int y), and making the copy in the function itself? (the compiler will probably give
<ramiro>
the same binary at the end)
<TheVibeCoder>
still, they are ways to create filtergraphs which would queue too much frames and cause OOM, maybe there should be limit how many bytes of memory should be allowed to queue and when it reaches limit abort processing...
<TheVibeCoder>
and current threading in ffmpeg CLI may impose another sort of extra queues which is more problematic with big resolutions videos
<cone-912>
ffmpeg Marton Balint master:a6a510c1d95e: tests/fate/probe: add test for pcm misdetected as mp3 in wav
<cone-912>
ffmpeg Marton Balint master:fe97bf875234: tests/fate/probe: add test for dts in wav
bbbccc has quit [Ping timeout: 272 seconds]
bbbccc has joined #ffmpeg-devel
\\Mr-C\\ has joined #ffmpeg-devel
\\Mr_C\\ has quit [Ping timeout: 252 seconds]
Gramner has quit [Ping timeout: 252 seconds]
Gramner has joined #ffmpeg-devel
natto17 has quit [Ping timeout: 244 seconds]
natto17 has joined #ffmpeg-devel
Flat_ has quit [Ping timeout: 272 seconds]
Flat has joined #ffmpeg-devel
halloy5771 has quit [Read error: Connection reset by peer]
softworkz has joined #ffmpeg-devel
halloy5771 has joined #ffmpeg-devel
<softworkz>
TheVibeCoder: 1. Thank you - 2. Don't worry, I'm not leaving. What I meant is that I will not pursue the show-graph auto launch feature anymore
softworkz has quit [Quit: Leaving]
ChitraMicrosoft has joined #ffmpeg-devel
<ChitraMicrosoft>
Quick question does FFMPEG natively support ARM64 builds or are there parts that use EC code?
<JEEB>
native aarch64 has been possible for quite a while
<Lynne>
EC? entropy coding?
<JEEB>
their mixed binary thing most likely
<JEEB>
I think foobar2000 is using that to have support for x86_64 plugins
<JEEB>
so a master winarm64 binary from there is probably the most openly built thing
halloy5771 has quit [Read error: Connection reset by peer]
<JEEB>
openly built as in it's being done in a publicly defined CI flow which means there are no secrets etc. and of course also means you can relatively easily check how the sausage is made
<wbs>
ChitraMicrosoft: yes it's been possible to build ffmpeg for native windows on aarch64 since 2017 (before public SDKs were released). but building ffmpeg for arm64ec probably doesn't work without a bunch of hacks (unless doing it as a plain x86_64 build)
<JEEB>
yea, it's been possible for quite a while :)
<BtbN>
The main problem for winarm64 is the lack of a properly developed toolchain
<JEEB>
llvm-mingw is probably the best at it
<BtbN>
it only works for cross compiling though
<BtbN>
there is no native toolchain
<wbs>
there is?
<BtbN>
mingw/msys on winarm64 itself relies on x86 emulation
<wbs>
it does not come with a full posix emulation layer for running the ffmpeg configure script, no
<BtbN>
the environment for those to run and be useful in doesn't exist though
<wbs>
it is totally usable as is as a native toolchain on windows, for a large number of projects. but yes it does not come with a posix emulation environment for running shell scripts and such, no
halloy5771 has joined #ffmpeg-devel
halloy5771 has quit [Read error: Connection reset by peer]
JEEB has quit [Ping timeout: 240 seconds]
JEEB has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #ffmpeg-devel
<BtbN>
https://bpa.st/N7CQ is it normal that the graph stuff prints this sed block there on install? Looks like something, somewhere is missing the silence thing
<jamrial>
no, it shouldn't do that
<BtbN>
also, I guess we re-link on install now?
<BtbN>
did that always happen?
<jamrial>
uh, i doubt it
<BtbN>
Cause that paste is from "make install"
<BtbN>
I can't immediately tell what causes that, hm
<BtbN>
"INSTALL install-progs-yes" also looks a bit odd
<BtbN>
Make printing the comment is also strange, but I guess it's just what make does
<jamrial>
it was introduced in 517a805565
ChitraMicrosoft2 has joined #ffmpeg-devel
<BtbN>
Yeah, but I don't see anything there that'd trigger re-linking and doing a lot of that only at install time
<BtbN>
I hate how impossible it is to debug Makefiles...
cone-912 has quit [Quit: transmission timeout]
<BtbN>
ok, I see why it's happening. It runs "rm fftools/resources/graph.html.gz fftools/resources/graph.css.min.gz fftools/resources/graph.css.c fftools/resources/graph.css.min fftools/resources/graph.html.c" at the end of a successfull make. So of course, at make install, those deps are missing again, and it re-generates them, and then needs to link again, cause outdated