Hector Martin

I had some plans to contribute to ffmpeg (on a completely different part of the codebase) in the near future, for which I even bought some hardware... With this attitude from the devs, I'm pretty sure I won't be doing that any time soon.https://twitter.com/BMahol/status/1255884140249001984 …

Consider that you're coming off as extremely entitled by quote-tweeting the maintainer of an open source project and trying to shame them for not fixing your issue. "I had some plans to contribute" is sort of irrelevant too.

Have you read my thread? I'm not shaming them for not fixing my issue, I'm shaming them for not acknowledging the issue, which is *completely* different. I have no problem with ffmpeg having bad codecs. I have a problem with the ffmpeg devs saying their bad codecs are good.

I've read the entire thread and I do not think that's how adults should resolve technical disagreements.

I do not know enough about audio processing to comment on who's right, but if somebody were to drag a disagreement regarding one of my projects onto Twitter like that I'd block them

Would you also tell a user who took their time to make a test case and bug report that they're wasting their time and their argument is invalid (even though I literally explained how what I tested is a completely real practical situation)?

That's a loaded question as it already implies that one person is right and the other one isn't. As said I can't make that assessment here. Generally speaking if *I realize* I am wrong I would admit so, but I don't think that's the answer you're looking for.

Okay, are you sure you've read the thread? Because I tested a use case I *have* and is *real* and I'm *literally putting it into production on Sunday*, and ffmpeg sucks at it, and fdk doesn't, and I proved it. The other side's argument is "your use case isn't real".