search

mpv-player / mpv

🎥 Command line video player
https://mpv.io
Other
28.62k stars 2.92k forks source link

AMD Fluid Motion support for mpv #6559

Closed SamyahMaddyx closed 5 years ago

SamyahMaddyx commented 5 years ago

Hi guys!

Since ~2016 AMD videocards have ultimate feature -- AMD Fluid Motion. See how it works: https://youtu.be/_pBFG26oXJY

For PotPlayer and Media Player Classic this work as DirectShow filter: https://bluesky23.yukishigure.com/en/BlueskyFRC.html

For Linux and mpv this not work at all. But mpv may be first!

Sooo... Can anyone add this feature to the player? It would be amazing!

(please)

P.S. This is 0% CPU load. All work on GPU.

zc62 commented 5 years ago

AFM officially supports powerDVD only. (BlueskyFRC is not official.) I would suggest you submit a request to AMD first. Let them make an API that mpv can use.

clapbr commented 5 years ago

Hi guys!

Since ~2016 AMD videocards have ultimate feature -- AMD Fluid Motion. See how it works: https://youtu.be/_pBFG26oXJY

For PotPlayer and Media Player Classic this work as DirectShow filter: https://bluesky23.yukishigure.com/en/BlueskyFRC.html

For Linux and mpv this not work at all. But mpv may be first!

Sooo... Can anyone add this feature to the player? It would be amazing!

(please)

P.S. This is 0% CPU load. All work on GPU.

Closest thing we have to this is SVP. You'll need amdgpu-pro opencl runtime OR Rocm for gpu accel. Still uses a bit of CPU though.

edit: I'm referring to Linux, in Windows I'm not sure SVP is paid or free. Anyway, in that case you just need an updated Radeon driver, that includes opencl by default.

v-fox commented 5 years ago

So, it's like mvtools reimplemented in OpenCL ? Or shaders ? Doesn't that mean that it's not AMD-specific or even requires a GPU ? Basically, universal motion-interpolation.

Too bad that @wm4 expressed despise to motion-interpolation when asked about it previously. But I bet that it's only because he was never shown a working mvtools preset that was free of all possible ugly artifacts. In terms of mvtools you would want:

Hrxn commented 5 years ago

Could you put that into a VapourSynth script? 😄

v-fox commented 5 years ago

Could you put that into a VapourSynth script?

@Hrxn I did ! …sort of. It's in the first link. However, actually maxing out quality literally like that will destroy any CPU. I would like to see results of that from someone with 64-core Threadripper, or similar beast, being tested with 23->60 and 60->144 fps 480p, 720p and 1080p. I can use FlowFPS with fairly small blocks on my flimsy FX-6100 on <480p but even that is far from being maxed out. Proper DCT and max overlap detection are not feasible and finding balance between aggression of smoothing (thscd1, wider search, better modes of interpolation) and artifact-prevention (blocks size, overlap, p*, dct, lambda and badsad stuff) is a pain.

The point of what I was trying to say: perfect quality configuration of mvtools may be used as reference for reimplementing those "best" algorithms in a GPU-friendly way. But first one has to find that "best" configuration.

ghost commented 5 years ago

Too bad that @wm4 expressed despise to motion-interpolation when asked about it previously.

I mean, if you want it? There's no robust/performant/portable solution, though.

v-fox commented 5 years ago

I mean, if you want it? There's no robust/performant/portable solution, though.

Couldn't mvtools' approach somehow be reimplemented as some kind of vulkan compute shader or OpenCL pipeline as a new generation replacement for tscale ? Although, OpenCL has the problem of stagnant GPU-centric FOSS implementations (do Mesa and libclc/LLVM even have all necessary parts ?) and Nvidia's aversion to it (still, with support though). But AMD did it somehow for their craptastic closed driver, even if it's just for marketing "bragging". Real video processing pros could whip up something more robust.

Most of mvtools' code is not even strictly interpolation-related but the hardest part is their analyzation before actual interpolation, with higher source frame-rates it eats up more resources than interpolation itself, so it's easier to do 23->60 than 60->75. It seems it's kind of generic for all other types of processing, so, probably, it could be simplified to only necessary parts and things that are of too low quality, made only to be practical on CPU, and low-level CPU optimizations could be ignored. Like, maybe, whole BlockFPS function. And it could even be improved to account for more frames than 1 previous and 1 next, made to work with formats other than yuv4XX. Though it would need hundreds megabytes or few gigs of V/RAM for keeping several raw high-res frames with whole bunch of analytical data about them and OpenGL 4.x & Vulkan-capable chips or beefy ≥10-core CPUs with proper OpenCL stacks (such as pocl, beignet/intel-compute-runtime, unsure if ROCm, that supports AMD GPUs and Intel CPUs, will actually work on mainline kernel & get packaged in distros, replace Mesa's Clover or neither) or software rasterization on AVX with Mesa's swr or via llvmpipe, later of which just recently got GL_ARB_compute_shader but no GL_ARB_gpu_shader5, judging by mesamatrix.net, not sure about on-CPU Vulkan.

Quite amazing that so much time-sensitive complex multi-stage processing on so much data can be done at runtime at all. But on CPU you can choose either quality on ultra low-res or known glitches on high-res. Those slick, clear camera pans though…

ghost commented 5 years ago

Sure, it can probably be done, but nobody has.

Regarding the thing this issue requests, that's more about using what the driver already provides. Maybe it could be done in vf_d3d11vpp, and/or using a MFT filter? Of course windows only. And I'm personally not interested in spending time on some windows specific and driver specific thing. But it sounds a bit like it uses a mechanism that's already needed for deint anyway.

v-fox commented 5 years ago

Sure, it can probably be done, but nobody has.

That would require some hardcore skills… but unlikely much more hardcore than all complex shader stuff, so it's surprising that no one tried yet, with all weird GPU-overloading shaders floating around.

I've heard that firmwares of some TVs has their crappy versions of motion-interpolation running on their ARM SoCs which, when enabled, leads to even worse output latencies than those scalers & panels already have. No way ARM SOC could do any decent version of motion-interpolation in CPU-only.

Regarding the thing this issue requests, that's more about using what the driver already provides. Maybe it could be done in vf_d3d11vpp, and/or using a MFT filter? Of course windows only. And I'm personally not interested in spending time on some windows specific and driver specific thing. But it sounds a bit like it uses a mechanism that's already needed for deint anyway.

Meaning that it's some kind of "blackbox" system-wide filter, installed with Windows version of the driver", that hooks up to its framework (probably, another LLVM fork, like all that Intel and "open" AMD OpenCL stuff too, I'm pretty sure that all their Windows driver profiling stuff uses LLVM libs too, just as all Linux' open drivers) in non-standard way ? AMD probably could have easily decoupled it from internal interfaces, if they wanted too, but done it this way specifically to prevent it from running on Nvidia's GPUs and Intel's massive multi-core CPUs with AVX (like ones used for professional CGI rendering). So much for "promoting open standards". Remember TrueAudio Next, realtime massive audio processing pipeline on GPU via OpenCL ? That too could have universally replaced all heavy on-CPU audio filters in games, players, studios… well, everywhere. What a waste of good ideas.

epigramx commented 4 years ago

"hard to do" isn't the greatest reason to close this request, it may be the main reason one uses mpc-hc on windows.

ghost commented 4 years ago

If you want to use driver fixed function features, using mpc-hc is the better choice anyway (but the best choice for this would be the native windows media player).

giovinazzo-kevin commented 3 years ago

If you want to use driver fixed function features, using mpc-hc is the better choice anyway (but the best choice for this would be the native windows media player).

Talk about opinionated devs recommending a dead project instead of listening to user requests... Well, I guess I have no other option but to fall back to PotPlayer, since I'm a filthy Windows/AMD user. Too bad, I liked mpv for the short time I've tried it.

CounterPillow commented 3 years ago

@G3Kappa I'm sure your shitty ass comment will make everyone scramble to implement a closed source API into mpv that we don't have access to at all, especially the developer who has since deleted his account.

giovinazzo-kevin commented 3 years ago

Hey - no need to scramble over a potential user. As I've mentioned, there are already several players that implement this feature, so i have no need for mpv.

CounterPillow commented 3 years ago

@G3Kappa That you think people actually give a shit about you using or not using mpv is incredibly adorable. Are you gonna ask to speak to the manager next? Gonna cry? Maybe shit and cum?

Akemi commented 3 years ago

great discussion just take a room both of you and don't bother me any more. issue comments closed.