[noggin]

What you are describing here sounds either as if it is Wide Colour Gamut Rec 2020 SDR - either using a BT.1886 SDR EOTF or a legacy 2.2-2.4 Power Law Gamma EOTF? 10-bit SDR has been a thing for decades - even 720x576 and 720x480 Rec 601 SD video can be 10-bit - Or you are describing a file that contains WCG Rec 2020 video captured or graded to an HDR10 ST.2084 PQ EOTF BUT not correctly flagged as such? The two are VERY different.

What I mentioned as such thing is 10 bit encoded videos with BT.2020 gamut. As you also wrote 10 bit videos in their own are not special. Yet I really not dig enough deeply into the color management side of video encoding (while I think I have more then enough information in this topic in still images and visualization technology) therefore I don't really know hot these informations encoded into the video streams. But if video files are something like still images the color space information in the file is just a simply metadata to define the 'absolute positions' of the RGB primaries. So without such technical knowledge I assume that 10 bit video files basically have 10 bit wide luminance resolution while color gamut is just a metadata to show in theory, in originally those 10 bit wide 'color values' in which color gamut need to be interpreted.

From these aspect 10 bit BT.2020 color target videos are basically HDR videos without any further special definitions. I think Dolby Vision and HDR10 also relies on this basis just have their own standard tone curve for encoding and some more other such details _(Will read about it if I will have enough time)_. What is interesting that this is just my 'theory'. But on the net there are also such videos, exactly how I mentioned. Files defined as 10 bit or HDR videos while they doesn't really have Dolby Vision or HDR10 encodings. They are basically just 10 bit videos with BT.2020 color space flag. And here I am. There are such files what are properly handled by GCGTV and there are also files which are not properly handled. It could be the fault of the files, sure, but the interested aspect of it that there are really lot of such files. Is it possible that all of them are wrong/fake? And one another aspect. If these files are not really HDR files _(I mean that they are just simply SDR videos with wrong encoding therefore with seems HDR results)_ Kodi's tonemapping should 'distort' it's dynamic range also but of course with wrong result _(DCR-ed SDR content)_.

Of course the whole mess could be the result of my missing knowledge. In my mind based on still images HDR videos is wide color gamut videos and because 8 bit is simply not enough to represent such range without banding _(it there is no 'proper' dithering)_, we need 10 bit videos to show that color informations. So if HDR as concept is basically just the more then 8 bit WCG videos what I wrote and mentioned is correct. _(In still images this is a little bit different as WCG in not mandatory part of the HDR concept. There could be HDR image with standard REC.709/sRGB gamut. In practice HDR images are simply those images which have more 8 bit resolution. Just if your display device could render it enough wide luminance scale the result will roughly banded. Of course exactly because this last sentence HDR as concept should not bypass this lumunance question circle but in the practice in the past HDR images not must be in WCG.)_

But back on topic. What I mentioned HDR files are neither Dolby Vision, neither HDR10 files. MediaInfo tells just thet 10 bit encoded with BT.2020 target. From my aspect those files are HDR files, and because there are really such files on the net with HDR 'name', I think not I'm the only one who think the same. Of course I don't know that those files have/use or not real wide gamut, but clearly shows that.

The other problem is the decoding process. Independently from this HDR 'state mess', a 10 bit HEVC is a 10 bit HEVC. If we don't care about proper colors and the dynamic range itself, all 10 bit HEVC files should be properly decoded from performance aspect if the HW can handle such things. But now we have more problems. Performance, colors, dynamic ranges and that there are more standards for the same thing. And why I hate electronics from the 80's

I just would like to draw a pattern which files are correct and which are not yet to help on the further development and on my 'clairvoyance'.

What's your opinion?

I work in broadcast video areas - so I deal less in opinion and more in international standards

Colour Gamut defines the R, G and B primaries in CIE colour space - i.e. what actual colour your primary red, green and blue are.  This is the gamut.  Rec 2020 defines different RGB primaries to Rec 709, and Rec 601 had slightly different colour primaries (technically) for 525 and 625 systems (aka 480 and 576 lines).  NTSC and PAL also had different primaries to each other.  (There are also additional differences like what colour temperature you defined as white)

Separate to the definition of the primary RGB colours used in each gamut standard, there are also different RGB->YCbCr (aka "YUV") matrix standards for Rec 2020, Rec 709 and Rec 601 - these define the relationships between RGB camera and display values and the Y (Luminance) and Cb (B-Y) and Cr (R-Y) colour difference signals (as the Cb and Cr signals are often subsampled to reduce their resolution and the bandwidth required to carry them) used in most video signals (both at baseband and in compressed form).

These quantised RGB and YCbCr values can be carried at a number of bit depths - SD video was often quantised in 8-bit resolution (16-235 and 16-240 for Y and CbCr respectively) but 10-bit versions were also defined (64-940 for Y for instance, sometimes also described as 16.00 to 235.00 I believe). SDR HD video is largely produced in the 10-bit domain these days (though some editing codecs are still 8-bit), and 12-bit representation can also be used.  Some Rec 2020 may not use YCbCr representation - other subsampled options are now available... (Dolby in particular can sometimes use these alternate colour spaces - albeit within the same gamut - Rec 2020)

The Colour Gamut stuff is not directly related to dynamic range in SDR/HDR terms - these are defined by EOTF (display) and OETF (camera) transfer functions (Electro Optical - i.e. the relationship between the electronic video signal and optical output, and Opto Electrical i.e - the relationship between light hitting a camera sensor and the electronic video signal created).  The EOTF is used to define the dynamic range of a video signal for a display (i.e. how to map the digital values it receives to the brightness values on a picture).  There are EOTFs that are defined for SDR video (BT.1886) and for HDR Video (ST.2084 for PQ HDR and ARIB-B67 for HLG HDR for instance). Before BT.1886 there was a less-well defined SDR EOTF - as all video was largely assumed to be displayed on CRT, and that EOTF was implicit in the display tech that CRT used I believe (Power Law Gamma of 2.2-2.4 typically?)

Both Colour Gamut and EOTF are metadata in a video signal BUT that metadata is vital in displaying them correctly - as the EOTF defines the relationship between video level and light output - and not usually linearly.  

If you have a video signal without either implicit or defined EOTF and gamut metadata you have literally no idea how to display it correctly.   HDR content can exist in both wide Rec 2020 and narrow Rec 709 gamut - though in consumer video pretty much all HDR content is Rec 2020.  Similarly you can use Rec 2020 primaries with both BT.1886 SDR and ST.2084 PQ or ARIB B-67 HLG HDR EOTFs.

As you say - 10-bit HEVC (if you ignore metadata embedded within the HEVC stream) is the same video and compression whether it is 10-bit SDR or 10-bit HDR, and whether it is 10-bit Rec 709 or 10-bit Rec 2020 (*).  This is why the meatada is vital - if you don't know the gamut and dynamic range of the signal (and in the case of YCbCr encoding, also the RGB<->YCbCr matrix - which is part of the gamut standard) you are stuffed.

(*) You have to know whether the video is Rec 709 or Rec 2020 not just because the primaries are different but also because the two standards use different RGB<->YCbCr transfer matrices - if you transfer Rec 2020 video using a Rec 709 matrix, or Rec 709 using a Rec 2020 matrix, your RGB results will be mathematically wrong.

Running every file you want to know more about through Media Info will tell you a lot about the metadata in that file - Gamut, EOTF etc.  I also only really use content I know and trust for that kind of stuff - not random stuff I downloaded.