powdeau wrote: Sat Jan 28, 2023 4:51 pm
What if the movie has only 100 nits or only 600 nits trim pass, would that be a problem?
100nits = AFAIK it's not used in DV playback but it is used with Windows 10 Movies&TV app when tone mapped to SDR. So when the movies only has 100nits trim, its the same has no trims for DV playback.
600nits= definitely has an effect on my C2, in fact, all the trims work together at the same time. I used to think that only one trim was selected but it's not the case at all.
pattern to see what I'm talking about: https://drive.google.com/file/d/1wgph-I ... share_link
Thank you, you were right about 600nits trim pass taking an effect.
So I guess if a movie has only 100nits trim pass, it's better to generate new DV metadata with Resolve (if using C1 + x700).
If I convert a HDR10+ to DV, is it possible to additionally add trim passes?
powdeau wrote: Sun Jan 29, 2023 4:43 pm
So I guess if a movie has only 100nits trim pass, it's better to generate new DV metadata with Resolve (if using C1 + x700).
No, the only reason you should generate DV instead of using the official dv source is if the L1 plot and PQ comparison clearly show that they are not the same grade. (speaking of hybrid p8 remux of course)
now if the content has high L1 max_pq values and is "L1 no trim" or "L1 + 100nits trim only", there may be an issue with the x700/x800m2/oppo which seem to have no reaction to higher values but this is has nothing to do with generated DV.
If I convert a HDR10+ to DV, is it possible to additionally add trim passes?
Well not sure why you would want to do that but the dovi_tool has a function that can copy the metadata from one rpu to another but I believe the shots must be the same.
RESET_9999 wrote: Sun Jan 29, 2023 4:56 pm
No, the only reason you should generate DV instead of using the official dv source is if the L1 plot and PQ comparison clearly show that they are not the same grade.
now if the content has high L1 max_pq values and is "L1 no trim" or "L1 + 100nits trim only", there may be an issue with the x700/x800m2/oppo which seem to have no reaction to higher values but this is has nothing to do with generated DV.
So to avoid that issue with x700, isn't it better to generate new DV that will have trim passes instead of using the official one without any trim passes?
powdeau wrote: Sun Jan 29, 2023 5:11 pm
So to avoid that issue with x700, isn't it better to generate new DV that will have trim passes instead of using the official one without any trim passes?
No, the default resolve trim passes have a too strong/undesired effect when the content is very bright. When the studios grade DV, the L2 trims are edited manually shot by shot after the algo generated the default values.
This is why I overwrite them if you use my script to inject an XML file.If you go back a couple of pages, I posted a pattern that shows exactly that.
Hi, bit of a newbie here still, so forgive the questions...
Up until this point had just been using MakeMKV in this way;
Insert disc > Open MakeMKV > File > Open Disc > Then ticking the appropriate film title(s) > Then hitting makemkv
I understood this method to backup everything including the DV layer. I don't have a capable player currently of playing DV, but I thought that when I did get one (soon) all my film rips would be useable with DV, having read through some of this thread, I don't think that is possible?
Is the above method the correct way of capturing a film? I thought I read somewhere that the m2ts files are a better approach for displaying DV content, but that means you have to do a complete backup of every disc?
powdeau wrote: Sun Jan 29, 2023 5:11 pm
So to avoid that issue with x700, isn't it better to generate new DV that will have trim passes instead of using the official one without any trim passes?
No, the default resolve trim passes have a too strong/undesired effect when the content is very bright. When the studios grade DV, the L2 trims are edited manually shot by shot after the algo generated the default values.
This is why I overwrite them if you use my script to inject an XML file.If you go back a couple of pages, I posted a pattern that shows exactly that.
I see, so to avoid that issue, it is best to just extract the original XML file and run it through your script, which will add the missing trim passes.
powdeau wrote: Mon Jan 30, 2023 5:16 pm
I see, so to avoid that issue, it is best to just extract the original XML file and run it through your script, which will add the missing trim passes.
extract original XML ? i dont think the dovi_tool can do RPU to XML.
If you mean the generated resolve XML, then yes IMO you should always overwrite the default trims with my script or manually.
powdeau wrote: Mon Jan 30, 2023 5:16 pm
I see, so to avoid that issue, it is best to just extract the original XML file and run it through your script, which will add the missing trim passes.
extract original XML ? i dont think the dovi_tool can do RPU to XML.
If you mean the generated resolve XML, then yes IMO you should always overwrite the default trims with my script or manually.
I'm sorry, I didn't explain myself properly. What should I do, if I have a DV Blu-ray without trim passes and I want to avoid the issue with x700? How can I add those trim passes using your script?
powdeau wrote: Mon Jan 30, 2023 5:59 pm
I'm sorry, I didn't explain myself properly. What should I do, if I have a DV Blu-ray without trim passes and I want to avoid the issue with x700? How can I add those trim passes using your script?
there's nothing you can do about it.
There's no point in adding blank trim passes and it wouldnt make any difference with the x700 that may have issues with high L1 values.
ragico wrote: Thu Jan 26, 2023 11:55 pm
Sorry no. All my P7.ts are from Dovi Fel on purpose. None is from a Mel. And I can assure you that they worked and played perfectly. Unfortunately I did not keep that version.
I don't know but it doesn't add up. I tested a version from the day before and it's also crashing with my test files.
You're welcome to try it: https://mega.nz/file/pZln1IhT#QlMIyPOhW ... 6LidHO1Xqg
This one is the old org.xbmc.kodiDV package.
I don't have the 2023-01-23 build anymore.
Anyways, I have to rework the code so that it works for all files.
This is just temporary.
