[embedding-shape]

It seems really weirdly written. It's written with a lot of authority, like saying "Don't use VLC" and "Don't use Y" yet provides no reasoning for those things. Just putting "Trust me, just don't" doesn't suddenly mean I trust the author more, it probably has the opposite effect. Some sections seem to differ based on if the reader knows/doesn't know something, but I thought the article was supposed to be for the latter.

Would have been nice if these "MUST KNOW BEFORE" advises were structured in a way so one could easily come back and use it as a reference, like just a list, but instead it's like a over-dinner conversation with your "expert and correct but socially-annoying" work colleague, who refuses to elaborate on the how's and why's, but still have very strong opinions.

[joe_the_user]

Yeah, as far as I know, to understand video formats, you need to understand encode-decode process, how film/video editor operate normally (keeping in mind film/video editing has levels from $100s to way beyond me), history, how optics and cameras work, etc. Then particular choices and confusions can be understood.

This indeed just seems to jump-in in the middle and give a bunch very specific recommendation. I have no idea if they're good or bad recommendations but this doesn't seem like the way to teach good procedures.

[astrange]

There are not very many recommendations in this article, but they're good.

[embedding-shape]

Wish I knew which ones were applicable to me, but without any reasoning, these "recommendations" are as good as random tweets with factoids.

[astrange]

Well, I just told you they're good, so now you know.

[embedding-shape]

Yeah, based on your comment I learnt as much as the original article, which is basically nothing. So thank you :)

[eduction]

And? It’s a GitHub gist not an oreilly book. Context.

[embedding-shape]

So? This was just a HN comment, not a review of a paper.

[Etheryte]

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.

[ffsm8]

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

[LiamPowell]

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.

[zenmac]

The author did mention to use MPV, which is much much lightweight than VLC. Being using it as default for quite some times now.

[eviks]

what are you talking about? Of course it's only about playback just like the other 2 alternatives

> single best media player out there ... VLC is not recommended.

[ffsm8]

Literally the first sentence

> 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.

[eviks]

Literally don't stop at the first sentence!!!

> 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

[ffsm8]

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.

[ErroneousBosh]

VLC is great for playing stuff back, but can produce some horribly incorrect video files especially if you're dealing with stuff for editing.

There's a reason why VLC isn't used in broadcast stuff and ffmpeg is.

[rfl890]

VLC has always caused problems for me when seeking backwards (graphical glitches). mpv has never caused any issues in this regard.

[my65thaccount]

VLC and mpv literally use the same underlying codec library. (As well as ffmpeg.)

[homebrewer]

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.

[eviks]

So? Here is the post where VLC dev explains why you can't seek 1 frame back (you can do that in MPC and mpv) https://forum.videolan.org/viewtopic.php?f=7&t=126609&start=...

[astrange]

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.

[arch1t3cht]

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].

[1] https://github.com/mpv-player/mpv/wiki/libavformat-mkv-check...

[MallocVoidstar]

IIRC VLC used the wrong primaries for converting to RGB for a long time (years) even after it being reported to them as wrong

[gruez]

>even after it being reported to them as wrong

Source?

[linolevan]

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.

There's also https://code.videolan.org/videolan/vlc/-/issues/25651 but that's an off by one error so likely not really relevant to video playback for the average user.

[knowitnone3]

VLC has left me hanging many times. It's play a file wrong or not played at all while mpv plays it no problem. Do not use vlc.

[ramesh31]

technically correct is the best kind. who cares if it's obnoxious? take the opinions and agree or disagree with them.

[dylan604]

How do you know it is technically correct without explanation. It's not much different from someone getting blown off for being annoying because they constantly question simple answers when seeking better understanding. I was fortunate to work with a group of engineers when I was very young that accepted my constant use of "why?" not as disrespectful questioning but realized I was actually learning so they naturally just provided more details leading to less "why?" being asked. This eventually got to the point where I would ask a question, and the answer would be to read a specific book on the shelf. This was way before the internet. I received a better education on the job than I ever was going to get in school.

So no, I'm not just going to take an opinion without more information. I don't change my mind just on say so.

[pomian]

Why? Is the most simple test of a valid explanation. If you don't need to ask why any more, you've answered the question. Sometimes it takes 3 or 5 white in a row!

[snakeboy]

It works if you know the person and have a baseline for how much confidence you give their opinions. If it's just a random person on the internet, they need to support their argument.

[alwa]

I mean—they can. They don’t need to give more than they’re already giving we anonymous strangers for free. For all we know, this person wrote this for people they encounter personally or professionally, and we’re just incidentally benefitting.

We as readers should gauge their credibility for ourselves, whether by reputation or by checking the claims. I don’t know who wrote it but it seems basically correct, consistent, and concisely argued to me.

[jaapz]

How can I disagree when they don't provide a reasoning behind why something is the better option?

[yaur]

When we switched from x264 to hardware based encoders it saved something like 90% on our customers' power and cooling bills.

So while this essay might be "technically correct" in some very narrow sense the author is speaking with far more authority than they have the experience to justify, which is what makes it obnoxious in the first place.

[mrguyorama]

The author is directing this at complete noobs who are subbing their first anime and you are complaining that it is not applicable to running a datacenter?

[knowitnone3]

the author never talked about power savings or cooling bills, they talked about quality so they are still correct.

[encom]

This is already mentioned in the article. Software vs. hardware is a tradeoff. x264 produces higher quality (perceptual or compression efficiency) video, at the expense of latency.