Dolby Vision now possible through MP4 Mux.

[staknhalo]

I like the Clockwork Orange one, if what you want to see is there (flashing colors for RPU and/or Paramount/Dreamworks intro for FEL video data), it's like a punch in the face, you can't miss it

right but those flashes are just a buggy reaction, not the actual RPU working.
I prefer quietvoid's rpu test file + power rangers sample for fel

Because when you play the clockwork file on a player that is not supposed to have an RPU reaction like MPV, there's still a rpu reaction because the file is actually buggy and not because the rpu is working.
If you play quietvoid's rpu test file on MPV, there is no reaction at all which is the correct behavior.

Right it's artificing from misalignment - I saw the same thing when trying to encode 'Transformers (2007)' base layer and add full FEL layer back in before we realized encoding BL on FEL titles does this (misaligns slightly and creates random flashing artifacts at times) and you just have to remux them instead (without pro tools to re-encode I suppose) - that's what I made my own old FEL test file from

But it only shows the artifacts if trying to display the RPU - because it is RPU playback capable - is what I'm getting at, and the impression I was under - which would mean it still works as a test if so, right? I've never had it flash colors on a non-capable device.

MPV doesn't show color artifacts for me it stays red/orange until the BL changes itself. How were you able to get the flashing to show?

Edit: I do have the queitvoid test as well, and run through all of them on a device (the p7/p8/p5 test files)

Double edit: I can get the flashing to show in MPV, but just like Windows Store apps with Dolby Vision plugin - it IS supposed to show RPU this way - even if not 100% PQ accurate on playback if that's what you meant, because I know you don't like Windows Store apps for DV playback because of PQ/color inaccuracy - so just like the SHIELD, even though MPV can't show FEL video data, it uses RPU effects from FEL layer still to display some DV effects - so same effects output as if MEL (again, even if not 100% PQ accuracy)

Code: Select all

mpv.com --target-trc=pq --target-prim=bt.2020 --vo=gpu-next --gpu-context=d3d11 file.mp4/mkv/ts

https://www.avsforum.com/threads/author ... t-61416962

If you try to play without that command, it displays NO RPU effects/artifacts at all - as I would expect

So it does seem the flashing colors will only show when RPU is supposed to be displayed, which is how I always thought

Edit:

If you play quietvoid's rpu test file on MPV, there is no reaction at all which is the correct behavior.

I missed this part - but I still don't understand - how can it show artifacts from RPU if not processing RPU (even if inaccurately) ? Queitvoid's doesn't work like you said, but the Profile 5 misaligned file does work as intended too. Is it that it doesn't adhere to standards or certain formats/levels of authored RPU(CMV 4.0 or whatever it's called) ? - but it is still showing RPU (in all but queitvoid's test) when trying to, on purpose - and this only effects MPV curiously - I've never had a device work with the FEL test that didn't work with queitvoid's test - MPV now aside

[RESET_9999]

Well, sure it tells you if the device is "trying" make use of the rpu and I'm not really sure what those flashes are but it doesnt tell you if the RPU essence is working (L1/L2) which should be the main goal of an RPU response test file. But it's ok to use the clockwork file, I just prefer the more "official" test files over the handcrafted ones.

IIRC, you can also see a flash on the shield with the power rangers test file even though the EL+RPU was not delayed.

[staknhalo]

Well, sure it tells you if the device is "trying" make use of the rpu and I'm not really sure what those flashes are but it doesnt tell you if the RPU essence is working (L1/L2) which should be the main goal of an RPU response test file. But it's ok to use the clockwork file, I just prefer the more "official" test files over the handcrafted ones.

IIRC, you can also see a flash on the shield with the power rangers test file even though the EL+RPU was not delayed.

Right that's all I ever used it for - if a device can use the p7 FEL RPU at all (in addition to does FEL video data also show up or just RPU) - for testing a specific RPU effect or to see how many and which ones it does or doesn't support - I too use quietvoid's only - because I don't know what you put (or attempted to) in yours, and quietvoid gave me nice text to follow along with on the screen for each specific response/effect lol

But still why doesn't MPV work with his p8 test? Too new a metadata format or something and MPV just isn't updated to recognize it? It's just got me curious now is all. And really this (computer programs) is the only thing it would happen on I would think - you're not going to have a Dolby Vision physical product (streamer stick or disc player) that doesn't have ANY RPU response whatsoever - although I guess software could 'break' via update on a player product

[RESET_9999]

IDK it just doesnt support it. I'm sure it will in the future. FEL too.

[staknhalo]

IDK it just doesnt support it. I'm sure it will in the future. FEL too.

Yeah I asked about that, I could only imagine if a beefy GPU to 'mix the streams' so to speak, or a beefy multi-core CPU to do the grunt work. But I'm sure a lot easier said than done. Especially when just me saying it

[quietvoid]

But still why doesn't MPV work with his p8 test?

What test? mpv only supports the initial colour conversion (namely ICtCp to YCbCr, polynomial, and MMR mapping).
Any other dynamic metadata isn't used at all.

[sw5163]

Everything still plays as it should, the file will also have the DVH1 tag just for file consistency, and iTunes WILL NOT add it at all, so can't transfer to iPhone this way - so in theory you can't accidentally play it via Apple native video player

I can, SMB directly access my PC.

using this command

Code: Select all

mp4box -add video.hevc -new P7hvc1-noDVcommand.mp4

And it DOES NOT play properly on Android/SHIELD/Tivo - HDR10 only everywhere - so it is not the inner HEVC stream they look at only/ever when playing like I thought - when using HVC1 they respect the rules and look to the container - see nothing - and so no DV playback

I think I didn't make myself clear.
You could convert MEL (i.e. p8 PRU without reshaping data + BL) and real ICtCp P5 to p5.dvh1 and only do this for MEL and ICtCp P5.

Don't do this on FEL.

MEL and real ICtCp P5 converted this way should be playable by most devices while fully taking the advantage of RPU.

[staknhalo]

But still why doesn't MPV work with his p8 test?

What test? mpv only supports the initial colour conversion (namely ICtCp to YCbCr, polynomial, and MMR mapping).
Any other dynamic metadata isn't used at all.

Here, download these

https://mega.nz/file/sWBXCSoY#i93nPt5ZQ ... xM00DI8BOI

1 is the Clockwork Orange p7 FEL/FEL RPU test from Reset

2 is your p8 RPU test

If you play 1 in MPV normally (drag and drop or whatever - if you don't have custom settings saved for it) only the base layer plays, without any (proper or incorrect) RPU response

Now if you play 1 again with the command

Code: Select all

mpv.com --target-trc=pq --target-prim=bt.2020 --vo=gpu-next --gpu-context=d3d11 file.mp4/mkv/ts

You see flashing color artifacts as a result of RPU being improperly misaligned, but processed (or attempted, it's affecting it in some way)

Your video, number 2, no RPU response either way

edit: the misaligned p5 Reset made (you probably have it, if not I will upload) also shows RPU effects/artifacts when played with that code - besides properly color shaping/shifting the ICTCP BL - or so it seems

It's not that I'm saying it does play the RPU - if you guys say it doesn't I believe you - but what is the unintended thing obviously happening? Is it simply artifacts of a misaligned RPU will show, even though no correct RPU effects? I just don't get how if it doesn't play the RPU - it can then show artifacts from the RPU - that's what is confusing me. Wouldn't it have to be processing the RPU to display those artifacts, and if so, then why no other (correct) RPU effects? I just want to understand is all lol

I can, SMB directly access my PC.

I'm not so concerned with that, me, nor anyone I share my Plex files with, would be doing that (some people I share Plex with watch on iPhones - and I have an iPhone too so if on a plane/at airport this is how I would be watching Plex)

I think I didn't make myself clear.
You could convert MEL (i.e. p8 PRU without reshaping data + BL) and real ICtCp P5 to p5.dvh1 and only do this for MEL and ICtCp P5.

Don't do this on FEL.

MEL and real ICtCp P5 converted this way should be playable by most devices while fully taking the advantage of RPU.

Right but I don't want MEL/p8 as fake p5 - I only want actual p5 as p5 - even for iOS - p7 and p8 I want to keep as p7 and p8 - but without choppy playback on Plex on iOS - DVH1/HVC1 is what is needed - but I'm trying to keep everything else the same because I do not only use iOS and so try to keep as 'native' as I can - only change what I really really have to - for the least amount of files for every type of device/operating system

[sw5163]

My bad, sorry.

[staknhalo]

My bad, sorry.

No don't be sorry - you still helped me a lot, thank you - you just thought I wanted more than I did

[quietvoid]

1 is the Clockwork Orange p7 FEL/FEL RPU test from Reset

If you play 1 in MPV normally (drag and drop or whatever - if you don't have custom settings saved for it) only the base layer plays, without any (proper or incorrect) RPU response

Now if you play 1 again with the command

Code: Select all

mpv.com --target-trc=pq --target-prim=bt.2020 --vo=gpu-next --gpu-context=d3d11 file.mp4/mkv/ts

You see flashing color artifacts as a result of RPU being improperly misaligned, but processed (or attempted, it's affecting it in some way)

It is caused by the Dolby Vision processing.
By default you get `--vo=gpu` which doesn't support it.
When enabling `--vo=gpu-next`, Dolby Vision processing is enabled.

You can also bypass the processing using `--vf=format:dolbyvision=no`.

I haven't looked at what the file actually contains for metadata, yet.
So far it just looks like intentional behaviour if the metadata is just messed up.

[staknhalo]

It is caused by the Dolby Vision processing.
By default you get `--vo=gpu` which doesn't support it.
When enabling `--vo=gpu-next`, Dolby Vision processing is enabled.

You can also bypass the processing using `--vf=format:dolbyvision=no`.

I haven't looked at what the file actually contains for metadata, yet.
So far it just looks like intentional behaviour if the metadata is just messed up.

So it's a case of

because Dolby Vision processing is enabled, it will show RPU misaligned artifacts, and just simply isn't coded to show any other proper RPU effects, but could potentially, because it shows the artifacts, just doesn't have the code to do so currently

?

[quietvoid]

So it's a case of

because Dolby Vision processing is enabled, it will show RPU misaligned artifacts, and just simply isn't coded to show any other proper RPU effects, but could potentially, because it shows the artifacts, just doesn't have the code to do so currently

?

Probably.

[sw5163]

You see flashing color artifacts as a result of RPU being improperly misaligned, but processed (or attempted, it's affecting it in some way)

I think those are caused by processing "reshaping data" in RPU (polynomial, and MMR mapping).

From my understanding, P5 RPU has "reshaping data" for ICtCp->YCbCr.
P8.1 RPU doesn't need "reshaping data" for HDR10->HDR10.
P8.4 RPU has "reshaping data" for HLG->PQ.
P7 RPU has "reshaping data" for processing the weird colour in EL (I'm not sure what it really does)

MPV can adapt those polynomial, and MMR mapping for ICtCp->YCbCr, HLG->HDR10 etc.
However, it can't process EL and merge that with BL like proper dolby decoding engine.
Resulting in wrongly processing those "reshaping data" on BL.

I think RPU consists ("reshaping data" for colour space transformation) + (Levels for brightness/contrast trimming)
So you can see some artifacts when scene/brightness change, but it's wrong.
And MPV just abandons all the brightness/contrast trimming.

It’s also probably the reason why it’s so important to “remove_mapping” when converting FEL->MEL

I'm not sure about this, please point out my mistakes, many thanks.

[staknhalo]

You see flashing color artifacts as a result of RPU being improperly misaligned, but processed (or attempted, it's affecting it in some way)

I think those are caused by processing "reshaping data" in RPU (polynomial, and MMR mapping).

From my understanding, P5 RPU has "reshaping data" for ICtCp->YCbCr.
P8.1 RPU doesn't need "reshaping data" for HDR10->HDR10.
P8.4 RPU has "reshaping data" for HLG->PQ.
P7 RPU has "reshaping data" for processing the weird colour in EL (I'm not sure what it really does)

MPV can adapt those polynomial, and MMR mapping for ICtCp->YCbCr, HLG->HDR10 etc.
However, it can't process EL and merge that with BL like proper dolby decoding engine.
Resulting in wrongly processing those "reshaping data" on BL.

So you can see some change when scene/brightness change, but it's wrong.

I'm not 100% sure about this, will need anyone knowing how this exactly work to confirm, many thanks.

Yes that makes sense to me - and would explain why it happens on p5 and p7 files, and not p8 - as a result of it saying "I don't know what any of this means" when looking at the non-shaping RPU effects metadata - while DV processing is enabled - but the artifacts sneak through from the color shaping that it is reading from the RPU - because you don't need code for artifacts

The p7 EL shaping from my understanding is to make it look 12bit color from a 10bit file, or the other way around, something like that