/mpv/ - libplacebo or not libplacebo

...

Other urls found in this thread:

github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe#commitcomment-25567012
github.com/mpv-player/ffmpeg-mpv
github.com/mpv-player/mpv/commit/257a2b9646e845ef801588e871b9859d30ebf99a
github.com/rust-lang
github.com/shinchiro/mpv-winbuild-cmake/commit/3994ee3
twitter.com/NSFWRedditVideo

1) What percentage of libplacebo is finished?
2) Will mpv adopt it for rendering?

Could rossy add d3d11 support for libplacebo or is it too soon to do that kind of transformation?

MPlayer masterrace

MaxPainPlayer?

MPP?

Will wm4 come back?

>github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe#commitcomment-25567012
Haasn can't bear C anymore and we all understand him.

You are free to name your fork like you want, dude.

Probably not but that's great.

He's going to rewrite mpv.

Whats new with mpv drama?

My bet is on traps drama since this is a FOSS program.

i use vlc ty

ffmpeg broke things again and wm4 quit irc saying he'll find another hobby and job

>ffmpeg broke things again
What was it this time? And I thought the point of his fork thing was to quickly fix upstream breakages.

lmao

wm4 is the greatest developer ever

is there any build like Bomi but updated?

is there going to be another ""stable"" release or no

Merriweather Post Pavilion?

soon™, it's up to lachs0r.

He needs a vacation

my condolences

Checking for Libav/FFmpeg library versions : ffmpeg-mpv not found
Unable to find development files for some of the required FFmpeg/Libav libraries. You need git master. For FFmpeg, the mpv fork, that might contain additional fixes and features is required. It is available on github.com/mpv-player/ffmpeg-mpv Aborting.

trying to compile on Windows, wat do?

def not placebo.

gnome frontend or kodi makes it the the most stable and minimal program for me.

its like the i3 of wms or the ranger of file managers.

i watch local content via physical dvds and rips and wan based video streams

ffmpeg broke mpv multiple times and infuriated wm4, you have to build his fork and link mpv against it. Use shinchiro's build script with your linux on windows environment of choice.

bump

How can I include liblacebo during the MSYS build?

You don't because mpv does not use it yet.

how do you link mpv against ffmpeg-mpv on Windows

bump

best gui?

bump

How can you bump a thread that's on the front page?

how many is there?

>tfw brainlet
Added a shader to the folder but it doesnt seem to be running at all. Tested 2 or 3 different shaders yet nothing happens. How do you use shaders with mpv? Trying to get this to work on >windows.

it's not automated.
glsl-shader="~~/folder/one.glsl"
glsl-shader="~~/folder/two.glsl"

Tried that after posting, still nothing. I also tried switching between vo=opengl and gpu too but no dice.

Wait, I'm wrong. For some reason I cant see the changes in the screenshots but running 2 instances of mvp makes it noticeable.

Get stats.lua and put it in your scripts folder and use shift+i then press 2 or 3 and see if the shader is even being used.

They're loading. I'll continue my so far unsuccessful quest to remove the fucking aliasing. Thanks user.

screenshots don't read back the image from the renderer, but take the frame from the demuxer
only window screenshot (ctrl+s) does the former.

bump

Are you fucking retarded? He includes locale.h which is what defines locale_t on every platform *except* Apple. His criticism of OS X is completely justified.

>stats.lua
built into mpv these days

This is actually a very good example of why a framework like DirectShow (as old and "deprecated" as it is) is a good thing: You have a fully defined interface between splitter, decoder, renderer and media player. And the interface will never change. So a media player developer using DirectShow never has to worry about ffmpeg breaking stuff, because the media player developer will just leave it up to DirectShow to pick a suitable external splitter/decoder DirectShow filter installed on the OS.

That said, I don't really understand why ffmpeg has an ever changing API with ever changing structure definitions etc. I find it highly annoying. They should define some sort of higher level API that is designed in such a way that it can be extended without breaking compatability. If they did that, no software using ffmpeg would ever have to worry about ffmpeg breaking stuff again (except for simple bugs being introduced in ffmpeg).

For example, they could create an API where a video frame is simply a CVideoFrame class, with only some methods like "GetDwordProperty(LPSTR propertyName)", GetBoolProperty, GetDataProperty etc. All information of the video frame could be retrieved by the media player by calling these general GetXxxProperty APIs. This would allow the CVideoFrame class to add new properties without changing the API at all.

>he doesn't know about all the hacks directshow players have to do
kek

I didn't claim DirectShow was perfect. Just saying that an OS media framework with a stable binary interface has undeniable benefits.

WHAT THE FUCK HAPPENED TO "OPEN WITH" EXTENSION? YOU CAN ONLY USE IT ON BROWSERS NOW AND CAN'T SPECIFY ARGUMENTS ANYMORE FUCK THIS SHIT

Calm down.

it was literally the only thing that made this piece of shit player usable and it's gone now

>use mpv on Linux
>drag anime series folder onto mpv
>starts playback
>watch few episodes
>get bored
>shift+q to quit and save position
>feel like watching the series again
>drag the anime folder onto mpv again
>it continues from the place you left it on
>SUCCES

>use mpv on Windows
>drag anime series folder onto mpv
>mpv closed
>drag a bunch of anime episodes instead
>it werks
>watch few episodes
>get bored
>shift+q to quit and save position
>want to continue watching
>drag a bunch of episodes again
>it starts from the first episode instead of where you left it
>must switch to the desired episode manually to continue watching
>FAIL

Switching to Linux was worth it =^_^=

github.com/mpv-player/mpv/commit/257a2b9646e845ef801588e871b9859d30ebf99a
werks on Windows since this commit

Hello haasn:
github.com/rust-lang

Hello wm4:
github.com/rust-lang

Hello Sup Forums:
github.com/rust-lang

>it's a rust brainlet episode

Hello Mozilla

Rust > C > C++ > Go > *

Where were you when shinchiro absolutely BTFO wm4 and his faggot mpv/FFmpeg-mpv bullshit?

At home.

You can use basic photoshop features!
Great! You are going to be fucking rich, dude.

No photoshop needed: github.com/shinchiro/mpv-winbuild-cmake/commit/3994ee3

You can still use it with mpv

and people think it's a meme when we say mpv is designed for linux, with windows being a bolted-on afterthought

He enabled a configure option wm4 himself wrote for those that want to use ffmpeg upstream. I don't see how that btfo anyone.

Good to know it works, tho. Distros can probably relax now, knowing they don't need bloat their mpv packages by statically linking to wm4's fork.

>I don't see how that btfo anyone.
Because shinchiro is giving the middle fnger to FFmpeg-mpv for being outdated buggy shit! More people use shinchiro build than anyone else, even Linux users do not outnumber it.

>knowing they don't need bloat their mpv packages by statically linking to wm4's fork.

ffmpeg-mpv can be installed to the system alongside regular ffmpeg and only a couple of exports to env are needed to pick it up when building. See the mpv-git and ffmpeg-mpv packages on AUR.

>plex (based on mpv) is paid
>madvr 1.0 will be paid
>libplacebo is 2% finished
>vlc is the only one interested by libplacebo
>mpdn will never drop directshow and is deprecated
is it the end of media players?

Nowadays it is a meme. Even if wm4, and most of the devs desu, hate Windows, they know very well that the majority of their userbase is on windows and therefore making it work on windows is important.

mpv you dumb retard.

...

...

My favourite thing about the Rust community is how most of them are nodejs retards. That's why cargo is full of fucking 1 function microdependencies, because obviously you want as much of your project as possible to consist of wrapping reinvented APIs to make them work with each other and have as much code as possible be controlled by as many people as possible.

That's a shit argument, nobody is forcing you to depend on these tiny libraries.

For a second I thought I was in /dpt/.

it shows a cancer in the larger Rust community, and learning/writing Rust inevitably means you'll interact with those idiots. Those idiots also influence language design decisions, e.g. you'll notice that old pre-release versions of Rust had a much nicer syntax than current Rust, and the whole "oh everything is compiled statically because we love rebuilding every piece of software for any stdlib change at all" approach is quite clearly docker/Go "devops" cancer thinking.

Ah, kind of like Unix.

FSRCNN(X) looks pretty shit with low quality aliased anime. RAVU wins there hands down. FSRCNN(X) looks the best with high quality content (same as NGU Sharp, hehehe). 1080p Blu-ray to 4K looks amazing.

>ffmpeg-mpv can be installed to the system alongside regular ffmpeg and only a couple of exports to env are needed to pick it up when building. See the mpv-git and ffmpeg-mpv packages on AUR.
You can do that with ffmpeg 3.4, but that will not be possible with ffmpeg 3.5 once it comes out, as the soname version bump will be in effect.

But in any case, much like with Firefox and Chromium, distros will make sure it works with upstream and avoid having to pointlessly ship duplicate binaries.

yeah it fucking erased all my old arguments too what a fag dev

>the whole "oh everything is compiled statically because we love rebuilding every piece of software for any stdlib change at all" approach is quite clearly docker/Go "devops" cancer thinking
That's pretty fucking funny in light of the ffmpeg-mpv debacle.

ffmpeg still has an API and an ABI, even if they sometimes break it (like during ABI/API break phase like right now)

Rust has every dependency statically compiled in, so if there's a security bug found in the standard library that can be fixed even without breaking the ABI, each and every Rust binary needs to be recompiled or it'll stay vulnerable. Similarly, any security patches for widely used dependencies also mean all dependant applications need to be rebuilt.

With e.g. ffmpeg, shared libraries can be patched and all dependant applications can use them without being recompiled themselves.

>You can do that with ffmpeg 3.4, but that will not be possible with ffmpeg 3.5 once it comes out
the ffmpeg-mpv AUR package installs the ffmpeg-mpv libraries and headers into a separate directory, so the environment variable adjustment will still work even if ffmpeg bumps the soname. ffmpeg bumping the soname will only clash if you throw both ffmpeg and ffmpeg-mpv directly into /usr/lib/

>bjin and haasn will inevitable get full time jobs
Who will deliver the placebo?

And if every project ends up vendoring the library (which seems to be the case with ffmpeg) you have to update every one of them, which is not that different from recompiling the application.

Please don't talk about such things

It is somewhat different. mpv still doesn't link statically to ffmpeg-mpv, so you'd only have to recompile/patch one component of the vendored mess, i.e. ffmpeg-mpv.
Vendoring should be a last resort to deal with API and distribution problems, not the default behaviour.

Checking my mpv build, I can see that it links against 131 shared libraries in my /usr/lib. Now imagine if all of those were instead statically compiled in, and mpv would have to manually be rebuilt whenever any one of those updated. That's what you get with Rust.

What did the pre-release rust syntax look like? Got a comparison somewhere?

FWIW this is actually not a problem at all if you use a sane package manager like portage; which is designed with the ability to implicitly rebuild all reverse dependencies when you update something

e.g. haskell needs this even when linking dynamically, and C needs this as well if the ABI changes.

I think the problem is overblown when it comes to binary distros.

Someone spoonfeed me the best config and where to put it.

No

profile=gpu-hq
or
profile=opengl-hq

and you put it in the ~/.config/mpv/mpv.conf file
or the %Appdata%/mpv/mpv.conf file

I don't know of a good comparison article, but one example that comes to mind is that the template syntax for example changed to the awful C++-esque clusterfuck that Rust has now.

i think of bjin as of forever student

Oh, that's all? Thanks! I'm guessing I should use the opengl since I'm on an old chinkpad

arent we all

I've heard that wm4 has abandoned mpv and wanders the earth now. Is this true?

Sadly, yes.

ok enjoy compiling your web browser from source for hours then

>old version: mpv at very top of right click context menu
>new version: hidden behind sub-menu
This sucks.

Yes, we VLC now.