Live data from Hacker News

What you need to know before touching a video file

gist.github.com

181–190 of 251 posts

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

#181

Earlier quoted context omitted.

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

The person is asking for the better option.

I coincide with the person, by the moment Firefox is the better option, the comparative form is confusing.

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

#183
post #166

I edit videos on a hobbyist level (mostly using davinci resolve to edit clips of me dying in video games to upload to a shareX host to show to friends). The big takeaway for me was reading that for quality/efficiency libx264 is better than nvenc for rendering h264 video. All this time I’ve assumed nvenc is better because it used shiny GPU technology! Is libx264 better for recording high quality videos too? I know it…

You might want to try dumping your work from Resolve out in ProRes 422 HQ or DNxHR HQ and then encoding to h264/h265 with Compressor (costs $; it's the encoder part of Final Cut as a separate piece of software) on a Mac or Shutter Encoder. Also, I'm making a big assumption that you're using the paid version of Resolve; disregard otherwise. It might not be worth it if your input material is video game capture but if you have something like a camera that records h264 4:2:2 10bit in a log gamma then it can help preserve some quality.

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

#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 reasons", and that we only we discard half of chrominance because of equally "legacy reasons" is bonkers, though.

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

#185

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…

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…

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

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

#186
post #99

Earlier quoted context omitted.

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

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

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.

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

#187
post #50
post #32

Earlier quoted context omitted.

Why is that?

At least for the real part there was the great 10-bit encoding "switch off" at around 2012 where it seemed like the whole anime encoding scene decided to move into encoding just about everything with "10-bit h264" in order to preserve more detail at the same bitrate. VLC didn't have support for it and for a long time (+5 years?) it remained without proper support for that. Every time you tried playing such files they…

8-bit and 10-bit almost give digital video too much credit. Because of analog backwards compatibility, 8-bit video only uses values 16-235, so it's actually like… 7.8 bit.

It's nowhere near enough codes, especially in darker regions. That's one reason 10-bit is so important, another is that h264 had unnecessary rounding issues and adding bit depth hid them.

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

#188
Tangential but, at least for me, I find lots of video creators making 2-3 gig videos for no noticable difference in quality for me re-encoding them to 1/4th the size or less.

My impression is, their audience equates file size with quality so the bigger the file the more "value" they got from the creator. This is frustrating because bigger files means hitting transfer limits, slower to download, slower to copy, taking more space, etc...

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

#189

Tangential but, at least for me, I find lots of video creators making 2-3 gig videos for no noticable difference in quality for me re-encoding them to 1/4th the size or less. My impression is, their audience equates file size with quality so the bigger the file the more "value" they got from the creator. This is frustrating because bigger files means hitting transfer limits, slower to download, slower to copy, taking…

Yeah, similarly, my DSLR makes some huge video files, but they aren't that much better quality than my phone's. Of course, the sensor is massively better, and that makes a difference, but I don't know why the files are so much bigger.

My hypothesis is that they use a really high quality value, and that there are diminishing returns there.

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

#190

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.

> Not really, no, any more than there is a way to unblur something that was shot out of focus.

This is actually possible:

https://en.wikipedia.org/wiki/Deconvolution

If you have a high-quality image (before any compression) with a consistent blur, you can actually remove blur surprisingly well. Not completely perfectly, but often to a surprising degree that defies intuition.

And it's not a prediction -- it's recovering the actual data. Just because it's blurred doesn't mean it's gone -- it's just smeared across pixels, but clever math can be use to recover it. It's used widely in certain types of scientific imaging.

For photographers, it's most useful in removing motion blur from accidentally moving the camera while snapping a photo.

Post reply on HN