New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dolby Vision with wrong colors #7326
Comments
reminds me a bit of #4340, though it isn't the same issue. |
There's little we can do here because Dolby Vision is a closed spec. There's a branch that sort of generates the approximate result, but not for all files, and not quite correctly. The specifics of the encoding depends on proprietary metadata which we haven't managed to decode / reverse engineer yet. |
Ah, ok so it's going to be hit and miss whether a video will play, correctly. Am I to understand that you guys are actually working on it? |
It would be hit or miss on whether a video will play "vaguely watcheable but obviously wrong" or "completely and utterly wrong". I'm not actively working on it, no. Unless any progress is made on reverse engineering the proprietary dolby vision metadata. If you want to help you could gather sample clips that fall into different "categories" (not all profile 5 media has the same kind of color shift) and seeing what parts of the dolby black box metadata changes in response. That might help pinpointing where in the metadata the color space info is. |
Well, the first comparative examples I can give, are: Correct colorhttps://www.demolandia.net/downloads.html?id=1039472921 Incorrect colorhttps://www.demolandia.net/downloads.html?id=543675873 I don't know if that is useful, but there does appear to be a disparity in the HDR format. Note the BL+RPU and BL+EL+RPU. I have no idea what difference the 'EL' makes. Of the samples I have, the files that have incorrect color, don't have that 'EL'. |
OK, I grabbed more DV samples. The pattern, holds. All of the videos that don't have that 'EL', don't play correctly. |
I just wanted to say: FUCK Dolby and their racketeering-like patent trolling. Fuck them for re-introducing proprietary bullshit into modern video technology too. I wish they'd fucking die already. |
Well yeah, there's that lol. I kind of agree. Proprietary 'secret sauce' stuff is a bit nonsensical. |
Stream dumping video from here, the videos that play correctly have HDR10 metadata, included. So, obviously they will play correctly. The ones that don't play correctly, also don't have 'EL' in the HDR format. |
@ValZapod ITU-R ICtCp != Dolby Vision IPT |
@ValZapod Dolby Vision Profile 5 is not standard ICtCp. Dolby made sure you cannot just implement a standard thing they published, and get their newest marketing buzzword implemented. With regards to link, fun. Esp. the part about non-thread-safeness. Might be worth checking since it does contain references to reshaping. Some research was done earlier into this stuff https://code.videolan.org/videolan/libplacebo/commit/f850fa2839f9b679092e721068a57b0404608bdc , which lead to semi-OK results, but also weird switches at certain frames. A la https://0x0.st/zIBI.png → https://0x0.st/zIBl.png |
We're not missing the cross-talk matrix. We just bake it into the IPT coefficient matrix. (e.g. standard ITU-R ICtCp has a crosstalk of But yes, we're missing the polynomial reshaping bits. That's the stuff that there's no public documentation for, especially for the exact bitstream. (Though there is that one patent which provides an example bitstream that doesn't appear to match reality? Unless I'm mistaken) If you can figure out how to get these coefficients into the decoding pipeline somehow (e.g. as side data) we can implement the polynomial bits with relative ease. |
Sure it is not. It was the basis for ICtCp. Dolby did good work at researching the color spaces but ICtCp adds the last bit - optimise the space so it better fits into the T/P range so all code points are fully utilised for BT2020 color space source.
Looking at how specs are evolving it rather seems they simply released raw unfinished product, which was not acceptable to put into standards.
Thanks :) The part about thread safety is probably outdated already and just left there undeleted from my first experiments on composing a DVp5 compatible file. :)
I done mine back in 2018 and found pretty much information about the DVp5 internals (which on large part is identical to DVp7, which is pretty well documented in patents). The hardest part was the IPTPQc2 color space (which took a ~two months just to find out it's (semi-official) name so further docs could be found which specified the crosstalk and reshaping matrixes that were not embedded into the RGB to LMS matrix same way as is done with ICtCp). I am doing DVp5 not for purpuses of decoding but for encoding (creating test patterns). But problems I face are exactly the same as the process is exact reverse. The progress so far... it is not ideal, I still miss a point on why encoded video look undersaturated on the TV. One guess about why is that the data is assumed to cover BT2020 color space and the TV is more like P3... And contrary to other DV formats DVp5 carries no data about mastering display color space so TV can't decide where to compress and where just trim. Still, the colours are right and I don't see any shifts (except of lowering saturation) on several ColorChecker patterns. So, in this sense my code is more correct then, so is worth checking and comparing approaches. |
Please refrain from comments that could be interpreted as extremely offensive. |
Ebner & Fairchild IPT is not the Dolby IPTPQc2 either. Dolby adopted the way IPT is composed but over a PQ transfer function which in the end is completely different color space designed for different objectives (or just more objectives than was in the original). Here is the patent from Dolby: |
Actually it matches the reality pretty well. This patent specs profile 7 (used on BD discs). But with two tiny additions it matches also profile 5 (used in streaming). Those additions are: |
Fantastic work on digging all of that up. I'm sure we can benefit greatly from your work. I'm a bit preoccupied by life events these days so I don't have the energy left over to look into it, but I've cloned all the code just in case. |
We inherently support dynamic metadata because our shaders are "re-generated" every code based on the metadata attached to each individual frame. (Although we might want to double check that we don't trigger unnecessary shader recompilation as a result of changes to static HDR metadata). So it depends entirely on how fast libavcodec updates the side data. Which, as of when I last looked at this code, gets cached and re-sent per frame. We don't support DTM at all. Patches welcome. (Especially with regards to making sure this information is exposed as avframe side data) |
This is the actual data in the RPU of Dolby Vision profile 5 files. The number in patent seem to be (deliberately or not) an error. I've found a lot of such errors in many published pre-calculated matrixes, even in some ITU recommendations. Some of them are just numerical errors due to calculating them in low precision floating points, some of them are typos when transferring the data. This is why I always try to find from what data the matrix is derived and calculate values myself. |
@ValZapod We are software, not hardware. HDMI standards are irrelevant here, unless you care about metadata passthrough (I don't).
No. We intentionally clip incoming signals to the nominal peak, because not all gamma curves are well-defined outside the interval ITU-R standards seem to "allow" it, but they don't describe under which circumstances it would be useful for content production. My understanding is that the display of these value ranges are reserved for signal level calibration purposes, and I don't think that's a use case that really applies to us. @igorzep There's some room for interpretation of whether or not we should use the rounded or "exact" values of constants from standards, given that what matters is not the "theoretical" number but the number that will be used during production. |
Hi guys I've been following this thread from a couple of days, I've been doing some testing regarding the decode process involving a dolby vision profile 5 video. which does not involve NLQ as you mention previously since those videos does not contain EL (Enhancement layer) as far as my understanding. My problem is that I'm kinda confused as for the reshaping process of the stream. My understanding is that once you retrieve the data from the YUV 420 you should reshape the values using the polynomial coefficients in order to retrieve the IPT values as part of a pre-processing process before applying the dolby's proprietary color space conversion matrix (IPT -> LSM -> .... ->RGB) described in the patent to retrieve the "original image" (without the metadata applied). So I don't know if this assumption is correct or I missing something, I just wanted to check with you guys if you could clear those doubts to me since I've been trying to decode some DV5 demo videos unsuccessfully. I know this is kinda random but i wanted to know if you guys could help me out clearing out those questions. Thanks in advance. |
The reshaping part with polynomials is simple. Also look here how I encode it: param.poly_order_minus1 = 0; // first order when decoding take the number of coefficients in array according to the order, they will be Which polynomial is to apply is defined by pivot points. When you decode fragments by pivots as a verification you can visualise it - should get a smooth curve as the result. |
I don't know if this is helpful, but this guy appears to have done it. I installed the add-on and it works. |
@ValZapod at very least we should be able to test output with the sample files - thanks! |
@igorzep Thanks for the information, I had great advance based on your comments. Still I was checking the information related to IPTPQ_YCCtoLMS_coef, but still I cannot understand how they're calculated, based on my decode process for DV5 videos, those coefficients are dynamically generated among the metadata, but still I don't know if you have an idea about if those mean to be the ones to perform linear LMS to XYZ or RGB? any information would be appreciated. Thanks in advance. At this point I can retrieve the pivots and retrieve the IPT code based on the pivot's segment polynomial now for my understanding, I substract the YCCtoRGB_offset values and then I apply the IPT2LMS matrix and then apply the PQ transfer function, but after that is where I don't get how the LMS should be converted back to RGB, One of the dolby vision patents provides a matrix for LMS2XYZ but as I said earlier when decoding frames metadata, RGBroLMS_coef seems to be different for frame/scene. My process at the moment would be Substract YCCtoRGB_offset from IPT respectively Apply YCC2RGB(IPT2LMS) matrix apply PQ transfer function to retrieve L' M' S' Apply new matrix based on RGBtoLMS_coef? |
No idea how such an interface would look to begin with, and I am much more into getting proper handling of this color space as opposed to enabling playback for those whose displays happen to have this feature enabled. Given that the thing left was to decode those not-in-spec type 62 NAL units with the dynamic parameters and stick them in, I'd say this would be very much possible. |
Has there been any development on deciphering the metadata? |
I agree, I was trying to watch a movie a friend of mine is working on. It was, for some godawful reason, encoded in Atmos DV HEVC format and it is just horribly purple-green BS. Takes me hours to get this damn format to play with the correct colors. Why even do this? WHO NEEDS IT? I don't remember ever asking for more than we already have, in video quality-land. |
ValZapod, |
Yeah, indeed, this is supported now with |
For context, I can confirm this works on the
Thanks for the work here on this, if I'm seeing this correctly, |
So? I was listing the full spec.
Except it isn't, I came here because it does not show correct colors.
Again: Why all the effort? Aren't we at the limit for video quality, as far as demand goes? I don't see any demand for higher res or larger (or better compressed) color space with anyone I know. |
It's already fixed. You need to update mpv and learn how to configure for tone mapping DV. Or wait until the full implementation is in place. |
I can confirm that this is fixed now - works for me great with latest mpv build, no more green & purple colors on DV content I have. |
Sir, this is a |
I'm gonna go ahead and thank the developer for his great work. Thank you @haasn |
I'd like to thank everyone involved for their work on this! Is it possible to combine this with tone mapping?
with
(or any other algorithm) tone mapping doesn't happen. Do I have to set tone mapping parameters manually somehow until this is fully supported? |
It should support tone mapping if you have an up to date mpv. That was added around ~2 weeks ago in libplacebo. |
I'm using the |
ValZapod, |
@ValZapod I already enabled HDR mode in Windows 10. Thank you |
Is this fixed on Linux yet or just Windows? |
It is fixed on all platforms (that run |
Hello, I am new here and I am not very knowledgeable about this stuff but I enjoy learning. Currently I am trying to play DV video and I am having the green red hue problem. What I am seeking to know is how to set up mpv player. I already have ffmpeg installed but am unclear about libplacebo. I am using Windows 10. I am having trouble understanding "vo=gpu-next" as to what it is and how to 'enter' it. Sorry if this is something that has been answered and I am missing it or is being asked in the wrong place. I am not the swiftest cat with forums. I can follow instructions but I am a noob with a lot of this. Thanks anyone who can help. |
Using prompt go inside the folder where the |
Can ffmpeg convert DV to HDR/SDR now? |
Yes, see https://ffmpeg.org/ffmpeg-filters.html#Examples-90 It is done automatically by the |
How would one be able to use it within macOS then?
|
how can I play hdr files on macOS Apple Silicon, I've compiled mpv myself, it does recognise the file as hdr and shows proper colors to use 2020-ncl*, but it just doesnt look as bright/colorful(maybe), like the same video played over safari, it's a lg oled video https://youtu.be/njX2bu-_Vw4 |
I have the following versions installed:
And I have set edit: it's weird how it affects certain parts of the image and not others (depends on scene). but gpu-next certanly looks better then for example XV: |
mpv version and platform
Windows 10
Reproduction steps
Play some Dolby Vision videos. Not all videos play this way, and I tested with and without an mpv.conf. Same result.
Expected behavior
Play with correct color
Actual behavior
Picture plays in purple and green
Log file
Portable mpv log.txt
Sample files
Can be found, here
The text was updated successfully, but these errors were encountered: