www.makemkv.com

aboulfad wrote: Fri Jan 12, 2024 8:16 pm Ah sorry, excuse my lack of attention, the label confused me as its L1 + ... but of course 'trim offset' is a function of L2. Indeed, its quite noticeable, @1024 its super dark !

yea negative values (below 2048) works but the problem is with the positive lift. Try it on your TV internal player or force LLDV on your oppo, you'll see.

RESET_9999 wrote: Fri Jan 12, 2024 8:27 pm

JCLG8 wrote: Fri Jan 12, 2024 8:09 pm
Here's the mediainfo:

This is workflow 5??
I thought you wanted to demux ST P7 MKV to DT-DL TS ???
the workflow to do that is (4-3)


Workflow is supposed to work though but the output would still be ST P7 which could fail to play on the x700. I'll try to reproduce the issue but my guess is because of the Russian text for the dts tracks

Ah crap yeah forgot to mention this, sorry. I thought maybe ST DL will work so I don't need to convert so then I tried to just mux it as is to .TS. But honestly the same issue with TrueHD happens on both situations.

JCLG8 wrote: Fri Jan 12, 2024 8:35 pm
Ah crap sorry. I thought maybe ST DL will work so I don't need to convert so then I tried to just mux it as is to .TS. But honestly the same issue with TrueHD happens on both situations.

If you just mux it with tsmuxer the THD track will not work on the x700 because it will be missing the AC3 core.

PS, I'm not able to reproduce the issue. Can you try with a normal rip that doesn't come from some obscure Russian torrent tracker please??

RESET_9999 wrote: Fri Jan 12, 2024 8:48 pm PS, I'm not able to reproduce the issue. Can you try with a normal rip that doesn't come from some obscure Russian torrent tracker please??

Lol its not obscure its quite known actually but I understand.

RESET_9999 wrote: Fri Jan 12, 2024 7:43 pm All the HDMI devices I tested will ignore any positive lift for Trim offset so it will reflect in a darker image.
test file if you want to see it with your own eyes: https://drive.google.com/file/d/1JrU6JX ... drive_link

This is a much bigger issue than the LLDV CW bug because L2 trim offset is calculated automatically by the Dolby algo (then the colorist can edit it) so unlike Chroma Weight which must come from the colorist, trim offset is used a lot more often in real content and only the TV internal player support it. (ironically, all the devices support it just fine in LLDV)

Is the positive trim lift ignored by every TV-led device? e.g. Every Blu-ray player, Apple TV, and Shield in TV-led mode?

Also, is there any chance that it is intentional for the positive lift L2 Trim to be ignored on TV-led devices if that is the case? Maybe Dolby determined that the TV should make its own decision in those cases...?

Yes, I tested with two different TV (C8 and C2):
x700
x800m2
shield
ATV


I doubt this is intentional otherwise it would also be ignored when you play the file with the TV internal player.

speeddemon wrote: Fri Jan 12, 2024 10:27 pm Also, is there any chance that it is intentional for the positive lift L2 Trim to be ignored on TV-led devices if that is the case? Maybe Dolby determined that the TV should make its own decision in those cases...?

I agree with RESET, it also doesn't make sense for Dolby's own Professional Tools to generate positive trims when run automatically, if they intend for them to be ignored. I haven't seen/read any Dolby official articles or manuals mention advising against positive values on any trim adjustments when grading either, other than positive lift not being above 0.025 for letterbox content, see here: https://www.youtube.com/watch?v=AVZ7xcgeEAM

RESET_9999 wrote: Fri Jan 12, 2024 10:56 pm Yes, I tested with two different TV (C8 and C2):
x700
x800m2
shield
ATV


I doubt this is intentional otherwise it would also be ignored when you play the file with the TV internal player.

So the C8 & C2 don't have the issue when you're using the internal player? How about Kodi?

I want to test this from my Sony A95K to see if it behaves the same way... wondering if maybe this is an LG behavior... or is that not possible?

Does Dolby state this for a different reason?

Avoid using positive values over 0.025 on the LIFT trim control for letterboxed content. (Negative Lift values are acceptable on all versions).

Source: https://professionalsupport.dolby.com/s ... uage=en_US

right C8 and C2 internal players do not have this bug. I haven't tested kodi but I don't see why it would be any different.

Does Dolby state this for a different reason?

yes but they still can lift up to 0.025 which is ignored by the HDMI players and if the content is full screen then there is no restriction so this cannot be the reason plus they can lift with the other trim control as well.
Also, they can use the metafier to verify or fix any lift.

RESET_9999 wrote: Fri Jan 12, 2024 11:27 pm right C8 and C2 internal players do not have this bug. I haven't tested kodi but I don't see why it would be any different.

We really don't know how TV process DV signals. One possible explanation is internal player is doing LLDV.

RESET_9999 wrote: Fri Jan 12, 2024 10:56 pm Yes, I tested with two different TV (C8 and C2):
x700
x800m2
shield
ATV
I doubt this is intentional otherwise it would also be ignored when you play the file with the TV internal player.

This was one of my questions in my previous post - is this metadata actually used?
L2 trims are "per-target trim metadata" - typically 100nits, 600nits, 1000nits. How would TVs or players use this data?
If the TV happens to be one of these three numbers, it can use one of them.
If the TV is 350nits, 800nits, 1500nits, 2000nits, which L2 metadata would it use? use the closest one? or extrapolation? for example, 800nits TV will use both 600nits+1000nits?

Can you see internal player output? I think Kodi can show its output. If we know what signal come out of internal player, we can do better troubleshooting.

This was one of my questions in my previous post - is this metadata actually used?

of course, and all the trims work together in interpolation.
I did test files that can verify pretty much anything DV-related here: https://drive.google.com/drive/u/1/fold ... V0E3VVkhiC

One possible explanation is internal player is doing LLDV.

what

RESET_9999 wrote: Sat Jan 13, 2024 1:20 am of course, and all the trims work together in interpolation.
I did test files that can verify pretty much anything DV-related here: https://drive.google.com/drive/u/1/fold ... V0E3VVkhiC

Do you know any documentation on how metadata is "supposed to be" used? I see many documentations on how DV conetent is generated. However, I rarely see any documentation on how it is supposed to be used. We can only guess on how things should work or how things currently work.

RESET_9999 wrote: Sat Jan 13, 2024 1:20 am

One possible explanation is internal player is doing LLDV.

what

It depends on how the DV work flow on the display side, ins't it?
It needs to decode into DV data and send it for processing. For external player we know or we can guess who is doing the processing (TV-led, player-led, or combination). For internal player, do we know which part of display is doing the processing. It could be the internal player processing everything and send it for display. It is a SoC after all, not much difference than amlogic, mediatek, etc.

susanstone2022 wrote: Sat Jan 13, 2024 2:37 am We can only guess on how things should work or how things currently work.

We have all the tools we need to create or analyze any DV RPU and we understand very well how the DV metadata levels work, everything has been tested intensely in every possible way.