Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 29th April 2024, 08:44   #64721  |  Link
Siso
Soul Seeker
 
Siso's Avatar
 
Join Date: Sep 2013
Posts: 723
On beta 112 I had to use 12 cpu, 8 gpu, frames in advance 3, to get stable playback.
Siso is offline   Reply With Quote
Old 29th April 2024, 12:13   #64722  |  Link
tp4tissue
Registered User
 
tp4tissue's Avatar
 
Join Date: May 2013
Posts: 753
Quote:
Originally Posted by huhn View Post
the low queue setting are to avoid unreported frame drop/repeats. 4 is the maximum nvidia supports these days.
How is the madvr hdr support on the newer nvidia cards huhn. On my latest AMDs it switches so fast, and doesn't black out the screen.

On my old 1060, it goes black, then pops back when nvhdr kicks up.
__________________
Ghetto | 2500k 5Ghz
tp4tissue is offline   Reply With Quote
Old 29th April 2024, 14:19   #64723  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,998
1-5 black frames close to instant but the issue it the TV on my old sony TV is was instant with no frame delay.
madVR often breaks something forcing me to restart the PC so you should ask user where it works.

mpv works flawless.
huhn is offline   Reply With Quote
Old 29th April 2024, 18:22   #64724  |  Link
Klaus1189
Registered User
 
Join Date: Feb 2015
Location: Bavaria
Posts: 1,684
What do I need for mpv to get HDR working?

Can you post your mpv config and list of additional stuff I need?
Do I need Vulkan?
Klaus1189 is offline   Reply With Quote
Old 29th April 2024, 22:44   #64725  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,998
vo=gpu-next
gpu-api=vulkan
target-colorspace-hint

the 3rd line is maybe all you need.
i gave up on mpv after i figured out that it can't do an YCbCr-> RGB conversation correctly and ignores interlaced flags because the flag could be wrong...
huhn is offline   Reply With Quote
Old 30th April 2024, 17:19   #64726  |  Link
Klaus1189
Registered User
 
Join Date: Feb 2015
Location: Bavaria
Posts: 1,684
Too Bad. What do you use now?
Klaus1189 is offline   Reply With Quote
Old 30th April 2024, 17:43   #64727  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,998
this is don't care about HDR.
if you care about HDR try mpcVR it at least places the chroma correctly unlike madVR but has nothing worth calling a really good chroma scaler and so on.
huhn is offline   Reply With Quote
Old 30th April 2024, 18:03   #64728  |  Link
Drybonz
Registered User
 
Join Date: Jan 2019
Posts: 11
Do any of the new HDR settings on the test builds have a significant impact on performance to be aware of? Thanks for the help.
Drybonz is offline   Reply With Quote
Old 1st May 2024, 19:35   #64729  |  Link
kasper93
MPC-HC Developer
 
Join Date: May 2010
Location: Poland
Posts: 591
Quote:
Originally Posted by huhn View Post
figured out that it can't do an YCbCr-> RGB conversation correctly
really? 🤯
Quote:
Originally Posted by huhn View Post
ignores interlaced flags because the flag could be wrong...
Code:
deinterlace=auto
kasper93 is offline   Reply With Quote
Old 1st May 2024, 20:38   #64730  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,998
and did you get it in as default?

and yes mpv is doing conversation wrong haasn could not find out why but he is looking.

try ire 30.

edit: i actually wanted to check the new release if it got fixed but i forgot that limited range is also broken making this a pain to check...
https://i.ibb.co/VNxxCGN/limited-range-bug.png

and because i'm a bitter idiot of man child :-)
mpv let's write and usely and objectively wrong meta data that is not supposed to be used according to the spec:
https://ibb.co/j3brRK9
mpv ladies and gentle man defiantly the same image. this is not the ycbcr RGB bug.

i do the conversation bug test later if you care i need to remember how to work around bug/limitations to do that easily.

Last edited by huhn; 1st May 2024 at 21:23.
huhn is offline   Reply With Quote
Old 2nd May 2024, 00:11   #64731  |  Link
ashlar42
Registered User
 
Join Date: Jun 2007
Posts: 659
Quote:
Originally Posted by tp4tissue View Post
They already reported that the color grading for that scene was a mistake.

It was not intentional, some one dropped the ball.
Don't think so... https://www.ign.com/articles/2019/06...ll-was-so-dark
__________________
LG 77C1 - Denon AVC-X3800H - Windows 10 Pro 22H2 - Kodi DSPlayer (LAV Filters, xySubFilter, madVR, Sanear) - RTX 4070 - Ryzen 5 3600 - 16GB RAM
ashlar42 is offline   Reply With Quote
Old 2nd May 2024, 01:38   #64732  |  Link
oneonefive
Guest
 
Posts: n/a
Quote:
Originally Posted by huhn View Post
and did you get it in as default?

and yes mpv is doing conversation wrong haasn could not find out why but he is looking.

try ire 30.

edit: i actually wanted to check the new release if it got fixed but i forgot that limited range is also broken making this a pain to check...
https://i.ibb.co/VNxxCGN/limited-range-bug.png

and because i'm a bitter idiot of man child :-)
mpv let's write and usely and objectively wrong meta data that is not supposed to be used according to the spec:
https://ibb.co/j3brRK9
mpv ladies and gentle man defiantly the same image. this is not the ycbcr RGB bug.

i do the conversation bug test later if you care i need to remember how to work around bug/limitations to do that easily.
You were told many times over why mpv's behavior is actually correct. Quit speaking in bad faith and spreading misinformation.
  Reply With Quote
Old 2nd May 2024, 02:32   #64733  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,998
yes yes misinformation what else.
that why GPU does it correctly... (it doesn't but is much better)

it's the windows photo app that got it wrong, the bt 709 spec and GPU does it wrong right?
and clipping btb and wtw when a pixel is scaled is also not an issue but showing it when no scaling is done is also correct.
huhn is offline   Reply With Quote
Old 2nd May 2024, 03:15   #64734  |  Link
kasper93
MPC-HC Developer
 
Join Date: May 2010
Location: Poland
Posts: 591
Try reporting one issue and don't mix unrelated topics. It will be a lot easier to follow up on that. Screenshots are broken. It depends what you expect of them, but depending on your target options you will get different result, need to configure correctly. It is quite low priority as it really doesn't affect playback, which is what you should care about. If you want raw screenshot of video, use ffmpeg.
kasper93 is offline   Reply With Quote
Old 2nd May 2024, 04:56   #64735  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,998
the report is very short and have no unrelated information. it's just getting derailed after that by what's the words limited knowledge about the basic of calibration. just check it yourself...

like telling me with screenshot-tag-colorspace=no that it converts to sRGB it doesn't... the tone curve is untouched.

with madVR no matter what i do the screenshoot will give me the image i see at the time i took the screen shoot. well every renderer does.

BTW. any other calibrator in this thread that can "confirm" to me that BT 1886 is approximated 1.961?
huhn is offline   Reply With Quote
Old 2nd May 2024, 09:59   #64736  |  Link
kasper93
MPC-HC Developer
 
Join Date: May 2010
Location: Poland
Posts: 591
Quote:
Originally Posted by huhn View Post
with madVR no matter what i do the screenshoot will give me the image i see at the time i took the screen shoot. well every renderer does.
So you want rendered image dumped as-is to png without tagging or tagged as sRGB without conversion? Screenshot function is designed to produce tagged file which can be used to reproduce the image as it were intended to be viewed on different setups. It does not save image that is correct only on your display as some sort of "calibration tool", it is screenshot of video, not your display.

Imagine this simplified example:

video-csp -(renderer)> target-csp-a -(save)> png (tagged with target-csp) -(load)> image-csp -(renderer)> target-csp-b

Note that video-csp and image-csp may not be the same. But they both will correctly be converted to target-csp to produce the same image. If target-csp-a == target-csp-b, it would be the same output. Note that this is simplified and the round-trip is not always perfect, but this is how it suppose to work. And of course need a image viewer to correctly converts image-csp to your target display.

What you seem to want is mistagged screenshot as sRGB to view the difference between target-csp-a rendering:

video-csp -(renderer)> target-csp-a -(save)> png (tagged with sRGB) -(load)> sRGB -(renderer)> target-csp-b

Note that this is not valid way to do screenshot and if you want that, just use Print Screen key.

Quote:
Originally Posted by huhn View Post
the report is very short and have no unrelated information. it's just getting derailed after that by what's the words limited knowledge about the basic of calibration. just check it yourself...
I have limited time to invent bugs and reports myself. If you want me to work on something, I need exact steps to reproduce invalid result and valid results, with command line, images... If the limited knowledge of mpv developers is the problem, try not to argue the details, just argue the results and if you proof that the result image is wrong it will be easier to deep dive to dissect the issue, even with limited knowledge about the basic calibration.
kasper93 is offline   Reply With Quote
Old 2nd May 2024, 13:28   #64737  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,998
Quote:
Originally Posted by kasper93 View Post
So you want rendered image dumped as-is to png without tagging or tagged as sRGB without conversion? Screenshot function is designed to produce tagged file which can be used to reproduce the image as it were intended to be viewed on different setups. It does not save image that is correct only on your display as some sort of "calibration tool", it is screenshot of video, not your display.

Imagine this simplified example:

video-csp -(renderer)> target-csp-a -(save)> png (tagged with target-csp) -(load)> image-csp -(renderer)> target-csp-b

Note that video-csp and image-csp may not be the same. But they both will correctly be converted to target-csp to produce the same image. If target-csp-a == target-csp-b, it would be the same output. Note that this is simplified and the round-trip is not always perfect, but this is how it suppose to work. And of course need a image viewer to correctly converts image-csp to your target display.

What you seem to want is mistagged screenshot as sRGB to view the difference between target-csp-a rendering:

video-csp -(renderer)> target-csp-a -(save)> png (tagged with sRGB) -(load)> sRGB -(renderer)> target-csp-b

Note that this is not valid way to do screenshot and if you want that, just use Print Screen key.



I have limited time to invent bugs and reports myself. If you want me to work on something, I need exact steps to reproduce invalid result and valid results, with command line, images... If the limited knowledge of mpv developers is the problem, try not to argue the details, just argue the results and if you proof that the result image is wrong it will be easier to deep dive to dissect the issue, even with limited knowledge about the basic calibration.
don't waste your time on this.
actually in the example case the current gamma would be blank because you have no clue what it is.

--target-trc= is provided and you add that that's ok. you will get wrong results but mpv did nothing technically wrong.
but for bt 1886 mpv writes a total none sense number the bt 709 spec tells you is not used in production it is not an eotf and on top of that it writes the absolute correct advanced meta data that it is bt 1886 meaning it could be everything. but you also have to stop added bt 1886 if it is not the --target-trc= and no black is defined (i get to that later).

bt1886 is not 1.961 the only gamma curve it has is 2.4 and the rest is a mess between 1.0 and 2.4 at the same time. ignoring HDR SDR conversation... which is total mess. ok not really because if the black was not 0 then the output is not bt 1886 it is s specific curve of bt 1886 which need the black point to be reversible but that doesn't mean the image is bt 1886.

the next issue is windows only. Microsoft is sRGB it thinks every thing is sRGB and that is in theory changeable but not in practice yet.
if you let windows convert SDR to HDR it will think the SDR is sRGB.
i'm not here to make that your problem.

so yes if you don't know don't write something in that will definitely create a wrong result. to calibrate to bt 709 gamma i have do quite some insane stuff. because why would a calibration software like displaycal even provide me with a preset of something that isn't even used and is not bt 1886.

and that was now exactly what you don't want me to do.
i never learn.

TDLR;
this is what you want me to do?:
https://i.ibb.co/R61V8Zh/child-way.png
mpv.exe --no-config --vo=gpu-next
(not really what i used but close enough)

the gamma value is a fallback with bt 1886 advanced meta data you can write nothing which will work just fine with modern image viewer or something around ~2.2 is technically not correct because bt 1886 does have a gamma fixed gamma it is different on displays if the CR is different but the send image is 100% the same it's 2.4.

well i forgot the logs. which i'm supposed to provide even with a meta question where mpv isn't been used yet.

well have a nice day.
i actually don't want you to do anything i just don't want to argue that bt 1886 is 1.961. that's all.
huhn is offline   Reply With Quote
Old 2nd May 2024, 16:37   #64738  |  Link
kasper93
MPC-HC Developer
 
Join Date: May 2010
Location: Poland
Posts: 591
Quote:
Originally Posted by huhn View Post
don't waste your time on this.
actually in the example case the current gamma would be blank because you have no clue what it is.
I'll be honest I was your last hope. I haven't look at the issue yet. I know there were some previous discussion, but I haven't followed it. And generally I like digging into some "weird" problems. I also know that screenshots have some limitations, I wanted to look at eventually. But if you say no need to work on this. I won't bother.

Last edited by kasper93; 2nd May 2024 at 16:40.
kasper93 is offline   Reply With Quote
Old 2nd May 2024, 17:11   #64739  |  Link
tp4tissue
Registered User
 
tp4tissue's Avatar
 
Join Date: May 2013
Posts: 753
Quote:
Originally Posted by huhn View Post
the report is very short and have no unrelated information. it's just getting derailed after that by what's the words limited knowledge about the basic of calibration. just check it yourself...

like telling me with screenshot-tag-colorspace=no that it converts to sRGB it doesn't... the tone curve is untouched.

with madVR no matter what i do the screenshoot will give me the image i see at the time i took the screen shoot. well every renderer does.

BTW. any other calibrator in this thread that can "confirm" to me that BT 1886 is approximated 1.961?
I'm confused by the back and forth huhn,

What exactly is being done wrong? Is it the color space or the gamma tracking?

My colorimeter measurements and gamma test slides seems to check out fine for SDR and HDR. I am under windows 10, tested with both nvidia and amd gpus using madvr+mpchc.
__________________
Ghetto | 2500k 5Ghz
tp4tissue is offline   Reply With Quote
Old 2nd May 2024, 21:01   #64740  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,998
Quote:
Originally Posted by tp4tissue View Post
I'm confused by the back and forth huhn,

What exactly is being done wrong? Is it the color space or the gamma tracking?

My colorimeter measurements and gamma test slides seems to check out fine for SDR and HDR. I am under windows 10, tested with both nvidia and amd gpus using madvr+mpchc.
that's about mpv GPU-next. if you play a bt 709 file and make a screenshoot it will write at least to types of meta data for gamma.
a gamma number where they choice 1.961 for bt 1886. and a newer information that just says bt 1886. every image viewer that takes the new bt 1886 meta data will be fine it pretty much means do nothing. programs like windows photo app will use the old meta data and screws the image up.

what is any program supposed to do with that gamma... except mess the image up?

reason for that is mpv uses the encode function of bt 709 for bt 1886 as a decode function. don't ask me why bt 709-6 is clear that is it not used in production and it has nothing to do with bt 1886.

move on.
about color issue mpv gpu-next adds a green tint to a gray scale the brightness is also wrong.
this has not been retested by me in month.
huhn is offline   Reply With Quote
Reply

Tags
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 04:27.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.