Dolby Vision now possible through MP4 Mux.

[aboulfad]

Only DV5 with an IPT BL and DV8.4 with an HLG BL should trigger DV playback, because those are the only profiles supported by the ATV4K.

It seems, that ATV 2021 does not use the RPU for HLG based P8.4 videos either. I checked with RESET_9999 videos.

Very interesting, so I played those files (including P5 fake/real) and I notice some periodic changes in the video stream of some of them (hue changes ?) but I couldn’t find explanation on how to interpret the usage of those test files. I did search here too, any clues/tips is greatly appreciated.

I feel really silly because I never got past the red screen in some of those files until now ... I thought the DV file was not being displayed correctly. Here's my noob observations for some of those test video files (P5/P8) using Infuse 7.3.10/ATV4K/LG E7:

1. RPU TEST SL fake p5.mp4 : dvhe.05.06, BL+RPU, BT.2020/PQ
- DV triggers, red screen, bunch of text on red/blue/red screen, scary guy staring at me
- I can't tell wether there's some scene by scene adjustment regarding to RPU
- According to recently found comment and that video display full screen, ATV 4K is not reading RPU from my created DV P5 using yusesope mode 2

2. RPU TEST SL real p5.mp4: dvhe.05.06, BL+RPU (missing meta data)
- DV triggers, some video aspects are periodically changing: brightness, hue, ... ?
- In some scenes I do notice the lights (specular highlights ?) are kinda bright.

3. RPU TEST SL p8.mp4: dvhe.08.06, BL+RPU, BT.2020/PQ
- same as (1) above

4. HLG DV P8 in sync.mp4: dvhe.08.07, BL+RPU, BT.2020/HLG
- can't tell much

[manuelrn]

And in those cases, would it be possible for dovi_tool to omit those EOS/EOB NALUs and keep only the last one? (when muxing and injecting)
That is, if dovi_tool finds any EOS/EOB NALUs it checks if it is the last frame of the video, and if it is the last frame then dovi_tool keeps EOS/EOB NALUs but if it is not the last frame then it does not write that EOS/EOB NALUs.

No, it wouldn't be able to know how many frames there are.
I'd also rather not discard anything unnecessarily.

There's indeed a bug in 1.5.0 for files with multiple EOS NALUs present.
I'll add some tests and push the fix later.

Okay, you're right.

Just to make sure, that bug is already fixed in version 1.5.1, correct?

Thank you!

[Godmax]

Is there a command with ffmpeg to add black bars to a cropped 4k Dolby Vision video file? Can be mkv or m2ts or ts doesnt matter.

[RESET_9999]

Found this 2019 comment from @reset_9999

the FEL and RPU test files can also be used to find out if your device uses the L5 active area metadata in the RPU. if it uses L5, there will be black bars otherwise it will be fullscreen.

I'm not aware of any HDMI device that uses L5 metadata the way the TV's internal player does.
I really don't understand how L5 works on HDMI devices. Seems they all ignore it and are not affected by the issue described here: viewtopic.php?p=121490#p121490

[quietvoid]

Just to make sure, that bug is already fixed in version 1.5.1, correct?

Thank you!

Yes, see release notes: https://github.com/quietvoid/dovi_tool/ ... /tag/1.5.1

mux: Fixed repeating EOS NALUs by default. Fixes #146.
This only affected the default muxing options. If using --eos-before-el, the output file was correct.

[aboulfad]

Found this 2019 comment from @reset_9999

the FEL and RPU test files can also be used to find out if your device uses the L5 active area metadata in the RPU. if it uses L5, there will be black bars otherwise it will be fullscreen.

I'm not aware of any HDMI device that uses L5 metadata the way the TV's internal player does.
I really don't understand how L5 works on HDMI devices. Seems they all ignore it and are not affected by the issue described here: viewtopic.php?p=121490#p121490

I am terribly sorry, I realized now I may have mis quoted your comment in my above response. My thread of questions were all related to P7 converted to DV P5 dvdhe.5.06 BL+RPU and may have confused L5 with P5 ? I still have to read/learn about RPU metadata to understand the link above. Ah DV metadata levels !!!
I am just searching in posts to learn about the video test files you made and how to interpret them on my device chain. Merci ; - )

[aboulfad]

@nekno I re-created some DoVi mkv from my BD UHD and re-used the tools to create what I did a year ago. As you already know, yusesope tools convert P7 to P8 and mp4muxer slaps on a DoVi P5 header. It seems that is enough to fool Infuse to display DoVi so did my LG E7 internal player !!! So yeah "fake" or "frankenstein" DV P5 file for free.

As far as color space, RPU and all this stuff, I don't know what's happening. It's hard to compare with a movie without knowing the details of what is supposed to be. The test file was 10s so too short. Anyways its fun to learn all these tools (including dovi_tool), thanks to all : )

[mtotheb]

Have you guys ever come across a Profile 8 (dvhe 08.06) in an UHD Bluray? I thought only Profile 7 was used in these but the German Release of Lamb from Koch Media surprisingly is encoded like that.

[quietvoid]

Have you guys ever come across a Profile 8 (dvhe 08.06) in an UHD Bluray? I thought only Profile 7 was used in these but the German Release of Lamb from Koch Media surprisingly is encoded like that.

I also think UHD BD is supposed to be profile 7 only.

[RESET_9999]

Have you guys ever come across a Profile 8 (dvhe 08.06) in an UHD Bluray? I thought only Profile 7 was used in these but the German Release of Lamb from Koch Media surprisingly is encoded like that.

do you have the BDinfo report of the disc ?

[mtotheb]

So in makemkv it says "HEVC Main10@L5.1 (dvhe.08.06 BL+RPU)" about the source.

The HEVC File is "Dolby Vision, Version 1.0, dvhe.08.06, BL+RPU, Blu-ray compatible / SMPTE ST 2086, HDR10 compatible" ~ MediaInfo

But they even forgot to set the dvhe flag. I'm guessing that Bluray Players would just fallback to the HDR10 can't test it tho

I've also never seen a commercial uhd bluray being encoded with x265:

Writing library : x265 3.4+31-6722fce1f:[Mac OS X][clang 11.0.0][64 bit] 10bit
Encoding settings : cpuid=1049583 / frame-threads=4 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x2160 / interlace=0 / total-frames=0 / level-idc=51 / high-tier=1 / uhd-bd=1 / ref=3 / no-allow-non-conformance / repeat-headers / annexb / aud / hrd / info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=1 / keyint=24 / gop-lookahead=0 / bframes=4 / b-adapt=2 / no-b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=8 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=1 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=1 / selective-sao=4 / early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=0.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / bitrate=60000 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=80000 / vbv-bufsize=60000 / vbv-init=0.9 / min-vbv-fullness=50.0 / max-vbv-fullness=80.0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=9 / transfer=16 / colormatrix=9 / chromaloc=1 / chromaloc-top=2 / chromaloc-bottom=2 / display-window=0 / master-display=G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,1) / cll=420,69 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion / hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass

[RESET_9999]

The HEVC File is "Dolby Vision, Version 1.0, dvhe.08.06, BL+RPU, Blu-ray compatible / SMPTE ST 2086, HDR10 compatible" ~ MediaInfo

it says that on the original M2TS file on the bluray disc?

the (A24 Exclusive) bluray is FEL DV:

Code: Select all

Disc Size: 62,679,376,060 bytes
Protection: AACS2
Extras: Ultra HD, BD-Java
BDInfo: 0.7.5.9

PLAYLIST REPORT:

Name: 00800.MPLS
Length: 1:46:27.589 (h:m:s.ms)
Size: 56,098,996,224 bytes
Total Bitrate: 70.26 Mbps

(*) Indicates included stream hidden by this playlist.

VIDEO:

Codec Bitrate Description
----- ------- -----------
MPEG-H HEVC Video 55879 kbps 2160p / 23.976 fps / 16:9 / Main 10 @ Level 5.1 @ High / 4:2:0 / 10 bits / 1000nits / HDR10 / BT.2020
* MPEG-H HEVC Video 7688 kbps (12.09%) 1080p / 23.976 fps / 16:9 / Main 10 @ Level 5.1 @ High / 4:2:0 / 10 bits / 1000nits / Dolby Vision FEL / BT.2020

[mtotheb]

Yup that's straight off the Bluray. Great to know that the distributer here completely disregarded the FEL in probably the most unusal way for a bluray release

[quietvoid]

It should probably be compared to the FEL disc, in the hope that they're the same.

[nekno]

I've also never seen a commercial uhd bluray being encoded with x265:

Writing library : x265 3.4+31-6722fce1f:[Mac OS X][clang 11.0.0][64 bit] 10bit

Found this site a while back claiming x264 compliance testing by Criterion, and Warner BD discs encoded with x264, so if true, I guess not a big surprise that x265 would be used in commercial UHD BDs.

More surprising might be doing the encoding on that Mac they had in the editing bay...