Weird flashing on some movies

[rome1983]

https://forum.makemkv.com/forum/viewtopic.php?f=12&t=18602&start=8910#top

If scroll down to post 1561 reset_9999 has short video clip of the issue. Also noticed this on despicable me 3.

Thanks

[erazortt]

Well, so I looked into the sample of the transformes from the googledrive link in the thread you mentioned (this post: https://forum.makemkv.com/forum/viewtopic.php?p=140840&sid=228e1f47209e7fb7a127360f18246022#p140840).

First of all, please take a look at the el clip: https://drive.google.com/file/d/1XD1xWoAaaAlCceRgG7T_xI4zI7BToDBA/view?usp=drive_link This is the original el clip I extracted from the transformes clip, I have not messed around with it. See how it cycles through all the colors? I have never ever seen something like that before! This is not how its supposed to be looking. Based on this el clip, I actually don't even know how the resulting clip looks so sane.

Non the less, I tried to see what makes one frame look fine and one frame look bad. So I went and to debugging and looked at the dovi coefficiens. What I do see is that the MMR calculation yields a U component that is indeed way too high for these frames. However, I am relatively confident that this specific part of the code is sound. This can also be seen in the identically calculated V component at the same frame. For the night sky pixels it returns a very much expected value of 32767 which is exaclty at the half of the range, which for the U and V components means 0 signal. And for a very dark background, as seen in the sceene, this would be kind of the expected value, especially considering that the U and V compoents of the BL are also at 0 signal at that pixels.

So in conclusion, I am not saying that there couldn't be something wrong with my implementation, I could very well be. But considering the very broken look of the el clip already, I would think that this clip is not a good base for such conclusions. I would rather think that what is wrong is the original bitstream. And this is something which is not completely unheared of, I have already come across one example myself.

[rome1983]

Thanks for feedback.

[quietvoid]

@erazortt FWIW this only happens with DoViBaker, other solutions that "bake in" the FEL don't have the problem.

[erazortt]

Which other solutions are we talking about? Something that I could try and compare? Running the debugger in parallel should be very interesting indeed!

[quietvoid]

Which other solutions are we talking about? Something that I could try and compare? Running the debugger in parallel should be very interesting indeed!

I've tried with my code (https://github.com/OpusGang/awsmfunc/blob/master/src/awsmfunc/base.py#L1905), using https://github.com/quietvoid/vs-nlq.

But in AviSynth you might be able to do the mapping step through avslibplacebo, and try making DoViBaker do the NLQ step only. Should be helpful to find where the issue comes from, since libplacebo does the full mapping correctly.

[erazortt]

I see avslibplacebo has a tonemap function but how do I feed a RPU file to it?

[quietvoid]

If you use the latest unofficial ffms2 from http://avisynth.nl/index.php/FFmpegSource, it adds a DolbyVisionRPU frame prop which has the RPU payload to be parsed. The video file must be single track profile 7 (BL + EL + RPU).

https://github.com/Asd-g/avslibplacebo/blob/main/src/tonemap.cpp#L330

And you should be able to do the mapping using

ConvertBits(16)
libplacebo_Tonemap(src_csp=3, dst_csp=1)

[erazortt]

Found and fixed. New release is already out. Thanks to anybody involved!