Exactly, very hard to take the rest of it seriously after the VLC bit. VLC has literally never left me hanging, across I don't know how many decades. It's gonna take more than a trust me bro to challenge that.
You're talking about VLC for video playback, TFA is taking about video editing.
VLC ignores a lot for it's outstanding video playback support, which is great if you want the playback too just work... But that's the player perspective, not the editing/encoding
While VLC is excellent at playing every format under the sun, it's not good at playing all those formats correctly. Off the top of my head:
- Transfer functions are just generally a mess but are close enough that most people don't notice they're wrong. Changing the render engine option will often change how the video looks.
- Some DV profiles cause videos to turn purple or green.
- h.264 left and right crops are both applied as left crops that are summed together which completely breaks many videos. They could just ignore this metadata but from what I've heard their attitude is that a broken implementation is better than no implementation.
> Hanging out in subtitling and video re-editing communities, I see my fair share of novice video editors and video encoders, and see plenty of them make the classic beginner mistakes when it comes to working with videos.
Seriously, you quoted pretty much the only sentence in the whole article that's about plain playback, and even in that bullet point, the following sentence mentions hardcoding subtitles.
> It turns out that reading the (f.) manual actually helps a lot!
The non-recommendation of VLC vs mpc/mpv is literally for playback as I quoted! MPC also doesn't do any encoding, yet it's recommended
> the following sentence mentions hardcoding subtitles.
And that sentence starts with "Apart from simply watching the video" to tell you the same thing the previous sentence told you - that comparison where VLC was not receommended was about playback, not editing
Yes, I think everyone, including the author of the article will agree that you've quoted the one sentence thats about playback. I agreed on that from the beginning as well. After all, after you've modified a video file, you will want to check if it looks as desired. You want a video player for that, ideally one that doesn't ignore things for improved compatibility.
The point was that the rest of the article wasn't and if you unironically can't tell that, then you should seriously train your reading comprehension.
Have you tried both? mpv is able to play high resolution HEVC videos backwards at real time by holding the "previous frame" key. VLC can't reliably jump backwards even at second intervals, forget about reverse playback.
VLC makes a choice not to seek backwards to keyframes, which means you get video corruption.
Seeking is surprisingly difficult. Many container formats don't support it at all, because they don't have indexes, and so it's easy to mess up playback or lose A/V sync by trying it. Constructing the index is about as hard as decoding the entire file too.
libav{format,codec,...} are just libraries for demuxing and decoding video. There is huge variability in how those libraries are used, let alone how the video is displayed (which needs scaling, color space conversions, tonemapping, subtitle rendering, handling playback timing, etc. etc.). mpv also has its own demuxer for matroska files, since libavformat's is very limited [1].
I'm not the OP of the claim (and I love VLC) but maybe they're referring to this early 2018 issue: https://trac.videolan.org/vlc/ticket/19723 which seems to be being actively worked on.
VLC ignores a lot for it's outstanding video playback support, which is great if you want the playback too just work... But that's the player perspective, not the editing/encoding