Dolby Vision now possible through MP4 Mux.

[RESET_9999]

I just pushed a new version to fix the "Soul 2020" DoVi RPU parsing once converted to profile 8.
You can find it here: https://github.com/quietvoid/dovi_tool/ ... /tag/0.3.5

Played Soul a bit with a sample and there were some noticeable brightness adjustments at scene changes.
Maybe because of the different black bars, I'd have to test more. This was simply mode 3 and removing the first 40 frames.

thank you!
we definitely have a different version because on mine the frame difference is 56 and there is no black bars mismatch
I'll give it a go later but last night i watched 30 minutes of something else and there was absolutely no brightness jump. it looked amazing actually.

I'm able to remove / add frames at the start of the video with the json edits but I still don't understand how to add or remove frames at the end, every time i get ''error expected value'' ...SMH I'm stupid...

I tried to create an mp4 with mp4muxer (2020.03.06.) from the above files, but now everything plays it back as hdr10, even the Oppo:

Code: Select all

mp4muxer.exe --dv-profile 8 --input-file injected_output.hevc --input-file audio.ac3 --dv-bl-compatible-id 1 --output-file 1try.mp4

@quietvoid, do you know why?

is this version the latest one? because the new version doesnt work for me as well .. you have to use the very first version of the mp4muxer.

this one: https://drive.google.com/file/d/1yZ1EgB ... sp=sharing

[quietvoid]

thank you!
we definitely have a different version because on mine the frame difference is 56 and there is no black bars mismatch
I'll give it a go later but last night i watched 30 minutes of something else and there was absolutely no brightness jump. it looked amazing actually.

I'm able to remove / add frames at the start of the video with the json edits but I still don't understand how to add or remove frames at the end, every time i get ''error expected value'' ...SMH I'm stupid...

I was just testing so didn't bother syncing the RPU properly, just tried to get the same length. That's probably why there was slight flicker.
This is what my JSON would look like:

Code: Select all

{
    "mode": 3,
    "active_area": {
        "crop": true,
        "presets": [
            {
                "id": 0,
                "left": 0,
                "right": 0,
                "top": 276,
                "bottom": 276
            }
        ],
        "edits": {
            "0-144684": 0
        }
    },
    "remove": [
        "0-55"
    ],
    "duplicate": [
        {
            "source": 144627,
            "offset": 144627,
            "length": 16
        }
    ]
}

I'm not sure if changing the black bars makes a difference, but Dolby Vision metadata often has odd numbered offsets (275 instead of 276).
Played the same sample and it looked perfect.
There's a slight frame freeze in the middle of it. Not sure what happened there. Happens when playing in HDR10 as well, so maybe the inject did something..

Also, when adding duplicated metadata, the process is done after removing. So that's something to keep in mind as well.

Your .ts file and when I remux it as MKV both play in DoVi on my Firestick with Kodi.

Thank for checking, still not here Also when I drag the ts file into recent mkvtoolnix, the mkv file also plays back as hdr10 with Kodi. (When I removed other files from the directory, Plex finally recognizes the ts file and plays it back as DoVi.)
Which Kodi version do you use? I have Kodi19DV-Final-libbluray-aarch32.apk from here (end of Feb 2021).
And yesterday when I switched on the Firestick after couple of weeks, there was an OS update again (I hate those), maybe that's why ? (Profile 5 mp4 files are still fine.)

But since you have a working sample, you can try out playing it back on your 2018 LG, from Firestik+Kodi and from Plex to be able to compare? Plex should be fine without issues, but if my guess is right, you should see heavy banding / posterization from Firestick+Kodi (meaning it only triggers player-led).

I'm using my own build of Kodi, but it uses nightly so v20 N * and FFmpeg 4.4
I looked at the sample on both the TV's player and Firestick but there's not much difference for me.
The most noticeable thing is that the Firestick has worse near black gradients on the fade out of the Doom Patrol logo, so it shows as a black blob moving.

[RESET_9999]

I was just testing so didn't bother syncing the RPU properly, just tried to get the same length. That's probably why there was slight flicker.

yep, it for sure is the reason why it flickers. The bluray Vigilante dv metadatas are clearly out of sync and when I watched it, I was amazed at how dynamic DV really is. There's a brightness changes literally every scene and sometimes, even on camera view changes.

Thank you for your JSON script, that's all I needed to understand how it works

[chros]

I looked at the sample on both the TV's player and Firestick but there's not much difference for me.
The most noticeable thing is that the Firestick has worse near black gradients on the fade out of the Doom Patrol logo, so it shows as a black blob moving.

So, you don't see banding/posterization? That's promising ...

I'm using my own build of Kodi, but it uses nightly so v20 N * and FFmpeg 4.4

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

[quietvoid]

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

Apparently my injected Soul video is corrupted near (if not directly) at a seamless branching boundary. Looking into it..
Edit: Seems to be caused by the source video being extracted by FFmpeg.
No corruption in the source when using mkvextract.

[RESET_9999]

Apparently my injected Soul video is corrupted near (if not directly) at a seamless branching boundary. Looking into it..
Edit: Seems to be caused by the source video being extracted by FFmpeg.
No corruption in the source when using mkvextract.

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.

[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