Mpv – A free, open-source, and cross-platform media player

You speak as if VLC is the pinnacle of video player technology. I know it is an open source darling, but it's been a buggy, overengineered mess since forever, which is why many use alternatives as mpv, IINA when I used macOS, SMplayer, etc.

On fact, with all due respect, I never understood why VLC was so widely praised. It is the only player to stutter for me on Windows, to get lost in its settings page, to have a terrible playlist implementation that's forced upon you, doesn't handle corrupted media as well as others, etc. mpv on the other hand does one thing and does it very well.

I'll skip ranting about VLC for Android TV this time

A playback architecture that can wrangle all of that cruelty into a consistent experience was hard won.

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.

VLC doesn't have perfect compatibility. I think it worked correctly on random video files less frequently than mpv the last time I tried it. And mpv can actually step forward and back frame by frame.

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 experience enough.

If so, how comes you can do the workaround one suggested of entering a time one second ago then going forward a frame at a time?

I know the devs are good and they want the feature to be perfect, but it reminds me that they removed the ability to browse files on the iPhone which is unexplainable, or show that they are a bit in denial of what users need, which is confirmed by this thread.

The choice not to implement it for architectural reasons is entirely up to the devs, is likely justified, and in most cases users acting entitled to support and feature additions from OSS developers who are volunteering their time is something I side against. But the devs also should be able to talk to people who aren't marinated in that same viewpoint, for their own sake if nothing else. The leap from "there exist cases where implementing this feature in a performant manner wouldn't be feasible" to "we shouldn't implement this feature even for the many cases that would support it" isn't going to be obvious to everyone.

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.

VLC is what it is today

VLC is the least common denominator of video players. Its UI is asinine and the two primary reasons for its popularity are its iconic logo and multi-OS compatibility.

I admit you're probably right on the topic of stepping backwards by one frame, but I wouldn't be so quick to shower VLC with broad praise like that.

Yet the bumblebee flies. mpv does, in fact, have a working "go back one frame" button, so VLC protestations that such a thing is infeasible look silly now. Great example of "red pen" versus "blue pen" thinking: we should spend less time decrying things as wrong or impossible and more time looking for approaches that we might have overlooked. Less "no", more "yes, if".

I wonder: Is this why vlc delays for 5 to 10 seconds every time I use the "skip backward" functionality on my iPad, where other players don't have that delay?

Going back one frame is about as hard as going back one second. VLC allows you to click on the bar to go back to a time, which doesn’t work in all video formats (as mentioned by the dev). Going back one frame would not be any harder or more variable across formats than going to a specific time.

Because it's an open-source project, not commercial software.

In your job, you have to special-case some things because the alternative is not delivering what the boss wants. Regardless of the problems this may cause, or how much tech debt it generates - those are (in the end) business decisions, and while you can make a case to the boss that implementing the special case feature is going to cause huge problems, it's the boss's call as to whether it gets implemented.

In an open-source project the maintainer is the boss. If the maintainer thinks that the feature is going to cause problems, they're totally free to say "no, I'm not going to implement that feature". And, ofc, because it's FOSS, the user is totally free to fork it, or submit a PR for the feature, or whatever.

just got here from a Google search. I gotta say the replies from Remi sound defensively toxic. I'm not here to program the app, I'm just here to find a simple feature and/or request it.

I think Remi sounds curt rather than toxic. There's no automatic right for anyone to go to a FOSS project and request a feature and have it implemented. The maintainer is perfectly within their rights to just say "no". It's their project, their code, their time, and they're free to do/not do anything they like with it.

And this is exactly the problem when these devs are in charge of creating systems that actually do matter. They will not support edge cases, problems in a process, etc.

This is a very broad generalization and not a good one either. Particularly in this context. It's obviously not possible to do it for all video formats in a consistent way. I haven't read through all of it yet I could tell all the proposed solutions are hacky ones. Your scenario doesn't apply here. Businesses are different. This is on open source project. Anyone can work on it.

What are you even saying about the choas of the world?! Every dev knows how work is. You are just describing every other software job. Somehow it sounds like you are boasting how matured you are just because you do what your client asks/needs. Even then, many business/software make a concious choice to support or not support something based on some guidance. The guidance could be some core principles or just some product managers whim.

It's highly likely that VLC developers chose not to support the feature for the very reason(s) that's described in the post. It's a concious choice they made. I don't see anything wrong in that. They definitely are not some school kids with some daddy issues to hide behind some code. They clearly have answered all the questions from a technical stand point.

When I was hired for my first real programming job, my future manager spent a lot of time asking me questions about how I deal with ambiguity. This stuck with me as a really important element to consider in people, but that doesn't seem universal, especially in tech circles.

Outside of those contributing to open source projects professionally, the vast majority of contributors will (naturally) be those with greater technical abilities, which unfortunately impacts the general UX of free/OSS overall in my opinion.

You've got some very confused beliefs about what mkv is and why it's used. Mkv is a container, not a codec, which is most often used to store lossy video and audio tracks. It can store lossless tracks too, but that is uncommon in practice. Other popular containers, such as mp4 (e.g. MPEG-4 Part 14), can also store lossless tracks.

The biggest reason anime people prefer mkv to mp4 is because mkv supports the ASS/SSA subtitle format, which is favored by the anime subbing community for its extremely versatile formatting options. For instance, it is common for subbers to cover up signs containing Japanese text with translated subtitle text, tracked to the video, styled and transformed to appear virtually seamless. Less relevant but still important to some people, mkv supports a plethera of old (and very lossy) video codecs, which is sometimes relevant when it comes to repackaging old encodes of hard to find media. Being able to copy in the old video codec without transcoding preserves what little quality there is while allowing you to package it with modern subtitles. Mkv also has superior support for chapters, metadata, etc.

But I get it, you hate anime and think weebs are pervs. I thought you were a man who values tolerance highly, but whatever man. It has little bearing on technical matters. Incidentally, anime people generally favor mpv above VLC, because the ASS/SSA support is a lot better in mpv (mpv uses it for rendering the psuedo-GUI.)

As for the bugs and UX issues in VLC, I assume that your claims are more accurate than your understanding of media containers, but VLC is nevertheless the best video player to recommend to nontechnical users you might find yourself playing tech support for. They won't tinker with it and therefore won't discover most of the issues you're talking about. What they'll get out of it is a media player that plays whatever file they throw at it, without feeling the need to run sketchy "codec packs" they found god knows where on the internet.

"I'll be waiting for your patch. Surely you're not as lazy and incompetent as the existing volunteer developers."- Rémi Denis-Courmont

I see Rémi Denis-Courmont's arrogant attitude and disrespect for users and developers hasn't improved in all these years.

That's out of context quote: https://news.ycombinator.com/item?id=41282178

This might be true in some application areas, but certainly not generally.

Where is that commercial kernel that works over a wide spectrum of architectures and system sizes?

Where is that commercial compiler that works on many architectures?

Where is that commercial packet capture software that people a paying for to get work done?

Where is that commercial emulator that can run your operating system on a very different machine in countless combinations.

The list could go on and on...

What commercial video player do you use which is better than both mpv and VLC?

I've long since come to the understanding that if I want software that are useful, I must go and pay for it. Commercial software exist to make money, and to make money they must be useful.

Even if it were free, wouldn't you want to do something nice (like give them money) for the person(s) who made the useful thing for you?

If you have a long video with only a single key frame at the beginning then

...you can't support the scrub bar efficiently either, so no one encodes video that way.

Typically to go to a frame you find the last IDR frame before it (and in reasonable encodings those are frequent enough) and decode forward until you get to the frame of interest. Doing that every time the user presses the single frame back button really doesn't seem that bad, and neither does holding onto some extra reference images for at least like 1080p frames. (8k video and such starts getting more expensive but maybe even then start doing all some references after the first press of the frame back button in this GOP or some such.)

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 and maintained indefinitely, but what folks are asking for is technically possible.

I don’t see any reason it couldn’t be supported for a set of formats with reasonable encoding/decoding settings, and provide some error message for other formats if a user attempts to step back, e.g. reverse frame stepping unavailable for current video due to format/encoding/decoding settings.

Yeah, this. That's likely more or less what they already do with the scrub bar.

that's still a whole lot of yapping that as an end user I don't care about. i can frame scrub forwards and backwards in multiple other apps. right? very weird response from the vlc team in that original thread.

Wouldn’t creating in-memory key frames for every nth frame resolve substantial computations on a frame-by-frame basis?

all that's correct, but it's besides the point since other players are able to do this.

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...

I think technically he’s correct (I haven’t worked on media decoding code, but I understand how common video encoding formats work).

He’s technically simply wrong (I have worked on media decoding code, hell I’m working on a related project today). His player supports seeking back by 10 seconds or whatnot, but he insists that somehow to implement precise seeking to the previous frame, you need to seek from the very beginning of the video, no two ways about it:

There is not a slight technical difficulty. On a logical level, this feature is algorithmically impossible, except for the extreme: You can decode all frames up to the previous one. But this would be far too slow for anything except really short videos.

It’s obvious bullshit, if you encounter one of those pathological videos (that don’t really exist except in his mind or in some test suites) you just give up after a reasonable amount of time, same as how you give up if you can’t seek back ~10s in a reasonable amount of time.

And players do give up seeking all the time already, not just on these hypothetical one-I-frame-per-hour videos, but real world videos with messed up pts/dts with no reasonable way to go back a short interval.

Or in the less-than-worst case you could cache the created full frame if no native full frame is encountered for X seconds and then in the worst case you don't have to go to the beginning of the video, but to that cached intermediate full frame?

Re-rendering shouldn't be hard, it's just a specialized version of seeking. VLC has seeking.

The claim that you would have to decode all previous frames in the entire video is... completely baffling to see coming from the dev. He's arguing a stupid technicality that a video might not have keyframes. That's not a reason to omit the feature entirely.

Just a ridiculous idea, could a reversed version of the video be kept around so that if you hit frame backwards it's frame forwards operation on the reversed video so you can show that frame, if you continue playback the head goes to the closest second of the forward video

Again: There is no reason to start caching previous frames until AFTER the user has paused and pressed the "back frame" key. Only THEN does it need to rewind to the previous i-frame and re-render and cache frames. And there is no measurable cost to remembering the timestamp of the last i-frame, so you know where to rewind to.

It is interesting that nobody in the thread went to check in the code of mpv, smplayer, etc. to see how it's done there. Surely this would be the best response to his request for technical suggestions?

Maybe because these users just can't code?

He mentions in the thread that he had to delete posts offensive to the developers. Maybe that's why?

Maybe. As those posts have (allegedly) been deleted, it is now impossible to say. It seems probable though. I do find it interesting that he didn't delete the post, spewing actual verbal abuse at the people who dared to propose possible solutions in good faith.

It is interesting that nobody in the thread went to check in the code of mpv, smplayer, etc. to see how it's done there. Surely this would be the best response to his request for technical suggestions

He has flatly ignored and refused to address, that these other players can do this at all. He makes only mention of "video editors". Well, and YouTube -- cherry picking the easiest case to attack (on grounds of single file format).

At the end of the day, what he needs is an algorithm, which can then be applied against the VLC codebase. For example:

* track timestamp of latest keyframe

* track nframes since latest keyframe

* optionally, keep some sort of unique id to positively identify this keyframe

- now, scrub back to last keyframe (if time accounting is sloppy for this format, overscrub by some amount, the run forward to the keyframe. If overscrubbing is significant, this is where you could compare the keyframe against the reference, to ensure you aren't way far back and needing to run forward further)

- okay, you've found your keyframe; advance (nframes - 1)

- profit

If he comes back and says "that's not fully general", that's true --- but the people asking for this don't care if it's fully general; it's suitable for common use cases and that's what they want. Let it work where it will work. Give up where it won't.

If he comes back and says "sure, that could work, but I don't have time, send a patch", well, okay, that's understandable.

What's actually happening is he's coming back and saying that won't work at all, that it won't support the majority of cases, will take too much compute, etc. and that's just flat out not true. You can do it selectively for the common cases. He might not want to, but that's different from can't.

Like, consider a scenario where you're playing back realtime video over a network connection. You won't necessarily be able to seek forward in that scenario -- you might not have enough video buffered, or hell, the connection could be plain interrupted. Imagine if they just didn't implement forward seek because the solution could not be fully generalized...

And who is going to spend time coding such a thing up, knowing that it is likely to be rejected as "not fully general"?

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.

FWIW, I've been on both sides of this discussion, as an OSS maintainer and user, and have experience with demanding users and arrogant and, yes, _lazy_ developers alike. Let's stop the narrative that users don't have the right to request features because they're not paying customers, and that this is driving developers to burn out. Communication is key to producing useful software regardless of its license. OSS development in particular is not just about throwing some code online and forgetting about it.

The dev said they are happy to accept patch

No he didn’t.

The dev said they are happy to accept patch for this feature.

Did they? Because I read a bunch of the thread and “happy” is he last word I’d use to describe the developer’s sentiment. All I see is “let’s see you provide a patch, and I don’t believe you will”.

Everything about it screams that if a patch were provided, they’d do anything in their power to find reasons for refusal.

Even if I cared about VLC, reading those replies guarantees I would never attempt to submit the patch.

I don't think the other people commenting were being at all rude. They asked nicely if a feature would be possible. He replied with a blank "No" and from then on it was pretty much "but other players can do it so it must be possible" and him rudely and incorrectly asserting that it isn't and that anyway if it was why don't they do it if they want it so much.

The correct response would have been something like "it's more difficult to do and in some circumstances it will have very bad performance so we haven't done it yet".

This is classic "It's hard and I can't be bothered so I'll make up some technical reason why it's impossible". Programmers do this all the time and it's kind of annoying.

(And yes I understand video coding and I know why it's more difficult in some cases.)

He really sounds like an asshole :D sorry for this stupid comment, but i had to tell.

As a FOSS maintainer, I have sympathy for him, but as a communicator, I see he really failed to address multiple commenters pointing out that several other FOSS video projects had the feature. (At least in the first page of comments.)

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.

It says it's a project on the Internet that has to deal with spam. Are you reading more into it than that?

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 just "use mpv". mpv is extremely configurable on top of great defaults also. Setting default audio and sub languages in order of your preference (such as enm before eng and en if you prefer honorifics tracks) is a common tweak.

I thought VLC was awesome while growing up, and at the time it probably was compared to Windows Media Player and such. I remember a common bit of praise was that it supported more types of video files. I haven't really run into anything mpv won't play (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), but also I'm guessing we've standardized more on codecs and containers these days which doesn't hurt.

has a trove of a million hidden features

No software person would find this praiseworthy. A million features = two million bugs, and indeed it shows.

VLC is only praised in "normie" places. It is hated in places like anime forums, 4chan, etc.

works everywhere

No, it doesn’t. I had problems with it, which was tackled by basically every other players easily (e.g. seeking or simply playing anything).

VLC makes video choppy on my low-end Debian machine. MPV plays them perfectly.

Compared to mpv. Some would also say compared to mpc-hc.

The last issue that caused them to leave was their desire to move mpv to their own build system, which they believed they could write in a weekend. Other mpv developers thought that was a stupid idea and argued in favor of something more standard, such as meson. That was the last straw for both sides.

Ghost is my soulmate. As a OSS maintainer, I feel that.

You also close issues without even trying to understand what they’re about?

https://github.com/mpv-player/mpv/issues/177#issuecomment-29...

https://github.com/mpv-player/mpv/issues/177#issuecomment-62...

some random dude coming to my repos expecting I implement whatever they ask, or else be called a dick.

If that’s what you took from that discussion, I sincerely recommend you take a break. You may be experiencing burnout. It’s of course your choice to not implement something you don’t want in your project, but let’s not pretend everyone making a request, especially people who have shown research are dicks out to get you.

I tell you this as fellow open-source maintainer. I’ve learned over the years that if people opening issues are a frequent source of frustration, the first step is to investigate how I can make that less of an issue (e.g. using a GitHub template that forces a specific kind of action) and secondly realise that I need some distance and to relax. When you feel like everyone is an asshole, it’s probably just you.

By the way, that maintainer in particularly was known for lashing out at the smallest things and being rude unprovoked. Perhaps consider reading more of the history before calling them your soulmate.

So you’re saying going forward 1 frame in a video is in the scope, but going back 1 frame is out of scope. Weird stance.

I see your point, but frame advance/rewind is very very basic stuff, a feature that has been around since VCRs went on sale to consumers in the 1980s. Doing it on digital videos with intraframe compression obviously requires some memory tradeoffs, but it's inarguably core functionality for a video playback application.

Yeah. I did try playing around with some of the colorspace options you can find googling, but nothing seemed to work.

to be in maintenance mode.

Sad to hear.-

PS. On a tangent, rethorically - baring bugs and security - at one point is (if ever) software "finished"?

"We built this search engine. It works. The infrastructure has team enough to run it. But we have this huge payroll of people."

So "improvements" and "features" (and constant UI and UX changes) ...

... "enshittification" ensues.-

When is "good enough" ... good enough?

What non-maintenance work needs doing? From the outside, it plays basically all the formats. There is always the potential for improving algorithms, but it strikes me as pretty feature complete.

The correct place to handle character sets is when you're reading the file, not to sprinkle it all throughout your program.

I'm skeptical that rust magically deals with, for example, character sets in 30 year old subtitle files, in a way that makes C seem inadequate.

It's not just that C is "inadequate" - C and its standard library provide no assistance in that task. As the mpv author explains in profane detail in the linked commit message, POSIX locales are an active hindrance, not a useful form of "legacy compatibility".

Not "magically", but more reasonably and without forcing your entire program into a different state, breaking any ability for libraries to work with a huge range of functionality consistently. C locale handling is basically impossible to work with robustly, even before you get into how it can't be effectively used at all in a thread safe way.

...here he goes all out and just insults whoever he can think of...

No, he observes that software devs as a group, and as a culture tend to produce worse results than incredibly-distracted and certainly-fatally-intoxicated simians banging on typewriters.

It's a bit of hyperbole, but the overall state of software is absolutely dire.

...the Chinese, listeners of bland music...

In some-to-much of the world, it's pretty well-known that a lot of cheap crap (much of which has historically been made in China) is very shoddily made and fairly quickly finds its way to the landfill. One shouldn't confuse criticism of shoddily-made products for criticism of the citizens of the country of origin of said products.

I'd also expect the referenced (certainly entirely-hypothetical) CD to be something that ends up getting thrown into the dumpster in huge numbers because store inventory managers expect it to be WAY more popular than it actually ends up being. Also, see above about not getting confused about what the target of the insult is. ;)

There was probably more going on in his life than some trouble dealing with locales.

shrug Not everyone chooses to write in sterile $DAYJOB-approved language when explaining in detail the root of their frustration with the absolutely bullshit garbage pile they have to build upon for their non-corporate side project.

Try watching UHD HDR on intel iGPU without accel, or AV1. MPV also supports vulkan decoders.

Just do a quick automatic benchmark surely?

Hahaha yeah, that's why I don't like it.

Vulkan in theory should be more flexible, but in practice VAAPI still has some advantages when it comes to power efficiency due to Vulkan path lacking some needed features (I think something to do with color space conversions which in Vulkan now have to happen using regular GPU compute units which is inefficient). In the longer term, Vulkan should be preferable in all scenarios.

See also some details here: https://github.com/mpv-player/mpv/discussions/13909

mplayer

There is a fork that's still under development [1], or you can use mpc-be [2].

[1] https://github.com/clsid2/mpc-hc/ [2] https://github.com/Aleksoid1978/MPC-BE

VLC doesn't play everything though. mpv plays stuff that VLC can't play. I never have to worry about codecs or installing anything.

Frames shouldn't be skipped but if the monitor is at 60Hz and the video is at 24 then many frames will have to come early or late. That's what causes the stutter that is most apparent on slow planning scenes. It's like the reel in the projector is being fed through in a jerky manner so each from lines up with one of the monitor frames rather than going through at constant speed like it's supposed to. There's no way around this. However with 120Hz monitors you just display one frame every 5 frames and no jerky motion is required (except the fact that US releases are at 23.976fps, not 24, so a frame will have to be doubled every now and then I guess, or maybe the soundtrack is just pitched up to 24? Don't know).

The CPU computation time is definitely not a problem, the fact that 60/24 (or sometimes 23.97) is not an integer is

Is it ? I had dozens of monitors and never saw it

I’m not the person you asked, and I don’t have that issue, but this common trend of replying to any criticism with “have you filed a bug report?” rubs me the wrong way.

I have opened detailed issues on IINA which describe a bug, how to reproduce, and the correct behaviour (according to their own docs), and they’ve just sat there unacknowledged for years.

IINA’s issue count is twice as big as mpv’s, despite being a UI covering a single OS. Personally I don’t think it’s worth it over vanilla mpv, which I’ve recommended even to non-technical users who like it.

Admittedly I have not, but I did search for and find similar issues on their github before making this comment, and I do plan to investigate this more one day and possibly make a proper issue. There are indeed a lot of "X tool is broken because of Y" statements of varying credibility floating around in the multimedia community where it's unclear if they were actually ever reported upstream or even double-checked recently (people still claim that VLC uses nearest-neighbour chroma scaling, for example, but that's no longer true (except for screenshots, it's still a problem there)), and that is something I'm trying to work against by investigating and reporting this when I can. But since I don't use IINA myself and since, as another commenter pointed out, IINA bug reports don't seem to get a lot of responses on average, it hasn't been the highest priority for me.

mpv tries to be pretty minimalist (and does this well), you could try a frontend (Celluloid, Haruna, etc.). And for the commandline, when you install the mpv package, depending on the distro, the package creates a default shortcut/desktop file, so you can open videos on your WM without hitches, on the menu bar. You can associate the shortcut to mime/file types and set as default player too. You can create yourself a desktop file too if necessary on your profile (eg: $HOME/.local/share/applications/mpv.desktop) with this file/content [1]

[1]: https://github.com/mpv-player/mpv/blob/master/etc/mpv.deskto...

There are graphical frontends like Celluloid.

https://celluloid-player.github.io/

You don't need to use the command line.

If you set it as your default video player it will work as you expect.

If you don't want to set it as your default video player you can probably do something like "Right Click -> Open with..." and choose MPV.

In my experience Plex has a serious problem with determining whether or not it's capable of playing a file back directly without converting. I regularly have to switch it to "convert automatically" to make a file play.

I think it's also partially an issue with video + audio being paired by region.

AFAIK, the video you are being served is always based by the geolocation and what video was licensed for that. E.g. in a French version of a movie, text in the movie may have been localized into french inside the video. Additionaly there might be additional/missing scenes in the localized version to get the desired age ratings in that market.

The audio is then synced to that version of the video. That means that e.g. the French audio produced for the US video is not 1:1 the same audio as the French audio for the German video.

So that takes it beyond a licensing issue, and would mean additional effort to produce compatible audio tracks for content that they may only have streaming rights for temporarily. For content native to the streaming service they usually put that effort in.

Not OP but also wrote a similar thing for mpv.

https://github.com/ftk/mpv-confluence/tree/torrserver

A lot of stuff I watch is 720p, and it's okay with that. But with some types of higher quality files it can be (very) slow.

That said, I have replaced most of my "exact seeks" with "sub-seek"; in input.conf:

  Alt+Right        sub-seek  1   # Go to next/previous sub (within demuxer-readahead-secs)
  Alt+d            sub-seek  1
  Alt+Left         sub-seek -1
  Alt+a            sub-seek -1

  demuxer-readahead-secs=120     # sub-seek only works within this cache
  demuxer-hysteresis-secs=60     # Fill cache only if lower than this; saves battery

I think it's also bound by default, but I'm not sure what that is from the top of my head. You'll definitely need to set that cache as it's only 2 seconds or so by default.

Reverse usually works significantly worse, at least with common video codecs that work on key frames and intraframes. Depending on your work flow, codecs that don't operate on keyframes/intraframes will actually provide mpv the capability of playing backwards at full speed (eg: rawvideo, ffv1, magicyuv...).

I have found this not to be as straightforward as this. In particular:

1. Although `yt-dlp` consistently is able to download videos at link speed (even when the said link is in multi-gig range!), streaming the video through `mpv` will not work as well and some videos would buffer every couple chunks. But that was in the past…

2. With recent changes to how videos are served and "protected", I'm still able to download them with recent versions of `yt-dlp`, but streaming a `yt-dlp` generated playlist will reliably fail to work (this is true for the newpipe android app too.)

3. Even back when streaming youtube worked, closed captions and other such features would not work by default.

I download videos first, nowadays. And then play them with mpv anyway.

These two do seem connected, at least in my case, maybe the video is waiting for the audio codec. Of course your issue could be something entirely different than what I'm typically encountering!

I have like 3 things trying to be audio device on my linux (of which the graphics card is the most unwanted one and sometimes it randomly manages to take over despite me not changing any settings) and the list of audio modules that show up is simply enormous (pulseaudio, pipewire, alsa, ...), some of those make VLC stutter, others don't. It's a mess but at least pipewire works better than puseaudio in my case...