321–330 of 576 posts
If you're on Linux, don't forget to enable hardware acceleration by adding hwdec=auto to mpv.conf. Works with AMD/Intel/NVIDIA. https://interfacinglinux.com/2024/01/10/hardware-acceleratio...
Earlier quoted context omitted.
If you enter video-related enthusiast scenes, such as fansubbed anime releases, mpv is recommended over anything else across the board. There are releases that break in VLC, and mpv is usually first to support new features. It also has particularly good defaults in terms of good and accurate playback, so where you might see some people say "install mpc-hc and these scripts and change these settings", with mpv it's ju…
> I even use it when an image I saved ends up as .html for some reason and then use the info screen to determine the real extension it should be so I can rename it If you’re on Linux on macOS, you’ll have access to the `file` command-line tool which can do it effectively. In a couple of lines of shell scripting you can even have it auto-change the extension. https://en.wikipedia.org/wiki/File_(command)
Earlier quoted context omitted.
> video with only a single key frame at the beginning I've literally never seen a video like that in my life, but I'd still expect it to work. Just decode everything starting from frame 1. My desktop can decode H265 at 1,666 fps. I can wait. https://docs.nvidia.com/video-technologies/video-codec-sdk/1...
That blows up pretty quickly though? Even a 10 minute video will take in the worst case ~20 seconds to decode at that rate. Not really an excuse not to have it (since most video wont be encoded in such an insane way), but the developers owe no obligation to users to implement it.
Earlier quoted context omitted.
I think technically he’s correct (I haven’t worked on media decoding code, but I understand how common video encoding formats work). If you have a long video with only a single key frame at the beginning then to step back you would need to, starting from the beginning of the video, decode every frame up to the previous frame you wanted to jump to in order to apply frame deltas, also assuming you have some sort of fra…
Wouldn’t creating in-memory key frames for every nth frame resolve substantial computations on a frame-by-frame basis?
Earlier quoted context omitted.
That strikes me as such a strange statement, I’ve always considered it to be among the most impressive OSS projects out there. It tackles enormous complexity, works everywhere, and has a trove of a million hidden features. For example, I use it to headless play streams from CLI.
VLC is only praised in "normie" places. It is hated in places like anime forums, 4chan, etc.
It sounds stupid but the killer feature for me is possibility to have multiple subtitles visible, all easily configurable with a few keybinds (track, offset, position, size etc). No streaming service provides this, and they actively omit subtitle languages that aren't "relevant" to your geolocation. I cannot respect a service like that.
+1. This is a fantastic feature. I haven't even bothered learning the keybindings (perhaps I should), I just start with --sid1= and --sid2= and it works well enough. Neither me nor my significant other are native English speakers, but we have different native languages. I'm comfortable enough with English, but like having English subtitles since I have a hard time with some dialects and occasionally just miss a word…
Earlier quoted context omitted.
You need to send an email to the admin and ask for approval in order to register an account on VLC website to report bugs. This says it all.
That's the result of being successful for wide non-technical audience. The signal over noise would approach zero if everybody could create a bug report when something does not work as they wanted. Have you tried to create a meaningful bug report (not feature request) that has not been previously reported and were rejected? If so your complaint is valid. I haven't so I don't know.
I hear you, but it could be something not so extreme. Lots of even more popular projects work fine with bug reporting system on GitHub, which everyone has access to.
> Have you tried to create a meaningful bug report (not feature request) that has not been previously reported and were rejected?
No I don't, I just want to subscribe to the issues I care, which you can't do without having an account..
Earlier quoted context omitted.
> It's of course work to do, and I'm not super motivated to send them that patch, and there's the question of it it would be merged That's my issue; he calls for people to send patches, but anyone capable of writing such a patch is also probably going to see that he's not positive on the matter, and that his "patches welcome" is really pretty passive aggressive in this instance. At least, that's how it comes off to m…
There's also a middle ground: Painstakingly describe the solution first, along with its downside of not being general in the same way as some of the existing features (I guess for example seeking back 10 seconds) are not, and ask whether a patch implementing this solution would be welcome before implementing it.
https://forum.videolan.org/viewtopic.php?f=12&t=103604&p=407...
I wanted to report a big about VLC's extraordinarily badly designed "Magnification/Zoom" user interface, so first I searched the forum to see if there was any other discussion about it, which there naturally was.
So I painstakingly wrote up an extremely detailed description of a bunch of interrelated bugs related to zooming and how it terribly interacted with other features like rotation, in response to the VLC development team brushing off another user complaining about its terrible "Magnification/Zoom" user interface, and they brushed me off too because they were too lazy to read it.
They told me to just submit a bug report, but I pointed out that I was describing a several interrelated bugs, which would require submitting many bug reports, which they would have known if they had actually bothered to read what I painstakingly wrote in great detail with step by step instructions about how to reproduce the bugs and suggestions for improvements, so I obviously wanted to discuss them all first to see if they were even worth my time submitting multiple bug reports about, or if all my efforts reporting bugs and trying to fix them and submit patches would be a waste of time, brushed off and ignored like they did to the other users who described the bugs and usability problems they were experiencing.
Jean-Baptiste Kempf himself replied "If you did shorter posts, maybe people will read them..."
To which I replied "if you did less arrogant responses to long posts, maybe people wouldn't give up on trying to help you."
And of course most of the pathologically terrible bugs I described are still there, a dozen years later. And Jean-Baptiste Kempf still continues to act that way.
More details:
https://news.ycombinator.com/item?id=41281153
HN user KingMob's post perfectly summarized my discouraging experience from a dozen years ago, about a set of bugs and usability problems relating to the horrible "Magnification/Zoom" interface:
https://news.ycombinator.com/item?id=41280375
>KingMob 5 hours ago | unvote | parent | context | flag | favorite | on: Mpv – A free, open-source, and cross-platform medi...
>It's because the developer is misconstruing a non-technical decision they made as a technical limitation. The commenters are trying to point this out, which misses the reality that the developer probably isn't going to budge from their requirement of universal support.
>That dev's rationalization also sends a signal to any commenter with the technical chops to submit a PR, that it will probably be rejected for not supporting 100% of the codecs. I have no doubt people who could do it, over the years looked at that thread and concluded it would be a waste of their time.
Jean-Baptiste Kempf still continues to act that way, and still hasn't even admitted to those bugs and usability problems, let alone fixed them or accepted patches from anyone else who did. He just discourages qualified developers from collaborating, and brushes off legitimate requests from users who can't code but fucking well know other video players don't suffer from those problems.
Earlier quoted context omitted.
IINA has issues with color space conversions. I've heard that the specific issue is that it always (incorrectly) assumes a BT601 matrix for all videos, though I haven't verified it myself and cannot really right now. (I did verify its colors differing from stock mpv before writing this comment, though.) Various mpv wrappers exists, but for reasons like these stock mpv is the only fully reliable version.
Have you filled a bug report about this?
Earlier quoted context omitted.
Disagree! VLC is what it is today because the authors understood video standards enough to make the _right_ abstractions that could generalize to ~every video format ever. That is no easy task. Video container standards are utterly perverse, and seem to delight in stomping over even the most innocent intuitions about what you would expect to find in a stream of bits that purports to contain "video". They often refuse…
> VLC is what it is today because the authors understood video standards enough to make the _right_ abstractions that could generalize to ~every video format ever. VLC used to be the dominant video player for this reason, but then everything has crystallized around h.264 (and h.265) which made the breadth of codec support not as important anymore, making VLC slowly losing relevance because they aren't focused on user…