Dolby Vision now possible through MP4 Mux.

[quietvoid]

do you think if it could be possible to add an option to ignore the frame count and inject whatever you feed it? Do the few last frames really matter?
As long as the rpu is in sync with the BL at the start, it should be fine right? of course the default mode should stay as it is right now (frame count must match) but if you could just add a parameter like --ignore-framecount , that would save a lot of calculation.

It is possible, I guess the default behaviour would be to duplicate the last added metadata for the the rest or remaining frames?

[manuelrn]

do you think if it could be possible to add an option to ignore the frame count and inject whatever you feed it? Do the few last frames really matter?
As long as the rpu is in sync with the BL at the start, it should be fine right? of course the default mode should stay as it is right now (frame count must match) but if you could just add a parameter like --ignore-framecount , that would save a lot of calculation.

It is possible, I guess the default behaviour would be to duplicate the last added metadata for the the rest or remaining frames?

I believe that the ideal would be that, in case the amount of frames of the video and the RPU does not match, the last frame of the RPU is copied repeatedly the number of times necessary to obtain the same frame length as the video.
And in case the RPU contains more frames than the video, when the last frame of the video is processed with the RPU, skip the next frames of the RPU.

In fact, I think the tool should behave like this by default, without using that '--ignore-framecount' argument or any other argument.
But, when this happens, the tool should show a warning message about it so that the user is aware of it (just in case he did it accidentally).

Regards!

[RESET_9999]

totally agree

[quietvoid]

Ok, makes sense.

[RESET_9999]

I got @manix(thank you) Atomos Shogun samples (LLDV stream captured in PQ then tonemapped to SDR with the same static madVR settings) ...

Star Wars P5 vs P8 vs HDR10 bluray:
https://slow.pics/c/Nd423gGO
https://slow.pics/c/qA4L4HUk
https://slow.pics/c/cKSjjNSD
https://slow.pics/c/jKrPq1Vf

Ted Lasso P5 vs P8 vs HDR10:
https://slow.pics/c/8nVLCFVq
https://slow.pics/c/H6xrVpNu
https://slow.pics/c/CtyxwrRU


Star Wars P5 and P8 look pretty much the same in DV but they are both different from HDR10.
Ted looks different in all samples, P8 is closer(but not the same) to HDR10.

I don't know what to think... He has to use the Dune Player for Ted samples because the x700 don't like cropped DV, so that could maybe explain the difference if the dune has issues with p5.

[shawnc22]

In the case of Ted Lasso, are you just doing a straight P5 to P8 conversion? Then for star wars, you’re going throught the whole process of RPU extraction from P5 and applying it to the UHD HDR10 layer to get P8? If so, and I’m not sure if this has been asked already, but is quietvoid’s tool doing a colorspace conversion when going from P5 to P8? If not, that might be the reason why Ted Lasso looks so different. For the Star Wars scenario, it could be that the same RPU metadata can be applied to BL’s that’re in different colorspaces without issue.

[RESET_9999]

In the case of Ted Lasso, are you just doing a straight P5 to P8 conversion? Then for star wars, you’re going throught the whole process of RPU extraction from P5 and applying it to the UHD HDR10 layer to get P8? If so, and I’m not sure if this has been asked already, but is quietvoid’s tool doing a colorspace conversion when going from P5 to P8? If not, that might be the reason why Ted Lasso looks so different. For the Star Wars scenario, it could be that the same RPU metadata can be applied to BL’s that’re in different colorspaces without issue.

both files are done the same way...
extract and convert rpu from profile 5 web-dl to p8 at the same time and then the rpu is injected into the HDR10 hevc stream.

the only difference is the player... but manix is doing the x700 sample even if the DV is cropped. The black bars will be grey but the rest should be fine


EDIT nop, its not the player...
p5 dune vs p5 x700 vs p8 dune vs p8x700: https://slow.pics/c/vuto1Dy6

[quietvoid]

It would be complicated to know if the HDR10 just has different chroma. That's pretty much the only difference I can see.
Would need a way to convert the DV ITP/IPT PQ colorspace into regular BT2020 PQ, but there's nothing public that does it all as far as I know.

Otherwise the only thing that comes to mind might be to change the min/max according to limited/full levels.
Since P5 is full, but the conversion doesn't change the numbers, only the flag.

[RESET_9999]

one more comparison...
p5 vs p8 vs HDR10: https://slow.pics/c/e1ssuSEG

I thought maybe the LLDV bug was acting up here but nop, I get a similar difference in tv-led: https://screenshotcomparison.com/comparison/16090

here are the clips if you want to check them yourself:
https://drive.google.com/file/d/1Lh7zmo ... sp=sharing,
https://drive.google.com/file/d/1Oqkvmz ... sp=sharing

but as you say, hard to tell if its the source or the conversion

[chros]

This must be it then, can you share your apk? Thanks

I'm not sure if it's going to be a different package, so backup first..
https://mega.nz/file/MdETXSAR#vPtlIY-nm ... NcRsZLlTyk

Thanks, the .ts file plays back as DoVi with your Kodi build (it's installed as a separate package). (The mkv that I created by dragging the .ts file into recent mkvtoolnix still plays back as hdr10.)
And indeed there's no banding/posterization, so my theory was wrong: Firestick 4k also triggers tv-led DoVi with our 2018 LG.
(That's a different thing that FireOS screwed up audio passthrough from external apps (not streaming ones) completely, and I have occasional stutter with high bitrate streaming profile 5 mp4 files )

[chros]

but as you say, hard to tell if its the source or the conversion

Or madvr?

[quietvoid]

(The mkv that I created by dragging the .ts file into recent mkvtoolnix still plays back as hdr10.)

Remuxing from TS is not supported, it won't copy the Dolby Vision config. Only MP4 or straight from the bitstream works currently.

here are the clips if you want to check them yourself:
https://drive.google.com/file/d/1Lh7zmo ... sp=sharing,
https://drive.google.com/file/d/1Oqkvmz ... sp=sharing

but as you say, hard to tell if its the source or the conversion

Thanks, I'll try to see if I can get anything different by playing with the metadata.

[RESET_9999]

but as you say, hard to tell if its the source or the conversion

Or madvr?

madVR?
exactly the same static settings were used and dynamic tone mapping was disabled. the difference is NOT caused by madVR.. plus as i said, I'm seeing the same difference in tv-led...

PQ comparison, no madvr involved: https://slow.pics/c/qZ8YCaN2

[Manixx2020beyound]

(The mkv that I created by dragging the .ts file into recent mkvtoolnix still plays back as hdr10.)

Remuxing from TS is not supported, it won't copy the Dolby Vision config. Only MP4 or straight from the bitstream works currently.

here are the clips if you want to check them yourself:
https://drive.google.com/file/d/1Lh7zmo ... sp=sharing,
https://drive.google.com/file/d/1Oqkvmz ... sp=sharing

but as you say, hard to tell if its the source or the conversion

Thanks, I'll try to see if I can get anything different by playing with the metadata.

So Im wondering the p5 funky colors are not created in post only the final stages of doblyvision encoding
While pulling from the doblyvision 12bit master & xml data simultaneously true SDI
To create a profile 5 FULL color & Rpu
To my knowledge the 12bit master is not in done in doblyvision itcp protocol
& I’m sure the color conversion from 12bit master to p5 produces similar differences form the 12bit master as well.

We should test more uhd p8 conversion
To see what the consistency in the results are,
So far I like the hybrid p8 look, I don’t know how u guys feel about it seems to minus some of doblyvision flaws from their original proces

[RESET_9999]

also, it looks like the weird lines (ringing???)mostly in the blue are caused by profile 5 DV decoding because I can see them in TV-LED DV as well while the p8 DV is clean like HDR10.

they dont seem to be present in the p5 source:
p5 clip, no capture no tonemapping VS p8 capture , no tonemapping: https://slow.pics/c/x0YGLSYn


there is also the metadata that are different in the RPU and the BL:

We should test more uhd p8 conversion
To see what the consistency in the results are

i agree



@quietvoid, i was looking at the rpu and i noticed this, shouldnt the p8 file set to 0 here ?

Remuxing from TS is not supported, it won't copy the Dolby Vision config. Only MP4 or straight from the bitstream works currently.

on my end, the only way I can get a DV MKV with your p5 to p8 conversion is by using Makemkv.

raw hevc with mkvtoolnix = no DV
mp4 dv with mkvtoolnix = no DV
ts DVwith mkvtoolnix = no DV

even when I simply remux the makemkv DV file with mkvtoolnix, i still lose DV metadata.