Re: [FFmpeg-devel] Graphprint Patches Overview

["softworkz ." <softworkz-at-hotmail.com@ffmpeg.org>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Michael
> Niedermayer
> Sent: Donnerstag, 22. Mai 2025 13:24
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Graphprint Patches Overview
> 
> Hi Kieran
> 
> On Thu, May 22, 2025 at 08:21:48AM +0100, Kieran Kunhya via ffmpeg-devel
> wrote:
> > It's obvious basic testing was not done on this patchset seeing the scale
> > of memory leaks.
> >
> > I would like the TC to decide on reverting and proper resubmission later.
> 
> Iam not speaking for the TC here
> 
> 1. The graphprint code was on the ML for a month and resumbitted for review
>     12 times, basically noone reviewed it (going back to that will not help
> it)
> 2. The graphprint code is very actively worked on (thats normal and good
>     and what git master is for and thats how it improves quickly)
> 3. The statement that the graphprint code wasnt tested is obviously false
>     softworkz tested it. I tested at least build on multiply platforms
> 4. "seeing the scale of memory leaks." try to compare this to
>    IAMF "git log --grep IAMF --oneline", IAMF is after a year still receiving
>    frequent security fixes. This is just as a comparission
> 
> What you are doing is trying to gain from somewhat popular oppinions
> at the expense of the project and team.
> 
> many disliked the "opening of a browser" and thats now resolved
> and reverted, but instead of letting the wounds heal you throw salt in them.
> And while people are working and improving the code you push another
> round of animosity
> 
> I dont really care if the code is all reverted or not. (it seems though
> wiser to let people work on it as they already do)
> What i do not agree with is this seeding of animosity you do.
> 
> This very much reminds me of
> Simple Sabotage Field Manual
> https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/SimpleSabotage.pdf
> 
> Also there is IMO nothing for the TC at this point. Its actively worked on
> code,
> there is NO disagreement that any bugs or leaks need to be fixed.
> And reverting this is not going to accelerate any fixes (if any bugs even
> remain).

Just one more note on the status: This is not a work in progress, it's done
and complete, otherwise I wouldn't have submitted.
I did not check for memory leaks - yes, I should have done that! Albeit
it's not library code, no large amounts, not constantly growing and most of 
it allocated only a few milliseconds before the FFmpeg process exits.

Given the attention that some are paying to those few Kilobytes, I have to
wonder why nobody seems to be aware of the existing memory leaks with 
QSV hardware acceleration. These _do_ appear to be growing over time.


> many disliked the "opening of a browser" and thats now resolved
> and reverted, but instead of letting the wounds heal you throw salt in them.

At that time, I haven't had a chance to say anything. I will follow-up
to it shortly, but I wanted everybody incl. myself to cool down before.

What I can tell though in advance: That narrative of "inexperienced 
developer accidentally used a 'bad' API" doesn't fly. It was a 
deliberate decision under awareness of the potential risks when
not done right.

I really wonder how Kieran can't be embarrassed trying such maneuvers which
are so obvious to everybody.

Best
sw


_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".