I use it to inspect video frames by frames, particularly being able to go back one frame. VLC doesn't support it, this thread about the feature is hilarious https://forum.videolan.org/viewtopic.php?t=120627
replies(19):
> 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).
VLC is what it is today because the authors understood video standards enough to make the _right_ abstractions that could generalize to ~every video format ever. That is no easy task. Video container standards are utterly perverse, and seem to delight in stomping over even the most innocent intuitions about what you would expect to find in a stream of bits that purports to contain "video". They often refuse to make even basic promises, like "the first frame's timestamp starts at 0" or "every parcel of data has a timestamp". Seemingly reasonable ideas that a neophyte might propose, like "suppose we store the video's framerate-" must be immediately interrupted with "you FOOL, there IS no framerate, nothing can be certain, this video might not even have frames, it might in fact be an interactive gift basket experience merely PRETENDING to be an mp4-". That's just the nature of the beast.
A playback architecture that can wrangle all of that cruelty into a consistent experience was hard won. Of course they're not eager to throw new features into the mix that will pollute that mental model, and suddenly introduce thousands of codec-vs-player-feature checks that were heretofore ruled out in principle. At a certain point, the architecture is sacred, and it's the only thing making VLC maintainable. If a feature doesn't work for everything, it doesn't work.
No, it hasn't. The only reason I use mpv instead of VLC is because of the frame step feature. Everyone else has proven that it is possible and practical to do.
Never let the perfect be the enemy of the good. If people don't use your product, it doesn't matter how right and pure of vision you are.
>Never let the perfect be the enemy of the good. If people don't use your product, it doesn't matter how right and pure of vision you are.
This is great advice... for a business. VLC isn't a business, it's a useful thing that exists. It gives people fulfillment to donate their time to keep it useful and relevant. That fulfillment is going to be directly proportional to how elegant the design is and how much leverage they have, i.e. small amount of good code provides wide amount of functionality for many happy users. The more that maintenance of VLC degrades towards "brutal hand-crafted specialization of huge switch cases", the less well-maintained it's going to be. This is not an excuse, it's a statement about human nature, something akin to economics.
It's possible that mpv picked a better abstraction and they can provide a strictly better application for the same or less software maintenance cost. But I tend to suspect that the differences arise from levels of support, not better design. That's just a spider sense though.
> VLC isn't a business
I assume this means you can hire lead devs to fix bugs and add features.