Dolby Vision now possible through MP4 Mux.

[RESET_9999]

I dont know, but you can always test the original and generated tone mapping with workflow 7-4 and decide which one you prefer.

@RESET_9999 given this:
Since L2 trims are not static, what is the best practice here: generating new metadata or keeping retail RPU?

[LV8HD]

I dont know, but you can always test the original and generated tone mapping with workflow 7-4 and decide which one you prefer.

@RESET_9999 given this:
Since L2 trims are not static, what is the best practice here: generating new metadata or keeping retail RPU?

Wouldn't it be wrong to keep retail?

The movie was mastered at 4000 nits; proven by a HDR analysis, MaxCLL: 4427 nits, MaxFALL: 2325 nits.

On the other hand, Dolby Vision L1 is statically capped at 650 nits. Doesn't this mean that even if a TV hypothetically supported up to 4427 nits, using Dolby Vision would cap all content at 650 nits? Possibly wrongly tonemapped as well.

Generating a new RPU and transferring retail L2 metadata to it can be a solution?

[extranet]

Simple question but probably not a simple answer. I want to rip DV FEL files and keep FEL. Staxrip converts to 8.1 but doesn't keep FEL. I understand with Dovibaker it is possible? But although I've used Avi/Vapoursynth a lot, I'm still not really an expert at working out how to import files to the script. What is the simplest way rip DV FEL and keep FEL?

[RESET_9999]

Wouldn't it be wrong to keep retail?

The movie was mastered at 4000 nits; proven by a HDR analysis, MaxCLL: 4427 nits, MaxFALL: 2325 nits.

On the other hand, Dolby Vision L1 is statically capped at 650 nits. Doesn't this mean that even if a TV hypothetically supported up to 4427 nits, using Dolby Vision would cap all content at 650 nits? Possibly wrongly tonemapped as well.

Generating a new RPU and transferring retail L2 metadata to it can be a solution?

Some colorists prefer to keep L1 static and do most of the work in the trims, and that can work. However, looking at the L2 trims here, they’re not dimming the image very much (gamma brightens and slope dims equally) , and given that this is an insanely bright HDR grade, I’d expect proper CMv4.0 metadata to perform better overall.

That said, I’d still generate a few tone-mapping samples using workflow 7-4 and verify the results. There’s no need to guess anything, it takes about 10 minutes to produce tone-mapping samples with both the original metadata and the generated one, and then you can directly compare the output.

cmv4.0 generated: https://drive.google.com/file/d/1ec1rWd ... drive_link
original: https://drive.google.com/file/d/1VqXaGX ... drive_link

[RESET_9999]

Simple question but probably not a simple answer. I want to rip DV FEL files and keep FEL. Staxrip converts to 8.1 but doesn't keep FEL. I understand with Dovibaker it is possible? But although I've used Avi/Vapoursynth a lot, I'm still not really an expert at working out how to import files to the script. What is the simplest way rip DV FEL and keep FEL?

workflow 8-2-1 in dovi_scripts:
https://forum.doom9.org/showthread.php?t=185317

[extranet]

Simple question but probably not a simple answer. I want to rip DV FEL files and keep FEL. Staxrip converts to 8.1 but doesn't keep FEL. I understand with Dovibaker it is possible? But although I've used Avi/Vapoursynth a lot, I'm still not really an expert at working out how to import files to the script. What is the simplest way rip DV FEL and keep FEL?

workflow 8-2-1 in dovi_scripts:
https://forum.doom9.org/showthread.php?t=185317

Thanks. Maybe there should be a way to extract data from an existing DV 7 file to add to the same file but encoded to DV 8.1? I had a couple of files with both files still present and it might have been quicker rather than having to set up the encoding parameters and re-encode. But at least this preserves FEL Maybe one day this will be incorporated into StaxRip.

[LV8HD]

Some colorists prefer to keep L1 static and do most of the work in the trims, and that can work. However, looking at the L2 trims here, they’re not dimming the image very much (gamma brightens and slope dims equally) , and given that this is an insanely bright HDR grade, I’d expect proper CMv4.0 metadata to perform better overall.

That said, I’d still generate a few tone-mapping samples using workflow 7-4 and verify the results. There’s no need to guess anything, it takes about 10 minutes to produce tone-mapping samples with both the original metadata and the generated one, and then you can directly compare the output.

But as I pointed in the previous post, can I generate a new RPU with dynamic L1, CMv4.0 and transfer L2 trims from the original RPU? Is this going to preserve the colorist intention or is it incompatible with the newly generated L1? If so, I think I am going to stick with the generated metadata since, as you expected, performs better.

[RESET_9999]

But as I pointed in the previous post, can I generate a new RPU with dynamic L1, CMv4.0 and transfer L2 trims from the original RPU?

no

[bbeny123]

Hi @RESET_9999.

Sorry for the long post; I’m directing these questions to you since you have the most hands-on experience with FEL processing here.

I’ve ported DoViBaker to VapourSynth, making it compatible with macOS on Apple Silicon in the process. I’ve also significantly optimized it (LUT implementation, code cleanup, and optional use of VapourSynth’s internal resizers). I plan to make it public soon (once I’ve improved the build process). On a base Mac Mini M4, it achieves ~32fps during a FEL bake + prores_videotoolbox encoding, which I believe is a significant performance boost compared to the original DoViBaker on AviSynth.

While benchmarking and refining the code, I ran into a few technical questions regarding the regeneration of L1/L2 for P7 FEL:

1. ProRes 4444 vs 422 HQ vs 422
I’ve compared encodes for The Green Knight and noticed that ProRes 4444 takes ~5x longer for cm_analyze and takes up significantly more disk space (4444: 900GB, 422HQ: 600GB, 422: 370GB).

• The L1/L2 values in the generated XMLs only differ deep in the decimals.
• The plots for 4444, 422 HQ, and 422 look nearly identical (https://slow.pics/c/VGzmPFRT).

Question: In your experience, is there any practical benefit to using 4444 for FEL bakes, or is 422HQ/422 sufficient?

2. Mastering Display & Metadata (L6/L9)
In your generated RPU for The Green Knight, you used BT.2020 as the color primaries.

• The BL metadata specifies BT.2020, but does that necessarily dictate what should be used as cm_analyze --mdl argument?
• Most FEL RPUs have empty MDL fields (any idea why?). According to GenAI (Gemini), 4000-nit masters are almost always DCI-P3. How do you reliably determine whether to use P3 or BT.2020?
• Level 6 and Level 9 are the only ones that change depending on the BT.2020/P3 choice. I know L6 is ignored by TVs, but does L9 matter for players like Ugoos (or any other)? Should I avoid transferring a generated L9 into the original RPU?

3. Target Nits for L1/L2 Generation

• Should the nit target for regenerating L1/L2 for P7 FEL always match the original RPU?
• In The Green Knight, BL metadata says MDL = 1000 nits, but the RPU is 4000 nits. When I generated for 1000 nits, the MaxFALL plot was flat. What is your rule of thumb for choosing the target?

4. Experience with BestSource (FFMS2 sucessor)
I’ve been testing BestSource as an alternative to FFMS2.

• BS indexing is significantly slower in my tests.
• On The Green Knight, the last two EL frames lacked RPU data, resulting in a shorter ProRes file and forcing an RPU pad. My 422 HQ plots are affected by this, while the 422 and 4444 encodes (using FFMS2) matched the original length perfectly.

Question: Have you used BestSource for P7 FEL indexing, and if so, what is your experience with its reliability compared to FFMS2?

Thanks in advance for your insights and for all the work you've done for this community!

[RESET_9999]

I’ve ported DoViBaker to VapourSynth, making it compatible with macOS on Apple Silicon in the process. I’ve also significantly optimized it (LUT implementation, code cleanup, and optional use of VapourSynth’s internal resizers). I plan to make it public soon (once I’ve improved the build process). On a base Mac Mini M4, it achieves ~32fps during a FEL bake + prores_videotoolbox encoding, which I believe is a significant performance boost compared to the original DoViBaker on AviSynth.

Nice, thank you.
I get about the same speed in avisynth when I use:
SetFilterMTMode("DoViBaker",2)
Prefetch(8)

1. ProRes 4444 vs 422 HQ vs 422
I’ve compared encodes for The Green Knight and noticed that ProRes 4444 takes ~5x longer for cm_analyze and takes up significantly more disk space (4444: 900GB, 422HQ: 600GB, 422: 370GB).

The L1/L2 values in the generated XMLs only differ deep in the decimals.
The plots for 4444, 422 HQ, and 422 look nearly identical (https://slow.pics/c/VGzmPFRT).

Question: In your experience, is there any practical benefit to using 4444 for FEL bakes, or is 422HQ/422 sufficient?

422 HQ is more than enough... And isn't it ffmpeg 444 prores 12bit but 10bit in the pipeline?

In your generated RPU for The Green Knight, you used BT.2020 as the color primaries.

The BL metadata specifies BT.2020, but does that necessarily dictate what should be used as cm_analyze --mdl argument?
Most FEL RPUs have empty MDL fields (any idea why?). According to GenAI (Gemini), 4000-nit masters are almost always DCI-P3. How do you reliably determine whether to use P3 or BT.2020?
Level 6 and Level 9 are the only ones that change depending on the BT.2020/P3 choice. I know L6 is ignored by TVs, but does L9 matter for players like Ugoos (or any other)? Should I avoid transferring a generated L9 into the original RPU?

I don’t know whether L9 has any effect at playback, but I suspect it doesn’t. I’ve seen some Web-DLs (Amazon, I think) with dynamic L9, and Metafier flags it as invalid.
I don’t think the choice of MDP really matters here, but we could generate a test sample that alternates between P3 and BT.2020 to check whether there is any visible difference in practice.
I don't really understand the Dolby documentation on what L9 is actually supposed to do, so I’m not sure how to interpret it. Maybe @quietvoid has more insight on this.

L9 is listed per shot to improve the alignment of the XML to the bitstream metadata carriage.

Should the nit target for regenerating L1/L2 for P7 FEL always match the original RPU?
In The Green Knight, BL metadata says MDL = 1000 nits, but the RPU is 4000 nits. When I generated for 1000 nits, the MaxFALL plot was flat. What is your rule of thumb for choosing the target?

When I replace original Profile 7 levels with generated metadata, I always match the RPU MDL, because I don’t know whether the FEL reshaping metadata depends on the MDL.
This is something I wanted to verify after adding Profile 7 encoding support in the latest dovi_script beta.

If I'm just generating a new P8 rpu, then I choose MDL based on the grade's actual brightness (measured in madvr)

When I generated for 1000 nits, the MaxFALL plot was flat

avg_pq doesn't seem to matter in CMV4.0 anyway. No matter its value, only max_pq seems to have an effect.

I’ve been testing BestSource as an alternative to FFMS2.

BS indexing is significantly slower in my tests.
On The Green Knight, the last two EL frames lacked RPU data, resulting in a shorter ProRes file and forcing an RPU pad. My 422 HQ plots are affected by this, while the 422 and 4444 encodes (using FFMS2) matched the original length perfectly.

Question: Have you used BestSource for P7 FEL indexing, and if so, what is your experience with its reliability compared to FFMS2?

First time I hear about BestSource but FFMS2 and DGdecode have been 100% reliable so far so I don't have any reason to try something else.
Is it frame accurate with the VC-1 codec? This is the only thing that bothers me with FFMS2.