Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What you need to know before touching a video file

gist.github.com

Post reply on HN
Print view View original

71–80 of 251 posts

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

#71

Post by fenwick67 »

craftkiller wrote: post #46

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…

here you go

> 10 bits per sample Rec. 2020 uses video levels where the black level is defined as code 64 and the nominal peak is defined as code 940. Codes 0–3 and 1,020–1,023 are used for the timing reference. Codes 4 through 63 provide video data below the black level while codes 941 through 1,019 provide video data above the nominal peak.

https://en.wikipedia.org/wiki/Rec._2020

Compare to

https://en.wikipedia.org/wiki/Rec._709

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

#72

Post by dylan604 »

perching_aix wrote: post #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…

I was a DVD programmer for 10 years. There was a defined DVD spec. The problem is that not every DVD device adhered to the spec. Specs contain words like shall/must and other words that can be misinterpreted, and then you have people that build MVP as a product that do not worry about the more advanced portion of the spec.

As a specific example, the DVD software had a random feature that could be used. There was one brand of player that had a preset list of random numbers so that every time you played a disc that used random, the random would be the exact same every time. This made designing DVD-Video games "interesting" as not all players behaved the same.

This was when I first became aware that just because there's a spec doesn't mean you can count on the spec being followed in the same way everywhere. As you mentioned, video decoders also play fast and loose with specs. That's why some players cannot decode the 10-bit encodes as that's an "advanced" feature. Some players could not decode all of the profiles/levels a codec could use according to the spec. Apple's QTPlayer could not decode the more advanced profiles/levels just to show that it's not "small" devs making limited decoders.

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

#73

Post by mafuyu »

craftkiller wrote: post #46

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…

The keywords you're missing are color spaces and gamma curves. For a given bandwidth, we want to efficiently allocate color encoding as well as brightness (logarithmically to capture the huge dynamic range of perceptible light). sRGB is one such standard that we've all agreed upon, and output devices all ostensibly shoot for the sRGB target, but may also interpret the signal however they'd like. This is inevitable, to account for the fact that not all output devices are equally capable. HDR is another set of standards that aims to expand the dynamic range, while also pinning those values to actual real-life brightness values. But again, TVs and such may interpret those signals in wildly different ways, as evidenced by the wide range of TVs that claim to have "HDR" support.

This was probably not the most accurate explanation, but hopefully it's enough to point you in the right direction.

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

#74

Post by latexr »

weinzierl wrote: post #57

The article talks about image comparisons but does not say what the best way to extract an image is. If I want the best possible quality image at a precisely specified time, what would I do? Can I increase quality if I have some leeway regarding the time (to use the closest keyframe)? Is there a way to "undo" motion blur and get a sharp picture?

I usually use a shortcut in mpv to extract the screenshot. If I want to do it via the command-line:

  ffmpeg -ss 00:00:12.435 -i '/Users/weinzieri/videofile.mp4' -vframes 1 '/Users/weinzieri/image.png'
The means “go to 00:00:12.435 on the file /Users/weinzieri/videofile.mp4 and extract one frame to the file /Users/weinzieri/image.png”.

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

#75

Post by yaur »

ramesh31 wrote: post #12
embedding-shape wrote: post #9

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

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

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.

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

#76

Post by memoriuaysj »

craftkiller wrote: post #46

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…

YCrCb can also be better for HDR or not - 4:2:2 vs 4:4:4

if you expand limited YCrCb to a large HDR range you'll get a "blurred" output.

Imaging converting 1 bit image (0 or 1, black or white pixel) to full range HDR RGB - it's still black and white

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

#78

Post by jandrese »

BitsAndObjects wrote: post #5

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

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.

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

#79

Post by memoriuaysj »

ErroneousBosh wrote: post #62
weinzierl wrote: post #57

The article talks about image comparisons but does not say what the best way to extract an image is. If I want the best possible quality image at a precisely specified time, what would I do? Can I increase quality if I have some leeway regarding the time (to use the closest keyframe)? Is there a way to "undo" motion blur and get a sharp picture?

> Is there a way to "undo" motion blur and get a sharp picture? Not really, no, any more than there is a way to unblur something that was shot out of focus. You can play clever tricks with motion estimation and neural networks but really all you're getting is a prediction of what it might have been like if the data had really been present. Once the information is gone, it's gone.

it's not gone, just more difficult to extract

video has certain temporal statistics which can allow you to fit the missing information

only true blurred white noise is impossible to recover

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

#80

Post by echelon »

cnntth wrote: post #55
echelon wrote: post #43

Earlier quoted context omitted.

[flagged]

OP makes zero comments about content generation, and the complaint is about upscaling introducing artifacts not in the original source. No different than hating a bad 4k remaster / sharpening.

That advice is not universal, and without context it's simply wrong.

You wouldn't upscale a classic film in this way, but there are plenty of low-resolution shots that benefit. Especially with VGA resolution renders and modern AI workflows.

Just looking at the Topaz marketing, you can see a lot of places where it indeed does work. And 20-year industry professionals are using it today for their day jobs.

If you want to say "don't upscale a classic film in Topaz", say that. Because context makes the advice correct. This blanket "do not use" statement is flat out wrong.

Post reply on HN