mpv ffmpeg yt-dlp whatever

>>105863162 (OP)
>pedoware
(thast what you get for shilling)

>>105863162 (OP)
>mpv ffmpeg yt-dlp whatever
VLC ffmpeg whatever imagemagick

>>105863176
whatever is made by children? that's impressive.

green is my pepper

when will mpv switch to librempeg as a primary fork, and use ascale by default?

>>105863176
>pedoware
look at the size of those tits. That's not a child faggot

Why do my webms look sharper on mpv than vlc?

>>105863692
They don't. You are just imagining it.

>youtube video #xxxxxxx

will vulkan ever become good with mpv?

>>105863848
expr "$(curl -L 'https://www.youtube.com/watch?v=XXXXXX' 2>/dev/null | htmlq -t title)" : '\(.*\)-'

the dying art of web-scrapping!

>>105864025
What does that do? Gets the video title without yt-dlp and youtube throttling monkey business?

>>105863162 (OP)
What's the max allowed frame rate for webms on 4chud dot org?

>>105864439
>max allowed frame rate for webms
Deprecated FrameRate Number of frames per second. Informational only.

>>105864250
yes. it just gets the title from the web page. you can't throttle that. it's the magic of the scrap.
expr "$(curl -L 'hxxps://www.youtube.com/watch?v=BFMfAatBwB8' 2>/dev/null| htmlq -t title)" : '\(.*\) -'

^^ added space before last '-' so you don't need to manually trim. also, hopefully avoid triggering the auto embedder.

>>105864472
>also, hopefully avoid triggering the auto embedder.
fail

vlc mediaconverter ikatube

>>105863162 (OP)
How do I get a more recent MPV on Debian stable? There's no MPV in backports like there is for yt-dlp

>>105864510
shilled it again award

>>105864510
answer >>105862020

>>105864539
the answer is no

>>105864250
yes. it just gets the title from the web page. you can't throttle that. it's the magic of the scrap.
expr "$(curl -L 'https://www.jewtube.com/watch?v=XXXXXXXX' 2>/dev/null| htmlq -t title)" : '\(.*\) -'
^^ added space before last '-' so you don't need to manually trim.

>>105863162 (OP)
brat

>>105864607
what is midikit

>>105864609
wow, I made a script that stopped the downloads and tries again later if "youtube video #" was returned instead of the title but this just makes it quick and easy
thanks

>>105864644
can't remember it well but i think it's a midi drum kit i made

>>105863162 (OP)
Sup faggots. So I've been using mpv ever since I started using Linux, just because it was the recommendation I got from some anons, and honestly I never had any complains about it, it just works. I actually used this config I found back then (which I just discovered has been archived, but still works)
https://github.com/hl2guide/better-mpv-config
My question is: do I even bother changing it? I use mpv for watching yt videos sometimes, and maybe some anime here and there, but maybe I'm missing out on some super kewl settings or tweaks for a better experience.

>>105864695
i see

>>105864824
why are you asking these questions

>>105864874
curious
do you want me to stop

>>105864905
i feel it's a little too frequent
by the way does your laptop have a 1024x768 screen or it was just for show

>>105864989
>i feel it's a little too frequent
deal with it
>does your laptop have a 1024x768 screen or it was just for show
it was connected to a monitor set to 1024x768@85Hz
https://fuguita.org/?河豚板ガイド
sorry it took so long

>>105865084
are you using openbsd now

>>105865205
i want to use devuan now

>>105865245
why

>>105864510
post link to the mediaconverter

>>105863728
I can literally go to the exact same frame number and it’s clearer on mpv

>>105865305
disappointed with slackware and gentoo

>>105865312
it's a haiku builtin program
https://www.haiku-os.org/
>>105865352
what disappointment

>>105865362
packages and >>105567568
um
https://www.z80.kr/gallery/files/230419_desktop.png
https://www.linuxquestions.org/questions/slackware-14/==update==-kde-1-1-2-for-slackware-15-0-d-4175730997

This thread is a shell of its former self.

>>105865587
whatever

exact same screenshot from same frame of video showing higher quality in mpv vs vlc

why?

>>105865720
>higher quality
That is subjective at best, stranger.

>>105865836
>subjective
literally not

>>105865465
i don't get why tmpfiles is needed at all, it's pretty much useless for me
openrc doesn't depend on tmpfiles by itself
devuan also hates it https://xcancel.com/DevuanOrg/status/1802997574695080067
there isn't a single package in the devuan repo that depends on that
>packages
what's wrong with them

>>105865850
you shouldn't object, because "subjective" is what matters when it comes to human vision.
leave blurfags to their "objective" faggotry.

>>105865850
>motion picture
>look at the pixelated quality of this single frame
hurr durr objectivity is king in the mpv thread

>>105865720
likely better scaler + film grain generation

>>105865245
>>105865352
you need alpine

ikadev, generate chapters doesn't seem work, I use web_hls and 360.

>>105867347
>I use web_hls and 360
I mean 360p

>>105863162 (OP)
If your media player was any good, you wouldn't need a thread every single day to talk about configuring it.

>>105863223
ganoo

well let me put it another way, will gpu-api=vulkan ever actually work without crashing
on a intel igpu

>>105867688
Report crashes to mesa, they are fast to fix.

>>105867347
it's working for me
post the video link
chapters are extracted from video description and some videos might have weird format for that

>>105868094
https://www.youtube.com/watch?v=sfNiFG611u8
yes, just checking some videos with long duration on from same channel, they all have chapters, only that one that doesn't. fyi chapters are shown with ytdl.

>>105868300
that video has timestamps at the end of line
only timestamps at the start are parsed right now
chapter extraction is sloppy because there isn't a standard format

>>105868398
if thats such very rare case, I wouldn't mind you to ignore it. I just happened to find it.

>>105868441
i saw that format before but it's uncommon
yt-dlp also accepts timestamps at the end
maybe i will implement it later

>>105868060
where do I find the logs

>>105865981
neat
>what's wrong with them
slackware package management system tools does not track or manage dependencies
doing a complete install this wouldnt matter as requirements are met
for a minimal install it becomes tedious and documentation is sparse
https://www.remembertheusers.com/2022/12/0900-slackware-minimal-install.html
https://wiki.installgentoo.com/wiki/Slackware#B-but_muh_dependency_resolution helps
slackpkg doesnt offer the packages i want so i have to setup slackpkg+ for third party repositories such as alienbob or multilib
sometimes i find mirrors to be dead so i have to look for a blog or forums confirmation post with fix
slackbuilds offers what i am looking for but only build scripts to compile and install software
the tools such as sbopkg sbotools slackrepo and more offers dependency resolution
slackonly provides packages from slackbuilds but repository is outdated
doing a complete install consumes too much space
on limited storage i ran out of space quickly under ext4 + lvm
opt for btrfs zstd filesystem compression but skeptical about file recovery and reliability this includes xfs
ext4 does have metadata checksum but only crc32
cshatag is alternative that uses sha256 works with most filesystems although can be replicated by script
maybe i shouldve used pkgsrc packages
interesting https://bonslack.org
will install again for 15.1 release
find myself compiling often from slackbuilds fixing scripts to install properly was annoying consider https://wikipedia.org/wiki/CRUX for familiarity chose gentoo + zfs instead since reminded of peculiar posters
if https://gitgud.io/cloveros/cloveros was still maintain i wouldve used it instead
my cpu is slow for heavy compilation i thought inclusion of binary packages wouldve reduce compile times but my make.conf said no
i didnt mind at first then it became concern after how many hours to days went by
>>105866979
do you still use alpine or guix
tixati supports i2p now
also https://a.pote.to

Why doesn't loop in ffplay work when I am trying to loop a specific fragment in a large .mkv file, e.g. a movie? It just plays once and stops, when it should loop.
ffplay -loop 0 -ss 00:59:23.767 -t 5 -i file.mkv -vf crop=1920:816:0:132,scale=1280:-1 -an -sn

profile=high-quality
Rate my config.

>>105864439
1000 fps test

>>105869543
i see
for devuan you can do a minimal install with the netinst image and skip the mirror setup so it just installs a very minimal system
the disk space it uses is less than 1gb
then manually install anything you need
alpine is even more minimal in this regard but i had to compile several programs since binaries are glibc only
> chose gentoo + zfs instead since reminded of peculiar posters
who
> also https://a.pote.to
what's this

>>105863162 (OP)
mpv is best. vlc sucks

>>105863162 (OP)
hi frens. back with a pretty big update with my yt-dlp frontend.

dl links:
https://files.catbox.moe/r5me0i.zip
https://bunkr.pk/f/0AZCkSQLzyjiO

>new thumbnail and icon
>reworked download button to prevent rare double click, double download if you clicked fast enough
>added a status bar
>added a bookmark system for channels. creates a config folder in XDG config location (typically ~/.config) called ytdlpfrontend and a sql database file ytdlpf-bookmarks.db
>bookmarks are automatically alphabetically sorted for that fine organization
>added a new context menu (dropdown menu) in channel browser to let users select if they want to pull every single video the channel has for their selected content type, or limit the amount to all, 1000, 500, 250, 100, 50, 10 5, or 1 if they just want to pull the latest and greatest video the channel uploaded.
>went ahead and set embed chapters, embed json information, add metadata, embed thumbnail, sponsorblock, and block sponsors to enabled by default. i figure they are sane enough people will probably also have them enabled. of course, they can be turned off by the user.
>added the ability to list videos in the channel browser tab to show upload dates. but its ridiculously slow due to yt-dlp slow processing.
>added a nifty video list display that displays the amount of videos being listed

i hope this brings joy to frens.

>>105872282
Forgot to show the edit bookmark function

>>105871641
yes
reading https://www.aguslr.com/blog/2019/03/24/lightweight-debian.html suggests debootstrap can be further minimal than netinst or mini.iso
will test zfs on linux further to reproduce this bug https://github.com/openzfs/zfs/issues/14118 with zfsbootmenu as it has protections preventing this from occuring https://github.com/zbm-dev/zfsbootmenu/blob/29a1049eada463447d4f3b39bc77b20c4d0afb11/90zfsbootmenu/zfsbootmenu-lib.sh#L1667-L1726
>who
!.pC/AHOKAg !!pkSOt4I5Lqy Anonymous
>what's this
https://pastebin.com/9LUTZaTc
>>do you still use alpine or guix
answer

Why isn't Previous/Next an alias for "Next Chapter" / "Previous Chapter" when playing audio cd's? Is there a reason for this? Is it possible to make it work the way I want but only for cdda?

I don't want to have to PgUp/PgDown

>>105863162 (OP)
pedotroon thread

>>105872463
>>105871641
Why spending so much time to make devuan/debian minimal when you can just use Gentoo? Hardware limitation?

>>105872560
already using gentoo so hardware limitation

>>105872617
No binary packages? Get yourself a chroot, build them yourself and expose them over HTTP or NFS, etc.

>>105869717
WORKSFORME
(linux x86_64, ffmpeg built from git ~10 days ago)

>>105872532
I found this, you might find it interesting: https://github.com/Argon-/mpv-config/blob/master/scripts/betterchapters.lua

>>105872626
read posts

>>105863162 (OP)

>>105872463
>>>do you still use alpine or guix
>answer
im not >>105866979
and for the question i already answered in previous desktop threads
>>105872560
compile time

>>105873241
sorry
i think i already seen the answer

>The camel's back was broken when I updated my Alpine install and the GPU driver stopped working. And one of the previous update already broke pen tablet input.

>Now all of my linux installs have converged to Devuan.

guix must find
>>96980784

>>105873401
>the GPU driver stopped working
kernel or userland?

I searched the manual but I think I'm not looking in the right places.
My monitor is 60 Hz, and most of the stuff I watch are either 24/30 fps.
Is there a way to increase the frames to 60?
Or is it done by default?

>o and P
>Show progression bar, elapsed time and total duration on the OSD.
Is there a way to control what show when these are pressed?
I want it to show the remaining time and the duration of cache

>>105874377
osd-msg3

>>105874499
Yes anon.
Your no answer post solve nothing.
osd-msg3 just show current time / the total time

>>105874515
anon... you set the string
osd-msg3="${duration} sneed ${estimated-frame-number}"

>>105863162 (OP)
what's a good gui for yt-dlp

https://github.com/mpv-player/mpv/pull/13620#issuecomment-3064213452

REVERT REVERT REVERT REVERT REVERT REVERT REVERT REVERT
>REVERT REVERT REVERT REVERT REVERT REVERT REVERT REVERT
REVERT REVERT REVERT REVERT REVERT REVERT REVERT REVERT
>REVERT REVERT REVERT REVERT REVERT REVERT REVERT REVERT

COWBOY COMMIT WITH NO INPUT FROM ANY OTHER DEVELOPERS! MASSIVE RED FLAG!!

>>105875767
it's about time

>>105875767
<llyyr> if this is true shouldnt we switch default vo already?
<llyyr> that issue seems worse than any of the remaining gpu-next issue
<JEEB> yes we should
<Dudemanguy> +1 from me. fringe interpolation issues are less important imo
<guido> +1

>>105866031
What is motion if not a collection of images retard.

If every frame is higher quality then the entire video will be higher quality it’s like you subhumans don’t even understand what video is

>>105865987
One is literally clearer than the other, nothing about that is subjective, clearer=better

>>105875793
There's only one actual maintainer in what you posted, and even she is hedging her opinion...

This needs reverting. Now.

No one gives a flying fuck about HDR. Suddenly merging a bunch of HDR changes and then retroactively claiming that --vo=gpu is broken (it is not) is manufactured obsolescence. You literally created the problem just so you could pretend like --vo=gpu-next solves it.

Here are some things gpu-next will never be good at:

>stable vsync with no skipped frames
>rendering white
>rendering black
>functioning oversample
>functioning interop with every driver API

Oh also... THIS IS A BREAKING CHANGE FOR NVIDIA USERS! YOU KNOW, THE MOST COMMONLY USED GPU MANUFACTURER?? Just because most of the maintainers are AMDpoors doesn't mean that you can suddenly break a multi-system media player.

Just another fucking mistake, just like the Vulkan changes. WE WILL NOT BE BETA TESTERS! WE WILL NOT ACCEPT BREAKING CHANGES! If certain people are going to make commits like this against people's wishes, then you need to provide stable alternatives.

>>105875892
>she
>her

>>105875767
I was mad too but Kasper's reasoning is understandable. How are other fellow gpubros doing? :^)

>>105875767
gpu-next is broken dogshit.
has visual blocking artifacts with opengl. high cpu usage and 1+ second start up time with vulkan.
hwdec=auto causes files to freeze for 2-3 seconds when playing.

>>105875942
>>105875892
>THIS IS A BREAKING CHANGE FOR NVIDIA USERS! YOU KNOW, THE MOST COMMONLY USED GPU MANUFACTURER?
Why the hell would they do this
https://github.com/mpv-player/mpv/issues/16189

>>105875928
>Kasper's reasoning is understandable.
There is nothing understandable about his post. It breaks down to:
>HDR is "bad" on vo_gpu (it's not, HDR tonemaps perfectly fine, and DVp5 rendering could be fixed with a small patch/backport)
>therefore, because of this small minor problem, we have to fuck over all nvidia users, we literally have no other choice!

Like, who the fuck cares that the OSD renders weirdly in HDR? No one cares, this is such a small nothingburger problem in comparison to... you know... alienating a massive portion of users?

>>105876008
hwdec=no

>>105876022
>and DVp5 rendering could be fixed with a small patch/backport
Do it. Whole libplacebo could be backported to vo=gpu.

>>105876035
>boot up japanese cartoons of children without hwdec
>*WHIIIRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRYYYYYYYYYY*

>>105875942
>>105876008
the mpvcord is such a fucking cult, how are they so deluded that they think a majority of their users want gpu-next and bloatplacebo?

minimalist fork when?

>>105876008
Maybe try complain to your multi billion company, instead?

>>105876008
>Why the hell would they do this
>https://github.com/mpv-player/mpv/issues/16189
This is literally vo=gpu issue...

>>105876052
You fucking retard. You probably thought this comeback was extremely clever, but what you don't realize is that (You) the cuck has to work around manufacturer constraints and ensure that mpv is stable, it's not on the manufacturer's onus just because you committed a breaking change knowing all of the limitations.

>>105876035
Isn't it sad that you have this piece of dedicated hardware on your computer specifically made so that video decoding is "free", but because your video renderer is spaghetti code, you're unable to utilize it?

>>105876073
>>105876098
What issues? You are posting issue affecting vo=gpu and crying over gpu-next? This issue says:
> Workaround either use --hwdec=no or --vo=gpu-next (using gpu-next, it would use hwdec=vulkan instead of nvdec)

>>105876040
You don't need to backport an entire project. Small hacks for a very niche and uncommon usecase would work fine, and have been used to great effect throughout mpv's golden years of development.

Please keep in mind that the whole decision for gpu-next being the default literally **HINGES** on DVp5's existence. This is their only argument. Ever heard of a motte-and-bailey?

And no, saying that the OSD is too bright is not a valid reason to introduce breaking changes. It's just a fucking OSD.

>>105876139
>And no, saying that the OSD is too bright is not a valid reason to introduce breaking changes. It's just a fucking OSD.
It's not about OSD, vo_gpu is not usable for any kind of HDR output, not setting any metadata is deal breaker.

>>105876127
Not the person complaining about the issue, but Vulkan is unusable on all NVIDIA driver stacks. Telling people to "just use vulkan" is basically equivalent to telling them to use razors to brush their teeth rather than rusty nails. gpu-next is not optimal for opengl, only gpu is optimal for opengl.

>>105876127
Bro bruh brother
https://github.com/mpv-player/mpv/milestone/4

I am using gpu-next with these and was happy with colour reproduction.
--target-colorspace-hint=no
--hdr-compute-peak=no
--icc-profile-auto
Any edge cases I should be aware of with the big hdr commit to keep the colors same as it was with above config?

>>105876174
>only 38% complete
what the fuck were they thinking??

>>105876159
>vo_gpu is not usable for any kind of HDR output
Who. Fucking. Cares.

1. HDR. Is. A. Meme.

2. vo_gpu. Renders. HDR. Just. Fine.

Just because its not optimal for you, or because you want special tonemapping options, doesn't mean that vo_gpu is unable to handle HDR files. For many people, a basic tonemapping curve works just fine.

>>105872282
>>105872321
Never take the buttpill, here's why:
>be 14
>buy my first dildo, start getting into anal play
>eventually learn to cum without touching my dick
>feels so so so so so so so much than just masturbating the normal way
>keep doing this daily, sometimes more than once daily, for years
>gets to the point where it's pretty much the only way I masturbate anymore, never even really bother touching my dick
>amass a huge collection of toys over time
>ashamed of it but whatever

>be 27
>apartment gets broken into while at work
>nearly everything in my apartment gone, including my chest full of toys
>distraught, but life goes on
>don't jerk off for a while because no toys and also too upset
>wait about a week
>finally get horny again
>try masturbating the normal way for the first time in about a decade
>problem
>can't cum
>can get hard, can get right up to the point where I want to cum but can't actually get over the hill
>spend like 90+ minutes trying and failing to cum
>precum everywhere, dick starting to ache
>give up and go to bed
>try again the next day
>same problem
>give up
>start getting really pent up and frustrated
>third time's the charm?
>...nada
>mfw
I gooned myself into impotence. I don't know how to fix this. I have so much regret.

>>105876190
they weren't.

https://github.com/mpv-player/mpv/issues/16053#issuecomment-3064447973
>(yet still always looks wrong compared to vo=gpu or chrome HDR).
Here we fucking go...

libplacebo cult is about to learn the hard way that vo_gpu has always been the colorists choice of video renderer. As it so happens, forcing people to use an inferior option doesn't suddenly make all of the problems go away...

Take your bets for how long it will take for a revert.

Wow the new gpu-next experience is amazing, it's just like using VLC!

>>105876190
kasper was doing the any% run

>>105876293
is this videolan/haasn's final sabotage of mpv just as wm4 predicted?

the horrible retarded color autists strike again. break the software for 50%+ of your users for people who pixel peep on image comparison websites.

>>105876293
Lol but I think this may be a hwdec problem

>>105876349
I still get that checkerboarding pattern at the bottom of the screen without hwdec.

https://github.com/wm4

will he return to stop this?

>>105876366
He's been silently working on his rust fork for years. One day he'll return and save us.

>>105875913
yes, that's my wife guido

>Overall, when HDR isn't in the equation, gpu+opengl in general has less issues than gpu-next+vulkan.
>Unless there are active efforts to solve the related issues in libplacebo, saying this when there are conversations about renaming gpu-next to gpu and remove the current gpu eventually doesn't give much confidence.
the trvthnvkes that saved mpv...

>>105876847
nanahi based and correct as usual

* no one worth listening to would complain about a changed default.
* gpu-next/libplacebo may have been a problem in the past, but it's not much of a problem with nu-mpv in 2025. and --libplacebo-opts gives you superior run-time customization options out of the box. you can patch libplacebo (like i do) if you "need more".
* scope creep, script bloat, wintardification, ...etc are infinitely more relevant concerning trends.
* possible winshit issues with gpu-next are irrelevant, and windows support should be dropped anyway.

>>105877019
you just exposed yourself as one of the IRC LARPer and stealth nu-mpv dev

all those months of credibility down the drain.

the people that hate wintards are the same that hate libplacebo. you are not one of us, nu-pvfag

>>105877050
i didn't know my mostly single-issue "schizo posts" (made extra clear with a namefag) were seen as "credible".

>>105877019
I thought the DWSN schizo was anti nu-mpv. Suspicious...

>>105877120
you let the mask drop, it's time to hang the towel up and find something new to hide your real positions with.

you're literally doing the "hey guys im anti numpv like you guys but *insert the root cancer of numpvism is actually good!!" meme and you don't realize how obvious you are.

>>105877275
>the jeet seeking "hate-validation" and drama around his irrelevant change is annoyed

libplacebo is absolute, utter garbage.

AviSynth Dither tools > zscale >>>>>>> libcrapcebo

>nanahi on mpv github: sensible arguments defending mpv from retardation
>nanahi on /g/: promotes closed-source botnet spyware, erps as an anime girl
Why is she like this?

>>105873629
either

>Sadly, by prioritizing HDR, this means that mpv becomes a worse player for anime by default.
Rope yourself autogynephilic tranny.

I'm honestly just tired. I'm going back to 0.35.1 or something. That was the last time I remember mpv being "hassle-free".

What is everyone else ITT planning to do? Moving back to VLC? I personally can't go back and would rather just downgrade mpv.

>>105874370
You don't want that. You want to decrease your monitors refresh rate to 30Hz (or some other video mode if it's supported) to match instead.

>>105875767
>Sadly, by prioritizing HDR, this means that mpv becomes a worse player for anime by default.

>>105874770
Ok, this wasn't in the manual.
What variables do I need?
>Command 'osd-msg="${duration}${estimated-frame-number}"' not found
never mind you're just AI posting

>>105878277
I can't, it's a TV.
I don't think this is possible on most cheap monitors.

>>105874370
That's what interpolation and tscale is for, but like the other anon said it's worse than trying to match a clean integer double like 48 or 120Hz.

>>105879293
>That's what interpolation and tscale is for
Thanks, Any recommended settings for these?
>trying to match a clean integer double like 48 or 120Hz
I'm aware of that, inserting non existing frames can produce all sort of artifacts.
But I thought I'd give it a try.
I'm watching 1080p anime on Intel HD 620 iGPU.

>>105879331
Read the manual. Lots of cargo cults regarding this.

>>105879348
I tried.
There's too much technical jargon and I really don't understand half of it.

>>105879433
If you can't read that, I can't help you since you wouldn't be able to read my recommendation. Sorry.

>>105879462
Your no answer post isn't helpful anon.
I'm not asking HOW TO SET INTERPOLATION.
I'm asking what's best settings are.
tscale doesn't offer explanations on how sharp/smooth.
And googling reveal a filter called sphinx which is not in the manual.
People like you is why /g/ is dying.

>>105879471
>I'm not asking HOW TO SET INTERPOLATION.
>I'm asking what's best settings are.
I can read nigger. Stop projecting.

>>105880533
Heyy it's llyyr :D

>>105879471
>People like you is why /g/ is dying.
No, that would be people like me,
check out these stabterpolation artefacts!
WOHOOO!
I made up the word stabterpolation -
it just means stabilization and interpolation.

>>105880751
You give too much credit for your edge

>>105879055
read the manual
https://mpv.io/manual/master/#options-osd-msg3
https://mpv.io/manual/master/#property-list

you put it in mpv.conf. property values go inside a ${}. so osd-msg3="${duration} sneed ${estimated-frame-number}" would display the duration of the video, the word sneed, then the estimated current frame number. i'm sure you can figure it out from here.

>>105880769
I always knew I was innocent

>>105863162 (OP)

seen haruna tan seen haruna tan

https://github.com/mpv-player/mpv/pull/16528#issuecomment-3065381527
what the fuck gpu-next sisters

>>105880803
Anon, I appreciate your guidance.
I have issue with the ""
It caused the problem.
osd-msg3="${time-pos}/${playtime-remaining} Cached:${demuxer-cache-time}"

>>105880960
>can't render video correctly
>can't render subtitles correctly
what CAN gpu-next do correctly?

>>105880960
aria

>>105880960
>gpu-next is broken in ways no one even knew

>>105881114
>>105881145
>rendering "fancy subs" perfectly and without becoming a bottleneck is of the utmost importance
lmao
if i was forking mpv, or rather developing an alternative in rust, "fancy subs" would be near the top of the list of things that are NOT going to be supported.
things like --image-lut are infinitely more relevant, and is actually useful, instead of pushing all the autistic retardation into a fucking subtitle. lol

>>105880960
>>105881145
>>105881363
meant for >>105880960 not >>105881114. sorry

>>105881363
these look like regular ass subs not doing anything fancy

>>105881760
i was taking in general. because only a "fancy sub" fags would care about blend-subtitles=video. but not only that, they would even pixel-peep the output. lol

>>105865245

you are all brown wanna play with ubuntu six

>>105880960
gpu-next sisters we're fucking losing this can't be happening nooooooo

kasper cope
https://github.com/mpv-player/mpv/pull/16534

>>105882369
>Apparently it's critical for mpv to be anime media player
For me it's critical that the player doesn't freeze when I use hwdec, produce artifacting (opengl) or have a slow startup time (vulkan). All of which ONLY happens with gpu-next.

Any recommended mp4 settings to use for making videos for 4chan?

>>105882386
> For me it's critical that the player doesn't freeze when I use hwdec
link to the issue? Is this confirmed? What does vo changes in hwdec?
> produce artifacting (opengl)
only on nvidia x11
> have a slow startup time (vulkan).
happens also with vo=gpu
> All of which ONLY happens with gpu-next.
false

>>105882369
this is the kind of retarded autistic-like (no disrespect intended) logic bloat nu-mpv suffers from.
there is no code endeavor that is guaranteed to fail more than attempting to perfect defaults. those who need vo=gpu can set it in config.
in fact, i would be willing to go as far as forcing every user to explicitly set a vo, rather than adding this logic bloat. if wintards and their likes would be unrecoverably annoyed by that, so be it!

>>105882634
libplacebo IS nu-mpv bloat. you lost the plot

>>105882369
Bruh, why can't libplacebo blend subs into video anyway? It's kind of silly to determine vo this way since there's a lot more things that are different between these two vos. What makes _that_ option in particular so special?

>>105882537

360p and iterate bitrate to meet size

there is a handle for filesize never worked have not tried in years

I use MPC-HC + madVR because I watch real cinema instead of Chinese cartoons.

>>105872282
>>105872321
dl links:
https://bunkr.site/f/XtXwKL2qFWxm2
https://files.catbox.moe/bf9xfg.zip

updated version. added the ability to save video formatting options to bookmarks now.

>>105882369
>kasper93 wants to merge 1 commit into mpv-player:master from kasper93:fix_anime

https://datatracker.ietf.org/doc/rfc6386/ (webm vp8)
>The color space type bit is encoded as follows:
>0 - YUV color space similar to the YCrCb color space defined in [ITU-R_BT.601]
similar? what did they mean by this? and similar to the 525 or 625 line version?

>>105881363
>>105881860
>>105882620
kasper detected

>>105882369
bro it's useless to add this bloat, either fix or document that it doesn't work with gpu-next currently, if anime pepes can configure blend-subtitles they can configure vo

>>105878232
patched 0.29.1

>>105882937
So is kasper pushing breaking changes without consulting other people and then trolling anyone who complains?

>>105863162 (OP)
Why does this goes so hard?

>>105883948
Nothing new. Same old cycle and attitude from nu-devs. Bugsper likes pushing the boundaries and 4chan drama. We're nothing more than beta testers cleaning up their mistakes.

>>105883948
> consulting other people
what other people?

>>105884041

>>105884049
where did you find this picture of me?

>>105884072
Rope.

>>105882720
>360p
Why

>>105883948
>>105884016
The reality is, a majority of maintainers have already lost their interest in mpv. The placeboification and rustification of mpv has pushed away developers and they're tired of committing code to the project. (ironic, because people like to falsely claim that these ATTRACT new developers).

>>105884597
>The reality is, a majority of maintainers have already lost their interest in mpv. The placeboification and rustification of mpv has pushed away developers
Which ones were pushed away? Look at commit history and tell me which developers were pushed away and were active before.

>>105884931
the only one that mattered.

>>105884931
haasn <= lost his drive to contribute to libplacebo and mpv because of wm4's departure
akemi <= lost interest because of wm4's departure
sfan5 <= tired of breaking changes and enbloatification, just wishes mpv was stable again
kevmitch <= lost interest because of libplacebo abstraction and lack of wm4
rossy <= lost interest because of libplacebo abstraction and lack of wm4
avih <= lost interest because mpv is now unfixable spaghetti code, and he doesn't want to deal with it anymore
jeeb <= no wm4 = no mpv
N-R-K <= lost interest because of rustification and enbloatening
mia <= lost interest with no wm4
LaserEyes <= combination of libplacebo, rustification and enbloatening
TheAMM <= lost interest because of wm4's departure
DanOscarsson <= has no interest in committing because of mpv's current divergence from wm4's core philosophy
christoph-heinrich <= libplacebo

dudemanguy will likely leave once more Rust is integrated since she's only interested in pure C. na-na-hi is on the way out as well.

god knows what consequences this will have... I give mpv about 1 year tops before it's officially abandonware.

yt-dlp not working anymore on vimeo?

>>105885515
BROOOOOO HOW IS VIMEO STILL ALIVE LMOA

>>105885515
Also it just got fixed

'sper and llyyrjeet are crying in the irc again

>>105885603
Storytime!

>>105885603
What now?

>>105885054
>haasn <= lost his drive to contribute to libplacebo and mpv because of wm4's departure
I don't know why haasn abandoned us, but I don't think it was wm4's departure
>akemi <= lost interest because of wm4's departure
akemi contributed more than ever last year
>sfan5 <= tired of breaking changes and enbloatification, just wishes mpv was stable again
sfan5 contributions are constant over the years
>kevmitch <= lost interest because of libplacebo abstraction and lack of wm4
last real contribution 2016, way before libplacebo and wm4
>rossy <= lost interest because of libplacebo abstraction and lack of wm4
rossy implemented whole d3d11 in libplacebo
>avih <= lost interest because mpv is now unfixable spaghetti code, and he doesn't want to deal with it anymore
avih got hit hard by wm4's departure, he refuses to contribute to mpv anymore without wm4
>jeeb <= no wm4 = no mpv
same as avih
>N-R-K <= lost interest because of rustification and enbloatening
can't tell too small sample size
>mia <= lost interest with no wm4
can't tell too small sample size
>LaserEyes <= combination of libplacebo, rustification and enbloatening
can't tell too small sample size
>TheAMM <= lost interest because of wm4's departure
can't tell too small sample size
>DanOscarsson <= has no interest in committing because of mpv's current divergence from wm4's core philosophy
can't tell too small sample size
>christoph-heinrich <= libplacebo
quite the opposite
>dudemanguy will likely leave once more Rust is integrated since she's only interested in pure C
rust is not going to be merged
>na-na-hi is on the way out as well
no evidence of that

>>105885764
>rust is not going to be merged
https://github.com/mpv-player/mpv/pull/16051
>Disclaimer: Don't worry it is only a draft. No one will take away your precious C mpv.
>not a draft anymore
it's over
kasper will just cowboy merge it

>>105885854
he also updated the test CI to build with rust

>>105879064
Then I guess you have to deal with Mpv's default behaviour. You definitely don't want that smooth motion video crap that uses interpolation or whatever to force every video to be 60 FPS. If it supports variable refresh rate then I think Mpv can do some magic that effectively forces the TV to down clock its refresh rate on its own.

120000 fps test. ffprobe claims it just 30k fps. and gst-discover failed.

>>105886011
What's bad about interpolation?
Because with anime at least is decent enough

>>105885854
>>105885886
What's the issue with this again?
As long as it's part of the Meson build system and I don't have to care about it and it doesn't break with newer Rust compilers then go for it.
Nobody is re-writing Mpv in Rust but it could make sense so use C bindings / ffi for some use-cases to call into Rust code from C if that makes things more robust or offers better performance or makes the crap less like spaghetti code.
>>105886084
It's taboo.

>>105886091
Rust compiler is mandatory for compilation which supports less platforms than C and has minimum version requirement such as nightly.
Why do I need to install rust when mpv is the only thing that needs it? Everything else compiles with C/C++.
Also requires network connection during compiling for microdependencies.

>>105886133
But which platform are you building Mpv for that has a) good GPU support and b) zero support in LLVM (and therefore Rust)?

>>105886166
Also, you can vendor the crates and install them offline. It's a pain in the ass but Gentoo does this and other Linux distros probably do the same too.

>>105886188
with meson you can do meson subprojects download no need for internet connection after, you can even create tar release like that

>>105886166
OpenBSD has tier 3 Rust support on AMD64. Tier 1 supports very few platforms.
mpv doesn't need a GPU to play videos. It can use software VO and can also play audio only.
>>105886188
>It's a pain in the ass
That's the major point.

>>105886247
>mpv doesn't need a GPU to play videos. It can use software VO and can also play audio only.
But then you don't need subtitles with audio only so they can just make this conditional.

>poles ruining perfectly good software
why are they like this?

>>105886253
lyrics

>>105886258
Does Mpv support that? Honestly, I've never tried that. How does it work, do you have lyrics embedded in the metadata of the file, or are they like subtitles (in which case you probably don't need proper language matching unless there's translated lyrics in multiple languages)

>>105886274
guido uses it a lot

>>105886288
Is he a big fan of K-Pop and J-Pop?
I just learned today that Mpv is an Anime player so this all new to me.

>>105882369
what's blend-subtitles=video good for anyway? can anyone include screenshots and show why it's important?

fix
https://github.com/mpv-player/mpv/issues/13019
https://github.com/mpv-player/mpv/issues/16218

>>105886378
vo=gpu
gpu-api=opengl

>>105882537
h264 is shit compared to VP9, you need speed? use an SVT-VP9 enabled ffmpeg build if your cpu is e-waste tier slow
https://wiki.x266.mov/docs/encoders/SVT-VP9

>I think we can remove vo=gpu-next

>>105886441
>SVT-VP9
Isn't that kill now because they decided to focus on the AV1 encoder?

>>105886525
it still works and it's fast af

>>105886348
it's not wasteful

>>105886619
It doesn't allow moving subs down into black bars tho and that's actually useful. What do you mean by not wasteful?

>>105886378
>1-2 ms on Wayland + AMD
FOSS chads win again

>>105863162 (OP)
I've spent more time ricing mpv than watching anything this weekend

>>105886188
>It's a pain in the ass
it's a single cargo command

>>105886247
OpenBSD has Tier NONE support from upstream GCC and LLVM according to the definition Rust uses.
In fact, no platform whatsoever has Tier 1 support if you use that definition.. lol.
Every non-toy OS will take care of the rust toolchain themselves and make sure they ship working versions, just like they do for other compilers.
Maybe find an issue you actually experienced next time, or complain about matters you have solid knowledge on... lol who am I kidding.

jfc kasper is insufferable.
and all this pushing for unstable defaults, pretending they're ready because they don't want to fix the known issues is just bonkers.

I've used gpu-next since 2022 and vulkan api since 2019. They should not be defaults yet.

Kasper has been clearly suffering from salience bias. He always tries to promote things that aren't quite ready because he focuses on one thing and I believe he has done it to more than just Vulkan and gpu-next, I just don't recall since it has been a while. He should not be in a management role but I don't care since I don't work with him and these mpv issues don't affect me.

gpu-next should have been default since 0.37

>vo=gpu
>profile=fast
>gpu-dumb-mode=yes
>script-opts=osc-layout=box
d-does this bring back wm4?

>>105888580
>gpu-dumb-mode=yes
wm4 hated handing operations to nebulous gpu blackboxes

>>105875892
>Just because most of the maintainers are AMDpoors
pot calling the kettle black, you are clearly too poor to afford an HDR monitor

>>105888769
He spent all of his money buying a Ferrari GPU just to stare at it parked in the drive. Of course he can't afford a HDR monitor.
Meanwhile, practical AMD enjoyers can enjoy their modern comforts and have more money left over to spend on other things because they weren't concerned about who has the biggest epeen

>>105888638
that's nice but the default configuration used to enable gpu-dumb-mode before they changed the scaling and tonemapping defaults. that's why the distinction between bilinear and triangle scalers existed. apparently you'd also need to add gpu-api=opengl on linux, i didn't realize how bad it'd already gotten.

>>105878050
>>105877019


is it possible to have the best of both worlds? ie use some kind of autoprofile to switch to gpu-next+opengl (works fine for me on kde 6/wayland) when a video is detected as hdr, but fall back to gpu when non-hdr?

JULY 24TH IS UPON THOU TROLLS


U GOD DAM TROLLS HAVE PLAYED UR GAME 4 FAR TOO LONG, U HAD UR POINTLESS FUN BUT NOW IS THY TIME 2 DISPATCH EVERY HIGHLY TRAINED POLICE OFFICER 2 RAPE U IN THY ASS

TROLLS WILL GET WHATS COMING TO THEM … WITH NO CHANCE OF ESCAPING . THEY WILL BE HELD IN CUSTODY AND PUT IN JAIL 4 THEIR CRIMES AND ANY ESCAPEES WILL BE SHOT IMMEDIATELY

STILL THINK THIS IS A GOD DAM GAME AFTER THIS WARNING ?


YURITROONS, BASEDTARDS, FOODISTNIGGERS, MADTHAD0890, PRICK-KUN, TROLLS, REV SAYS DESU AND THE WIFE-BEATER JON DEL ARROZ WILL BE SENT 2 JUSTICE AND THEN KICKED INTO THY ORBIT AND FROZEN

LETS FUCKING DO THIS U GUYS
UTUBETROLLPOLICE/UTUBETROLLJUDGMENT 2025

Is there a way to completely disable video scaling so that e.g. a 4K video will appear as native size on my 1440p monitor, even if the window ends up larger than the display area?

>>105889512
--video-unscaled=yes

>>105886348
>blend-subtitles=video for anime with complex ass subtitles
Pros:
> Subtitles match the video's "quality" (e.g., softness from upscaling).
> Applies video filters/effects to subtitles (useful for consistency).
> Reduces some VRAM usage and avoids certain overlay artifacts.

Cons:
> Can make subtitles blurrier or lower-quality overall.
> Transparent effects may show video bleeding through.
> Prevents subtitles from extending outside the video frame (e.g., into black bars).
> Potential performance hit with complex subs or HDR.

>>105889683
Only thing missing is the emojis and this would've been identical to what chatjeetpt spits out.

>>105889683
>Prevents subtitles from extending outside the video frame (e.g., into black bars).
This is never supposed to happen with ASS subs anyway.

i remember hevc exact seek was broken in some ffmpeg version, did they ever fix it?

>>105877019
I just want a media player to play media
I'm not trying to join your gay cult

>>105877019
>--libplacebo-opts gives you superior run-time customization
elaborate

>>105890134
it's not even true to begin with. blend-subtitles=video is not strictly needed for that.

>>105886441
>SVT-VP9 enabled ffmpeg
Tried that same shitty performance with same fake arguments.
What's your ffmpeg command?

>>105886441
>e-waste
>Need xeon minimum

>>105889918
is it wrong though? post the chatjeet version then, this was grok 4

>>105890615
>i remember hevc exact seek was broken in some ffmpeg version, did they ever fix it?
that hevc seek bug was a pain in the ass back in like 4.x or whenever, but they mostly fixed the core decoder shit ages ago. still broken as fuck in ts containers though—seeks to the wrong keyframe and you get artifacted garbage until the next one. check trac ticket #9412, it’s from 2021 and still open, but lol good luck with that patch if you’re not on gentoo ricing your own kernel.

workaround: figure it out yourself you lazy fuck, or just remux that crap to mp4 like a real autist would. don’t be a windows pleb using outdated builds; grab the latest from git or your distro’s repo if you’re on a real os. if it’s something else, post your command and log or gtfo.

>>105891120
I come here to talk with people

>>105890949
-rc vbr -b:v 2.2M -preset 3 -g -2
I get 30 FPS at 720p with that preset and over 150 FPS at 7 on a Ryzen 5600X

>>105890961

>>105863162 (OP)
>whatever
more like AGPropemaxxever

https://github.com/mpv-player/mpv/pull/16271
this is pretty cool, does libass even support ruby characters like shown in the image example?

>>105892506
what?

Why does this thread, alone amongst its general peers in the catalogue, have no guides in the OP?

I am a living fossil who is only just now moving away from MPC-HC+madVR, and there is so much conflicting information on the internet about setting up mpv that I haven't got the slightest idea where to start.

>>105893600
It just works.

>>105893600
>mpc-hc + madVR
why would you downgrade to mpv?

>>105893600
>Why does this thread, alone amongst its general peers in the catalogue, have no guides in the OP?
Because this thread exists in response to /mpv/ which had some of the worst cargo culting in the history of the internet and we eventually bullied the authors of both of the really famous bad blog posts that people were using as guides to disavow them. You shouldn't change anything until you notice you don't like it then ctrl+f the manual, except perhaps hwdec=yes, no idea why that's still not the default. If they consider gpu-next and vulkan ready for prime time then hwdec was years ago even on Linux.

>>105894283
vulkan hwdec has lossy RGB conversion currently, you can't make it default.

>>105893600
>moving away from MPC-HC+madVR
Why would you willingly move away from a superior configuration? Are you stupid?

>>105894373
If they changed the default to auto/auto-safe/yes there's no situation where vulkan would be the default with the current probe order. You'd get d3d11va, videotoolbox, vaapi, or mediacodec. All of which have worked perfectly for over 10 years except maybe mediacodec but that has more to do with OEMs special casing ExoPlayer in their broken drivers.

>>105894685
vulkan was moved up in the probe order ages ago for some reason, currently only d3d11va is above it.

>>105894749
>https://github.com/mpv-player/mpv/blame/master/video/decode/vd_lavc.c#L264
so it was
>kasper
big fuckin surprise, he's doing 10x the damage haasn ever did.

>>105894781
oh well, it fucks over wintards the most since the autoprobe will no longer select d3d11va-copy for safe hwdec kek

>>105894866
It wasn't going to do that anyway since kasper also de-prioritized the -copy variants. Which is fine, only dxva2-copy ever needed to exist and dxva2 is never considered safe.

>>105894866
auto-safe selects d3d11va. did you mean auto-safe-copy? because that won't get you vulkan either since it's not -copy. windows is the only operating system that doesn't get fucked over by this commit. since kasper is known to be a windows user you gotta wonder if he's doing it for a laugh.

you guys really like to complain, tell what are the issues, expect that you don't like X or Y
>>105894373
this is just a lie
>>105894866
>>105894930
what's the issue here? d3d11 is prefered will work on any system. On Linux Vulkan is gated behind environmental variables, unless it works

>>105894986
>On Linux Vulkan is gated behind environmental variables
Maybe if you're using a really outdated system.

>>105894997
mesa only enables it on targets that passes CTS

>>105894930
yes but dxva2-copy was de prioritized in an older commit in favor of d3d11va-copy. if you were using vulkan backend, hwdec=auto-safe would select d3d11va-copy
>>105894979
see above, auto-safe used to probe for d3d11va-copy before vulkan. you can't use d3d11va with vulkan rendering unless you have interop (which mpv does not).

with the current probe order, mpv prioritizes unsafe vulkan decoding on winshitdows which is funny as fuck since kasper is a winshitter

>>105895044
>unsafe vulkan decoding
how it is unsafe?

>>105894986
>this is just a lie
It is trivial to test for. You didn't even do the bare minimum before jumping on my neck and calling me a liar.

Stop at any video frame with --start and --pause. Take screenshots with minimal config:

--no-config --screenshot-format=png --dither-depth=no --sid=no
vs.
--no-config --screenshot-format=png --dither-depth=no --sid=no --hwdec=vulkan

If the video is AV1, disable film grain with --vf=format:film-grain=no

Compare SHA2-256 for both images. You will not generate the same hash. No other video decoding API has this problem.

>>105895171
might be dirty line on 1088 cropping, d3d11va does the same with zero-copy

>>105895212
d3d11va in zero-copy mode produces a very visible green line at the bottom from looking at the issues in the tracker. This does not do that, so the image hash should not be different since the screenshot is not capturing any gpu texture padding. vulkan decoding is clearly producing lossy output on the rendering side, and outside of special vulkan filters, the only think video decoding effects for rendering is RGB conversion.

>>105895044
>with the current probe order, mpv prioritizes unsafe vulkan decoding on winshitdows
No, it doesn't. gpu-api=vulkan is only the default on Linux, Windows still uses d3d11 and so will hwdec with d3d11va.
>>105895212
>>105895339
Only get the border defect with shitty AMD drivers. In their defense it's not a supported operation according to Microsoft but still why not give users nice things.

reminder that 0.29.1 + cherrypicked patches is unfathomably comfy

>>105895566
>No, it doesn't. gpu-api=vulkan is only the default on Linux, Windows still uses d3d11 and so will hwdec with d3d11va.
why are you so retarded and unable to follow the conversation? no one is talking about d3d11 being the above in gpu-context probe order. we're talking about hwdec probe order, two different things... are you being obtuse and bad faith on purpose?

will vulkan+hwdec=auto give you vulkan on a windows system, yes or no? has d3d11va-copy been de-prioritized on windows systems, yes or no? stop being a weasel.

>>105895610
which patches are essential

>>105895669
you have to patch CVEs and nanahi's vo_gpu fixes in.

>>105895659
>will vulkan+hwdec=auto give you vulkan on a windows system, yes or no? has d3d11va-copy been de-prioritized on windows systems, yes or no? stop being a weasel.
and what is the problem with using vulkan hwdec with your vulkan gpu-api?

>>105895689
the people above you already discussed it, including yourself >>105895566

now stop shifting the goalpost and explain why unsafe video decoding is white listed above d3d11va-copy even when it has known issues.

>>105895669
>>105895688
this + whichever few nu-mpv features you find useful and stats.lua

no want rust in mpv

>>105895659
D3D11VA IS AHEAD OF VULKAN IN THE HWDEC PROBE ORDER. KILL YOURSELF.

>>105895718
FAGGOT RETARD, READ THE FUCKING CODE

VULKAN IS LITERALLY ABOVE D3D11VA-COPY. HOW FUCKING HARD IS IT TO FUCKING READ SHIT FOR BRAINS

const struct autoprobe_info hwdec_autoprobe_info[] = {
{"d3d11va", HWDEC_FLAG_AUTO | HWDEC_FLAG_WHITELIST},
{"vulkan", HWDEC_FLAG_AUTO | HWDEC_FLAG_WHITELIST}, # <-------------- YOU ARE HERE
{"dxva2", HWDEC_FLAG_AUTO},
{"nvdec", HWDEC_FLAG_AUTO | HWDEC_FLAG_WHITELIST},
{"vaapi", HWDEC_FLAG_AUTO | HWDEC_FLAG_WHITELIST},
{"vdpau", HWDEC_FLAG_AUTO},
{"drm", HWDEC_FLAG_AUTO | HWDEC_FLAG_WHITELIST},
{"mediacodec", HWDEC_FLAG_AUTO},
{"videotoolbox", HWDEC_FLAG_AUTO | HWDEC_FLAG_WHITELIST},
{"d3d11va-copy", HWDEC_FLAG_AUTO | HWDEC_FLAG_WHITELIST}, <------------- RETARD EYES SHOULD GO HERE
{"vulkan-copy", HWDEC_FLAG_AUTO | HWDEC_FLAG_WHITELIST},
{"dxva2-copy", HWDEC_FLAG_AUTO | HWDEC_FLAG_WHITELIST},
{"nvdec-copy", HWDEC_FLAG_AUTO | HWDEC_FLAG_WHITELIST},
{"vaapi-copy", HWDEC_FLAG_AUTO | HWDEC_FLAG_WHITELIST},
{"vdpau-copy", HWDEC_FLAG_AUTO | HWDEC_FLAG_WHITELIST},
{"drm-copy", HWDEC_FLAG_AUTO | HWDEC_FLAG_WHITELIST},
{"mediacodec-copy", HWDEC_FLAG_AUTO | HWDEC_FLAG_WHITELIST},
{"videotoolbox-copy", HWDEC_FLAG_AUTO | HWDEC_FLAG_WHITELIST},

>>105895757
WHY ARE YOU POINTING TO D3D11VA-COPY? NOBODY IS TALKING ABOUT D3D11VA-COPY. LOOK AT D3D11VA. IT'S RIGHT THERE. ABOVE VULKAN. STOP PRETENDING WE'RE TALKING ABOUT COPY OR GPU APIS.

>>105895779
D3D11VA DOES NOT FUCKING WORK WITH VULKAN RENDERING WITHOUT HWDEC INTEROP YOU FUCKING RETARD

STOP TALKING ABOUT D3D11VA, NO ONE FUCKING CARES YOU FUCKING RETARD

>>105895806
>D3D11VA DOES NOT FUCKING WORK WITH VULKAN RENDERING WITHOUT HWDEC INTEROP YOU FUCKING RETARD
VULKAN HWDEC IS WORKING WITH VULKAN

>>105895806
STOP TALKING ABOUT THE VULKAN GPU-API. IT IS NOT USED ON WINDOWS. WE ARE TALKING ABOUT HWDEC AND HAVE BEEN SINCE THE BEGINNING. FOLLOW THE REPLY CHAIN.

>>105895816
>>105895819
ARE WE GOING TO PRETEND LIKE PEOPLE DON'T USE VULKAN ON WINDOWS NOW?????? IF SOMEONE CHOOSES TO USE VULKAN, THEY SHOULD NOT AUTOPROBE TO A DECODING API THAT RAPES THEIR IMAGE

STOP
MOVING
THE
GOALPOST

THIS IS ABOUT HWDEC AUTOPROBE, NOT GPU-CONTEXT AUTOPROBE, RETARD FAGGOTS

>>105863162 (OP)
dilate, vlc or bust

>>105895819
>FOLLOW THE REPLY CHAIN.
the irony >>105894866 >>105895044
who can't read now?

>>105895833
>ARE WE GOING TO PRETEND LIKE PEOPLE DON'T USE VULKAN ON WINDOWS NOW??????
um, well it's not the default and if they are using it it's their fault. the defaults are safe and correct. hwdec=yes would not cause problems for windows users except in your fantasy land.

>>105895859
no matter how much you samefag the conversation started here >>105894373

>>105895864
>um, well it's not the default and if they are using it it's their fault.
let me break it down for your sissy brain

>vulkan rendering on windows = safe
>d3d11 rendering on windows = safe
>d3d11va-copy on windows = safe
>vulkan decoding on windows = unsafe!

>previous behavior before autoprobe was fucked with when using vulkan context = safe!
>previous behavior before autoprobe was fucked with when using d3d11 context = safe!
>current behavior with d3d11 context = safe!
>current behavior with vulkan context = unsafe!

in the past = 2/2 scenarios worked
now = only 1/2 scenarios work

can finally make neural connections now instead of shadow-boxing about gpu-context? have you stopped having an aneurysm you little sissy?

>>105895901
and whether you like it or not, it hasn't been deboonked yet, not even by open-sores linuxsisters, which shows that vulkan should be removed from the whitelist all-together in favor of nvdec and vaapi.

>>105895914
>>d3d11 rendering on windows = safe
>>vulkan decoding on windows = unsafe!
I told you the reason in >>105895212. Sampling directly from 1088 texture can cause some small differences, because we are not sampling 1:1 pixels. This is nothing critical, as the difference is not perceptible, it is a few pixels being rounded differently. You will get more differences anyway after whole pipeline. Also note there is no difference between gpu-api. `--gpu-api=vulkan --hwdec=vulkan` is exactly the same as `--gpu-api=vulkan --hwdec=d3d11va --d3d11va-zero-copy=yes`. We don't have zero copy option for vulkan, it's always zero copy.

Note it's not a problem on decoding that does not need cropping.

>>105896302
looks like libplacebo issue with initial image read, will need to fix that.

>>105896302
zero-copy hwdec's have always been considered unsafe throughout mpv's history, and d3d11va--zero-copy is disabled by default. why is vulkan listed as safe and placed so high in the probe order if this is the case? there is a glaring contradiction here.

this is just another point in favor of why hwdec=yes can't be the default in the built-in config, as autoprobe promotes unsafe hwdec

>>105896302
>>105896405
Actually this is indeed a rendering issue on libplacebo's end.

If you switch from default lanczos to ewa_lanczossharp, you will get the same image hash. But if you apply antiringing to ewa_lanczossharp, the image hash will be different again. The rounding issue is caused by rendering pipeline.

Vulkan wins again, libspaghetti in shambles.

>>105896412
>zero-copy hwdec's have always been considered unsafe throughout mpv's history, and d3d11va--zero-copy is disabled by default. why is vulkan listed as safe and placed so high in the probe order if this is the case? there is a glaring contradiction here.
the issue was unknown at the time it has been bumped in probe order

>>105896430
>Actually this is indeed a rendering issue on libplacebo's end.
with --cscale=bilinear I get only this diff on the bottom, which is expected, because there is uncropped data texture there. That's GPU processing for you, you will get sampling errors. I don't think libplacebo is bugged here really...

>>105896412
>zero-copy hwdec's have always been considered unsafe throughout mpv's history, and d3d11va--zero-copy is disabled by default.
mostly because documentation states you shouldn't do it. Either way on some iGPUs it is critical as they are to slow to copy 4k frames in reasonable time, so zero copy is a must.

nanasper stans

>>105896676
Rope.

>>105896538
mpv hasn't prioritized development on slow iGPUs in years. if your rig is too slow, you should opt-in to zero-copy decoding just like how you have to opt-in to built-in gpu scaling. if this is not the case anymore, then --hwdec documentation should be updated accordingly to state that even "safe" decoders can be unsafe. currently it only warns about shit drivers and shit manufacturers causing problems on safe decoders, which is not the fault of the API.

>>105896412
zero-copy and non-copy-back are not the same thing. -copy copies all the way back to system RAM to get re-loaded into the GPU as a new texture. You still get a copy with d3d11va, it's just a GPU-to-GPU copy. RTFM.

>>105898424
who are you replying to? we're talking about vulkan video being zero-copy by design. no one brought up *-copy variant decoders. RTFT (read-the-fucking-thread)

>>105892786
>also am in the process of implementing a mini web engine to match browser styling more precisely
Uh oh

>>105898476
'pillow about to have a meltdown

>>105896302
>Note it's not a problem on decoding that does not need cropping.
Wait, so it's not a problem on anything then? Real videos are all 16:9 or 16:8. Again this will only affect bad AMD drivers that decode 1080 video to a 1088 texture.

>>105898640
the issue is rendering related, the kind of result you get is completely dependent on what scaler you use. some scalers are effected by it (like default lanczos), some aren't. this also affects vulkan-copy, so vulkan-copy is not safe either

>>105898687
I'm not getting any artifacts with any combination of d3d11 and vulkan, and d3d11va and nvdec and vulkan on Nvidia. On my AMD iGPU I'm consistently getting the green stripe. It's a driver bug.

>>105898640
>>105898687
did some hash-matching tests on 1080p files with different encodes and scalers. here are the results FWIW:

>H264 8-bit with default chroma scaler
vulkan + vulkan = not safe
vulkan + vulkan-copy = safe
vulkan + d3d11va-copy = safe

>H264 8-bit with "high-quality" chroma scaler
vulkan + vulkan = not safe
vulkan + vulkan-copy = safe
vulkan + d3d11va-copy = safe

>HEVC 10-bit with default chroma scaler
vulkan + vulkan = not safe
vulkan + vulkan-copy = not safe
vulkan + d3d11va-copy = not safe

>HEVC 10-bit with "high-quality" chroma scaler
vulkan + vulkan = safe
vulkan + vulkan-copy = safe
vulkan + d3d11va-copy = safe

>AV1 10-bit with default chroma scaler (film grain disabled)
vulkan + vulkan = not safe
vulkan + vulkan-copy = not safe
vulkan + d3d11va-copy = not safe

>AV1 10-bit with "high-quality" chroma scaler (film grain disabled)
vulkan + vulkan = safe
vulkan + vulkan-copy = safe
vulkan + d3d11va-copy = safe

>>105898727
this doesn't seem to be related, because d3d11+d3d11va always produces the same image hash regardless of chroma scaler choice on my dedicated amd gpu. we're probably talking about different issues. this seems to be about incorrect chroma sampling on certain hwdec/decoder surfaces

>>105898687
>dependent on what scaler you use
I can tell you right away the difference is whether your scaling kernel is an interpolation kernel or not. it's an interpolation kernel if f(-1)=0, f(0)=1, and f(1)=0. Triangle (not bilinear) and "bicubic" and catrom (but no other bcsplines) meet this definition, lanczos and polar filters don't. if you sample an image with these non-interpolation kernels without scaling them, at least some pixels will change color. mpv used to bypass resampling completely if the image wasn't scaled so this wasn't a problem but kasper broke it.

>>105898772
A quick thing about the results and why I think this is rendering related and not a bug on the video decoder side, the fact that image hashes for vulkan-copy and d3d11va-copy don't match software decoding when using lanczos for chroma is kind of suspect. This seems to be something that only effects the vulkan context specifically, because d3d11 context is unaffected by whatever this sampling issue is.

>>105898825
I would agree normally but in these results >>105898772 there are some times when the polar scaler (ewa_lanczossharp) does match the software decoded output (nv12 surface + copy-back decoders, all p010 surfaces) so I'm not sure.

>mpv used to bypass resampling completely if the image wasn't scaled so this wasn't a problem but kasper broke it.
Does libplacebo even do a final no-op bilinear pass if the output is unscaled? I thought this was "broken" when --scaler-resizes-only was deliberated omitted.

>>105898825
>>105898871
Just tried --scale=catmull_rom and --cscale=catmull_rom using the same hash testing here >>105898772, still got the same results as p010+lanczos where none of the combinations matched with software decoding, so that theory isn't it either.

vulkan and hwdec is just fucked, don't use it. there's no other takeaway from this.

>>105898984
>Graphics driver issue
Werks for me

>>105898476
mpvOS

>>105899082
do the hash test and report back, only then I'll believe you

>>105898825
>mpv used to bypass resampling completely if the image wasn't scaled so this wasn't a problem but kasper broke it.
What are you saying? It's caused by cscale. Anyway, link the commit that broke "it" or stop with low quality baits.
>>105898909
>>105898984
>>105898772
The amount of misinformation is insane. 1080 is not divisible by 16, so the actual coded size is 1088. Decoders decode that, and the last 8 pixels are generally garbage. The texture is larger, and sampling is not exact at the borders. vo=gpu with D3D11 behaves the same way and always has. Stop comparing image hashes, compare the image itself to understand what's going on, instead of assigning "not safe" labels.

>>105899115
this is vulkan rendering related. The hash test proves it.

d3d11 + d3d11va = passes the hash test
d3d11 + d3d11va-copy = passes the hash test
d3d11 + vulkan-copy =passes the hash test

meanwhile vulkan with these combinations does not on certain decoder formats, see: >>105898772. If the issue was decoder related then d3d11+vulkan-copy would fail the hash test just like the vulkan combinations.

does anyone have good settings for replicating the volume normalization on youtube? i've found a lot of schizo configs online but they're all worse than just af=loudnorm.

>>105899115
>Stop comparing image hashes, compare the image itself to understand what's going on
Also, I don't see what the difference is between comparing hashes and doing a magick diff on the images, the point is showing that vulkan with gpu surfaces produce different outputs than d3d11 and gpu surfaces, therefore loss in visual quality with vulkan (however minimal). this is not related to gpu or gpu-next.

new
>>105899825
>>105899825

>>105899868
>slop+frog OP
go away

>>105899868
>trying to add a pasta to an /a/ colony
good luck

>/a/

>>105893600
>MPC-HC+madVR
Only reason to move would be to MPC-BE because it handles yt much better and won't take an hour to load a large playlist (and freeze your browser if you dragged and dropped the URL!)
You should look at it more by features/UX not >muh MPC old