Green frames sometimes

[boulderdash09]

Hello,

I discovered this wonderful new tool and I wanted to give it a try and encode a Dolby Vision UHD Bluray in x265.

• First, I use MakeMKV to rip my Dolby Vision 4K Bluray so I have a mkv file which shows "Dolby Vision, Version 1.0, dvhe.07.06, BL+EL+RPU, Blu-ray compatible / SMPTE ST 2086, HDR10 compatible" in mediainfo.

• I extract the hevc file from this mkv and I use this command to create RPU.bin : dovi_tool -m 2 extract-rpu myvideo.hevc (because I want a profile 8.1)

• I open the mkv file in staxrip and I encode in x265 with these parameters : --dolby-vision-profile 8.1 --dolby-vision-rpu "path to RPU.bin"

• I mux the resulted hevc file with tsmuxerR and I have a .ts file which shows "Dolby Vision, Version 1.0, dvhe.08.06, BL+RPU, HDR10 compatible / SMPTE ST 2086, HDR10 compatible" in Mediainfo

Everything looks good, I tested my .ts file on my TV (via Plex/Shield) and it displays Dolby Vision logo. The image is really great but sometimes (mainly in black screens with just a white text or something in the middle), the screen becomes green just before the cutscene (it's really fast but we can definitely see it). Of course it's not the case if I play the source mkv (so it doesn't come from the source). I tested on different TV/devices (even with a mp4 container) and the problem remains.

Is something wrong in my encoding chain or is there a bug somewhere ? I already tested to encode with profile 5 (I lose HDR compatibility in this case so I don't want that), I also tried to extract rpu.bin untouched (mode 0) and I encoded with profile 8.1 : In this case there is no green frames but the colors are also not so good so I think it's not the good thing to do...

[quietvoid]

If mode 0 doesn't have any error, there is no bug.
If you have encoded a different resolution than what is coded into the RPU (for example, cropping), it is possible that the image is incorrect on playback.

[boulderdash09]

No I didn’t crop at all.

I will do another test but what is the correct extract_rpu mode if I want to encode with dolby vision profile 8.1 in x265 ? Mode 0 or mode 2 ? (I chose mode 2 at the beginning because the readme says that mode 2 is for profile 8.1 but maybe I’m wrong...)

[quietvoid]

Mode 2 is correct for profile 8.1, mode 0 is only for verifying the parsing is correct first.
There shouldn't be issues introduced by the conversion, from my tests.

Might be a decoder issue if it's not all the time, or something wrong in the RPU in the first place if it's reproducible at the same frames in the source video.

[boulderdash09]

Ok thank you for your response and thank you for your work ! I will test that again. The issue is not reproducible in the source video in this case. It's really strange because I only see this issue in black screens, for example a black screen with just a white text in it. The white text becomes green just before the cutscene... But yes it can be a decoder issue...

[quietvoid]

No idea, these kind of issues can't really be debugged because all the processing on playback is proprietary, so who knows what is wrong.

There's no specification on the different profiles either, so I can't confirm whether it's an issue with the conversion or not without testing myself.
Can you share a sample with which the issue can be reproduced? Or the title you reencoded with a timestamp of when the issue occurs?

[boulderdash09]

Yes of course, here is a 2 minutes sample where I can reproduce the issue : https://uptobox.com/ic7q7p5btf51

The issue is visible at about 1:33 where we can see the white texts. All the film is ok for me except for this scene and another one (another black screen with just a small object in the middle).

Let me know if you have the same issue, I just did another test and I reproduced it...

[quietvoid]

I can only reproduce when reencoding, there might be a slight desync caused by x265.
With a converted RPU only, there's no green flashing.

The only solution would be to reorder the frame metadata according to presentation order, instead of the order in which they're parsed from the file.
I'm not sure when I'll have the time to look into that.

[boulderdash09]

Thank you for your tests, I understand the issue now.

No problem if you don’t have time to look into that for now, you already do an incredible job with your tools so we know it takes time :)

[quietvoid]

I had a quick look at the metadata order after encoding, and the order varies depending on the encode settings.
There's not much I can fix here, the metadata insertion is dependent on x265.

For example, default settings end up with a lot of difference between original RPU order and extracted from reencode.
With --ref 6 --bframes 16, there are less differences in the order but the issue is still present on playback.

The same issue happens with HDR10+ metadata.
It might be possible to reorder properly in x265's code but it would probably never end up upstream.

As far as I know there aren't many noticeable issues with out of order metadata in most cases, so this kind of scene might be one of those.
There's no use in matching the order for the source file, because it won't match the reencode (with the current x265 behavior) anyways.

[quietvoid]

I've reopened this because I think it's feasible to output the correct order.
x265 just outputs differently because the frame order changes, but the presentation order is the same.

[boulderdash09]

I'm glad to read that, I really appreciate your work.

Do you think hdr10plus_parser has the same "issue" and needs the same update ? (decode order vs presentation order)

[quietvoid]

Yes

[quietvoid]

Should be fixed in 0.2.0, I can get identical metadata before and after encode.
And the sample does not flicker green anymore.