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

231–240 of 251 posts

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

#231

Post by izacus »

jaapz wrote: post #123
Drybones wrote: post #116

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…

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

This kind of insulting quip, refusing to engage with the body of the post, is really inappropriate. Can you please not behave like an arse?

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

#232

Post by ErroneousBosh »

memoriuaysj wrote: post #161
ErroneousBosh wrote: post #121

Earlier quoted context omitted.

No, it's not "restoring detail". The information is gone. It is predicting what the information might maybe have been like.

you are arguing with math proofs here, the information is not gone, if it was a real video (as opposed to adversarily generated video)

I'm struggling with the idea that you can use maths to recover information from a video that simply was not present in the video.

I get that what you're describing can statisically "unblur" stuff you've blurred with overly-simplistic algorithms.

I can provide you with real-world footage that has "natural" motion blur in it, if you can demonstrate this technique working? I'd really like to see how it's done.

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

#233

Post by Numerlor »

Drybones wrote: post #116

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…

I did recently see someone compare mpv and vlc on a 8k HDR @ 60fps file with mpv really lagging while vlc doing it fine. I could confirm the mpv lags but don't have vlc, so not sure if it's just better in that specific case or did something like no actual HDR

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

#234

Post by arch1t3cht »

Numerlor wrote: post #233
Drybones wrote: post #116

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…

I did recently see someone compare mpv and vlc on a 8k HDR @ 60fps file with mpv really lagging while vlc doing it fine. I could confirm the mpv lags but don't have vlc, so not sure if it's just better in that specific case or did something like no actual HDR

This may just be because mpv has higher-quality default settings for scaling and tonemapping. Try mpv with profile=fast, maybe. To properly compare mpv's and VLC's performance you'd need to fully match all settings across both players.

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

#235

Post by Numerlor »

arch1t3cht wrote: post #234
Numerlor wrote: post #233

Earlier quoted context omitted.

I did recently see someone compare mpv and vlc on a 8k HDR @ 60fps file with mpv really lagging while vlc doing it fine. I could confirm the mpv lags but don't have vlc, so not sure if it's just better in that specific case or did something like no actual HDR

This may just be because mpv has higher-quality default settings for scaling and tonemapping. Try mpv with profile=fast, maybe. To properly compare mpv's and VLC's performance you'd need to fully match all settings across both players.

It was with the fast profile using both software and hardware deciding, important detail I forgot was that the video was av1. Don't have the link to it now but it was from jellyfin's test files

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

#236

Post by arch1t3cht »

jorl17 wrote: 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…

The core idea of YCbCr - decoupling chrominance and luminance information - definitely has merit, but the fact that we are still using YCbCr specifically is definitely for historical reasons. BT.601 comes directly from analog television. If you want to truly decouple chrominance from luminance, there are better color spaces (opponent color spaces or ICtCp, depending on your use case) you could choose.

Similarly, chroma subsampling is motivated by psychovisual aspects, but I truly believe that enforcing it on a format level is just no longer necessary. Modern video encoders are much better at encoding low-frequency content at high resolutions than they used to be, so keeping chroma at full resolution with a lower bitrate would get you very similar quality but give much more freedom to the encoder (not to mention getting rid of all the headaches regarding chroma location and having to up- and downscale chroma whenever needing to process something in RGB).

Regarding the tone of the article, I address that in my top-level comment here.

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

#238

Post by chrisldgk »

perching_aix wrote: post #47
weinzierl wrote: post #41

"Don't use Topaz AI, Anime4k, RealESRGAN, RIFE, etc. Trust me, just don't." Why? I only know Topaz and I always thought it had its narrow but legitimate uses cases for upscaling and equalizing quality?

Can't mind read the guy obviously, but the usual motivation that I'm aware of is that you pretty much fuck over everyone else that comes later. Upscalers improve over time, but in terms of distribution, recency bias is strong and visual treats are inviting. So when those much better upscalers eventually come around, what's more likely to still be available is the secondary source you distributed, which is already ups…

You should read the article.

The reasons stated against upscaling were that (re-)encoding video files should generally be done in a way that preserves as much of the original information and intent as possible. AI upscalers add information where there is none, thus modifying the video in a way that goes against that goal.

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

#239

Post by savolai »

savolai wrote: post #155
Drybones wrote: post #144

Earlier quoted context omitted.

Chromium based browsers have non-google sync. Vivaldi implements their own encrypted sync service and I believe Brave does as well. But I am talking about browser feature support, not stuff that can supplemented with an extension like a password manager. Firefox has poor support for modern web features including video processing and encoding which makes it very bad at web conferencing/video calls or in-page streaming…

Oh I thought you meant actual chromium browser. Those seem rather marginal features from my pov but of course once you need them, you need them, I guess.

Also, for context: ’Some truth here, but it’s overstated.

Firefox does WebRTC fine. AV1 works, simulcast works, calls and streaming work. Chrome still leads on performance tweaks and extra APIs, but “very bad” is just wrong.

DevTools aren’t “much worse.” Different, less popular, sometimes better (CSS, network). Chrome wins mainly because everyone targets it first.

API gaps are real but the list is sloppy. WebGPU and WebTransport exist in Firefox now, just behind on advanced bits. Periodic Background Sync barely matters. WebRTC support keeps closing the gap.

Missing stuff like Web Serial, Badging, fuller Web Share? True, and mostly intentional.

HDR is the weakest claim that actually holds. AV1 decode exists, but HDR support still feels half-done.

TL;DR: Firefox lags Chromium in breadth and polish, not in core modern web capability. Calling it bad for video or modern apps doesn’t match reality.” ’

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

#240

Post by BloodyIron »

foresto wrote: post #198
Drybones wrote: post #133

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

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

Show me a piece of software without flaws and I'll show you either a liar, or perhaps the program "ping".
Post reply on HN