Dual layer FEL dolby vision to Apple compatible BL+RPU

[sw5163]

First of all, thanks so much for quietvoid's and yusesope's amazing tool.
Sorry in advance if this has been posted or wrong.
I think it is possible to do the convert.

1. Extract bl.hevc and el.hevc from source
   ffmpeg -i FEL_test_for_AVS.m2ts -c copy -map 0:0 bl.hevc -map 0:1 -c copy el.hevc

2. Mux and convert to P8 (it seems Apple indeed doesn't support FEL)
   dovi_tool --edit-config fel_to_p81.json mux --bl bl.hevc --el el.hevc --discard

fel_to_p81.json
{
"mode": 2,
"remove_mapping": true
}

I haven't quite figure out what "remove_mapping" is.
But the result has similar RPU as in Apple's strange screensaver. (Thanks ValZapod)
And without it, the result will end up with awful green screen.

3. Use mp4muxer from https://github.com/DolbyLaboratories
   mp4muxer -i BL_RPU.hevc --dv-profile 5 --dvh1flag 0

This end up with a BL+RPU HDR10 based profile 5 mp4 just like their screensaver.
dvh1flag for Apple compatibility.
I know profile 5 shouldn't have HDR10 bl but it tricks Apple's native player to play dolby vision.

Sample mp4 as follow
https://drive.google.com/file/d/1kJTUMbnyN8Xvj17BLjBq1sYdhmP2otgy/view?usp=sharing

Original m2ts is from https://www.avsforum.com/threads/dune-pro-vision-4k-dolby-vision-fel-and-rpu-response-other-random-stuff.3188469/post-60582530
I think "remove_mapping" lose some RPU info, but the birghtness around 28 and 40 second flicker, so it is dolby vision.
Also Apple seems to ignore level 5 RPU data.

[quietvoid]

remove_mapping is useful for converting to profile 8.1 from FEL, where the video was preprocessed beforehand (like processing FEL).
Otherwise, the RPU would cause an additional mapping/processing on playback, so double the processing which is wrong.

[sw5163]

Thank you so much for the clarification.

[sw5163]

So sorry to bother you again, but It's very strange some fields in CM2.9 L2 RPU data work on iOS devices yet same fields in CM4.0 not.
https://forum.makemkv.com/forum/viewtopic.php?p=123910#p123910

Im not familiar with this dolby vision thing so it may be a stupid question.
I was wondering if that's an Apple problem or CM4.0 has some different from CM2.9 besides extra levels.

And if latter is the case, what should I do to just use CM2.9?
(I found most fel only have level 1 2 4 5 6 and CM4 potentially disable some L2 fields)

Please excuse my English.

update:
Oh is it because CM4.0 alread has trim in L8？

[quietvoid]

Oh is it because CM4.0 alread has trim in L8?

CM v4.x ignores L2 trims because the L8 are supposed to replace them. L2 is then only present for backwards compatibility.

[sw5163]

Thanks a lot, that solves my doubts.
From my test result, only L2_saturation_gain makes a difference when L8 presented.
Your tool is just amazing!

[sw5163]

Looks like we can play BL+RPU on apple tv now, cheers!
I still have one last question regarding remove_mapping.

I noticed that apart from mapping coefficients, some "pivot_value" have been changed.
Is that normal?

(Left) remove_mapping=true, (Right) remove_mapping=false

In addition, it will lead to some differences in test pattern from AVS forum.
The differences are not perceptible in real case FEL conversion file.
I mean if the processing is wrong there should be a difference in real content, right?

update: there is difference in real content, converting from FEL to p8.1 without remove_mapping is wrong.

(Left) remove_mapping=false, (Right) remove_mapping=true

Both player support dolby vision and the result is same switching them.
Can't post real content, Im currently in US, but in real contents they seem identical to each other.

Sample files are attached. Huge difference in 26 and 30 second.
https://drive.google.com/drive/folders/1wTkjXey78_rRTp7PhuM9R5EcAZJ5Qubc?usp=sharing

[quietvoid]

You shouldn't be blindly using remove_mapping.
The pattern you mention is using a random RPU, so it's meaningless.

[sw5163]

Many thanks!

[sw5163]

update:
Following is very likely to be wrong. I am truly sorry for anyone who may have spent their time on this.

Find something interesting, when 'mapping_idc' is 0,1,1 will lead to green screen on iOS devices.
All zero will be fine.
Also those polynomial/MMR mapping do have an impact on both profile 5 and profile 8.
For profile 5 when polynomial removed, it's like some sort of retro style filter enabled, very noticeable.
polynomial removed:

Original:

Source from https://developer.dolby.com/tools-media/sample-media/video-streams/dolby-vision-streams/

For profile 8, some players show a difference but it's extremely unnoticeable.

From https://patents.google.com/patent/US20190373290A1/en:
Mapping_Polynomial Method
[0126]
This method is applied to the luma component or when mapping_idc is equal to zero. The resulting prediction from BL is constructed in a piecewise manner. Inputs are the BL signal of the current component and the pivot array introduced in the previous section. The variables poly_order_minus1 and linear_interp_flag are held in the Dolby Vision metadata.

I've spent a few days trying to convert 'mapping_idc' 0,1,1 to 0,0,0 with minimum changes in polynomial/MMR/other fields.
But clearly Rust is too difficult for me, so I decided to move on.
Thanks you all for bringing this into possibility.

[sw5163]

My bad, you are right.
Can confirm the real P5 doesn't have MMR data. I mislabeled them. I am so sorry.
The profile 5 difference above is caused by removing poly coefficients, I think.

I don't know if the followings are correct: (FEL->8.1)

When 'mapping_idc' is set to 0, poly coefficients are used to do the mapping. And that's what it intends to do?
(higher quality?)

When 'mapping_idc' is set to 1, mmr coefficients are used to prepare the BL to be EL ready?
(no quality change or even downsampling?)
This could possibly explain why Apple has green screen when 0,1,1

Therefore, P5 should only have 'mapping_idc' as 0,0,0 with 'poly coefficients' in RPU?
P8.1 should have 'mapping_idc' as 0,0,0 with no poly/MMR coefficients at all? (as in the Dolby official P8 demo video)
FEL should have 0,1,1 to use poly_coef to enhance luma and MMR_coef to enhance chroma?

Please don't hesitate to point out my mistakes.
If above is true, what will happen if we 'just' remove MMR data while having poly coefficients remain in RPU with the 2 chroma channel 'mapping_idc' set to 0 as something like [ [0,0,0,0,0,0,0,0], [0], [0] ], instead of removing them all in 'remove_mapping'.
Would the quality be better since the luma channel remains?

Sorry for being annoying and sound stupid.
Any explanation would be very much appreciated.
Happy weekends!

[quietvoid]

Polynomial mapping is usually only for the the luma channel. MMR is for chroma.
Some services like Apple TV+ or iTunes also have chroma polynomial mapping, since profile 5 doesn't do MMR.

If above is true, what will happen if we 'just' remove MMR data while having poly coefficients remain in RPU with the 2 chroma channel 'mapping_idc' set to 0 as something like [ [0,0,0,0,0,0,0,0], [0], [0] ], instead of removing them all in 'remove_mapping'.
Would the quality be better since the luma channel remains?

No, that would be making the final tone mapped image wrong.
Both poly and MMR mapping are totally optional, but if they're present in the original they shouldn't be changed unless the actual video is preprocessed separately.

So profile 5 with both poly (luma and chroma) requires both, or the image is wrong.
Same for profile 8.4.

[sw5163]

Wait, you mean profile 8.4 can use polynomial mapping in luma channel and MMR in chroma?
I thought MMR requires EL.
I will do some test. Thank you for the detailed explanation!

[quietvoid]

Wait, you mean profile 8.4 can use polynomial mapping in luma channel and MMR in chroma?

Yes.

I thought MMR requires EL.

That would be NLQ.

[sw5163]

Can confirm Apple doesn't support MMR except in 8.4, other profile will lead to green screen.
Another thing is I tried use your p84_cmv40_tests and noticed Apple only use First frame mapping_idc data.
For example if the first [0,71] frames is 'mapping_idc' 0,0,0 it will play play properly the rest of the video.
However if the first frame is 'mapping_idc' 0,1,1 and the rest is 0,0,0, it will have green screen.
Very strange.

There is currently no way to convert HDR10 to HLG loselessly, right?
So I think I will stick to remove_mapping and have fake profile 5.

[draco1544]

HDR format : Dolby Vision, Version 1.0, dvhe.05.06, BL+RPU / SMPTE ST 2086, HDR10 compatible / Codec ID : V_MPEGH/ISO/HEVC This file will display correct Dolby Vision on the apple tv ?

[draco1544]

The fake profile 5 mp4 will work with infuse ?

[legosoff]

Does not work.