> this feature is algorithmically impossible
> You're just looking at one specific video, not the general problem.
> is not generally possible.
As a fellow multimedia dev, man, who cares? Sometimes we forget that software ought to be useful, not hypothetical ideals of truth. Just implement the feature for those codecs that support it and which probably are in the 98% percentile of what users actually use, regardless of the damned "general case".
Or accept and announce shamelessly that you don't have either the knowledge or the development resources to tackle such a complex feature. But excuses about not being possible for absolutely every possible codec in a completely generic way is just denying that the world is just a chaotic and dirty place where things are not ideal nor perfect. Just give your users a real-world solution (or rejection).
I don't know how they get away with that though. In the coding work that I do, I'm constantly dealing with rules that have exceptions on top of exceptions. I just need to special-case some things, because the alternative is not delivering what the business needs.
In your job, you have to special-case some things because the alternative is not delivering what the boss wants. Regardless of the problems this may cause, or how much tech debt it generates - those are (in the end) business decisions, and while you can make a case to the boss that implementing the special case feature is going to cause huge problems, it's the boss's call as to whether it gets implemented.
In an open-source project the maintainer is the boss. If the maintainer thinks that the feature is going to cause problems, they're totally free to say "no, I'm not going to implement that feature". And, ofc, because it's FOSS, the user is totally free to fork it, or submit a PR for the feature, or whatever.
> just got here from a Google search. I gotta say the replies from Remi sound defensively toxic. I'm not here to program the app, I'm just here to find a simple feature and/or request it.
I think Remi sounds curt rather than toxic. There's no automatic right for anyone to go to a FOSS project and request a feature and have it implemented. The maintainer is perfectly within their rights to just say "no". It's their project, their code, their time, and they're free to do/not do anything they like with it.
Once the devs have made clear they don’t plan to do exceptions (as other softwares do) then users should accept it and move on instead of keep harassing volunteers.
That may even mean that you have to hold yourself to a higher standard than some low-effort post on the part of some casual user. Especially if you're the boss, the maintainer, the leader. And if that's asymmetric then yes it is - but to be a maintainer/manager of a project is also asymmetric. Good managers might also promote that culture more widely across all the project's contributors and so yes it may apply to all developers, too.
Not everyone that engages with your project is going to be perfect, some may even be rude. But as a representative of that project it's a skill to be able to cope with that, on behalf of the project (not you). I think one of the most underrated skills of a FOSS maintainer is a degree of fault-tolerance, to use a systems analogy.
Or, you could argue that no, it's not incumbent on a maintainer to be anything, even to be kind. But then don't expect your users to come back.
VLC developers are of course free to reject any feature request but if they do it by bullshitting their users (and that includes tacking on additional requirements that no user actually needs like perfect support for all formats under the sun) then they will be rightfully called out for it. Then throwing a tantrum and citing CoC violations is not going to improve things.
It's their project so ultimately they get to choose to run it into the ground but this kind of behavior is not something I want to support as a user os I will stay away from VLC which includes not making helpful bug reports and not donating.