I cannot notice any difference between bilinear and any of the other better built in scalers. Not even when zooming in on a screenshot. I'm talking about 1080p->4k
It is good but it has too much aliasing, someone needs to create a meme shader from this:
https://www.intel.com/content/www/us/en/developer/articles/technical/conservative-morphological-anti-aliasing-20.html
And a related question: are frame drops in display-resample drops of the "virtual" frames that mpv creates in order to display every vblank, or frames from your actual video being dropped.
by reading source, seems like delayed is when mpv detects driver has taken too long for a vsync. Mistimed seems to be when mpv needs to repeat or skip virtual frames as a consequence. I don't know if you could ever have one without the other though.
And a related question: are frame drops in display-resample drops of the "virtual" frames that mpv creates in order to display every vblank, or frames from your actual video being dropped.
It does seem that mpv doesn't distinguish between virtual frames and actual frames for the framedrop property. I guess the difference between a mistimed virtual frame and a dropped virtual frame is that the former is incremented during scheduling and the latter happens if mpv decides to show the virtual frame but it can't?
>doesn't distinguish
actually maybe not, I guess https://github.com/mpv-player/mpv/blob/02b49458a37313efa1b6bbaf99a73f406cd3eece/video/out/vo.c#L937 means that it only counts as a frame drop if we find a frame that's been queued for 0-vsync, which should only happen if the previous frame took too long and so during the frame adjustment we decided the next frame should not be shown. So the frame drop property is effectively when 0 virtual frames are shown for a physical frame, i.e. the actual frame was dropped entirely.
which seems like its supposed to range from [0, ideal_frame_duration] and be incremented by vsync_interval each time the frame gets repeated.
But vsync_offset gets reset to prev_error each time in https://github.com/mpv-player/mpv/blob/02b49458a37313efa1b6bbaf99a73f406cd3eece/player/video.c#L925
No wait I'm still confused as to why vsync_offset is initialized as -prev_error instead of just prev_error.
last_error is basically display_sync_error which is frame_duration - num_vsyncs * vsync. If the ideal frame duration is slightly past what we end up showing, then error is positive. I'd think that we'd want to set vsync_offset as just the error, so for instance if we have a frame that would ideally last 1.1 vsyncs, but we only display it for 1 vsync, the next frame should ideally begin at an offset of 0.1 into the next vsync.
>questioning wm4 code
The original wm4 code just used `display_sync_error`, without the negation. I can understnad why we want to use the previous error before updating it, but why negate it?
It's because the direction of the offset is necessarily flipped. Take wm4's original code and pretend the error is 0.005 for the next frame (0.005 longer than the perfect frame duration). If you want to apply that error to the current frame instead (what wm4 later did), then it's not 0.005 but -0.005. The current frame's duration needs to be -0.005 shorter. Hence, the code always flips the sign of the prev_error whenever it assigns the offset value to the frame.
but he's already using prev_error. If what you're saying is true, should we be negating the next frame's error (display_sync_error) instead of the current frame's error (prev_error).
No? The error is calculated with regards to the next frame (display_sync_error). This can be a positive or negative value depending on the circumstances. The prev_error negation comes from the fact that the original calculation is against the next frame and not the current frame like I said.
Although going by my logic, that would mean this line is wrong and should be -prev_error. Actually I think it probably should be -prev_error. This might be the cause of mistimed/delayed frames that always happen at the beginning of display-resample.
https://github.com/mpv-player/mpv/blob/master/player/video.c#L894
Maybe let me clarify. In https://github.com/mpv-player/mpv/blob/master/player/video.c#L858-L859
we have
double prev_error = mpctx->display_sync_error;
mpctx->display_sync_error += frame_duration - num_vsyncs * vsync;
So from that point onward, prev_error represents the error for the current frame, and display_sync_error is the error for the next frame we're going to show.
So when he does -prev_error isn't he flipping the error for the _current frame_, not the next frame? If your error for the current frame was 0.005, I agree that your next frame needs to be 0.005 shorter. But sync vsync_interval is when to display the frame within the vsync, wouldn't you set vsync_interval to 0.005 then? (indicating that you should not show the frame at the start of the vsync but 0.005 in, thereby reducing the length by 0.005).
3 weeks ago
Anonymous
shit I meant "vsync_offset is when to display..."
3 weeks ago
Anonymous
>So from that point onward, prev_error represents the error for the current frame
No. It represents the old value of mpctx->display_sync_error before it gets calculated again. Subtle but important difference. The value was calculated on a previous loop so the direction of the offset is still mismatched. It's in reference to the mythical next frame not the current one. You can ask "why didn't wm4 make it -mpctx->display_sync_error" and that would be valid question. I suspect he made a mistake when he first added that value.
3 weeks ago
Anonymous
> The value was calculated on a previous loop so the direction of the offset is still mismatched.
I still don't buy this. I agree that if the previous frame was longer, we need the next frame to be shorter.
But if you think about what vsync_offset means, it doesn't represent the length but rather the ideal position to display the frame within a vsync, and it's used only for interpolation purposes. So say the previous frame was 0.05 longer than needed, when we present the next frame we effectively need to treat it (for blending/interpolation purposes) as if it should be 0.05 in. So vsync_offset should be set to 0.05, not -0.05.
3 weeks ago
Anonymous
actually I think I get it now. Our offset needs to be -0.05 because assuming we had a magic temporal interpolator, when we present the next frame we should ideally pick up where the previous frame should have left off.
3 weeks ago
Anonymous
[...]
I was typing a reply but yes that's the idea. Also you can always just change the code yourself to "frame->vsync_offset = prev_error", flip on interpolation and observe that it's completely wrong.
Thank you for sticking with me. So here's a concrete example to verify my enlightenment:
Assume we calculate the error for the next frame (call it frame n) as 0.05 (frame is ideally 0.05 vsync longer than what we can actually present). Then on the next iteration (after we've presented that frame n [and all its virtual frames]) when we are computing info for frame n+1, we would like to "pick up" where frame n should have ideally left off. So assuming a magic temporal interpolator, we would give it the offset -0.05, so that the effective net duration for frame n does end up being 0.05.
3 weeks ago
Anonymous
er typo on the line >the effective net duration for frame n does end up being 0.05.
meant to say the effective net duration is incremented by 0.05 (due to effects of interpolation).
3 weeks ago
Anonymous
er typo on the line >the effective net duration for frame n does end up being 0.05.
meant to say the effective net duration is incremented by 0.05 (due to effects of interpolation).
Yeah that's correct. It's not exactly intuitive just looking at the code.
3 weeks ago
Anonymous
Ok sankyuu. I've also got one more schizo bug report (possibly for real this time):
Reproduction: play a 30fps video on a 60fps display with display-sync.
Symptom: Enable trace-logging, look at speed_factor_v
The speed should be 1.0 exact, but I see it as 1.00004.
Root cause: The vsync interval passed into calc_best_speed is ultimately calculated as (double)((int64_t)(1e6/60.0))/1e6, because nominal_vsync_interval is stored as int64_t, and storing 1e6/60.0 in a long slices off precision that matters.
int main(int argc, char *argv[]) {
printf("What mpv effectively currently calculates vsync as %.20fn", (double)((int64_t)(1e6/60.0))/1e6);
printf("What vsync should ideally be %.20fn", ((double)(1e6/60.0))/1e6);
printf("Current calculated best speed %.20fn", calc_best_speed(vsync, dur));
}
3 weeks ago
Anonymous
Something to fix, improve. Not sure why mpv uses such low base as 1e6 for vsync. Maybe it is enough in practice. But why not use floats all the way.
3 weeks ago
Anonymous
>Maybe it is enough in practice
Well it does seem to have the observable effect of speeding up video to 1.00004, but maybe that's unnoticeable in practice.
3 weeks ago
Anonymous
>Maybe it is enough in practice
Well it does seem to have the observable effect of speeding up video to 1.00004, but maybe that's unnoticeable in practice.
Yeah I can confirm this. Considering that 60 Hz is one of the common refresh rates, more precision would be worth it. The actual value is, of course, 0.01666666666 so truncation is not so great here.
3 weeks ago
Anonymous
>bug report on LULZ
>bug report on the issue tracker
https://github.com/mpv-player/mpv/issues/12230
3 weeks ago
Anonymous
actually I think I get it now. Our offset needs to be -0.05 because assuming we had a magic temporal interpolator, when we present the next frame we should ideally pick up where the previous frame should have left off.
I was typing a reply but yes that's the idea. Also you can always just change the code yourself to "frame->vsync_offset = prev_error", flip on interpolation and observe that it's completely wrong.
basically this thinly veiled mpv general with off-topic pictures is made by a tranny called llyyr who enters a bigger mental breakdown when someone else makes the thread and mpv isn't listed as first in the OP
without ffmpeg and yt-dlp in the OP, the thread dies unless it necrobumps the thread
it and the other trannies use this thread to talk shit to each other anonymously because they don't have the balls (no pun intended) to do it with their names on
Well shit I got the same thing. I guess the fast float guys broke something. Someone just revert this stupid commit.
https://code.videolan.org/videolan/libplacebo/-/commit/9b9987cc12b3513ecd48239fdfdc4220bc61260f
I modified the official PKGBUILD into a git package and it works fine for me. You're doing something wrong.
3 weeks ago
Anonymous
Can you just post it for my retarded self.
3 weeks ago
Anonymous
https://dpaste.org/kPRLG
Modified to use the AUR's retarded pkgver and disabled updating submodules to latest commits since that will often break things. Changes are untested.
when using ffmpeg timestamp "-ss hh:mm:ss -to hh:mm:ss" is there a option or parameter to just make the second timestamp the end of the video?
I know I can enter the video length manually but I was wondering if maybe 'end' was a valid entry or something. I think that'd be super useful
Why are the webms I create with webm.lua all like 5mb+?
I've set target_filesize = 3750, crf = 10 (default)
they're all shorter than 1 minute and max width 760
???????????????????????????????????
return of the endgame chroma ewa_lanczossoft cargo cult meme with a brand new robidoux style derived mathematically calculated high precision blur
cscale=ewa_lanczos
cscale-blur=1.01646676628670456329563
haasn's old trial-and-error value was 1.015
I play video at exactly 23.98fps with display-resample with 1.000 vsync ratio and 0.001 jitter, any decent TV can receive 24000/1001p and 24p inputs and play them judder free.
So let me get this straight >mpv has worked perfectly fine for a literal decade >no one has ever complained about anything >everything literally just works >fast forward >gpu-next is a thing >suddenly, mpv is completely "broken" on fundamental level, and does everything "wrong" even though no one has complained about anything for years >and libplacebo is supposed to "fix" this because ???
Something smells fishy here...
the plex relicensing change didn't materially affect anything. On the other hand, with libplacebo we now have this extra dependency that has infiltrated and grown deep tendrils into the mpv codebase.
Imagine a world where wm4 and haasn were saving free (as in freedom(tm)) and open video rendering together... It would've been beautiful. I cry everytime.
>he doesn't know haasn reads madVR threads on avsforum religiously while stealing all of madshi's ideas and concepts
haasn has never come up with an original idea. everything in shitplacebo was stolen from doom9 and avsforum. he's a cringe redditor he's not /ourguy/
>wm4 keeps the project polished as fuck >some day, trannies appear >fast forward, wm4 quits because of trannies (haasn, etc) >trannies shit up everything, because their asshole is destroyed by dragon dildos >tranny shits out a massive shit nugged (gpu-next) >everything is now covered in feces
Imagine a world where wm4 and haasn were saving free (as in freedom(tm)) and open video rendering together... It would've been beautiful. I cry everytime.
>Special note also goes out to wm4, the developer of
mpv, whose ideas helped shape the foundation of the shader dispatch system.
gotta love how things stop being true in haasn's mind whenever he feels like deleting credit and jacking his ego off. madshi was right.
>he doesn't know haasn reads madVR threads on avsforum religiously while stealing all of madshi's ideas and concepts
haasn has never come up with an original idea. everything in shitplacebo was stolen from doom9 and avsforum. he's a cringe redditor he's not /ourguy/
>Special note also goes out to wm4, the developer of
mpv, whose ideas helped shape the foundation of the shader dispatch system.
gotta love how things stop being true in haasn's mind whenever he feels like deleting credit and jacking his ego off. madshi was right.
after getting kicked out of his own project he enlisted for the army, he then went on a stroll with his buddies across town square and got shot by police and now he's on his way to take majority vote in Germany so I heard
The more I argued with him, the better I came to know his dialectic. First he counted on the stupidity of his adversary, and then, when there was no other way out, he simply played stupid. If all this didn't help, he pretended not to understand, or, if challenged, changed the subject in a hurry, quoted platitudes which, if you accepted them, he immediately related to entirely different matters, and then, if again attacked, gave ground and pretended not to know exactly what you were talking about.
Whenever you tried to attack him, your hand closed on a jelly-like slime which divided up and poured through your fingers, but in the next moment collected again. But if you really struck him so telling a blow that, observed by the audience, he couldn't help but agree, and if you believed that this had taken you at least one step forward, your amazement was great the next day. Niklas Haas had not the slightest recollection of the day before, he rattled off his same old nonsense as though nothing at all had happened, and, if indignantly challenged, affected amazement; he couldn't remember a thing, except that he had proved the correctness of his assertions the previous day.
Sometimes I stood there thunderstruck.
I didn't know what to be more amazed at: the agility of his tongue or his virtuosity at lying. Gradually I began to hate him.
This. >average projector chad >host a get-together in your home theater powered by MADVR ENVY MK2 >dozens of people come to watch 70s and 80s classics on a massive silver screen >extensive tonemapping options make the colors really pop out in ways never seen before thanks to next-gen MADVR technology >movie ends, everyone in the theater claps >everyone has orgies right afterwards
>average mpv user >watches anime in a dimly lit room on his gaming PC (he doesn't even play anything except gachashit anymore) >too embarrassed to share his interests with anyone >"heh.. they dont realize the correct blur value for jinc-jinc is actchually 0.98125058372237073562493" he says under his breath >his 12 episode anime binge ends (he didn't even like it) >jerks off then goes to bed
>average mpv user >watches anime in a dimly lit room on his gaming PC (he doesn't even play anything except gachashit anymore) >too embarrassed to share his interests with anyone >>"heh.. they dont realize the correct blur value for jinc-jinc is actchually 0.98125058372237073562493" he says under his breath >his 12 episode anime binge ends (he didn't even like it) >jerks off then goes to bed
painfully accurate
>average mpv user >watches anime in a dimly lit room on his gaming PC (he doesn't even play anything except gachashit anymore) >too embarrassed to share his interests with anyone >>"heh.. they dont realize the correct blur value for jinc-jinc is actchually 0.98125058372237073562493" he says under his breath >his 12 episode anime binge ends (he didn't even like it) >jerks off then goes to bed
painfully accurate
anons I use mpv with gpu-hq because vlc can't even add a spline upscaler.
>everyone has orgies
As someone who knows people closely related to madshi's social circle, you would be surprised how much virgin vibes that guy has (even when he looks just like a normal fella on the outside). Just saying.
best in terms of quality/complexity probably spline36. best in terms of pure quality, probably one of the ai shaders, unless you have a degree in systems theory and understand all the filters and what their parameters mean from a mathematical pov so you can tweak them yourself
>According to a quick google search, they probably deleted their account in protest of GitHub's For You page.
what the fuck is "GitHub's For You page"?
who would delete their account over mandatory 2fa? Seems like the pettiest thing. It's not even a datamining operation because you can always use totp.
>dude my entire identity is that I jerk off to e-boi LOLOL
yeah no thanks buddy, you probably deleted your Eva account because you had a mental breakdown, therefore you're unhinged
Luckily I updates all mpv scripts regularly so here's the archive https://github.com/l-jared
If you don't trust a random person's fork, you can try to find the latest fork in https://web.archive.org/web/20221202155816/https://github.com/po5/mpv_sponsorblock/network/members
Are you really surprised? The rando git accounts that confirmed that jared is po5 are probably from some cringe discord. And we already know that po5 is a LULZtard so I wouldn't be surprised if they raid this place.
Yes. For the longest time libplacebo didn't discriminate between them at all, until haasn got tired of people complaining they couldn't use whatever bullshit they wanted to from mpv, but I don't think the main API has them exposed separately still.
>use llvm-mingw toolchain
From my experience with that toolchain, that's not really a selling point. Even gcc mingw is buggy at the best of times, and the llvm version is even worse both because it's newer and because it's just better in almost all situations to use the version of clang that's actually supported and distributed by microsoft. Kasper's memes are going a little too far on this one.
https://slow.pics/c/UaabyKwu
Default debanding fucks this image. Setting threshold back to old 64 seemed to fix it.
I wonder if the hdeband shader does any better.
Anon, I just took the screenshot as I was watching and toggled deband. You sound like llyyr.
If I remember, I'll do a no-config gpu-hq with dither disabled and a sample file, just for you.
your posts are super transparent, you keep making the same mistakes every time you try to participate in any big boy discussion
you dont need schizophrenia to notice your posts, whenever i see anything transparently retarded, i know its you, and the fact that you seethe and reveal yourself makes it even funnier
You have to go archive dumpster diving to find the actual reason why it was changed. Mia only changed it because some anon on an /mpv/ thread posted a source where deband-threshold=64 was a net negative.
Not really. Every encode has quantization noise regardless of how good or "clean" it is. Also, encoders who do their own debanding don't recommend turning deband off in mpv, the blanket recommendation is still profile=gpu-hq.
>if it's safe then it's not destroying anything
wrong, as a matter of fact, it's everything but safe to modify the video encode in any way by definition (if it's subjectively better the result in some shitty encodes, of course, but that don't change the underlying problem)
What exact format does "vulkan-device" want?
I gave it the uuid number i gave it "UUID=XXX" i have it the literal name of the device i gave it "1" but it never takes any thing and complains it dosent exist
You know I was telling you guys that haasn's debanding basically didn't do anything long before this thread was inundated with madvr shills. I'm literally always right.
We always knew that madVR had a better debanding though..? I don't see your point sizuchan. You don't have to insert yourself into every unrelated conversation.
Really? Moving the buttons to the top and thinning out the seekbar also makes the osc look more pleasing in windowed mode (you obviously have to disable osc/osc scaling in windowed)
>dude don't actually watch stuff or pay attention to content, just pixel peep for banding artifacts at all times so that you can get the most optimal experience at all times hurr hurr
You're literally a living embodiment of this meme
scale=catmull_rom
cscale=catmull_rom
dscale=catmull_rom
ok
I cannot notice any difference between bilinear and any of the other better built in scalers. Not even when zooming in on a screenshot. I'm talking about 1080p->4k
Because it's a meme, stop tinkering and just go with > gpu-hq
didn't ask albeit
>I cannot notice any difference between bilinear
Optometrist bros, we are gonna make so much money:
https://slow.pics/c/9GqKHzOi
>https://slow.pics/c/9GqKHzOi
I love how polar catrom just looks like you've applied a strong sharpening filter on top of a blurry image lmao.
It is good but it has too much aliasing, someone needs to create a meme shader from this:
https://www.intel.com/content/www/us/en/developer/articles/technical/conservative-morphological-anti-aliasing-20.html
What is PC100?
pixel clipper at 1.0 strength
>Optometrist bros, we are gonna make so much money
kek
ruby puta
ay wey
wooby pure
My wife Ruby
posting in a llyyr thread
tear in the fabric of reality
Kasper, write a pull request that shows the SAR and DAR next to the video resolution please
I hate Flan so fucking much.
So fucking much.
And all of you as well.
i want to kill myself
better go do it llyr
dont do it sizuchan
profile=gpu-hq
Rate my config.
where's osd-bar=no
vo=gpu-next
what does this do
puts your GPU next to you
What's the difference between delayed and mistimed frames in display-resample mode?
And a related question: are frame drops in display-resample drops of the "virtual" frames that mpv creates in order to display every vblank, or frames from your actual video being dropped.
by reading source, seems like delayed is when mpv detects driver has taken too long for a vsync. Mistimed seems to be when mpv needs to repeat or skip virtual frames as a consequence. I don't know if you could ever have one without the other though.
It does seem that mpv doesn't distinguish between virtual frames and actual frames for the framedrop property. I guess the difference between a mistimed virtual frame and a dropped virtual frame is that the former is incremented during scheduling and the latter happens if mpv decides to show the virtual frame but it can't?
>doesn't distinguish
actually maybe not, I guess https://github.com/mpv-player/mpv/blob/02b49458a37313efa1b6bbaf99a73f406cd3eece/video/out/vo.c#L937 means that it only counts as a frame drop if we find a frame that's been queued for 0-vsync, which should only happen if the previous frame took too long and so during the frame adjustment we decided the next frame should not be shown. So the frame drop property is effectively when 0 virtual frames are shown for a physical frame, i.e. the actual frame was dropped entirely.
Dont forget imagemagick
Is interpolation code broken in mpv? It relies on vsync_offset
https://github.com/mpv-player/mpv/blob/02b49458a37313efa1b6bbaf99a73f406cd3eece/video/out/gpu/video.c#L3248
which seems like its supposed to range from [0, ideal_frame_duration] and be incremented by vsync_interval each time the frame gets repeated.
But vsync_offset gets reset to prev_error each time in https://github.com/mpv-player/mpv/blob/02b49458a37313efa1b6bbaf99a73f406cd3eece/player/video.c#L925
nvmind, seems redraw frames don't trigger that reset logic
https://github.com/mpv-player/mpv/blob/02b49458a37313efa1b6bbaf99a73f406cd3eece/video/out/vo.c#L814
>questioning wm4 code
No wait I'm still confused as to why vsync_offset is initialized as -prev_error instead of just prev_error.
last_error is basically display_sync_error which is frame_duration - num_vsyncs * vsync. If the ideal frame duration is slightly past what we end up showing, then error is positive. I'd think that we'd want to set vsync_offset as just the error, so for instance if we have a frame that would ideally last 1.1 vsyncs, but we only display it for 1 vsync, the next frame should ideally begin at an offset of 0.1 into the next vsync.
The original wm4 code just used `display_sync_error`, without the negation. I can understnad why we want to use the previous error before updating it, but why negate it?
bump on this. Dudemanguy, you mentioend you're familiar with displaysync code, can you chime in?
It's because the direction of the offset is necessarily flipped. Take wm4's original code and pretend the error is 0.005 for the next frame (0.005 longer than the perfect frame duration). If you want to apply that error to the current frame instead (what wm4 later did), then it's not 0.005 but -0.005. The current frame's duration needs to be -0.005 shorter. Hence, the code always flips the sign of the prev_error whenever it assigns the offset value to the frame.
but he's already using prev_error. If what you're saying is true, should we be negating the next frame's error (display_sync_error) instead of the current frame's error (prev_error).
No? The error is calculated with regards to the next frame (display_sync_error). This can be a positive or negative value depending on the circumstances. The prev_error negation comes from the fact that the original calculation is against the next frame and not the current frame like I said.
Although going by my logic, that would mean this line is wrong and should be -prev_error. Actually I think it probably should be -prev_error. This might be the cause of mistimed/delayed frames that always happen at the beginning of display-resample.
https://github.com/mpv-player/mpv/blob/master/player/video.c#L894
Maybe let me clarify. In https://github.com/mpv-player/mpv/blob/master/player/video.c#L858-L859
we have
double prev_error = mpctx->display_sync_error;
mpctx->display_sync_error += frame_duration - num_vsyncs * vsync;
So from that point onward, prev_error represents the error for the current frame, and display_sync_error is the error for the next frame we're going to show.
So when he does -prev_error isn't he flipping the error for the _current frame_, not the next frame? If your error for the current frame was 0.005, I agree that your next frame needs to be 0.005 shorter. But sync vsync_interval is when to display the frame within the vsync, wouldn't you set vsync_interval to 0.005 then? (indicating that you should not show the frame at the start of the vsync but 0.005 in, thereby reducing the length by 0.005).
shit I meant "vsync_offset is when to display..."
>So from that point onward, prev_error represents the error for the current frame
No. It represents the old value of mpctx->display_sync_error before it gets calculated again. Subtle but important difference. The value was calculated on a previous loop so the direction of the offset is still mismatched. It's in reference to the mythical next frame not the current one. You can ask "why didn't wm4 make it -mpctx->display_sync_error" and that would be valid question. I suspect he made a mistake when he first added that value.
> The value was calculated on a previous loop so the direction of the offset is still mismatched.
I still don't buy this. I agree that if the previous frame was longer, we need the next frame to be shorter.
But if you think about what vsync_offset means, it doesn't represent the length but rather the ideal position to display the frame within a vsync, and it's used only for interpolation purposes. So say the previous frame was 0.05 longer than needed, when we present the next frame we effectively need to treat it (for blending/interpolation purposes) as if it should be 0.05 in. So vsync_offset should be set to 0.05, not -0.05.
actually I think I get it now. Our offset needs to be -0.05 because assuming we had a magic temporal interpolator, when we present the next frame we should ideally pick up where the previous frame should have left off.
Thank you for sticking with me. So here's a concrete example to verify my enlightenment:
Assume we calculate the error for the next frame (call it frame n) as 0.05 (frame is ideally 0.05 vsync longer than what we can actually present). Then on the next iteration (after we've presented that frame n [and all its virtual frames]) when we are computing info for frame n+1, we would like to "pick up" where frame n should have ideally left off. So assuming a magic temporal interpolator, we would give it the offset -0.05, so that the effective net duration for frame n does end up being 0.05.
er typo on the line
>the effective net duration for frame n does end up being 0.05.
meant to say the effective net duration is incremented by 0.05 (due to effects of interpolation).
Yeah that's correct. It's not exactly intuitive just looking at the code.
Ok sankyuu. I've also got one more schizo bug report (possibly for real this time):
Reproduction: play a 30fps video on a 60fps display with display-sync.
Symptom: Enable trace-logging, look at speed_factor_v
The speed should be 1.0 exact, but I see it as 1.00004.
Root cause: The vsync interval passed into calc_best_speed is ultimately calculated as (double)((int64_t)(1e6/60.0))/1e6, because nominal_vsync_interval is stored as int64_t, and storing 1e6/60.0 in a long slices off precision that matters.
#include <stdio.h>
#include <math.h>
double calc_best_speed(double vsync, double frame)
{
double ratio = frame / vsync;
double best_scale = -1;
double best_dev = INFINITY;
for (int factor = 1; factor <= 5; factor++) {
double scale = ratio * factor / rint(ratio * factor);
double dev = fabs(scale - 1);
if (dev < best_dev) {
best_scale = scale;
best_dev = dev;
}
}
return best_scale;
}
#define vsync 0.016666000000000
#define dur 1.0/3.0
int main(int argc, char *argv[]) {
printf("What mpv effectively currently calculates vsync as %.20fn", (double)((int64_t)(1e6/60.0))/1e6);
printf("What vsync should ideally be %.20fn", ((double)(1e6/60.0))/1e6);
printf("Current calculated best speed %.20fn", calc_best_speed(vsync, dur));
}
Something to fix, improve. Not sure why mpv uses such low base as 1e6 for vsync. Maybe it is enough in practice. But why not use floats all the way.
>Maybe it is enough in practice
Well it does seem to have the observable effect of speeding up video to 1.00004, but maybe that's unnoticeable in practice.
Yeah I can confirm this. Considering that 60 Hz is one of the common refresh rates, more precision would be worth it. The actual value is, of course, 0.01666666666 so truncation is not so great here.
>bug report on LULZ
>bug report on the issue tracker
https://github.com/mpv-player/mpv/issues/12230
I was typing a reply but yes that's the idea. Also you can always just change the code yourself to "frame->vsync_offset = prev_error", flip on interpolation and observe that it's completely wrong.
I use those programs but I don't see the point of making this thread every day. Why is this general needed?
basically this thinly veiled mpv general with off-topic pictures is made by a tranny called llyyr who enters a bigger mental breakdown when someone else makes the thread and mpv isn't listed as first in the OP
without ffmpeg and yt-dlp in the OP, the thread dies unless it necrobumps the thread
it and the other trannies use this thread to talk shit to each other anonymously because they don't have the balls (no pun intended) to do it with their names on
pasta
jesus christ can't build libplacebo because of this fast_float shit anymore
You have to clone the fast_float source too. Very annoying.
I did
../src/convert.cc:44:9: error: static_assert failed due to requirement 'std::is_same_v<float, unsigned short> || std::is_same_v<double, unsigned short>' "Not implemented!"
static_assert(std::is_same_v<float, T> || std::is_same_v<double, T>,
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/convert.cc:91:1: note: in instantiation of function template specialization '(anonymous namespace)::to_chars<unsigned short, int>' requested here
CHAR_CONVERT(hex, unsigned short, 16)
^
Well shit I got the same thing. I guess the fast float guys broke something. Someone just revert this stupid commit.
https://code.videolan.org/videolan/libplacebo/-/commit/9b9987cc12b3513ecd48239fdfdc4220bc61260f
git submodule update --init --recursive --remote
works for me™
nope same result owari da(tm)
If I compile libplacebo directly, this works. However if I try to use a PKGBUILD, I always end up with the random compile errors. Fuck fast float
I modified the official PKGBUILD into a git package and it works fine for me. You're doing something wrong.
Can you just post it for my retarded self.
https://dpaste.org/kPRLG
Modified to use the AUR's retarded pkgver and disabled updating submodules to latest commits since that will often break things. Changes are untested.
Well that works. Thanks anon
just works on my gentoo
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=10c0ba740fd2
when using ffmpeg timestamp "-ss hh:mm:ss -to hh:mm:ss" is there a option or parameter to just make the second timestamp the end of the video?
I know I can enter the video length manually but I was wondering if maybe 'end' was a valid entry or something. I think that'd be super useful
can't you just omit "-to" in this case
>2023
>ffmpeg still can't read SACD ISOs
what's a SACD
Sac Deez NUTS
yet another placebo 'hi-res' audio format
uosc.lua enjoyers, how do you turn off animations?
I use FreeSync to avoid pulldown judder so I don't really care about display-resample, so all of the animations in uosc look really ugly.
endgame just dropped:
scale=ewa_robidoux
scale-param1=0
scale-param2=0.5
cscale=ewa_lanczos
dscale=ewa_robidoux
dscale-param1=0
dscale-param2=0
glsl-shader="path/to/shader/PixelClipper.glsl" # Only luma pass
correct-downscaling=yes
linear-downscaling=yes
sigmoid-upscaling=yes
scaler-lut-size=10
sigmoid-slope=7.5
still looks like bilinear to me...
post your stats page 2
Why are the webms I create with webm.lua all like 5mb+?
I've set target_filesize = 3750, crf = 10 (default)
they're all shorter than 1 minute and max width 760
???????????????????????????????????
Weird default to have then just look at thsi shit
fuck off with the same thread everyday already
Why don't you fuck off from our thread?
fuck off you neets who circlejerk to the "least bloat possible" when watching youtube videos
These threads are usually slow on weekdays, so I'd actually assume most people who post here regularly are wagies.
I'll have you know I maximize bloat and ""quality"" when watching youtube videos.
Yes you're right, we need this space for another Twitter, platform currently known as X, thread.
Is profile=gpu-hq a good config for Android mobile?
on android stick to something other than mpv, or google will flag your account for possibly belonging to a... niece enthusiast
if your phone doesn't shit itself, sure
PS: it will drain your battery
Thanks, I believe in my phone.
FUCK fast_float
it just works
doesn't work when linking against macos 10.14
win7chads it's over...
mojavechads it's over...
is yt-dlp dead?
Works on my machine
Doesn't look like it
yt-dlp %url% -o - | mpv -
mpv <url>
mpv used to mean something...
media player V(5)
meme player for virgins
????
what kind of retarded repsonse is this. you sound pissy that you dont feel cool and special for using it or something
/wsg/chad here, finally got unbanned.
Anyway, I can finally use libplacebo extra_opts on ffmpeg, downscaled with polar_mitchell:
Command:
-vf "libplacebo=w=iw/2:h=-1:format=yuv420p10le:extra_opts='downscaler=custom:downscaler_preset=mitchell:downscaler_polar=true:downscaler_antiring=0.5'"
Yes, polar_mitchell has mild ringing just like ortho catrom.
Does libplacebo down samples in linear light by default?
yea
What about "correct-downscaling"?
return of the endgame chroma ewa_lanczossoft cargo cult meme with a brand new robidoux style derived mathematically calculated high precision blur
cscale=ewa_lanczos
cscale-blur=1.01646676628670456329563
haasn's old trial-and-error value was 1.015
>cscale-blur=1.0164667662867045632956
post pics
What about scale-wblur?
didn't haasn already fix that?
only in gpu-next
is gpu-next default yet?
god i wish
>only works with libplacebo versions from fucking 3 days ago
>otherwise refuses to build
yeah no
>v6.292.0
>Thu Jul 6 23:31:04 2023 +0200
>robidoux made a mistake
>wm4 made a mistake
i don't even know what is true anymore
Someone tell shinchiro to build libvpx with --enable-vp9-highbitdepth
Holy fucking shit I fucking hate shinchiro so goddamn much.
Just found out that I can use kernel matrix filters on my browser
>anyone using display-resample has been a speedwatcher
Not really
seething speedwatcher. I remember people defending display-resample claiming that it won't speed up your video for most cases.
I play video at exactly 23.98fps with display-resample with 1.000 vsync ratio and 0.001 jitter, any decent TV can receive 24000/1001p and 24p inputs and play them judder free.
sorry sweetie, your videos have been sped up by 1.00001002010040118684
Hello.
I am still on mpv 0.36.0 stable.
0.29.0 is the new meta
which was the last version before the libASS regression
while we're on the topic of speedwatching
https://github.com/mpv-player/mpv/pull/8130
THIS IS STILL NOT MERGED
ok?
I still don't understand the purpose of this
Flickering while seeking is great, but not flickering is also great. 0.29 it is.
>Flickering while seeking is great, but not flickering is also great. 0.29 it is.
What did he mean by this? (i don't see any flickering with 0.29)
bring back wm4, that's it
So let me get this straight
>mpv has worked perfectly fine for a literal decade
>no one has ever complained about anything
>everything literally just works
>fast forward
>gpu-next is a thing
>suddenly, mpv is completely "broken" on fundamental level, and does everything "wrong" even though no one has complained about anything for years
>and libplacebo is supposed to "fix" this because ???
Something smells fishy here...
it gives haasn a job
This video-sync stuff has nothing to do with libplacebo, and the audio stuff is wm4's fault. He quit in the middle of a refactor.
>he quit
Nice history rewrite
whose fault is the absolute state of libASS
it's sabotage
>VideoLAN
change that to Plex and you have the actually historically accurate version of this image
the plex relicensing change didn't materially affect anything. On the other hand, with libplacebo we now have this extra dependency that has infiltrated and grown deep tendrils into the mpv codebase.
>that has infiltrated and grown deep tendrils into the mpv codebase
OY VEYYY SHUT IT DOOWNNNN
literally just don't build mpv with libplacebo, it's that easy
cone should be a bit higher so its the nose
scarecrow from bob the builder
mpv is now property of VLC. welcome to the cone zone mother fucker.
-this post was brought to you by cone gang
-get coned idiot
This needs to be the splash screen logo for mpv on april fools
quintessential dorkurochan / sizuman posts
which one is which
same guy
sizumam is too well spoken and intelligent to be dokuro
no i'm not
go back to doom9
>wm4 keeps the project polished as fuck
>some day, trannies appear
>fast forward, wm4 quits because of trannies (haasn, etc)
>trannies shit up everything, because their asshole is destroyed by dragon dildos
>tranny shits out a massive shit nugged (gpu-next)
>everything is now covered in feces
ok but why do you keep thinking about trannies and scat
which was the last good mpv version?
I need to know ASAP
Time to rewrite mpv in Rust.
Imagine a world where wm4 and haasn were saving free (as in freedom(tm)) and open video rendering together... It would've been beautiful. I cry everytime.
That happened for years. wm4 just had a melty when haasn wanted to add libplacebo to the player.
Yes, and you can't even turn that one off. Good thing, since wblur isn't even exposed in the API. Trust haasn.
So uh guys... when VLC 4.0 comes out are we supposed to switch it it or something...
I like the little cone logo with the sunglasses and popcorn, so yeah I think it's better than mpv
wm4 did nothing wrong
I can't believe madshi won BIG...
avsforum is down the hall
>he doesn't know haasn reads madVR threads on avsforum religiously while stealing all of madshi's ideas and concepts
haasn has never come up with an original idea. everything in shitplacebo was stolen from doom9 and avsforum. he's a cringe redditor he's not /ourguy/
he didn't even steal the params for lanczossharp properly!
this, we all know that Jinc's true zero is at 3.0
>haasn stole a bunch of shit and made it better
holy based, thanks haasn and thank you KAMIplacebo
>Special note also goes out to wm4, the developer of
mpv, whose ideas helped shape the foundation of the shader dispatch system.
gotta love how things stop being true in haasn's mind whenever he feels like deleting credit and jacking his ego off. madshi was right.
wm4 might be dead but his spirit will forever live on
what happend to wm4 anyway?
after getting kicked out of his own project he enlisted for the army, he then went on a stroll with his buddies across town square and got shot by police and now he's on his way to take majority vote in Germany so I heard
The more I argued with him, the better I came to know his dialectic. First he counted on the stupidity of his adversary, and then, when there was no other way out, he simply played stupid. If all this didn't help, he pretended not to understand, or, if challenged, changed the subject in a hurry, quoted platitudes which, if you accepted them, he immediately related to entirely different matters, and then, if again attacked, gave ground and pretended not to know exactly what you were talking about.
Whenever you tried to attack him, your hand closed on a jelly-like slime which divided up and poured through your fingers, but in the next moment collected again. But if you really struck him so telling a blow that, observed by the audience, he couldn't help but agree, and if you believed that this had taken you at least one step forward, your amazement was great the next day. Niklas Haas had not the slightest recollection of the day before, he rattled off his same old nonsense as though nothing at all had happened, and, if indignantly challenged, affected amazement; he couldn't remember a thing, except that he had proved the correctness of his assertions the previous day.
Sometimes I stood there thunderstruck.
I didn't know what to be more amazed at: the agility of his tongue or his virtuosity at lying. Gradually I began to hate him.
Nothing, he lives in Munich and works as a software dev.
how do i take screenshots with filters on? I want to do upscaler comparisons.
CTRL+s retardbro
that takes a screenshot in the original size, not upscaled.
???
No?
i checked the config and i modified it at one point. thanks.
madshi would never cut himself
Madvr(tm) Envy got me laid.
This.
>average projector chad
>host a get-together in your home theater powered by MADVR ENVY MK2
>dozens of people come to watch 70s and 80s classics on a massive silver screen
>extensive tonemapping options make the colors really pop out in ways never seen before thanks to next-gen MADVR technology
>movie ends, everyone in the theater claps
>everyone has orgies right afterwards
>average mpv user
>watches anime in a dimly lit room on his gaming PC (he doesn't even play anything except gachashit anymore)
>too embarrassed to share his interests with anyone
>"heh.. they dont realize the correct blur value for jinc-jinc is actchually 0.98125058372237073562493" he says under his breath
>his 12 episode anime binge ends (he didn't even like it)
>jerks off then goes to bed
>average mpv user
>watches anime in a dimly lit room on his gaming PC (he doesn't even play anything except gachashit anymore)
>too embarrassed to share his interests with anyone
>>"heh.. they dont realize the correct blur value for jinc-jinc is actchually 0.98125058372237073562493" he says under his breath
>his 12 episode anime binge ends (he didn't even like it)
>jerks off then goes to bed
painfully accurate
DELET
anons I use mpv with gpu-hq because vlc can't even add a spline upscaler.
literally me
ewa_lanczos4sharpest
>everyone has orgies
As someone who knows people closely related to madshi's social circle, you would be surprised how much virgin vibes that guy has (even when he looks just like a normal fella on the outside). Just saying.
mipvee or em-pee-vee?
emm-piv
m-pee-ve
em pee 5 (like the gun by h&k)
I saw a manic homeless guy in Munich the other day and I could've sworn he was talking about libmpv or something. Maybe I was just hearing things.
Nearly half of the posts in the past several threads have been offtopic spam from two or three schizos...
Just report and ignore.
>pointless metapost
I hope you're including yourself in the offtopic spam buddy
Madshi will sic his hounds on you if you make too much progress. It cuts into his bottom-line.
is there any kind of consensus about the best upscaler settings rn?
Yes. Look at the first post in the thread.
u two say different things?
Different anon, It's subjective. You have to try different upscalers yourself to see what you prefer.
polar_catrom plus anti-ringing plus anti-aliasing
Just use adaptive sharpen if you're going to stack multiple types of post processing filters just to mitigate how shit polar catrom looks.
bilinear
best in terms of quality/complexity probably spline36. best in terms of pure quality, probably one of the ai shaders, unless you have a degree in systems theory and understand all the filters and what their parameters mean from a mathematical pov so you can tweak them yourself
at this point im just gonna use oversample....
oversample + CRT filter is basically endgame but no one knows it
What's with the new po5/Eva drama? I was trying to find the thumbfast repo and it 404'd because he nuked his po5 account.
https://github.com/mpv-player/mpv/issues/12350
>cute/funny
Unsurprisingly he's an unfunny dickyposter with a discord cult.
>According to a quick google search, they probably deleted their account in protest of GitHub's For You page.
what the fuck is "GitHub's For You page"?
I have no idea, I clicked the home dashboard and I don't see anything.
I saw another thread about github making 2fa mandatory maybe that's something to do with it
who would delete their account over mandatory 2fa? Seems like the pettiest thing. It's not even a datamining operation because you can always use totp.
Luckily I updates all mpv scripts regularly so here's the archive https://github.com/l-jared
>dude my entire identity is that I jerk off to e-boi LOLOL
yeah no thanks buddy, you probably deleted your Eva account because you had a mental breakdown, therefore you're unhinged
not using any of these scripts
>jared
>i know her
??
Because GitHub is retarded, this takes all forks with it, right? This is why you don't fork and mirror instead.
No, that's not the case: https://github.com/pacien/mpv_sponsorblock
still exists, it's just not searchable. I don't think github ever showed forks in search results though.
If you don't trust a random person's fork, you can try to find the latest fork in https://web.archive.org/web/20221202155816/https://github.com/po5/mpv_sponsorblock/network/members
This account belonged to a German male. I used to talk to him on Discord a lot. I didn't know he trooned out.
>discord
every time
Are you really surprised? The rando git accounts that confirmed that jared is po5 are probably from some cringe discord. And we already know that po5 is a LULZtard so I wouldn't be surprised if they raid this place.
No but I'm tired of being right.
i dont know whats happening
mpv ffmpeg yt-dlp
how can you have drama over a free video player? what is there to have drama about? it plays videos ffs
There's no drama.
We're all calm.
https://dpaste.org/9XtTb
thumbfast's vanilla osc.lua synced to 022dbfc9
https://github.com/mpv-player/mpv/pull/12356
I hate mpv so much its unreal.
>dokurochan with eyes emoji
He's just so shocked that mpv has been broken for so many years. This past week has been a rollercoaster of broken hearts and minds.
the more I look at that image, the more it feels like he's actually crying rather than smiling.
what is he crying about though?
People still arguing about FIR filters in the year of our lord plus MMXXIII
Just use VRR.
>VRR?
What's that?
Variable refresh rate. (FreeSync, G-Sync etc.)
How do I use ewa_lanczos4sharp?
Using latest git build.
its not mapped as an mpv option yet
Just testing for the memes, what's the libplacebo-opts command?
libplacebo-opts-append=upscaler=ewa_lanczos4sharpest
Ok, it worked.
I guess it's scaling both luma and chroma right?
Yes. For the longest time libplacebo didn't discriminate between them at all, until haasn got tired of people complaining they couldn't use whatever bullshit they wanted to from mpv, but I don't think the main API has them exposed separately still.
https://github.com/rorgoroth/mingw-cmake-env
less bloated win build, use llvm-mingw toolchain.
>use llvm-mingw toolchain
From my experience with that toolchain, that's not really a selling point. Even gcc mingw is buggy at the best of times, and the llvm version is even worse both because it's newer and because it's just better in almost all situations to use the version of clang that's actually supported and distributed by microsoft. Kasper's memes are going a little too far on this one.
Although to be clear, it is way better than the winlibs and msys2 packaging of the same, and I believe asan works where it doesn't with gcc.
https://slow.pics/c/UaabyKwu
Default debanding fucks this image. Setting threshold back to old 64 seemed to fix it.
I wonder if the hdeband shader does any better.
This is related to deband-iterations, use 16 iter to avoid the problem. its not placebo unlike what the docs try to claim.
i can't repro this
also you left dithering on
you didnt even do no-config
Anon, I just took the screenshot as I was watching and toggled deband. You sound like llyyr.
If I remember, I'll do a no-config gpu-hq with dither disabled and a sample file, just for you.
holy meds and obsession
your posts are super transparent, you keep making the same mistakes every time you try to participate in any big boy discussion
you dont need schizophrenia to notice your posts, whenever i see anything transparently retarded, i know its you, and the fact that you seethe and reveal yourself makes it even funnier
Reddit spacing
Anon, I haven't posted anything since my initial deband post and I haven't posted pics of anything in months.
Just ignore him, the reddit fag is schizophrenic
uh huh, ill take your word for it buddy, maybe you can try better at concealing yourself tomorrow
https://files.catbox.moe/ypov01.mkv
--no-config --profile=gpu-hq --gpu-api=vulkan --dither-depth=no --screenshot-format=png --screenshot-tag-colorspace=no --screenshot-high-bit-depth=no --pause
Here you go, schizo. Different frame than the first images.
That does not help afaict
Forgot to set gpu-next but it exhibits the same issue.
I confirm more banding with deband on (default settings) than off
Deband yes/no looks exactly the same on my monitor. Maybe I'm blind dunno
>Setting threshold back to old 64 seemed to fix it.
Indeed, the new 32 value is bad. Why was it changed?
somebody thought it was too aggressive and could lead to detail loss
https://github.com/mpv-player/mpv/commit/f60725263c770a59cb5a21abe07dfd2ea94e8cb4
That's just the doc update
https://github.com/mpv-player/mpv/commit/12ffce0f
You have to go archive dumpster diving to find the actual reason why it was changed. Mia only changed it because some anon on an /mpv/ thread posted a source where deband-threshold=64 was a net negative.
/wsg/fag is super addicted to spreading FUD for some reason, not sure why, probably needs to get banned again
/wsg/chad here, keep crying
news flash, if you have to call yourself a "chad" unironically, then you aren't a chad, you're just a loser
I am not the one seething over nothing, keep coping.
you keep seething about no one taking you seriously, it's lolcow behavior
but honestly dont leave, you make this general a better place
The cope continues
Never change schizoid
learn how to use --no-config first and maybe you can chime in with the big boys next time
Schizophrenia is treatable illness anon.
https://github.com/haasn/libplacebo/blob/master/src/filters.c#L483
How come hermite is an alias for bcspline? Shouldnt hermite be 0 0?
Yeah, hermite is 0,0, see:
https://www.imagemagick.org/Usage/filter/#cubic_bc
The Holy Trinity
Deband endgame:
deband-iterations=4
deband-threshold=8
deband-range=4
deband-grain=12
This is better
deband=yes
deband-iterations=1
deband-threshold=64
deband-range=64
deband-grain=0 #grain added with another shader
I've been using this
deband = yes
deband-iterations=2
deband-threshold=48
deband-range=32
Those add banding to https://files.catbox.moe/ypov01.mkv
here you go.
So what is the problem with debanding in that clip?
>Those add banding to
I really don't know, it's a mystery.
Theres already banding there. low intensity debanding doesnt add banding to banding, it just moves it around a bit
If so then it moves the banding to a more noticeable spot, that's not preferable as well.
people using deband in 2023, the actual state of video encodes
imagine watching a cool but somewhat obscure anime encoded in 2012 in 2023. with no one bothering to reencode in AV1 from source bluray
Is there an actual argument to not using deband if the source is good enough?
yes? Deband is atrocious..
So no because that's a meme ass cargocult answer.
Not really. Every encode has quantization noise regardless of how good or "clean" it is. Also, encoders who do their own debanding don't recommend turning deband off in mpv, the blanket recommendation is still profile=gpu-hq.
yes, even the lesser deband basically destroys the picture details and everyone using it on real life content it's a retard
mpv's default is safe, stop spreading fud.
>safe
because something it's safe it doesn't mean it's the best approach
I hate the dipshits in this general.
>mpv's default is safe
mpv defaults debanding to off technically. But I guess you meant the individual deband settings.
Moving the goalposts, if it's safe then it's not destroying anything. What's wrong with it then?
>if it's safe then it's not destroying anything
wrong, as a matter of fact, it's everything but safe to modify the video encode in any way by definition (if it's subjectively better the result in some shitty encodes, of course, but that don't change the underlying problem)
mpv's default is to not deband
I meant mpv's default debanding parameters
how do you use ffmpeg and not get crazy?
i cant find half of things in the documentation that i see on stackexchange and other online forums
What exact format does "vulkan-device" want?
I gave it the uuid number i gave it "UUID=XXX" i have it the literal name of the device i gave it "1" but it never takes any thing and complains it dosent exist
Try --vulkan-device=help
Thats were i got the uuid but what format does it want?
just the uuid number
"UUID=XXX"
the full name in ""
the full name in ''
the full name in " '' "
the gpu device number "1"
It isnt taking anything i give in it in any format from that command
>guy in #mpv going on an anti-plex rant right now
based?
You know I was telling you guys that haasn's debanding basically didn't do anything long before this thread was inundated with madvr shills. I'm literally always right.
It is definitely doing something:
https://slow.pics/c/ZAhHJues
Test image:
https://files.catbox.moe/02blkh.tif
Command used:
mpv --no-config --vo=gpu-next --deband=no --dither=no --keep-open=yes --screenshot-format=png --screenshot-high-bit-depth=no --autofit=1920x1080 gradient-16-bit.tif
i dun geddit, deband looks better here
>deband looks better here
As it should?
What is it that you don't get?
i thought we're arguing that mpv's default debanding actually sucks and it needs the threshold changed
We always knew that madVR had a better debanding though..? I don't see your point sizuchan. You don't have to insert yourself into every unrelated conversation.
what are your deband params sizuchad
i use stock mpv
https://github.com/mpv-player/mpv/issues/12358
Holy shit this guy just fixed the OSC.
looks worse, I don't like it
Really? Moving the buttons to the top and thinning out the seekbar also makes the osc look more pleasing in windowed mode (you obviously have to disable osc/osc scaling in windowed)
I prefer the fat bar that takes up all the vertical height.
LGTM
I like the idea of having the subs and audio on top leaving more room for the progress bar.
reminder you don't need debanding for 10-bit encodes
almost everyone in the "scene" moved to 10-bit HEVC and they don't turn deband off
>HEVC
Well there's your problem.
I miss this little nigga so much. I can't believe he's contractually obliged to not post here anymore.
Cap
i simply only turn on debanding if i see banding.
why would you leave a shader that can very easily destroy detail running all the time?
>dude don't actually watch stuff or pay attention to content, just pixel peep for banding artifacts at all times so that you can get the most optimal experience at all times hurr hurr
You're literally a living embodiment of this meme
And with that, another fudposter has been obliterated.