Hello, thank you for the response

• I built it using macports: sudo port install mpv
• mpv 0.38.0.
• I don't know if I'm using gnu-next, I'm using the default settings, I'm testing IINA because I want to use HDR later, I can't get HDR to work on MPV.
• no change when invoking mpv using --vo=libmpv.
• It's not HDR, so it's probably SDR, it's HEVC 10bit x265

I changed IINA settings, but I got the same results.
It's the same with the nightly 1.3.5 Build 141, It's still different from MPV.

I don't know if only I have this problem, or others will see the difference when they open MPV and IINA side to side with the same content

I downloaded IINA from iina.io, I didn't use macports.

IINA

MPV

To be honest, I'm not sure if it's the colors, gamma, contrast, or other parameter that causes a difference in image output

I’m experiencing a similar issue: VLC appears to have more vibrant colors compared to IINA, tried the recommended fix
Hardware decoder setting select Disabled
Uncheck the Load ICC profile setting

but its still persist, what to do? @low-batt

@Pseud0n1nja For audio/video processing IINA uses libmpv. This means for video problems IINA developers need to know if the same problem reproduces with the mpv player. If it does then the problem has to be reported to the mpv project. They will need to fix the problem. Then IINA will need to upgrade the version of libmpv IINA uses. If the problem does not reproduce with the current version of mpv then it could be that IINA is behind and needs to upgrade libmpv, or it could be a problem in the small amount of code in IINA that is involved in video processing.

This long discussion did uncover one such problem in IINA. See issue #5124. That problem will be fixed in the next release of IINA. We are currently struggling to fix the last couple of problems before releasing a beta.

Not clear from your description of the problem if the fix will address the problem you are experiencing. First step would be to try the current mpv player with no options and with adding --vo=libmpv. See discussion in #5124 about that.

Color is a very complex topic. When you peek behind the scenes you find many different digital encodings. Usually to investigate a color problem a sample of the video is required.

hi, thank you. I will make sure to send the log files when I can

Couldn't hurt, but I might not need them. I'm currently comparing log files from my test below and seeing some unexpected differences. Trying to track down what is causing them.

As you noted, by default mpv does not set any ICC color profile, which might explain one part of the variance. There is also the --cocoa-cb-output-csp output option that was recently added, but by default this is set to the display's color space which should be the default of a CALAyer.

Difference between mpv with/without --vo=libmpv is interesting, I wonder if moltenvk is somehow automatically creating an HDR colorspace? But this doesn't make sense this by default mpv should be tone-mapping HDR down to gamma 2.2.

Thanks for noticing this one! I was going to ask you about the difference with --vo=libmpv. I'm testing against mpv 0.38.0, not master. Seems cocoa-cb-output-csp was added after 0.38.0.

I too was wondering whether MoltenVK was enabling EDR or something like that. But I'm testing with a Apple/LG 5K UltraFine external monitor. It is a really nice monitor, but is not HDR capable.

20:57:02.271 [window0][d] window!.screen: "LG UltraFine" visible frame (0.0, 46.0, 2560.0, 1369.0) EDR: {supports=false maxPotential=1.0 maxCurrent=1.0}

I have been comparing the mpv log file generated by IINA to the log file generated by mpv when using --vo=libmpv. If you compare these two log clips in a diff program like Meld you can see IINA has a uniform sampler2D lut; entry near the start that mpv does not. Then there is a bigger section of differences also lut related.
Any guess as to what IINA is doing to cause this to be added?
iina-shader.log
mpv-shader.log

But I'm testing with a Apple/LG 5K UltraFine external monitor. It is a really nice monitor, but is not HDR capable.

With osx, all displays are EDR capable. If display does not natively do HDR, it is simulated by dynamically reducing the nits of SDR content. See https://prolost.com/blog/edr

diff

That highlighted shader appears to be the shader for 2D ortho upscaling/downscaling. I.e. using one of the scalars here https://mpv.io/manual/master/#options-scale other than ewa* and bilinear. The choice of vo should not affect this, perhaps the windows were different sizes and this causes one of them to be upscaled but not the other? If you use --scale=bilinear for both that should force naive bilinear scaling.

On this:

all displays are EDR capable

Definitely not true. From the documentation for NSScreen.maximumPotentialExtendedDynamicRangeColorComponentValue:

If this property is greater than 1.0, the screen supports EDR values. If the screen doesn't support EDR values, the value is 1.0.

In the log message above macPotential is this NSScreen value and as it is 1.0, thus this UltraFine monitor does not support EDR. I've not been able to figure out what it is that makes macOS decide a display is not EDR capable.

That is a good blog post.

On the scaling, I believe you nailed it. IINA zooms the window into place. I am probably comparing the wrong part of the IINA log. I will take another look.

Interesting, you are right! It is not well-documented, but it seems that there is indeed an assumption the pointer being passed is allocated via talloc. You can see in lcms.c that the the (pointer, length) from the param call is cast back into a bstr and is used as an argument to talloc_free and talloc_steal.

This seems like an mpv issue, the proper interface would be for mpv to accept a (pointer, length) pair and internally copy it to bstr. This would also avoid the issue of ownership.

Sorry meant this line: https://github.com/mpv-player/mpv/blob/master/video/out/gpu/libmpv_gpu.c#L109-L110

There should be a copy there instead of casting the input to bstr directly, since mpv should not make the assumption the input pointer was allocated via talloc.

Thanks for the confirmation I was not confused. I will report this to mpv.

I reported this to mpv. They already posted a proposed fix that calls bstrdup instead of casting the input to bstr as you indicated should be done.

Side note: I found that "Life Untouched" was not the best video to test with. I found that using an HEVC HDR video shot on an iPhone under low lighting can be a lot more obvious.

I made this test video:

Screenshot of results:

From left to right: IINA 1.3.5 (HDR off), mpv 0.38 with default settings, IINA develop (HDR off)

I'd be wary of using Quicktime as the reference because it uses a non-standard decode gamma for video tagged at bt709 ( SDR). Not sure how it behaves for HDR though.

I was just using QuickTime as a subjective point of reference, since presumably it's been best optimized to display color on Apple-branded hardware. I suppose it's out of scope entirely per this thread's title 😂

For the above screenshot with HDR content, I couldn't capture the QuickTime result accurately (I don't know if it's even possible to disable HDR in QuickTime), but the results above show an HDR video which has been down-mapped to SDR, and mpv 0.38 seems to do less well than previous versions in this regard.

I am finishing up a PR and then I will be turning my attention to this. The IINA code that configures the view layer is missing changes that mpv has made. This definitely accounts for some of the color differences.

I am now focused on this. I will be posting in #5124, the issue that was created for this.

@svobs Thanks for the help! I definitely need help with this one.

Of the 3 screenshots posted above, which one looks like it does in real life? Does the wood look redish? Or is it more brown looking like the screenshot on the left?

I believe I now have IINA matching up with mpv 0.38.0 with --vo=libmpv when playing the video taken on the phone.

The disadvantage of this video as a test is that it uses Dolby Vision as seen in the output from mediainfo below. Dolby Vision is listed in New features only supported by GPU Next. Need to find some other videos for testing.

low-batt@gag discussion-5109$ mediainfo 357682278-2d7aca13-11fd-4c89-8210-cc43a5dc45bb.qt
General
Complete name                            : 357682278-2d7aca13-11fd-4c89-8210-cc43a5dc45bb.qt
Format                                   : MPEG-4
Format profile                           : QuickTime
Codec ID                                 : qt   0000.00 (qt  )
File size                                : 2.77 MiB
Duration                                 : 2 s 667 ms
Overall bit rate mode                    : Variable
Overall bit rate                         : 8 719 kb/s
Frame rate                               : 30.000 FPS
Encoded date                             : 2024-08-14 04:44:11 UTC
Tagged date                              : 2024-08-14 04:44:11 UTC
Writing library                          : Apple QuickTime
com.apple.quicktime.location.accuracy.ho : 4.578440
com.apple.quicktime.make                 : Apple
com.apple.quicktime.model                : iPhone 13 Pro Max
com.apple.quicktime.software             : 17.6.1
com.apple.quicktime.creationdate         : 2024-08-13T21:40:20-0700
FileExtension_Invalid                    : braw mov mp4 m4v m4a m4b m4p m4r 3ga 3gpa 3gpp 3gp 3gpp2 3g2 k3g jpm jpx mqv ismv isma ismt f4a f4b f4v

Video
ID                                       : 1
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main 10@L4@Main
HDR format                               : Dolby Vision, Version 1.0, Profile 8.4, dvhe.08.04, BL+RPU, no metadata compression, HLG compatible
Codec ID                                 : hvc1
Codec ID/Info                            : High Efficiency Video Coding
Duration                                 : 2 s 667 ms
Bit rate                                 : 8 553 kb/s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Rotation                                 : 90°
Frame rate mode                          : Constant
Frame rate                               : 30.000 FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 10 bits
Bits/(Pixel*Frame)                       : 0.137
Stream size                              : 2.72 MiB (98%)
Title                                    : Core Media Video
Encoded date                             : 2024-08-14 04:44:11 UTC
Tagged date                              : 2024-08-14 04:44:11 UTC
Color range                              : Limited
Color primaries                          : BT.2020
Transfer characteristics                 : HLG
Matrix coefficients                      : BT.2020 non-constant
Metas                                    : 3,4
Codec configuration box                  : hvcC+dvvC

Audio
ID                                       : 2
Format                                   : AAC LC
Format/Info                              : Advanced Audio Codec Low Complexity
Codec ID                                 : mp4a-40-2
Duration                                 : 2 s 665 ms
Source duration                          : 2 s 717 ms
Bit rate mode                            : Variable
Bit rate                                 : 149 kb/s
Channel(s)                               : 2 channels
Channel layout                           : L R
Sampling rate                            : 44.1 kHz
Frame rate                               : 43.066 FPS (1024 SPF)
Compression mode                         : Lossy
Stream size                              : 48.4 KiB (2%)
Source stream size                       : 49.0 KiB (2%)
Title                                    : Core Media Audio
Encoded date                             : 2024-08-14 04:44:11 UTC
Tagged date                              : 2024-08-14 04:44:11 UTC

Other #1
ID                                       : 3
Type                                     : meta
Format                                   : mebx
Codec ID                                 : mebx
Duration                                 : 2 s 667 ms
Title                                    : Core Media Metadata
Encoded date                             : 2024-08-14 04:44:11 UTC
Tagged date                              : 2024-08-14 04:44:11 UTC

Other #2
ID                                       : 4
Type                                     : meta
Format                                   : mebx
Codec ID                                 : mebx
Duration                                 : 2 s 667 ms
Title                                    : Core Media Metadata
Encoded date                             : 2024-08-14 04:44:11 UTC
Tagged date                              : 2024-08-14 04:44:11 UTC


low-batt@gag discussion-5109$ 

Of the 3 screenshots posted above, which one looks like it does in real life? Does the wood look redish? Or is it more brown looking like the screenshot on the left?

The picture on the left is closest to correct:

• The bowl is a glossy ceramic, sort of moss green judging by this chart.
• The wood has a light stain which gives it a golden brown hue.
• The crumpled paper bag is just a very common brown paper bag.
• The paint on the wall behind the panels is also a shade of green, but lighter than the bowl. Using the chart linked to above, closest to "pistachio" when well-lit, but will look closer to "sage" with the video's lighting conditions.

The disadvantage of this video as a test is that it uses Dolby Vision as seen in the output from mediainfo below. Dolby Vision is listed in New features only supported by GPU Next. Need to find some other videos for testing.

That may be true with regard to proper display of Dolby Vision, but in this case it is down-mapping (pardon my wording because
I don't know the correct term) from HDR to SDR. Previously it was making sane color choices and the results looked okay, but I worry there is a regression somewhere.

EDIT: Discussion continued below.

This resulted in a huge color difference, I guess what went wrong, a color correction can produce such a big color difference?

As krackers says, quicktime's color is all wrong, and this thinks 2.4 gama is 1.95 gamma, but I'm still not sure why firefix is the same as quicktime. I also just learned that ICC is related to color space, so turning on ICC avoids mac color conversion?

1.96 gamma actually, anything that uses AVFoundation uses that gamma. Probably either firefox explicitly uses AVFoundation or they decided to emulate this gamma.

@rainlycoris Oh no! You mentioned ICC profiles. Noooo! Now we have to discuss them.

The documentation for the mpv icc-profile option says:

--icc-profile=<file>
Load an ICC profile and use it to transform video RGB to screen output. Needs LittleCMS 2 support compiled in. This option overrides the --target-prim, --target-trc and --icc-profile-auto options.

Thus you must use this option for mpv to use an ICC profile. Or you can use the option icc-profile-auto:

--icc-profile-auto
Automatically select the ICC display profile currently specified by the display settings of the operating system.
…
Applications using libmpv with the render API need to provide the ICC profile via MPV_RENDER_PARAM_ICC_PROFILE.

That last bit is important because it is another thing I was planning on fixing in IINA. IINA is missing code to set MPV_RENDER_PARAM_ICC_PROFILE. So --icc-profile-auto will not work with IINA. A minor problem as IINA has the Load ICC profile setting which is enabled by default. For my testing I disabled it to match up with mpv which is not using an ICC profile as I did not use either of the above options.

Last I heard, designers serious about color use a spectrophotometer, for example this one, to create an ICC profile specific to the individual display. You would then use the ColorSync Utility to install the profile. On newer models Apple has a concept of reference modes. The Pro Display XDR is individually calibrated:

Every display goes through our state-of-the-art color calibration. Each of the display’s 576 LEDs is also individually calibrated and has its light profile stored. An algorithm then uses this information to determine the exact light intensity at which each LED should be modulated to produce the best possible image.

This is all about making sure color matches across devices. But it also matters if we are comparing the output of different players.

In VLC settings if you go to the Video tab and then click on Show All and then navigate to Video/Output modules/Mac OS X you can see it is using Relative colorimetric for color conversion. For tone mapping it is using the Hable algorithm. Dithering is disabled. I am unclear on VLC's support for ICC profiles. I found information that they were working on adding it, but it seemed like that still needs to be completed.

QuickTime is color managed. The 1.96 gamma @krackers mentioned is discussed in Evaluating Video Using QuickTime Test Pattern Files:

AVFoundation uses a value of approximately 1.96 as the gamma of video (the gamma value without the boost required for classic dim surround viewing environments).

This comment speculates on why Apple might have chosen 1.96 gamma. There is a lot of discussion in the closed mpv issue Colour in mpv is dimmed compared to QuickTime Player. This comment discusses the debate about matching QuickTime behavior. I'm not clear on why that issue was closed. The referenced Little CMS slope limit PR mm2/Little-CMS#69 is still open.

Anyway to compare QuickTime Player to mpv I think you need to add the --icc-profile-auto option to mpv so they are both using color management.

compare quicktime player to mpv

You'll never get them to match up unless you also tell mpv to use 1.96 gamma to decode. Sadly there isn't an option to set this directly via --vf=format:gamma=gamma1.96 (the closest is 2.0), but you can kind of work around using --gamma-factor. And yeah those discussions you linked to are a huge rabbit-hole, but they contain excellent discussion and reverse engineering of the transfer function avfoundation really uses.

(My personal thought [but I don't know much about color management] is that 1.96 decode gamma is a bit too low for the "average" video, causing them to display "brighter" than they should be. Maybe it was ok decades back when LCD displays were poor quality compared to reference monitors and most videos people watched were explicitly mastered in a darkroom using reference displays, but these days with even basic LCD monitors having 1000:1 contrast ratio (compared to 2004 where apparently 300:1 was considered an achievement lifting shadows that much seems unnecessary. [Ironically if you go even older CRTs had "infinite" contrast ratio, but if you look at when the 1.96 gamma was introduced it was in snow leopard when the migration from CRT to LCD was near the tail end]. Additionally there is the argument that many non-professional videos (e.g. youtube) were simply edited on a bog-standard srgb monitor, so are most accurately displayed using srgb, and that Windows does not do any such color management so the average video is more likely to look "correct" when decoding with srgb vs 1.96. In fact I think even Chrome on osx does not use the 1.96 gamma since it implements its own video rendering pipeline.)

The two differences you're referring to are 10-bit backbuffer and setting wantsExtendedDynamicRangeContent to true, right?

I had not heard of mpv-macos-build. I like that it installs most of the needed dependences into its own homebrew directory.

For building mpv I am usually using mpv-build and specifying --jobs=10 to instruct meson to run the build in parallel where possible. This will cause all 10 CPUs on my M1 to hit 100%. I put the MacBook on a stand that has fans in it when doing builds as this is one of the few times I see the CPU temperature climb significantly.

For building mpv I am usually using mpv-build and specifying --jobs=10 to instruct meson to run the build in parallel where possible. This will cause all 10 CPUs on my M1 to hit 100%. I put the MacBook on a stand that has fans in it when doing builds as this is one of the few times I see the CPU temperature climb significantly.

Good to know, thanks. I did try mpv-build at first but switched to trying mpv-macos-build after encountered issues getting the dependencies correct. I ended up encountering the same issues, and solving them, in mpv-macos-build, so maybe now I will try mpv-build again since it is more configurable.

Nice! Are you going to report it to mpv, or do you want me to?

I'll be away from keyboard most of this weekend, so if you want to get things moving and take ownership of it, that would be great (feel free to reuse the video in part or in whole as desired). If not I can craft an issue for it next week.

Reported to mpv in mpv-player/mpv#14770.

Reported to mpv in mpv-player/mpv#14770.

@low-batt Thanks for filing, and also thanks for holding their feet to the fire to get it fixed for vo=libmpv. At last I was able to build a lib from the latest master & was able to confirm for myself that it is fixed.

I've merged the fix into the repo IINA uses for building libmpv. People are busy, but they will be building a new libmpv and pushing it to the server that hosts the dependencies when time permits.

since most of them do not respect MacOS color management like mpv does

mpv never respect MacOS color management because it does't use colorsync.

since most of them do not respect MacOS color management like mpv does

mpv never respect MacOS color management because it does't use colorsync.

@hooke007 you are correct.

After testing again, MPV does not respect MacOS color management.

The only video players I have found that do are QuickTime and Safari web player.

IINA does as well, but it's noticeably darker than QuickTime and Safari.

For audio/video and subtitle rendering IINA is using a library from the mpv project. IINA does play a small role with respects to video, but the vast majority of video processing is done by mpv. If IINA is working correctly and configured the same as mpv the picture should match. Thus if mpv looks too dark then IINA should look too dark as well.

However…

The situation has gotten a little more complex because mpv is working on a new generation renderer, gpu-next. Many color related fixes are only being added by mpv to the new renderer. Another test you should run is adding --vo=gpu-next when invoking mpv and see if the picture changes. Unfortunately GPU Next is not available yet to library clients such as IINA.

One difference between IINA and mpv is that the IINA setting Load ICC profile found on the Video/Audio tab of IINA's settings is enabled by default whereas mpv does not enable this by default. Try disabling that setting in IINA.

This discussion uncovered one color related problem in IINA causing a difference between IINA and mpv. That is discussed in issue #5124. That problem has been fixed and the fix will be included in IINA 1.4.0.

There are many mpv options that can be used to control color. Most of them can be applied to IINA. Using options it is possible to make the picture brighter. Lots of discussion about color can be found in the mpv project.

I was mistaken.

MPV does not have accurate colors on MacOS.

I use Safari web player and QuickTime as my source of truth in terms of color accuracy.

MPV is not color matched to them, but rather it's oversaturated. Meaning that MPV does not respect MacOS color management.

IINA is color matched to them (so it's accurate) but it's clearly darker than they are.

The "load ICC profile" makes no visible difference for me whether it's enabled or not.

IINA seems to be the most color accurate video player available for MacOS, but it still has the issue of being darker, which is a major issue when watching movies. Hoping that the fix you mention that was implemented in the new version of IINA solves it.

since most of them do not respect MacOS color management like mpv does

mpv never respect MacOS color management because it does't use colorsync.

@hooke007 you are correct.

After testing again, MPV does not respect MacOS color management.

The only video players I have found that do are QuickTime and Safari web player.

IINA does as well, but it's noticeably darker than QuickTime and Safari.

mpv use little-cms with its own gamma factor as color management method. You have to enable and tweaked it manually by some options to fit the colorsync's behaviour.

IINA enabled one of those options so it have the similar color as safari.

mpv's gpu/libmpv backend is always darker. Which is recorded as here mpv-player/mpv#4248 (comment) . And the related workaround is still on-ice in upstream mm2/Little-CMS#69

(I reviewed some comments in this thread, actually it was mentioned before #5109 (reply in thread))

In IINA 1.3.5 the Load ICC profile setting found on the Video/Audio tab of IINA's settings is enabled by default. When that setting is enabled IINA sets the mpv option icc-profile (icc-profile-auto in IINA 1.4.0) when playing a SDR video. To properly compare IINA to mpv when playing a SDR video you either have to disable the IINA setting or pass --icc-profile when invoking mpv.

With the latest version of mpv there are additional considerations when comparing IINA to mpv. See issue #5124 for a discussion of that. The fix for #5124 makes IINA match up with mpv --vo=libmpv for the video file shown in that issue.

Color is a complex topic. To investigate a color issue we need a video sample that exhibits the problem.

Issue #5124 contains screenshots showing the improvements mpv is making as a part of the GPU Next next generation renderer project. IINA has to wait for mpv to add support for the new renderer for libmpv clients before it can take advantage of these improvements.