Lossless profile 7 to profile 8 conversion ?

[jerome71]

First, thanks a lot for the great job.
Just downloaded the Mac executable and very easily and quickly converted a DV profile 7 to profile 8 (mode 2) :-)
It's great to have DV in a mkv!

I wonder how lossy the conversion is.
From what I've read :

• if the source file has a MEL (Minimal Enhancement Layer) the converted profile 8 file (BL+RPU) plays exactly as the source file would (lossless)
• if the source file has a FEL (Full Enhancement Layer), then the FEL is discarded (lossy).

Can you please confirm if I understand correctly? And, if there is some loss, is the target video's quality closer to the original DV video's or to its HDR10 fallback's?

Thanks in advance.

[quietvoid]

Your understanding is correct.

When the FEL is discarded, you lose on the potential image improvements it brings.
But this is only if your playback setup fully supports profile 7 in MKV.
There are only a couple devices which do this.

The video itself is still untouched, so it's image quality is the same as the HDR10 video.
The only difference is that there's dynamic metadata on top, so it becomes equivalent to MEL/profile 8.

[jerome71]

Thanks a lot @quietvoid for the explanation.
So if I understand well a UHD Blu-Ray (or rip) on my Oppo 203 clone is still better than a DV MKV when the source has a FEL. But it is the same quality if the source is MEL.

Now I just have to understand what is in a FEL: is it like the 2nd part of a progressive JPEG?
(that is of course a very different question, and just for my curiosity - I have not yet found a clear explanation of that)

[NeedsMoar]

The FEL is a 1080p video that's the residual data left after subtracting (sorta) the HDR10 base layer from the full bit depth master of the video. In some ways it's the opposite of progressive JPEG, since the progressive encodings usually increase resolution; this is a lower resolution HEVC stream along with the 4k UHD (or identical resolution in a case never really seen where the base layer is 1080p) video carrying what ends up as a couple of extra bits of data. So you've got the 4k luma, the subsampled chroma from that which is effectively 1/4 resolution, then the 1080p residual which is upscaled and combined with the 4k. The extra data is 1/4 resolution luma, and since it's also subsampled, 1/16th resolution chroma. Slapped together you end up with 12bpc 4:2:2 after the transformations, but I still refer to it as "KINDA 4:2:2 mostly 12 bit luma almost 12 bit color". It increases color and luma depth but the increase is at worse quality than the base video. It relies heavily on the impossibility of seeing any sort of gradation with 4096 shades of anything. 10-bit color is nearly impossible to see banding in without spreading a gradient between nearby colors out across 4k of screen and looking closely.

As I understand it this was done entirely because off-the-shelf decoder ASICs when UHD BD was standardized were 32 bit devices and couldn't handle more than 10 bits per channel during decode. It was cheaper to use 2 than design a new one.

It might be considered more like some branches of certain forms of progressive JPEG2000 which keeps pulling smaller variants of the image from the tree containing the full chroma data after loading an initial "good enough" subsampled version; there are at least 3 different settings for how JPEG2000 is progressively loaded though. Once is the chroma thing, one is size (starts tiny, works up the tree in detail and size, screws up loading of any webpage relying on it for alignment), and another I can't remember.

Regular JPEG progressive wasn't really useful as an optimization but it was something to look at and keep you from leaving the page while the 2400bps speeds you were getting over 50 year old phone lines on a 9600bps modem pulled more of the file. They're kind of similar in that way... HEVC Main12 4:2:2 doesn't end up significantly larger than Main10 4:2:0 when encoded and usually they're slightly smaller than a BL + FEL file, but 12 bit decoder chips didn't exist when UHD BD was being standardized (and still don't) and all of the microprocessors floating around were still 32-bit so they couldn't load a full 12-bit color triple into a register and bit manipulate it like they could with a 10-bit triple...

They're doing something similar with MPEG5 LCEVC but it looks to be a way of not picking an encoding standard while appearing to do something :P https://en.wikipedia.org/wiki/LCEVC

I'm actually considering one of those Oppo clones despite them being pricey; how do you like yours?