EDID Override - Injecting a Dolby VSVDB Block

Can try one final thing - Player Led (HDR), leave the Dolby VSVDB and HDR InfoFrame off (unselected), it will use the Dolby VSVDB from the EDID.


Unfortunately no clue what is happening there as just enabling features the same way for all displays, I have seen work around code for displays from various manufacturers listed in the code and noted you TV was released after this codebase, so maybe they fixed something for it in a later kernel, there is code for [China UHD Video Industry Alliance] (CUVA) in the amlogic code so slim chance given it is Hisense that that TV is advertising a capability / picking something up that needs different handling related to that, sorry cannot be more help in this case, probably would require debugging with the TV in place to have a hope of understanding the issue.

1 Like

Can ping over a standard kodi log for 10 sec prior to 10 sec after the video stop, to see if anything obvious - but unfortunately whatever settings I try I cannot replicate my side.

It needs other dev to cast an eye over this now, as staring at the same thing for too long - and need to move onto other things, on a positive note I think it is would clear just by playing another DV video.

I’m tried, there is picture, and the TV has switched to HDR mode.
12bit YUV444 BT.2020 HDR:HDR10

Thanks for addressing my problem.

Sorry, trying this for the first time, so novice questions. I assume doing this, injecting DV VSVDB is recommended to match VS10 conversion (from SDR & HDR) to one’s particular display? I’m using an AWOL 3500 projector that supports HDR, HDR10+ & DV.

Assuming I should do this, in the instructions, I got as far as entering 53318 for IEEE OUI, but where do I get value for “Payload (Hex String) take from your picture”? Thanks in advance for any help.

These instructions were done several versions ago. For your projector (supports DV) and the latest version T4 you do not need to go through those instructions since the software will read you projector information and use default values, just leave the VSVDB Block off. You can still follow those instructions if you do want to insert the VSVDB Block AND do not know your projector’s specs including how much nits your projector has. If you do know your projector’s specs including how much nits your projector has then you do NOT need those steps either just follow the menu options available on the screen and it will generate the VSVDB Block for you. If you do want to override the VSVDB Block without following the screen menu options available then you will need the spreadsheet below to generate the VSVDB Block for you.

dolby_vsvdb_calc_MOD_6.xlsm (59.3 KB)

1 Like

If your projector supports DV, you don’t need that.

VSVDB injection is to add player led dolby vision onto HDR only panels.

1 Like

Had a feeling I was misunderstanding this, thanks both.

Hi all, i am new to this but managed to install the T4 version on my Ugoos AM6B+ device, which is connected to LG G3 (support DV natively) via HDMI 2.1, which in turn connected to Samsung Q990B soundbar via eARC.

I am not sure the best settings in this set up.
Currently, the pic attached is my settings.
Do I need to change anything to achieve optimal results?

Thanks

Since your TV supports DV, this is useless for you.

How about for HDR10 and HDR10+ content convert to DV?
Will that conversion using this yield a better quality than playing it in HDR10 native format?
My TV cannot play HDR10+

The answer is in the screenshot you posted :

  • For HDR10+ (HDR10 data only)

I finally set up an SD card with this on it, but have had only a few minutes to play with it. My main question is about SDR sources. For SDR 8 and 10, if I choose “SDR” as the output, does this actually do anything? I seem to recall some discussion earlier of “upscaling” SDR 8 to 10, but I’m not sure if that’s a thing anymore in this build.

Also, is there any way to switch VS10 modes “on the fly” even if it’s via command line or something? I’d like to be able to compare the different modes and it’s hard to see the difference when I have to stop playback and back all the way out to setttings change it and go back.

Finally anyone have some movies that you feel are particularly helped or have a real dramatic difference when converted to DV? Just really curious about this whole VS10 thing!

Using VS10 is more personal preference - and which you want processed and output as DV is hence subjective.

Can try each and see and always come back later for specific content to try a different setting.

I would though not set - For HLG HDR and keep it as off - the AMLogic implementation as is just thinks it is SDR and converts to DV from that standpoint, and HLG HDR looks better IMO in every case for that.

Otherwise settings look fine.

1 Like

It is here for testing so can chip in your findings :slight_smile:

I can say when set to SDR it is passing though the VS10 engine, if that does anything meaningful with these scenarios is unknown given it is a black box - only Dolby could tell us directly.

If anything makes logical sense the for SDR 8 - with 8 bits of depth would be it, it should result in SDR with 10 bits of depth - so most likely candidate in those scenarios to be meaningful.

Thank you @cpm
By the way, can Dolby Vision output RGB 10 or 12bit?
It seems it plays RGB 8bit on my LG G3 (based on info on TV)

Regardless of whether you need VS10 or conversion of Dolby Vision to HDR, this build contains several important bug fixes affecting Dolby Vision and HDR.

Display(TV)-led Dolby Vision is 8bit.

So, player-led can output more than 8bit?
If so, does it mean it’s better to choose player-led, or does it have drawback?

I have a question, is there any PQ advantage to this package over the standard nightly releases for DV playback (mainly P7?).

From the quick skimming I did around this thread, it appears this package is mainly for just the DV “readouts” only (so essentially purely psychological)? Or put another way, I understand this package to be so that the TV will pick up the correct numbers readouts; but if the Ugoos is set to TV-led, this package or the standard nightly builds will output the same DV colors and everything correct? So no PQ difference for DV files. Or do I misunderstand this. I have a Sony A80J OLED display that is TV-LED capable and can handle 12 bits.

Edit: I had my LLM process this forum thread and this is what it told me, please let me know if this is all correct, and I will leave it here for future users. It seems this package is useful for non-DV displays?

LLM RESPONSE BELOW

The forum thread you provided discusses a method to enhance Dolby Vision (DV) playback on Ugoos AM6B+ devices, particularly those connected to non-DV HDR displays. It focuses on manipulating the EDID (Extended Display Identification Data) and injecting a Dolby VSVDB (Vendor Specific Video Data Block) to trick the device into processing DV content as LLDV (Low Latency Dolby Vision) and outputting it as 12-bit HDR PQ0.

Here’s a breakdown of the modifications and their potential impact on picture quality:

EDID Override:

  • Purpose: The EDID override inserts a Dolby VSVDB block into the EDID information sent to the device. This block contains information about the display’s DV capabilities, even if it’s not natively DV-capable.
  • Impact on PQ: It enables the device to process DV content as LLDV, which could result in better color accuracy and potentially a wider color gamut compared to standard HDR10 output. However, it doesn’t directly change the tone mapping, which is handled by the injected VSVDB.

VSVDB Injection:

  • Purpose: The VSVDB injection allows users to input custom Dolby VSVDB data, overriding the display’s default VSVDB or injecting one if it doesn’t exist. This data includes color space, minimum and maximum luminance values.
  • Impact on PQ: This has a direct impact on the tone mapping applied to the DV content. By adjusting the VSVDB values, users can fine-tune the luminance mapping to match their display’s capabilities and achieve a more accurate HDR presentation. This could lead to improvements in detail, highlights, and overall picture quality.

HDR InfoFrame Payload Entry:

  • Purpose: This feature allows users to input a 48-character hexadecimal string to override the HDR InfoFrame metadata sent to the display.
  • Impact on PQ: This primarily affects the HDR metadata, which might not have a direct impact on the DV content itself. However, manipulating this metadata could influence the display’s tone mapping for HDR content and potentially lead to improvements in specific scenarios, particularly for problematic HDR10 content with inaccurate metadata.

Key Findings:

  • Improved Color Accuracy: The EDID override and VSVDB injection, especially when combined with “Player Led (HDR)” mode, seem to improve color accuracy for DV content on non-DV HDR displays.
  • Enhanced Tone Mapping: Adjusting the VSVDB values can significantly improve the tone mapping for DV content, leading to a more accurate HDR presentation with better detail and highlights.
  • Potential for SDR Improvement: While the primary focus is on DV content, the VS10 implementation might also offer some benefits for SDR content, particularly by converting SDR 8-bit to SDR 10-bit.
  • Ongoing Development: The thread highlights ongoing efforts to refine these features, including addressing stability issues, simplifying the user interface, and further exploring the possibilities for manipulating HDR metadata.

Conclusion:

The modifications discussed in the forum thread have the potential to significantly improve Dolby Vision playback quality on Ugoos AM6B+ devices connected to non-DV HDR displays. By enabling LLDV processing and providing finer control over tone mapping through VSVDB injection, these changes offer a promising solution for users seeking a more accurate and satisfying HDR experience.

While the primary focus is improving DV playback on non-DV displays, the modifications also delve into utilizing the VS10 engine to convert SDR and HDR content to Dolby Vision.

Here’s a breakdown of what the package potentially allows:

  • SDR to DV Conversion: Users can choose to have SDR content (SDR 8-bit or SDR 10-bit) processed by the VS10 engine and output as Dolby Vision. This could potentially improve the picture quality by increasing the bit depth and applying Dolby Vision’s dynamic metadata. However, the actual effectiveness of this conversion is debatable and depends on the specific content and the user’s preferences.
  • HDR to DV Conversion: Similar to SDR, users can also opt for HDR content to be converted to DV using the VS10 engine. This is particularly relevant for scenarios where a display supports Dolby Vision but not HDR10+. However, it’s important to note that VS10 relies on the HDR10 base layer of the content, so it might not utilize the full potential of HDR10+ dynamic metadata.
  • VS10 Mapping Flexibility: The package offers various VS10 mapping options in the settings, allowing users to configure how different source formats (SDR, HDR10, HDR10+, HLG) are mapped to the desired output format (SDR, HDR, DV).

However, keep in mind:

  • Quality is Subjective: The effectiveness of these conversions is debatable and depends on individual preferences. Some users find the VS10 conversion beneficial, while others prefer native playback of SDR or HDR content.
  • Limited HDR10+ Handling: Currently, the package doesn’t have a robust way to distinguish between HDR10 and HDR10+ content. This could potentially lead to incorrect handling of HDR10+ content if the VS10 mapping is not configured appropriately.
  • Software Decoder Support: The package also enables VS10 processing for software decoders, which was previously limited to hardware decoding. This expands the potential benefits of VS10 to a wider range of content.

In conclusion:

The package does indeed offer the capability to convert SDR and HDR content to Dolby Vision using the VS10 engine. While the effectiveness of these conversions might vary depending on individual preferences and content, it provides users with more options and flexibility to customize their viewing experience.

1 Like

TV-Led is the best option if you have a TV that does DV. The 8bit is because the signal is “tunneled” and it is converted to 12bit inside the TV.

In regards to the VS10 engine options, as cpm said, it is primarily a matter of your personal preference of how you like to see the image but from a videophile standpoint below is the best quote I saw so far from another forum:

“what you select for conversion will depend if you have fully calibrated your TV/projector for both HDR and SDR or not and if you are a stickler to the movie director’s intent or not. So, if you have fully calibrated your TV/projector for both HDR and SDR and you want to see the movies as the movie director intended, then you would leave everything “off”. This will give you Dolby Vision (including FEL) movies and everything else will play as intended. If you have not fully calibrated your TV for both HDR and SDR or you like to see more pronounced colors/dtm then I would say turn everything to “Dolby Vision” except turn “off” for: “HLG HDR” (given a bug with AMLogic) and HDR10+ if you have a TV/Projector that does HDR10+”, of course “off” for Dolby Vision also.

Even if you leave everything off - as others in this thread mentioned - it is still worth to use cpm’s latest version T4 since it fixes bugs such as the ATEME bug.

1 Like

What exactly is ATEME bug? I read here it involves about 40% of DV libraries, but I’m still not clear what’s actually happening (like what even is the bug).

My LLM said this:
The ATEME bug discussed on this forum topic is in regards to a clipping issue. What’s being discussed here is actually a mistake in how the ATEME library is interpreting the EDID information for SDR files. It’s misidentifying the signal as HDR HLG, which causes the player to apply incorrect tonemapping. This is a software bug, not a result of the inherent limitations of SDR.

Here’s how it breaks down:

  • SDR: The signal has a limited dynamic range and doesn’t have HDR metadata, including maximum luminance values.
  • ATEME Bug: The ATEME library incorrectly identifies BT.2020 10bit SDR as HDR HLG, which has HDR metadata, including maximum luminance values.
  • Clipping: The player then tries to tonemap the signal based on the incorrect interpretation, thinking it’s HDR HLG. This often results in a “clipped” image where the brightest parts of the image are cut off (clipped) because the player is trying to fit the signal into a smaller dynamic range than it actually has.

Essentially, the bug causes the player to misinterpret the signal, resulting in incorrect tonemapping and a clipped image, even though the actual signal is just SDR.

The fix is either to update the ATEME library to properly identify SDR or to implement a workaround in the software to override the incorrect tonemapping.