Live data from Hacker News

What you need to know before touching a video file

gist.github.com

191–200 of 251 posts

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

#191
post #6

What's wrong with VLC?

my biggest pet peeve was that VLC was always considered a streamer and treated local files as streams as well. for the longest time, stepping within the video was not possible. reverse play was also a bane as well, even with i-frame only content. i have long found players that are better for me, but still find myself using VLC frequently because it still has features these other players do not.

This matches with my observation, VLC tends to be more tolerant of slightly broken files or random issues that you encounter when streaming. Especially for hls streams, vlc often works when ffplay refuses to play it, I believe because vlc uses their own demuxer (instead of relying on libavformat).

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

#192

Earlier quoted context omitted.

He's talking about using VLC for transcoding or encoding, where the functionality has lots of issues and is kind of bolted on the side. VLC for playing is totally fine.

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?

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

#193
post #175

Earlier quoted context omitted.

https://mpv.io/

Unofficial third-party builds from unknown github accounts; I think that you are really brave if you installed it. And the first party ones available there are for testing, with missing features :/ We do not have this kind of problems with VLC.

Did you miss the github builds or just discounting them?

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

#194

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…

Do you have a device that supports HDR such as any MacBook in the last 10+ years, any iPhone since iPhone 4, or most high end Androids?

If so, try this: https://gregbenzphotography.com/hdr-gain-map-gallery/

Clicking the "Limit to SDR" and "Allow Full HDR (as supported)" should show a significant difference if you device supports HDR. If you don't see a difference then your device doesn't support HDR (or your browser)

For these images, there's a specific extension to JPEG where they store the original JPEG like you've always seen, and then a separate embedded gain map to add brightness if the device supports it. That's for stills (JPEGs) though, not video but the "on the wire difference" is that gain map

I'm not an expert but for videos, ATM, afaict, they switched them to 10bits (SDR is 8bits), and added metadata to map that 10 bits to values > "white" where white = 100nits. This metadata (PQ or HLG) can map those 10 bits up to 10000 nits.

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

#195

Nearly this entire HN comment section is upset about VLC being mentioned once and not recommended. If you can not understand why this very minor (but loud?) note was made, then you probably do not do any serious video encoding or you would know why it sucks today and is well past its prime. VLC is glorified because it was a video player that used to be amazing back in the day, but hasn't been for several years now. I…

MPV is not user friendly, but I was very impressed by the gapless playback.

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

#196

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…

The issue is encoding is an art, especially as it's lossy. You choose how much data to throw away (kind of like when you pick a quality in JPEG). Further, for video, you generally try to encode the differences between 2 frames. Again, because it's a lossy difference, it's up to the creator of the encoder to decide how to compute the difference. different algorithms come up with a different answers. There result still fits the spec.

Let's just say we were encoding a list of numbers. So we get a keyframe (an exact number) and then all frames after that until the next keyframe are just deltas. How much to add to that keyframe number

    keyframe = 123
    nextFrame += 2   // result = 125
    nextFrame += 3   // result = 128
    nextFrame -= 1   // result = 127
etc... A different encoder might have different deltas. When it comes to video, those difference are likely relatively subtle, tho some definitely look better than others.

The "spec" or "codec" only defines that each frame is encoded as a delta. it doesn't say what those detlas are or how they are computed, only how they are applied.

This is also why most video encoding software has quality settings and those settings often includely the fact higher quality is slower. Some of those settings are about bitrate or bitdepth or other things but others are about how much time is spent looking for the perfect or better delta values to get closer to the original image as searching for bettter matches takes time. Especially because it's lossy, there is no "correct" answer. There is just opinion.

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

#197
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 short version is there's nothing wrong with it for your use case.

The author's POV is that the handbrake is a lossy conversion and often people use it in cases where they could have used a different tool that is lossless.

My uses of handbrake are that I always want a lossy conversion so no issue. A good example is anytime I make screen capture and want to post it on github. I want it to be under the 10meg limit (or whatever it is) so I want it to be re-encoded to be smaller. I don't mind the loss in quality.

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

#198
post #123

Earlier quoted context omitted.

> It is the Firefox of media players. So... the better option?

IDK where you have been for the last decade, but Firefox has not been the better option since Chromium was made Disliking Google Chrome proper is one thing, but Chromium is superior in every way. Rendering, features, speed, memory management

Chromium has more than a few flaws that I'm sure you can discover if you choose to. Here's an incident that I cannot forgive:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909

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

#199
post #184

I thought it was a good read, although with a couple of mistakes and a somewhat (IMO) childish sense of entitlement. This reads a bit like something a young teen who is heavy into tech wrote. I'm sure I could have authored something with the same overall tone and vibe when I was younger (perhaps not same quality, though!). Either way, it's a very decent read! The idea that YCbCr is only here because of "legacy reason…

I would have also expected at least a passing mention of chroma subsampling beyond 4:2:0 if only just to have an excuse to give the "4:2:0" label to the usual case they mention. And you might run across stuff in 4:2:2 or 4:4:4 not all that rarely.

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

#200

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…

> Naturally, we can stick brighter backlights in our monitors to make the difference between light and dark more significant, It's actually the opposite that makes the biggest difference with the physical monitor. CRTs always had a residual glow that caused blacks to be grays. It was very hard to get true black on a CRT unless it was off and had been for some time. It wasn't until you could actually have no light fro…

Note that crt's did not have bad blacks, they were far better than lcd displays. I am currently using an ips display and it has pretty good blacks, notably better than a normal lcd display. But I remember crt's being even better(probably just me being nostalgic for the good ol days when we were staring straight into an electron beam with only an inch of leaded glass to protect us). I Don't think they were lying, oleds are very very good(except for the burn in issue, but that's solvable), but I would be wary about the conclusions of a demo designed to sell something.

For what it's worth, the display I liked best was a monochrome terminal, a vt220, Let me explain, a crt does not really have pixels as we think of them on an modern display, but they do have a shadow mask which is nearly the same thing. however a monochrome crt(as found in a terminal or oscilloscope) has no shadow mask, the text of those vt220 was tight, it was a surprisingly good reading experience.

Post reply on HN