Tunnel DV for non DV capable TVs

Development Feature Requests
1

Hey @Portisch I’ve been playing around with the latest amlogic-no on my new X96 X10. My TV is a Samsung S90C, which isn’t DoVi compatible. Noticed that if I try to play a DoVi P5 test file, it actually plays fine and the comparison between scenes with no metadata and dovi tuning applied clearly shows that there is dynamic tonemapping going on. The debug command below shows dv_mode = HDR10

watch -n1 'echo "--- src_format ---"; cat /sys/class/amdolby_vision/src_format; echo "--- dv_mode ---"; cat /sys/class/amdolby_vision/dv_mode | grep current; echo "--- hdr_status ---"; cat /sys/class/amhdmitx/amhdmitx0/hdmi_hdr_status; echo "--- config ---"; cat /sys/class/amhdmitx/amhdmitx0/config'

--- src_format ---
vd1(inst1): DV FORMAT_DOVI
vd2(inst0): DV FORMAT_INVALID
graphic: FORMAT_SDR
--- dv_mode ---
current dv_mode = HDR10
--- hdr_status ---
HDR10-GAMMA_ST2084
--- config ---
VIC: 93 3840x2160p24hz
Colour depth: 10-bit
Colourspace: YUV444
Colour range: default
EOTF: HDR10
YCC colour range: default
Colourimetry: BT.2020

This is awesome, but it only works if the file is P5. If there is any “fallback” hdr data, then that gets played instead, and dv_mode = off. I have figured out a way to enable it for all dovi files though:

  1. Patch display edid to include a vsvdb block that pretends my display is compatible with player led dovi only
  2. Before playing any dovi files, run:
echo 2 > /sys/module/aml_media/parameters/dolby_vision_policy
echo 3 > /sys/module/aml_media/parameters/dolby_vision_mode
echo 3 > /sys/class/amdolby_vision/dv_mode

Now, if I play a file that has fallback hdr, dv_mode = HDR10, instead of off, so I believe it is working through vs10.

I’m pretty sure it should be able to do this without the EDID hack because the code that enforces it for P5 appears to be in CoreELEC/xbmc AMLCodec.cpp:2114 (won’t let me post a link, sorry). Is there a reason that it is done like this? A toggle that allows kodi to treat non dv compatible displays the same as it does for profile 5 would be very useful. I am new to CoreELEC so apologies if I’m missing something obvious here.

Amlogic-NO discussion
2

There is no need for a DV to HDR10 conversation when another HDR format is available.
It’s only the VS12 DV to HDR conversation is active because of the missing fallback.

I doubt the result is better then the mastered HDR fallback…

3

I agree for bright displays like the QD-OLED, this is mostly just a curiosity, but isn’t the whole reason that dolby vision and hdr10+ exist because dynamic tonemapping addresses drawbacks of “standard” HDR10 on displays that aren’t as bright (e.g. projectors), and can provide significantly better images (hence the popularity of LLDV EDID “hack” devices such as the hd fury)?

l can open a pull request if you are willing to entertain the idea of including a toggle for this in the “expert” settings.

4

Provide a sample in DV and fallback like this sample 1 minute HDR10+ system test - FF Pictures GmbH | Florian Friedrich to check if this is true. HDR10 is commonly known as not dynamic. So I would wonder when DV to HDR10 becomes dynamic.

Might you try echo 4 > /sys/module/aml_media/parameters/debug_dolby and check the md data while playing if it does change.
But I am not sure if this “before” processing or “after” or if it’s the DV metadata, what is dynamic.

Such way is much easier as CE-22 support EDID override by dump. So just make your “hack” EDID and enable features the TV don’t support…

Or just get a TV what support the format you want to use?

5

The EDID overriding is great, but these devices also inject the hdr infoframe so that non DV devices can play the LLDV content. As far as I thought, only the old amlogic-ng forks did that.

I’ll do some testing with a DV file that has HDR fallback to confirm whether or not dynamic tonemapping is active as it is in the case when playing a P5 file. If not, my original plan when I started playing around was to try and get the hdr infoframe injection stuff working in the new kernel anyway.

6

Yes, we know such behaviour for some forks.
But here is CoreELEC forum and such handling is not supported as it’s useless.

Get hardware what does support the DV chain to be able to enjoy best art of the media what is possible.

I got a new TCL just right now by myself supporting DV, HDR10+, HDR10, HLG native.
It just works, nothing to do.

7

Hey @Portisch. I did a quick test before heading off to work so excuse the poor camera handling. These are tests on a profile 8 sample. The Dovi_on file has the VDVSB EDID hack + changing those dolby_vision parameters before running the file. Reported dv_mode is HDR10. The other file is using my default edid with no tweaks. It’s running the fallback HDR, so it is completely static. The reported dv_mode in this case is off. So yes, it looks like the dolby vision driver is doing some dynamic tonemapping and then outputting plain HDR10.

8

Please share this sample so I can make local tests with it.

9

I have added the test files to the google drive folder where I posted the videos from my last post. They are from here. I have also uploaded my own generated test files that are just a grayscale pattern. The names are self explanatory. I did look at the debug metadata output as you suggested and it is definitely going through the dolby vision engine.

EDIT: I have a working fork of CoreELEC/xbmc that adds a toggle for this DoVi to HDR10 functionality and also lets the user set the max brightness of the display when enabled.

2 Likes
10

I only need one to test, so which one did you use?
I don’t want to search through hundreds of samples…

11

Mate, if you read my post I said I put them in my google drive directory:

No need to search through hundreds of tests..

You can use dv_test_p8.mp4 or either of the “10 000nits…” ones for a profile 8 test file.

The “10 000nits…” files, difference is most evident after 1 min playtime. I made dv_test_p8, so it flashes from the beginning if dovi is working.

12

There are statements that vs10 engine can do this in various locations. Here are two.

Zidoo forum post:

However, if you set HDR to “Dolby Vision VS10 Engine (For DV content)”, because your TV is HDR10, this will use the dynamic metadata present in the Dolby RPU as it converts to HDR10 in a similar way to how LLDV works

R_volution help docs:

If your TV is not supporting Dolby Vision, the Dolby Vision content will be converted and the R_volution will output HDR10 or HDR10+ according to your display through the VS10 engine.

13

And I would also need your rawedid because we have no Samsung TV.

These samples ar P8, not P5:

So I can’t test your theorie.
I don’t start to fake VSVDB because all my TVs support real Dolby Vision.

When I can check dynamic metadata on P5 sample it might be possible to use same system for other profiles.

14

Okay, I mislabelled dv_test_p5.mp4. My bad. I have added the files requested:

  1. rawedid_original_s90c - self explanatory
  2. P5_test_other.mp4 - self explanatory. A P5 test file. Contents don’t matter.

With that EDID applied, the P5 file should play with correct colours through VS10 → HDR10. This is the standard observed behaviour on the latest CoreELEC nightly with my display.

Next, I have uploaded a patch kodi-enable-vs10-all-dv-profiles.patch (see my reply below for pre-compiled version):

Applies to CoreELEC/xbmc with a couple of lines and adds a toggle to use VS10 for P8 files as well (still need to test P7). No need for VSVDB trickery that I was using before.

To prove this, the P8 tests will flash when using DoVi metadata and completely static when it is just HDR10.

With my patch + EDID applied, run the P8 test file 10 000nits scene....mp4 from the 1 minute mark (it is most obvious after this point if you have bright TV):

Force Dolby Vision to HDR10 = ON: P8 test file will obviously be changing in brightness, indicating VS10 engine is actively tone-mapping DoVi to HDR10.

Force Dolby Vision to HDR10 = OFF: Screen will not flash. Default HDR10 metadata is being used and VS10 engine not active.

Please let me know if there is anything else you need for testing. Happy to discuss specifics once you have confirmed with your own testing, as there are still a couple of unanswered questions, such as injecting a brightness target for VS10 tone mapping as I’m not sure how it gets the value without VSVDB currently, but this post is long enough for now.

P.S.

Get hardware what does support the DV chain

Of course, but I do this for fun. Buying a TV that supports all of the formats is too easy :smiley:

1 Like
15

For anyone playing along who doesn’t want to compile kodi, I have also now added precompiled kodi-patched.tar.gz

To test it, extract as /storage/kodi-patched in your CoreELEC device (I assume you can get around ssh and extracting the tar!) and then put the following as /storage/.config/autostart.sh:

#!/bin/sh

mount --bind /storage/kodi-patched/usr/lib/kodi /usr/lib/kodi
mount --bind /storage/kodi-patched/usr/share/kodi/system/settings/settings.xml /usr/share/kodi/system/settings/settings.xml
mount --bind /storage/kodi-patched/usr/share/kodi/addons/resource.language.en_gb/resources/strings.po /usr/share/kodi/addons/resource.language.en_gb/resources/strings.po

chmod +x /storage/.config/autostart.sh and reboot. The toggle should appear: Settings->System->CoreELEC->Force Dolby Vision to HDR10

No promises on keeping it updated, I just added it for anyone if they want to test. To revert, rm -r /storage/.config/autostart.sh /storage/kodi-patched && reboot.

2 Likes
16

Sure it does matter! For a real test I will need to check dynamic metadata change on DV P5.
And then check if same happen on VS10 HDR10.

Instead of making new user settings that confuse people even more, make the system smarter. If the fallback is none or HDR10 → use VS10. If the fallback is HDR10+ → use fallback.

No user setting will be need…

1 Like
17

The file is is a good test as it has lots of scenes with changing metadata. The actual scenes being displayed are pretty irrelevant is what I meant.

Instead of making new user settings that confuse people even more…

I agree. Never planned to make a pull request with a toggle. It’s just a convenience for early testing.

Very curious to see a image or video comparison on your tv with actual DoVi vs my edid + VS10 doing the HDR10 output.

18

For me it looks like the VS10 take the DV metadata and apply it on the frames.
So the TV really see HDR10, not HDR10+ signal. But the frames itself is already “patched” to HDR10+.

I checked the point where the metadata get signaled to the TV:

But the meta data never changes while playback, but the frames brightness is visible changing.

This would also explain why I see the brightness changes on my Vertex2 & SDR screen.
Because on real HDR10+ format I never see such brightness changes as the system is not capable for dynamic HDR meta data.

So VS10 create a static HDR10 data and internal apply dynamic data to the source.
This way it fakes HDR10+ over HDR10.

I am not sure but I think ffmpeg is not able to detect the “fallback” format:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '10 000nits scene 1000nits MDL CMv4.0 AVGPQ-10 Level 1 max_pq steps DoVi.mp4':
  Metadata:
    major_brand     : mp43
    minor_version   : 0
    compatible_brands: iso4mp43dby1
    creation_time   : 2025-05-05T00:06:35.000000Z
    encoder         : GPAC-2.2.1-rev0-gb34e3851-release-2.2
  Duration: 00:05:10.23, start: 0.000000, bitrate: 1742 kb/s
  Stream #0:0[0x1](und): Video: hevc (Main 10) (hvc1 / 0x31637668), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 1740 kb/s, 23.98 fps, 23.98 tbr, 24k tbn (default)
    Metadata:
      creation_time   : 2025-05-05T00:06:35.000000Z
      vendor_id       : [0][0][0][0]
    Side data:
      DOVI configuration record: version: 1.0, profile: 8, level: 6, rpu flag: 1, el flag: 0, bl flag: 1, compatibility id: 1

Or:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'DV Analysis Tunings vs HDR10plus to DoVi (cmv4.0 P5 HDR10 4000nits MDL).mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 1
    compatible_brands: mp42dby1isom
    creation_time   : 2024-08-31T19:14:27.000000Z
  Duration: 00:14:56.06, start: 0.000000, bitrate: 2072 kb/s
  Stream #0:0[0x1](und): Video: hevc (Main 10) (dvhe / 0x65687664), yuv420p10le(pc), 3840x2160 [SAR 1:1 DAR 16:9], 2070 kb/s, 23.98 fps, 23.98 tbr, 24k tbn (default)
    Metadata:
      creation_time   : 2024-08-31T19:14:27.000000Z
      handler_name    : video handler
      vendor_id       : [0][0][0][0]
      encoder         : DOVI Coding
    Side data:
      DOVI configuration record: version: 1.0, profile: 5, level: 6, rpu flag: 1, el flag: 0, bl flag: 1, compatibility id: 0

It’s only the kernel see the two metadata parts:

[   64.584762] AMDV: [inst1]metadata type=02000000, size=32:
[   64.590076] AMDV: [inst1]metadata type=01000000, size=160:
[   64.595537] AMDV: [inst1]metadata(162):
[   64.599349] 00 00 00 01 19 08 09 08 40 61 36 50 6f 00 3f f8
[   64.604896] 01 ff c0 0f ff d0 00 00 08 00 00 06 80 00 00 40
[   64.610443] 00 00 34 00 00 02 00 00 01 c9 59 80 00 0d 7a 89
[   64.615989] 59 be 7f 3a c7 09 59 91 32 80 00 00 40 00 00 02
[   64.621536] 00 00 00 02 00 00 00 07 0d 88 90 c0 61 82 97 8c
[   64.627083] 23 81 45 00 00 00 69 8f 96 bf ff c0 00 00 00 00
[   64.632629] 00 00 00 18 08 1f 73 80 54 40 30 08 00 41 0a 66
[   64.638176] 80 80 50 00 00 00 00 00 00 01 20 c1 f4 00 06 40
[   64.643723] 00 00 00 04 41 20 05 0b 01 10 00 00 7f c0 00 40
[   64.649269] cc c9 f1 b5 80 00 00 00 00 00 00 00 00 00 00 00

#define HDR10P 0x02000000
#define DV_SEI 0x01000000
1 Like
19

Yes, VS10 is performing the tone mapping to static HDR10. I think this is almost exactly similar to taking the output data when doing player-led LLDV and injecting a HDR InfoFrame as people do with HDFury or the CPM forks. The only difference is that In those cases however, the VS10 engine does its tone mapping with target peak brightness based on the display capabilities signalled through the VSVDB.

For my curiosity, the last piece is what it uses for the max brightness target when performing the tone mapping, especially if it can’t get the display max brightness through EDID. Maybe it just targets a hard-coded 1000nits.

20

Okay, I’ve been testing for a couple of days and the dolby vision to HDR10 functionality of VS10 has a hard-coded 1000 nit target luminance. I should’ve read the threads on this forum for the @cpm fork, because this was already known.

I think that the functionality is designed for devices that have peak brightness lower than 1000 nits, and which have a decent transfer curves. This way, the Dolby Vision metadata can still be applied with a “standard” 1000 nit target for the artist’s intent, leaving it up to the display to do the final roll off for highlights above their capability. On displays with higher peak brightness, this leaves a bit of performance on the table.

Good news is that I have got the HDR InfoFrame injection code from the CPM fork working in the latest CE-NO. This allows using lldv with non-DoVi capable displays and works great if you want to specify the peak brightness. It is only a small modification to amdv.c to achieve this. The “flow” can then be either:

  1. user sets “dolby vision for incompatible displays toggle”
  2. Extra setting for display peak brightness value appears (only in expert mode).
  3. If this value is unset, then the built-in DoVi to HDR10 code path is used. Otherwise, the LLDV + HDR InfoFrame code path is used.

OR:

  1. User sets the “Dolby Vision for incompatible displays” toggle. The settings text informs them that they will need a custom EDID for targeting a peak brightness other than 1000 nits.
  2. If custom EDID with VSVDB is set, then the LLDV + InfoFrame code path will be used, otherwise the built-in DoVi to HDR10.

I will post a fork with polished amdv.c code on the weekend. I will also make a pull request if you’re interested @Portisch, but otherwise I am happy to maintain this small fork for myself and anyone else who wants to use it.

7 Likes