241–250 of 576 posts
Earlier quoted context omitted.
Why would that be disabled by default?
In addition to what others have said, hardware decoding comes with other drawbacks. There’s occasionally decoding inaccuracies and there’s no support for most video filters (unless you’re using `auto-copy`)
MPV has versatile scripts. For example you can cut and crop a video you are watching[1]. You can also introduce hotkeys for functionalities I have never seen in another player. I use this (input.conf) sometimes to normalize the brightness and colors of a scene I'm watching (may not work when using hardware decoding): n vf toggle normalize=smoothing=100 Or rotate a video: Ctrl+r no-osd cycle-values video-rotate "90" "…
it also has a robust Lua scripting interface. I made a tool in Golang and Lua that allows Mpv to treat torrent files and magnet links as if they were http links. You can then stream a torrent directly. People also don't realize that mpv not only has the ability to stream youtube videos but you can also search youtube on the CLI using mpv `mpv ytdl://ytsearch:query` it can also play videos directly in the terminal usi…
Also I'm using it to stream from Gerbera and to sync progress seamlessly between phone and PC.
Earlier quoted context omitted.
Wow those answers are indeed funny. I agree that as an OSS dev/maintainer, it's easy to fall on the vice of over-generalization and crusade for the perfect solution, and it feels that's exactly what happened there. > this feature is algorithmically impossible > You're just looking at one specific video, not the general problem. > is not generally possible. As a fellow multimedia dev, man, who cares? Sometimes we forg…
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…
No, it hasn't. The only reason I use mpv instead of VLC is because of the frame step feature. Everyone else has proven that it is possible and practical to do.
Never let the perfect be the enemy of the good. If people don't use your product, it doesn't matter how right and pure of vision you are.
Mac users can get a very nice front end to mpv with https://iina.io Bonus trivia: Plex Media Player uses mpv as the video player
Earlier quoted context omitted.
Wow those answers are indeed funny. I agree that as an OSS dev/maintainer, it's easy to fall on the vice of over-generalization and crusade for the perfect solution, and it feels that's exactly what happened there. > this feature is algorithmically impossible > You're just looking at one specific video, not the general problem. > is not generally possible. As a fellow multimedia dev, man, who cares? Sometimes we forg…
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's poor performance in seeking backwards in general, not just by frame, is a big part of why it's no longer my media player of choice. Which is fine! As an OSS project there's no real reason to care about the number of users as long as enough people are involved to sustain the project, and making the developer experience pleasant is more important than making the user experience pleasant on that front. It just means it's not as good a tool for some users as others, like mpv.
I love mpv. But when I pause and resume the video, the first few seconds are jittery. I've not encountered that on other players. Does anyone know why this is?
In my input.conf file I've created filter keyboard shortcuts: F1 af toggle "acompressor=ratio=4,loudnorm" F2 vf toggle "bwdif" First one is an alright dynamic range compressor (makes the loud parts quieter and quieter parts loud). Second is a deinterlace at default settings. These are standard ffmpeg filters and mpv let's you turn these on in real time.
F1 af toggle "loudnorm=I=-14:LRA=1:tp=-1:linear=false:dual_mono=true"
Since loudnorm adjusts volumes and sets limits for you, you can forego mpv's audio downmixing if your target is stereo and simply put all your channels together before bringing them to loudnorm:
F1 af toggle "pan=stereo|c0=FC+LFE+FL+BL+SL|c1=FC+LFE+FR+BR+SR,loudnorm=I=-14:LRA=1:tp=-1:linear=false:dual_mono=true"Earlier quoted context omitted.
The dev said they are happy to accept patch for this feature. Remember that you're not entitled to demand new features, as a (non-paying) user, you can't allocate dev's time to work on what you want.
This card is played too often by developers who only want to work on features they personally find interesting or worthwhile. Yes, you realistically cannot implement everything every user wants, but at the same time your software is meant to solve problems. Keeping direct communication with your users, and understanding what they find useful or not, should be the driving force of the design and features of your app.…
Earlier quoted context omitted.
you'd have to "rebase" all the other frames to be derived from those
You wouldn't have to any more than you need 0 through N frames in memory to calculate frame N+1. Whatever your decoding state completes at frame N can be considered a key frame.
I wonder if caching semi-compressed frames would be more efficient in either case (CPU or GPU)