Earlier quoted context omitted.
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.
What you need to know before touching a video file
91–100 of 251 posts
Re: What you need to know before touching a video file
#92The second technical definition in this document is wrong. Great way to put the "the author is opinionated but is clueless" marker right near the top. > Actual video coding formats are formats like H.264 (also known as AVC) or H.265 (also known as HEVC). Sometimes they're also called codecs, short for "encode, decode". Codec is coder/decoder. It's not the format. There's a footnote claiming people mix the 2 terms up…
I would assert that the author was already being precise. A statement that X is "sometimes called" Y already conventionally carries the subtext that Y isn't actually the correct term; that Y is instead some kind of colloquial variant or corrupted layman's coinage for the more generally-agreed-upon term X.
Why mention the incorrect terminology Y at all, then?
Specifically in the case that pertains here, where far more laymen are already familiar with the Y term than the X term, giving Y as a synonym in the definition of X is a way to give people who are already familiar with this concept — but who only know it as Y — an immediate understanding of what is being discussed, by connecting their knowledge of "Y" over to the X term the author is defining. This is an extremely common practice in academic writing, especially in textbooks.
Re: What you need to know before touching a video file
#93What's wrong with VLC?
Making such a bold, unsubstantiated claim is a curious item in an otherwise detailed document. I went looking for other explanations and found this gem: https://www.reddit.com/r/mpv/comments/m1sxjo/it_is_better_mp... I think it might be one of those classic “everyone should just get good like me” style opinions you find polluting some subject matter communities.
Re: What you need to know before touching a video file
#94Earlier quoted context omitted.
> 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
#95Earlier quoted context omitted.
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 t…
You apply it to where it is needed. Not every scene need the same treatment.
Re: What you need to know before touching a video file
#96Earlier quoted context omitted.
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
It really is gone. You can predict what you think it might have been, but you can't know what it was.
but across many consecutive frames, the information is spread out temporaly and can be recovered (partially)
the same principle of how you can get a high resolution image from a short video, by extracting the same patch from multiple frames
Re: What you need to know before touching a video file
#97https://github.com/occivink/mpv-scripts
There is also a way to losslessly cut preserving the original encoding but you give up the precision of the cuts due to keyframes. The MPV script above can do that too: script-opts/encode_slice.conf
Re: What you need to know before touching a video file
#98Earlier quoted context omitted.
technically correct is the best kind. who cares if it's obnoxious? take the opinions and agree or disagree with them.
How do you know it is technically correct without explanation. It's not much different from someone getting blown off for being annoying because they constantly question simple answers when seeking better understanding. I was fortunate to work with a group of engineers when I was very young that accepted my constant use of "why?" not as disrespectful questioning but realized I was actually learning so they naturally…
Re: What you need to know before touching a video file
#99It 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…
Exactly, very hard to take the rest of it seriously after the VLC bit. VLC has literally never left me hanging, across I don't know how many decades. It's gonna take more than a trust me bro to challenge that.
Re: What you need to know before touching a video file
#100Earlier quoted context omitted.
Drives me crazy but I'm glad to learn of it :D Makes a lot of sense in retrospect, to the extent it bothers me I haven't figured it out myself earlier.
this is exactly what "higher" compression levels do (among other things like bigger dictionary) - they try harder, more iterations, to find the optimum combination of available knobs for a particular chunk of data.