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

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.

Legacy compatibility has value.

You can create/use a different string processing library without jumping to a completely different language.

Which is a shame because he's highly techinally competent.

in other words: they've kicked him out of his own project

I actually thought that last paragraph really undermined his case, because rather than substantiating like he did before, here he goes all out and just insults whoever he can think of; people who take it in the ass, greybeards, the Chinese, listeners of bland music...

I get him though. It's one of those writings from a foul mood. There was probably more going on in his life than some trouble dealing with locales.

It uses yt-dlp as the download backend, so it works with anything that yt-dlp handles.

I wish seeking word work better in this mode though. There is no reason seecon should freeze the player for minutes or indefinitely if the whole video can be downloaded from start to finish in seconds.

Is there a reason why one would prefer vulkan over vaapi, or the other way round?

Because if you don't have to enable a flag or two in a text config file what's the fun of using Linux after all :)

Doesn't work on all systems, I presume. Better to default to something that definitely works everywhere.

https://github.com/mpv-player/mpv/blob/a3baf94ab9f3b43a8027d...

Would be appropriate to have true/false/auto instead of auto==true though, so auto wouldn't use it unless it confirmed to be working.

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`)

If you autodetect hw accel, even the slowest underpowered gpu might get returned, which could result in worstened user experience compared to just using cpu.

It breaks on suspend-to-memory for my system with a nVIDIA GPU. I assume that's a driver problem, though.

I switch from mplayer to mpv some years ago but I don't remember when. I use it daily as my media center player.

They are not default keybinds, but like any configuration can be cycled or set at runtime. Actually I don't use the keybindings much directly since my default config usually is fine, but have a remote GUI to configure it when needed.

Depending on the aspect ratio of the video and playback viewport, you could move the subtitles into the potential black bar underneath.

If there is no black bar, you could get one of those long narrow LCDs off AliExpress, set up the driver, add it as an X display with the right positioning... and then drag the mpv window across that and the TV. Should work. Those little LCDs are just silly expensive though...

For language learning there are some scripts that allow you to hover words and show translations for them. I haven't used them myself with mpv, but I found that kind of tools to be invaluable on a browser when learning a language with a foreign script.

They probably don't want to license them globally, because the expected usage is low. But surely this could be taken into account in the contract / negotiation. Anyway I guess I'm just not in the target audience. But that's what MPV is great for, it allows you to tweak it for that 0.1% use-case.

The explanation I’ve read in the past is that the difference lies in how VLC was initially focused on playback of video streamed over a network (hence the name Video LAN Client), which was generally more rocky a couple decades ago when the quality and bandwidth of the average connection was lower and the only routes between the client and server could be highly indirect or routed through weak nodes.

In that environment, playing at all without constantly dropping out or buffering is the goal, which is more achievable when fudging accuracy/correctness (which wouldn’t have been possible anyway).

Not sure how true that is though, it’s not something I’ve ever verified.

While great in general, vlc has many small seek/sync issues, and also seems to be in maintenance mode.

Then you must have not used "mpv --vo=gpu-next".

Playing HDR and Dolby Vision encoded movies has been solved a long time ago in mpv, but they usually need the option shown above, which may not be the default on your system.

There are plenty of additional options in mpv that provide a finer control of how HDR colors are handled.

While playing a movie with mpv, press "I", so that mpv will display the information it has about the color space supported by your display and the color space used in the movie, which will allow you to verify if they are correct.

Not something I have experience with so can’t speak to that.

was the material purple-green by chance?

I have YouTube ReVanced, which is better than premium, which is still not as good as mpv.

Other services are strictly premium, paid affairs. Still not as good as mpv.

All it does is entice me to avoid that and go to mpv

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

Increíble. Consider putting this up somewhere folks can find it.-

> it can also play videos directly in the terminal using ascii

Beats Star Wars over telnet :)

There are lua hooks for play/pause/stop which is great for dimming room lights when the video starts.

it's crazy what you can do with its plugin scripts. MPV Android also supports them. I wrote one which turns off keyboard backlight and maxes brightness for HDR.

Also I'm using it to stream from Gerbera and to sync progress seamlessly between phone and PC.

Do you have an example?

It's relatively easy to get 100us level precision in CPU wait and mpv has 42ms (42,000us) to emit each frame (at 24fps). Nevermind that the monitor refresh is likely 60fps or better so each frame lasts for two+ monitor frames anyway. As long as it is consistent with each frame timing it should be very rare that a video frame is skipped or doubled up.

120Hz screens are good enough here that I'd call them a silver bullet.

A lot of monitors these days support a kind of variable refresh rate like Freesync, so this should be possible. I've never actually got it to work with AMD, Linux and mpv, though.

48hz support seems pretty common.

None of the distro keeps package up to date with mpv. Only rolling one are probably updated.

Adding a file does not enqueued them, it just open it and play it right away.

Huh, that explains it, I was wondering why I was having problems with some video that VLC would even playback correctly, I didn't think to try the stock mpv.

Have you filled a bug report about this?

infuse will also do good job, but it's using apple engine instead of ffmpeg, and it's paid for the good stuff https://apps.apple.com/us/app/infuse-video-player/id11362209...

iPhone-recorded Dolby Vision videos uses an additional metadata called "Ambient Viewing Environment", and I don't think any third-party player supports it at the moment.

https://developer.apple.com/documentation/technotes/tn3145-h...

Streaming or player errors? Plex has basically never failed to play any video I've ever given it, but a bad connection can totally ruin streaming. I wish they would implement pause and allow to buffer.

plex uses terribly old build of mpv with questionable config

It's x86; it works better for hardware accelerated video playback via VAAPI due to FOSS Intel drivers; because it's fully integrated out of the box, its total cost is a bit cheaper than an RPi, and as a single unit with no assembly, it's quite a bit faster to deploy.

I'm using these: https://www.amazon.com/MeLE-Fanless-Computer-Ethernet-PCG02/.... Works great with Linux, and has a very customizable BIOS.

> Obviously, this is slower. Sometimes much slower (depending on the file).

Anecdotally, I’d change that “sometimes” to “often”. After years of using `exact` I finally stopped. It always felt that the wait was longer than going to the previous keyframe and rewatching the bit. Now if I could only find the perfect timing to go back, though.

By default, mpv has vertical-scroll bound to volume and horizontal-scroll bound to scrubbing.

> Resample audio to match the video. This mode will also try to adjust audio speed to compensate for other drift. (This means it will play the audio at a different speed every once in a while to reduce the A/V difference.)

I'm not sure what's the benefit of that is though.

It's makes so the frame pacing fits the display refresh rate, making viewing a lot more pleasant and smoother. Eg.: Your Screen is 60hz, but the video is 59.97hz, then there will be a dropped frame. `--video-sync=display-resample` speeds the video up by a tiny percentage to make every display refresh match a new video frame. The correction factor is recalculated every frame and can be viewed by pressing I. This makes way more difference that one would imagine and makes 60hz gameplay look hyper smooth, even though not much changed. Frame pacing really matters. Applies to very closely matching framerates or multiples of (eg. 60hz screen with 29.97hz video), not to bigger differences like 50hz vs 60hz.

Drawback: MPV will be forced to run at screen V-Sync, draining battery faster. If your screen is 60hz, but the video is 29.97hz, MPV will re-draw the screen at 60hz, instead of just 29.97hz, doubling GPU load.

It's makes so the frame pacing fits the display refresh rate, making viewing a lot more pleasant and smoother. Eg.: Your Screen is 60hz, but the video is 59.97hz, then there will be a dropped frame. `--video-sync=display-resample` speeds the video up by a tiny percentage to make every display refresh match a new video frame. The correction factor is recalculated every frame and can be viewed by pressing I. This makes way more difference that one would imagine and makes 60hz gameplay look hyper smooth, even though not much changed. Frame pacing really matters. Applies to very closely matching framerates or multiples of (eg. 60hz screen with 29.97hz video), not to bigger differences like 50hz vs 60hz.

Drawback: MPV will be forced to run at screen V-Sync, draining battery faster. If your screen is 60hz, but the video is 29.97hz, MPV will re-draw the screen at 60hz, instead of just 29.97hz, doubling GPU load.

I'd say there are a few aspects that make VLC an easy, common choice: 1) it has incredibly extensive functionality (even if MPV has more capabilities, with VLC, it's all available through menus/GUI - no need to memorize any commands) 2) handles any files you throw at it EVERY time - out of the box. Throughout the years, VLC has been the only player which didn't choke on ANY file I threw at it. 3) It's multiplatform and works (in my experience) equally well on Windows, Linux, and MacOS - OUT OF THE BOX! Even on Android, where I normally prefer using MX Player Pro (bc it has a slightly nicer UI/UX), it was able to handle video files where the audio was in the DTS format. MX Player Pro required the installation of codecs to make the audio work. 4) It's been around forever, so if you want to look up any info related to it, you're sure to find it more easily than for any other player.

All that said, VLC is not always my video player of choice. On Windows, I typically prefer PotPlayer and MPC-BE. On MacOS - IINA. On Android - MX Player Pro. But I always keep it installed on all those platforms because I know that I can fall back to it reliably at a moment's notice and it will simply work.

Additionally, with regard to MPV, where I think it makes the most sense is for the highly discerning user who wants to tweak the rendering of video in a specific way. I think anime fans really like it a lot (I'd imagine they upscale or improve the image quality in very subjective, specific ways, though I didn't investigate this in detail). The other good use case is when you have somewhat limited hardware and you want the most efficient video player application. That is perfectly valid, I suppose, but I think for most people, whatever hardware they're playing a video file on is likely more than capable of running with a more 'unoptimized' video player app such as VLC.

VLC plays pretty much any media file from pretty much anywhere it can be stored, and it's got a pretty standard interface, so folks find it easy to understand how to operate it. That's it. No real "cult" situation there. Just an app that does it's job well. Same is true of mpv, but some people will prefer it (as I do) because it's lightweight and clean and quick (and all the stuff people also like about VLC).

We love VLC because it plays anything, everytime.

And has done this, for a long time, since times when other players struggled.

Maybe it's not the "Best" - it is still the goodest.

I do use MPC-HC on Windows, but it's no longer under development :'( IIRC it can't do AV1.

youtube-dl is still under development (last commit at the time of writing was 2 weeks ago), but there are forks with more features, such as yt-dlp.[1]

[1] https://github.com/yt-dlp/yt-dlp

yt-dlp[1] has now taken on that mantle. I think mpv nowadays just recognises yt-dlp as the de facto alternative, but if yours doesn't then you can just put this in your mpv.conf:

    script-opts=ytdl_hook-ytdl_path=yt-dlp

[1] https://github.com/yt-dlp/yt-dlp

Ahhh.... sounds like tweaking vim/nvim (which is one of my daily tools).

Sure the possibility to tweak the UI is limitless, but at least there are minimum usable UI, like gvim (Windows, Linux) or macvim (macOS) which are easy to install.

It does have a drag-and-drop window if you start it with `mpv --profile=pseudo-gui` (I think the same as its .desktop file)

> It doesn't really have things such as "File → Open" like VLC has.

Huh, it does for me (in the menu bar) on macOS! I guess that's platform-specific then?

Thanks for your response. Understand. So MPV may not be for me, I don't know how to use a command line app, I remember have to use to fix an Ubuntu issue and the UX was painful to me.

Both sound and video are stuttering for me, would that still be caused by audio issues?

That's funny. SMPlayer was my preferred MPlayer front end before I switched to MPV years ago. And I've never really felt like I needed more GUI for MPV.

> Strong clam, this ...

What's better?

You can also hold those keys to play normally at the speed set with [ and ], so you can actually play the video in reverse and slow motion or whatever. Be aware that it's usually very intensive on cpu time (and maybe gpu decoding if applicable) since it has to usually go back a whole keyframe and compute all frames between while doing that, which may result in less than smooth playback on some videos.

only next frame

mpc-hc is not discontinued.

https://github.com/clsid2/mpc-hc

Plus there is also mpc-be which is actively developed and pretty much the same.

https://github.com/Aleksoid1978/MPC-BE

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 to make even basic promises, like "the first frame's timestamp starts at 0" or "every parcel of data has a timestamp". Seemingly reasonable ideas that a neophyte might propose, like "suppose we store the video's framerate-" must be immediately interrupted with "you FOOL, there IS no framerate, nothing can be certain, this video might not even have frames, it might in fact be an interactive gift basket experience merely PRETENDING to be an mp4-". That's just the nature of the beast.

A playback architecture that can wrangle all of that cruelty into a consistent experience was hard won. Of course they're not eager to throw new features into the mix that will pollute that mental model, and suddenly introduce thousands of codec-vs-player-feature checks that were heretofore ruled out in principle. At a certain point, the architecture is sacred, and it's the only thing making VLC maintainable. If a feature doesn't work for everything, it doesn't work.

I notice a lot of devs try to deny the chaos of the world. It's almost like the code is where they go to hide from things that can't be cleanly and unambiguously expressed.

I don't know how they get away with that though. In the coding work that I do, I'm constantly dealing with rules that have exceptions on top of exceptions. I just need to special-case some things, because the alternative is not delivering what the business needs.

> But excuses about not being possible for absolutely every possible codec in a completely generic way is just denying that the world is just a chaotic and dirty place where things are not ideal nor perfect.

It's also not consistently applied. VLC will happily let you jump around in the videos, so his claim that the only way to do it is to play the video as fast as possible from the start of the video just doesn't jive with what is already there.

>Sometimes we forget that software ought to be useful, not hypothetical ideals of truth.

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.

If I want software that are hypothetical ideals of truth, I go and shitpost at the nearest neckbeard communion. Free-beer software exist to satisfy a man's desire to display his voluminous beard, everything else is tertiary.

Wonder how mpv deals with backwards step in infinite GOP/long GOP situations.

"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. And neither has VLC's spectacularly awful UI. Coincidence, or cause and effect?

https://news.ycombinator.com/item?id=13573499

DonHopkins on Feb 5, 2017 | parent | context | favorite | on: Nullsoft: The death of the last maverick tech comp...

VLC's UI sucks so terribly, it's like they went WAY out of their way to make it sucks on purpose, and stubbornly refuse to acknowledge that there are any problems or ever consider fixing them. One example of many [1]:

Type CMD-E (on Mac, or whatever the equivalent is on Windows) to get the video effects window.

Select "Geometry". Now check "Magnification/Zoom".

Notice how you get a picture-in-picture in the upper left corner, with a white rectangle showing the zoomed area, that you can move around by clicking. But if you press and hold, it also drags the entire windows (on a Mac -- I haven't tried on Windows -- VLC's UI and behavior on Mac and Windows diverges widely so I won't try to predict what happens).

Now look underneath the picture-in-picture and notices some ugly upper case pixelated text that says "VLC ZOOM HIDE". See how it's jaggy and rendered at the resolution of the movie you're playing itself, not at screen in a full resolution overlay with readable text?

Now look at the triangle with a jaggy curved hypotenuse below the jaggy words. That is the zoom "slider" (which also drags the window when you drag the mouse, so it's more like a clicker than a slider). See how it gets narrower and narrower in a succession of jaggy stair-step chunks, until it's merely one jaggy pixel wide? Well guess what: the TARGET AREA also gets narrow to match the width of the slider, so it's almost impossible to click on the bottom of the slider, to select the larger zoom sizes! Since the zoom slider is not very tall and its pixels fat and jaggy, you don't have fine grained access to very many zoom sizes at all, either. The zoom pixel steps are much bigger than screen pixels, depending on the video resolution!

What possible purpose could that serve? Why would any user guess that the lower narrow part of the slider represents a wider zoom showing a bigger rectangle over the picture-in-picture, while the top wider part of the slider represents a tighter zoom showing a smaller rectangle over the picture-in-picture? And what slider have you ever used that gets narrower from top to bottom, with a jaggy curve, and an impossibly narrow hard to click target area at the bottom?

This single facet of VLC's terrible UI deserves to be front and center in the User Interface Hall of Shame [2] -- it's even worse than Apple's infamous schizophrenically skeuomorphic QuickTime 4.0 player [3], from 1999! The latest version of VLC in 2017 is still much worse than the shameful QuickTime player was 18 years ago!

Who could have possibly gone so far out of their way to design and implement such a terrible user interface on purpose, then smugly brushed off and ignored 16 years of bug reports and cries for help on the VLC message boards, without harboring a malicious contempt for their users?

That's not even the worst of it. Now check "Transform" and pick one of the transforms like "Rotate by 90 degrees". Guess what? The magnification interface itself is rotated 90 degrees, because it's drawn on the video before it's rotated, so now it appears at the top right of the screen, rotated 90 degrees itself.

And guess what else? The mouse clicks are not even transformed properly, so clicking on the magnification interfaces does NOTHING, rendering it completely useless! Depending on the aspect ratio of the video, you can't even click in the upper left corner where it USED to be and SHOULD still be to operate it, because it is clipped off the right edge of the window.

Are those ugly cosmetic and impossible usability problems not bad enough for you? Then make a playlist with one item. Select "Repeat" mode. Play the movie. Now go to the finder and remove, rename or move the movie you're playing, or just unplug the USB stick containing the video. Not an uncommon occurrence, right? Now VLC will hang up, consuming 100% of the CPU time, often times seizing up the entire Mac, turning on the fan, locking out all user input, and forcing you to reboot! This happens to me all the time.

These bugs have been around for years. The more you fiddle around with it, testing out the edge cases and trying to combine various poorly designed and implemented features, the more bugs you find.

File a bug report, they say. People report these problems again and again. The developers just ignore them and brush them off. I've tried reporting these and other bugs, describing them in meticulous detail, which is frustrating because once I start writing step-by-step instructions to reproduce one problem, I keep finding more and more problems, each worse than the last, and then they just brush me off and ignore my bug reports too.

VLC's user interface is maliciously terrible in so many ways, the developers are careless and arrogant towards their users, and there's no hope of the developers ever changing their ways, acknowledging the problems, and improving it. Instead of improving usability for everyone, they're more interested in adding yet another obscure anime decoder feature so they can watch their AMV cartoon porn [4] [5].

[1] http://imgur.com/gallery/g0acV

[2] http://hallofshame.gp.co.at/index.php

[3] http://hallofshame.gp.co.at/qtime.htm

[4] https://www.videolan.org/vlc/releases/2.1.5.html

FOR ANIME FANS

New 6.1 downmixer to 5.1 and Stereo from MKV/Flac 6.1. Correct YUV->RGB color matrix in the OpenGL shaders. Improved MKV support for seeking, and resiliancy. Editions support in MKV. Better subtitles and metadata support from MKV. Various ASS subtitles improvements.

[5] https://myanimelist.net/forum/?topicid=208770

Now, if you are an AMV (Anime Music Video) creator and want to edit the video directly, the MKV is your best friend since it's a lossless video-content container due to the fact that you will find yourself adding effects to the video frames/audio. In this case you will want to lose as little as possible in your video, so MKV compression best suits.

TOPIC ANSWER: The reason why MKV is popular for anime is because of it's noted lossless compression. Anime show creators most likely notice this fact and use it to contain their video frames and audio tracks for maximum quality. - it has nothing to do with HD.

derefr on Feb 5, 2017 [–]

> Instead of improving usability for everyone, they're more interested in adding yet another obscure anime decoder feature so they can watch their AMV cartoon porn Mind you, FOSS is contributed to by people scratching their own itch. It's not so much that VLC has a lot of otaku developers; it's that a lot of people who watch (or subtitle) "AMV cartoon porn" see a problem with, or missing feature in, VLC, and think "I'm a programmer; I can fix that", and dash off one-off patches.

DonHopkins on Feb 6, 2017 | parent | next [–]

It just puzzles me that out of eight bullet points summarizing the new features in VLC 2.1.5, one of them was "FOR ANIME FANS" and none of them were "FOR USABILITY". It's the contempt and dismissal that the developers show to usability bug reports when they brush them off and ignore them, which bewilders and frustrates me. Go read some of the discussion group postings and bug reports over the many years, and you will see what I mean. It's a deeply entrenched pattern of behavior.

majkinetor on Feb 6, 2017 | parent | prev [–]

Its very hard to contribute patch to foss tool in general. There is no substitution for agile development team.

DonHopkins on Feb 6, 2017 | root | parent [–]

Oh I certainly wanted to contribute to the VLC project and integrate it into my own projects, but after having my concerns that I wrote up in great detail flippantly dismissed with such contempt, and seeing how the exact same thing happened to other users reporting legitimate longstanding bugs who were brushed off and ignored over so many years, I had no interest in contributing after that. It's fortunate that not every open source project suffers from such arrogant developers as VLC.

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.

I guess I don't want my video player to let audio exceed safe volumes...

> VLC is pretty bad and it shows the more you use it.

Compared to what? Such a statement is meaningless without comparison.

In his defense, some commenters had a pretty rude attitude. You cannot demand developers to implement a feature or call them out on being lazy.

Nobody even offered to research how other players accomplish this. They just expect that because they believe it can be done someome should do the work for them.

At least Remi was actually andering questions on the forums.

This attitude towards open source maintainers is what's getting them all burned out.

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.

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.

"not possible" is as much nonsense as "everything is possible". Is it possible for vlc to implement support for rendering and editing common 3d object models? Yes! But is it possible given what vlc was set out to do? No!

I think another sign of a projects long term decline is developers that are all too happy to expand the scope of the project. If that happens I just know that down the line the feature I started using the software because of is down prioritized due to the "need of supporting markdown in the email editor" when the software started as a MSN chat archiver.

It's a former developer that's no longer affiliated with the project since 2021 or thereabouts. They did not part on good terms because he behaved in the same way towards other mpv developers, "my way or the highway".

So you probably shouldn't let anything that old sour your opinion on the current mpv.

(I don't belong to either side, just have been using the player since its inception.)

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

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

Particularly: you don’t have to use mpv if it doesn’t do what you want it to do, and don’t bust my ** because of it.

Far from me to defend the whole mpv team[1], but the dev in that thread is a ghost (deleted user). I remember them, they were always rude and eventually got kicked out of the project and loudly complained about “being removed from the project [they] created”. I never found the exact reason why, though I can’t help but think the attitude had something to do with it.

[1] Some are quite nice and competent. Others are exceedingly rude and will e.g. jump on an issue that had thus far been entirely cordial just to, without provocation, insult users for using whatever OS they don’t like.

This isn't remotely similar. Nowhere is the MPV developer ( wm4) being unreasonable in that thread. And while wm4 was not exactly known for interpersonal skills, he was rarely wrong unlike Remi in this case in claiming things to be impossbile when they are not.

I don't see Remi's behavior in that thread attracting more developers than it pushes away.

Yeah he’s probably playing 5d chess, not just being an ass

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 frame counter to determine when you’ve reached the target frame. In the worst case this does require a lot of compute, but this is an edge case if you primarily care about common video formats with normal encoding settings. I assume seeking backwards is also painfully slow on videos encoded in this manner, so why stepping back 1 frame is out of the question when compared to seeking backwards, I don’t fully understand, it must have something to do with precise frame counts being unavailable on some hardware decoders for some formats (and there being no good workaround) so you _may_ not actually go back 1 frame.

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.

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

In fairness to him, he offers the posters an opportunity to propose a technical solution and responds to all the posts that do it. 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?

From what I can see, he's neither an ass nor adamant that it's impossible. He claims it's impossible to universally support the jump within certain technical constraints (which VLC supposedly limits itself to).

The only time I saw him being unpleasant in the thread is when people ignored his explanations and acted very entitled. Correct me if I'm wrong on anything here, but VLC is an independent free software project developed in no small part by volunteers; they have every right to choose their technical direction and compromises, and it seemed the people insulting them were in no position to demand anything from them.

To do this well you need to keep the old frames around...or go back to the previous keyframe and re-render. That might be hard if your design is playback-optimized.