Live data from Hacker News

What you need to know before touching a video file

gist.github.com

31–40 of 251 posts

Re: What you need to know before touching a video file

#31

Interesting read, it’s a shame the ranty format makes it 3x longer than necessary. Not sure why it takes a dump on VLC - it’s been the most stable and friendly video player for Windows for a long time (it matters that ordinary users, like school teachers, can use it without special training. I don’t care how ideological you are about Linux or video players or whatever lol).

I don't believe it's the case anymore, but it was very common for VLC to cause video corruption (see [1] for example of what it looked like) in the past, the hate just stuck around and I don't think it's ever going away. [1] https://www.reddit.com/r/glitch_art/comments/144vjl/vlc_star...

13 years since that post and this is the first time I’m hearing of this long-past issue.

Haters gonna hate I guess.

Re: What you need to know before touching a video file

#32

Interesting read, it’s a shame the ranty format makes it 3x longer than necessary. Not sure why it takes a dump on VLC - it’s been the most stable and friendly video player for Windows for a long time (it matters that ordinary users, like school teachers, can use it without special training. I don’t care how ideological you are about Linux or video players or whatever lol).

In the anime fan subbing community (which this document is likely from), it's very common to hate on VLC for a variety of imagined (and occasionally real but marginal) issues.

Why is that?

Re: What you need to know before touching a video file

#33

I'm always amazed when I see how many people are unfamiliar with VLC hate. It was notorious (to the point of it being a popular meme topic) for video artifacts, slow/buggy seeking, bloated/clumsy UI/menus, having very little format support out of the box, and buggy subtitles. I assume nowadays it's much better, since it seems popular, but its reputation will stick with me forever.

For a long time it was the only graphical user-friendly option for non-technical Windows users that had decent support for a wide range of formats. I don’t know about its early years, but friends, family and I have been using it for a good 15+ years without encountering the issues folks are describing in these comments.

It seems there’s a lot of open-source lovers that haven’t also accepted that bugs can get fixed, projects can improve, etc. They’d rather treat a project as though it was stuck at version 0 from 20 something years ago. Deeply ironic.

Re: What you need to know before touching a video file

#34
I wish he talked about avidemux.

It's a simple tool which is great for many things, it has filters and there are most of the formats. I think it uses ffmpeg under the hood.

It's an old tool but it's fine for most things, when ffmpeg is to fastidious to use. ffmpeg is still what I use, but some more complex tasks are just more comfortable with avidemux.

Re: What you need to know before touching a video file

#35

Interesting read, it’s a shame the ranty format makes it 3x longer than necessary. Not sure why it takes a dump on VLC - it’s been the most stable and friendly video player for Windows for a long time (it matters that ordinary users, like school teachers, can use it without special training. I don’t care how ideological you are about Linux or video players or whatever lol).

Follow-up comment: I love how the author’s one brief take-down shot at VLC is currently the dominant criticism in the HN comments (inc. mine). 10,000+ words and the entire lot is being questioned because of one dubious throwaway comment about VLC.

A lesson to learn in that.

Lol

Re: What you need to know before touching a video file

#36

I'm always amazed when I see how many people are unfamiliar with VLC hate. It was notorious (to the point of it being a popular meme topic) for video artifacts, slow/buggy seeking, bloated/clumsy UI/menus, having very little format support out of the box, and buggy subtitles. I assume nowadays it's much better, since it seems popular, but its reputation will stick with me forever.

Agree. Never mind how far they were behind on the more power user options like scaling, dealing with mismatches in video framerate and monitor refresh rate, etc.

Havent used it in ages, but a decade ago it felt a joke for all the video artifacts and subtitle glitches.

The one part that does get me some about people who blindly still praise it as THE video player at least outside of more technically inclined spaces like this, is so many people assume it exists as some monolith. Clearly library free, entirely the original work of VideoLAN, gracious they be that they give it all away for free.

Re: What you need to know before touching a video file

#37
post #14

I'm curious what the issue is with using Handbrake? I use it all the time on macOS and it's generally a simple and effective tool for my purposes.

the author can't stand how it simply re-encodes videos instead of extracting the video tracks and puts them in new containers.

Re: What you need to know before touching a video file

#38
I've had a lot of misconceptions that I had to contend with over the years myself as well. Maybe this thread is a good opportunity to air the biggest one of those. Additionally, I'll touch on subbing at the end, since the post specifically calls it out.

My biggest misconception, bar none, was around what a codec is exactly, and how well specified they are. I'd keep hearing downright mythical sounding claims, such as how different hardware and software encoders, and even decoders, produce different quality outputs.

This sounded absolutely mental to me. I thought that when someone said AVC / H.264, then there was some specification somewhere, that was then implemented, and that's it. I could not for the life of me even begin to fathom where differences in quality might seep in. Chief of this was when somebody claimed using single threaded encoding instead of multi threaded encoding was superior. I legitimately considered I was being messed with, or that the person I was talking to simply didn't know what they were talking about.

My initial thoughts on this were that okay, maybe there's a specification, and the various codec implementations just "creatively interpret" these. This made intuitive sense to me because "de jure" and "de facto" distinctions are immensely common in the real world, be it for laws, standards, what have you. So I'd start differentiating and going "okay so this is H.264 but ". I was pretty happy with this, but eventually, something felt off enough to make me start digging again.

And then, not even a very long time ago, the mystery unraveled. What the various codec specifications actually describe, and what these codecs actually "are", is the on-disk bitstream format, and how to decode it. Just the decode. Never the encode. This applies to video, image, and sound formats; all lossy media formats. Except for telephony, all these codecs only ever specify the end result and how to decode that, but not the way to get there.

And so suddenly, the differences between implementations made sense. It isn't that they're flaunting the standard: for the encoding step, there simply isn't one. The various codec implementations are to compete on finding the "best" way to compress information to the same cross-compatibly decode-able bitstream. It is the individual encoders' responsibility to craft a so-called psychovisual or psychoacoustic model, and then build a compute-efficient encoder that can get you the most bang for the buck. This is how you get differences between different hardware and software encoders, and how you can get differences even between single and multi-threaded codepaths of the same encoder. Some of the approaches they chose might simply not work or work well with multi threading.

One question that escaped me then was how can e.g. "HEVC / H.265" be "more optimal" than "AVC / H.264" if all these standards define is the end result and how to decode that end result. The answer is actually kinda trivial: more features. Literally just more knobs to tweak. These of course introduce some overhead, so the question becomes, can you reliably beat this overhead to achieve parity, or gain efficiency. The OP claims this is not a foregone conclusion, but doesn't substantiate. In my anecdotal experience, it is: parity or even efficiency gain is pretty much guaranteed.

Finally, I mentioned differences between decoder output quality. That is a bit more boring. It is usually a matter of fault tolerance, and indeed, standards violations, such as supporting a 10 bit format in H.264 when the standard (supposedly, never checked) only specifies 8-bit. And of course, just basic incorrectness / bugs.

Regarding subbing then, unless you're burning in subs (called hard-subs), all this malarkey about encoding doesn't actually matter. The only thing you really need to know about is subtitle formats and media containers. OP's writing is not really for you.

Re: What you need to know before touching a video file

#39
post #14

I'm curious what the issue is with using Handbrake? I use it all the time on macOS and it's generally a simple and effective tool for my purposes.

Handbrake is fine if you truly need to reencode (aka “transcode”) your video, but if you find yourself with a video that your player can’t read, you might be able to just change the container format (remux it) using ffmpeg, copying the video and audio streams directly across.

With video there are 3 formats: the video stream itself, the audio stream itself, and the container (only the container is knowable from the extension). Formats could technically be combined in any combination.

The video stream especially is costly in CPU to encode, and can degrade quality significantly to transcode so it’s just a shame to re-encode if the original codec is usable.

Container format mkv is notorious for not being supported out of the box on lots of consumer devices, even if they might have codecs for the audio and video streams they typically contain. (It has cool features geeks like, though, but for some reason it gets less support.)

Re: What you need to know before touching a video file

#40

Interesting read, it’s a shame the ranty format makes it 3x longer than necessary. Not sure why it takes a dump on VLC - it’s been the most stable and friendly video player for Windows for a long time (it matters that ordinary users, like school teachers, can use it without special training. I don’t care how ideological you are about Linux or video players or whatever lol).

I don't believe it's the case anymore, but it was very common for VLC to cause video corruption (see [1] for example of what it looked like) in the past, the hate just stuck around and I don't think it's ever going away. [1] https://www.reddit.com/r/glitch_art/comments/144vjl/vlc_star...

It has never been very common for VLC to cause video corruption.
Post reply on HN