Live data from Hacker News

What you need to know before touching a video file

gist.github.com

211–220 of 251 posts

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

#211
post #122
post #114

Earlier quoted context omitted.

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 hard…

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…

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.

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

#212
post #115

Earlier quoted context omitted.

Out of pure curiosity, what kind of things were you VLC using for, for it to break so often? I'm almost never doing anything with video, so I'm completely clueless in this field.

I don't recall my issues being media file or workload specific [0]. It was specifically just general frontend stuff I believe [1]. Although I should probably also mention that I don't remember much to begin with, other than my decidedly negative conclusion that made me switch players, and the overall personal narrative around that. It's been quite a few years if not a whole decade. [0] Doesn't mean there weren't any,…

Thanks for the reply, yeah that's interesting, I remember also having issues with VLC as a kid (I'm in my late 20's now), but I always chalked it up to me being a noob and not knowledgeable, I wonder retrospectively how much of that were actual me-issues and how much VLC-issues. Recently one of my parents wanted to play a DVD via VLC which did not work, where the issues ultimately was missing DVD libraries which apparently can't be shipped in Ubuntu due to licensing issues (libdvdcss). 12 year old me wouls not be able to debug this issue to be honest.

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

#213

Something I've never been able to find satisfactory information on (and unfortunately this article also declares it out of scope), is what is the actual hard on-the-wire and on-disk differences between SDR and HDR? Like yes, I know HDR = high dynamic range = bigger difference between light and dark, but what technical changes were needed to accomplish this? The way I understand it, we've got the YCbCr that is being c…

HDR is nothing more than metadata about the color spaces. The way the underlying pixel data is encoded does not change. HDR consists of

1. A larger color space, allowing for more colors (through different color primaries) and a higher brightness range (though a different gamma function)

2. Metadata (either static or per-scene or per-frame) like a scene's peak brightness concrete tonemapping settinsg, which can help players and displays map the video's colors to the set of colors it can display.

I actually have a more advanced but more compact "list of resources" on video stuff in another gist; that has a section on color spaces and HDR:

https://gist.github.com/arch1t3cht/ef5ec3fe0e2e8ae58fcbae903...

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

#214

Earlier quoted context omitted.

> Don't use Topaz AI, Anime4k, RealESRGAN, RIFE, etc. Trust me, just don't. Is what the submission says about Topaz and similar. > Applying any kind of post-processing[4] Is what the footnote you quoted is linked to.

There's no mistake, “Topaz and similar” == “any kind of postprocessing”.

Right, but since the "AI upscaling" "advice" is more specific, doesn't that take precedent?

> Do post-processing if you're surgical about it

> Don't do AI upscaling regardless, never do it, and don't even ask why

Is the impression I get from this article.

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

#215

Earlier quoted context omitted.

MPC-HC is still a thing? I remember installing that (and K-Lite Codec Pack) on Windows, back in the day. Haven't used, or even thought about MPC-HC in years.

Yes: https://github.com/clsid2/mpc-hc

Is anyone else annoyed about how this is not very discoverable? The first Google hit for ”MPC-HC” is the web site saying ”MPC-HC is not under development since 2017. Please switch to something else.” What happened? Has the maintainer refused to hand over the project, or something?

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

#216
post #201

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…

> 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. Soooo with everyone getting used to creative names instead of descriptive names over the past decade or two, I guess "codec" just became a blob and it just never crosses…

There's a term overload involved. In implementation terms, codec stands for coder/decoder, with "coder" referring exactly to an encoding capability: https://en.wikipedia.org/wiki/Codec

So that's a swing and a miss I'm afraid. But I'm very interested to hear what do you think a "coder" library does in this context if not encode, and why is it juxtaposed with "decoder" if not for doing the exact opposite.

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

#217
post #215

Earlier quoted context omitted.

Yes: https://github.com/clsid2/mpc-hc

Is anyone else annoyed about how this is not very discoverable? The first Google hit for ”MPC-HC” is the web site saying ”MPC-HC is not under development since 2017. Please switch to something else.” What happened? Has the maintainer refused to hand over the project, or something?

Nobody took over maintenance at the time. Eventually clsid2 picked it up, and it has been maintained by him ever since.

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

#218
Original post author here.

It seems like the main criticisms I am getting for this article are because it's escaped past its main target audience, so let me clarify a few things.

This post was born out of me hanging out in communities where people would make their own shortened edits of TV series and, in particular, anime, often to cut out filler or padding. Many people there would make many of the mistakes mentioned in the post, in particular reencoding at every step without knowing how to actually control efficiency/quality. I spent a lot of time helping out individual people one-on-one, but eventually wrote the linked article to collect all of my advice in one place. That way I (or other people I know) can just link to it like "Read the section on containers here," and then answer any follow-up questions, instead of having to explain from scratch each time.

> It seems really weirdly written. / ranty format

So, yes, it does. It was born out of one-to-one explanations on Discord. I wouldn't be surprised if it may seem condescending to a more advanced reader, but if I rant about some point to hammer it down it's because it's a mistake I've seen people make often enough that it has to be reenforced this much. I wouldn't write a professional article this way.

The other point many people seem to get hung up about is the "hate" on VLC. Let me clarify that I do not "hate" VLC at all, I just don't recommend it. VLC is only mentioned once in the entire page, exactly because I didn't want to slot in an intermission purely to list a bunch of VLC issues. I felt like that would qualify more as "hate."

That said, yes, pretty much anyone I know in the fansubbing or encoding community does not recommend VLC because of various assorted issues. The rentry post [1] is often shared to list those, though I don't like how it does not give sources or reproducible examples for the issues it lists. I really do want to go through it and make proper samples and bug reports for all of these issues, I just didn't have the time yet.

Let me also clarify that I have nothing against the VLC developers. VideoLan does great work even outside of VLC, and every interaction I've had with their developers has been great. I just do not recommend the tool.

[1] https://rentry.co/vee-ell-cee

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

#219
post #53
post #32

Earlier quoted context omitted.

Why is that?

Mostly that VLC has had noticeable issues with displaying some kinds of subtitles made with Advanced SubStation (especially ones taking up much of the frame, or that pan/zoom), which MPV-based players handle better. If you want a MPV-based player GUI on macOS, https://github.com/iina/iina is quite good.

Note that, while I haven't had time to investigate them myself yet, IINA is known to have problems with color spaces (and also uses libmpv, which is quite limited at the moment and does not support mpv's new gpu-next renderer). Nowadays mpv has first-party builds for macOS, which work very well in my opinion, so I'd recommend using those directly.

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

#220

Earlier quoted context omitted.

No it isn't, VLC plays everything back slightly incorrectly in all sorts of ways, the subtitle rendering and colorspace handling isn't compliant at all.

VLC uses libass for .ass subtitle rendering as far as I can see, shouldn't it be the same?

One difference I can immediately point to is that VLC always renders subtitles at the video's storage resolution and then up/downscales all bitmaps returned by libass individually before blending them. This can create ugly ringing artifacts on text.

I've also seen many reports of it lagging or choking on complex subtitles, though I haven't had the time to investigate that myself yet.

Either way, it's not as simple as "both players use libass." Libass handles the rasterization and layout of subtitles, but players need to handle the color space mangling and blending, and there can be big differences there.

Post reply on HN