www.makemkv.com

Donpoku wrote: Sat Mar 30, 2024 2:08 pm Thank you, so st should be white almost invisible, right?

right, paler is better and it should be at least the same as the other tv-led devices.

RESET_9999 wrote:

Donpoku wrote: Sat Mar 30, 2024 2:08 pm Thank you, so st should be white almost invisible, right?

right, paler is better and it should be at least the same as the other tv-led devices.

Thanks again. Btw, how do I test for true TV-LED-i know am6b+ android is lldv just want to see difference.

Sent from my SM-F946B using Tapatalk

Donpoku wrote: Sat Mar 30, 2024 3:51 pm Thanks again. Btw, how do I test for true TV-LED-i know am6b+ android is lldv just want to see difference.
Sent from my SM-F946B using Tapatalk

I think the Plex and Kodi app support DV with the original Ugoos firmware. It won't be true tv-led but it should be interesting to test if it's the same.
AFAIK the only way to test true tv-led is with a capture card.

RESET_9999 wrote: Sat Mar 30, 2024 12:02 pm here I marked whats wrong with each device: https://slow.pics/c/0njV9U5X

I tested the same pattern on my Sony A95L and the results are quite different:
Ugoos (CoreELEC V21 - latest nightly 0330) and x800m2 seem to track ST2084 the same.
In contrast, the internal application is completely broken

Sorry for quality of photos

x800m2:


Ugoos:



Internal:

I guess this depends on the TV. Your colorspace conversion also looks wrong /different than mine.

I'm on 20.5 latest nightly btw

bbeny123 wrote: Sat Mar 30, 2024 4:14 pm x800m2 seem to track ST2084 the same.

are you sure though? From your pics it looks like there is a difference: https://slow.pics/c/SqFAiJKa

perhaps your room is too bright to see it? My pictures were taken in a pitch-black room without any light and my DSLR camera (not phone) settings are locked.

RESET_9999 wrote:

Donpoku wrote: Sat Mar 30, 2024 3:51 pm Thanks again. Btw, how do I test for true TV-LED-i know am6b+ android is lldv just want to see difference.
Sent from my SM-F946B using Tapatalk

I think the Plex and Kodi app support DV with the original Ugoos firmware. It won't be true tv-led but it should be interesting to test if it's the same.
AFAIK the only way to test true tv-led is with a capture card.

Thx. Re-cmv4.0 tests patterns earlier- does reading the black texts at the top definitely confirms cmv4.0 hardware compatibility?

Sent from my SM-F946B using Tapatalk

Donpoku wrote: Sat Mar 30, 2024 5:19 pm
Thx. Re-cmv4.0 tests patterns earlier- does reading the black texts at the top definitely confirms cmv4.0 hardware compatibility?

No. When cmv4.0 is active, you will see brightness changes in the image at each metadata change.

cmv4.0 test file on cmv4.0 hardware:




cmv2.9 test file on any hardware

RESET_9999 wrote: Sat Mar 30, 2024 5:04 pm are you sure though? From your pics it looks like there is a difference: https://slow.pics/c/SqFAiJKa

perhaps your room is too bright to see it? My pictures were taken in a pitch-black room without any light and my DSLR camera (not phone) settings are locked.

https://slow.pics/c/Hn8RGz0x - unfortunately i don't have a better camera than a smartphone.
To the naked eye they look the same to me.

And as for the color space, in reality there are only 2 squares of green more, the camera cuts off a few red ones.

RESET_9999 wrote: Fri Mar 29, 2024 4:31 pm
I think you have a C1?

pattern: https://drive.google.com/file/d/1OhnEb_ ... drive_link

I have a Philips 808 and I think it's pretty much the same as C3. My tv shows colour space as RGB when the signal is RGB, probably a bug. I tried your pattern video and bt2020, bt.709 makes no difference again. The only thing I haven't tried is not signaling the flag at all, I think that's only in a special Coreelec build.

I took some photos:

bbeny123 wrote: Sat Mar 30, 2024 6:23 pm https://slow.pics/c/Hn8RGz0x - unfortunately i don't have a better camera than a smartphone.
To the naked eye they look the same to me.

And as for the color space, in reality there are only 2 squares of green more, the camera cuts off a few red ones.

Okay, the multi pattern image video comparison was done on 20.5 nightly 20240322 before the real content comparison.
For the real content comparison it was done on 20.5 nightly 20240329 and this build has no longer the tracking issue I saw in 20240322.

I flashed another drive to 21 and it's fine on this build too. So the pattern matches the output of the x800m2 and I'll edit out that part of the youtube video

EDIT: just to confirm, this is the tracking on 20.5 20240329
https://slow.pics/c/NBQVuXQw

Does anyone know of any software that can losslessly splice P5 DV HEVC streams while keeping the P5 DV metadata in tact? Splicing on I-frames, obviously.

I tried to splice out advertisements from a Chinese WEB-DL with the latest version of Avidemux (v2.8.1) but the P5 DV metadata got lost so my TV just showed me the raw purple and green IPTPQC2 colour space. It went from:

MediaInfo wrote:[Video
ID : 256
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5@Main
HDR format : Dolby Vision, Version 1.0, dvhe.05.06, BL+RPU
Codec ID : dvhe
Codec ID/Info : High Efficiency Video Coding with Dolby Vision
Duration : 43 min 42 s
Bit rate : 6 235 kb/s
Maximum bit rate : 54.5 Mb/s
Width : 3 840 pixels
Height : 1 634 pixels
Display aspect ratio : 2.35:1
Frame rate mode : Variable
Frame rate : 25.000 FPS
Minimum frame rate : 24.993 FPS
Maximum frame rate : 25.007 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.040
Stream size : 1.90 GiB (93%)
Title : mp4:stype=dvhe@GPAC2.1-DEV-revUNKNOWN_REV
Encoded date : UTC 2023-02-01 12:17:32
Tagged date : UTC 2023-02-01 12:18:09
Color range : Full
mdhd_Duration : 2622280
Codec configuration box : hvcC+dvcC

to:

MediaInfo wrote:Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5@Main
Codec ID : hvc1
Codec ID/Info : High Efficiency Video Coding
Duration : 42 min 32 s
Source duration : 42 min 32 s
Bit rate : 5 952 kb/s
Maximum bit rate : 6 221 kb/s
Width : 3 840 pixels
Height : 1 634 pixels
Display aspect ratio : 2.35:1
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.038
Stream size : 1.77 GiB (89%)
Source stream size : 1.85 GiB (93%)
Color range : Full
mdhd_Duration : 2552120
Codec configuration box : hvcC

Kaan_ wrote: Sat Mar 30, 2024 6:29 pm The only thing I haven't tried is not signaling the flag at all, I think that's only in a special Coreelec build.

All the CE versions I tried are not sending any color flags. It's either a bt2020 flag or no flag. I don't think there is a build that send a bt709 flag, that wouldn't make sense.
BTW, I just tested the latest nightly CE-21 and my vertex and tv osd are not signaling any flag as they should just like my x800m2 and the colors are 100% identical.

The people saying it requires a bt2020 flag is basically the same as saying that all these devices are wrong :x700 x800m2 oppo shield AppleTV, firestick/cube, chromecast gtv ... Sounds very unlikely to me.

I stand corrected. So great to hear we have a great device on our hands.

Still on 20.5 latest nightly though, 21 is not stable with some movies. Like 1917.

Hello,

Thanks for testing this out.

On the face of it HDMI is just 0's and 1's so the same will be the same - finding the cause of diff is the fun bit / or maybe the cause of madness

Could I ask how you are determining no colorimetry / extended colorimetry is being sent in your tests? Are you peeking the data using an HDFurry or some other such device between the box and the TV?

From a code perspective if not explicitly setting for bt.2020 it will fall back to logic which will set the HDMI AVI Info Frame (sent before each image frame to the TV) to be bt.709

You can see this also in Kodi - on screen or looking into the AMLogic driver parameters that bt.709 is being set - I see no-where where it would strip that again before sending out the box.

What I would suspect is the older TV where still respecting this flag somewhere in the processing, newer TV and DoVi implementations should ignore it and likely not confuse people by showing it on screen either once duly ignored.

The interesting point for me is in the AMLogic code, there is also an explicit note/comment to set this, appears to be coming directly from Dolby (possibly to cater for the older TV / implementations - or ones they knew would not ignore this TV side) though yet to find a copy of that doc and what it actually say under section 4.4.1.

/* Dolby Vision Source System-on-Chip Platform Kit Version 2.6: * 4.4.1 Expected AVI-IF for Dolby Vision output, need BT2020 for DV */
Along side explicit code to then make sure it is set for Tunnelling IPT.

Side note: When i changed the code to clear out the flag completely - the TV looked the same as when it was set code-side to bt.709.

Check page 34 in the below pdf for details on why it would default to bt.709 from an HDMI perspective (note - this is the exact resolution based logic which is making it set to bt.709 in the AMLogic implementation, if not setting to bt.2020), obviously though Dolby knows better and just using HDMI as a Tunnel for its own IPT 12bit data.

https://picture.iczhiku.com/resource/ee ... prgNxm.pdf

One other thing not yet looked into is the content type flag in the Info Frame - I doubt TV's take this into consideration these days with all the TV side controls but maybe worth checking.