[FFmpeg-user] Dolby Vision

[Mark Himsley]

On Sun, 8 Dec 2019 at 10:03, Ted Park <kumowoon1025 at gmail.com> wrote:
>
> > When I play the file downloaded from that page on an VG 4K Dolby
> > Vision capable TV it plays correctly with the right colours, but the
> > colours are way wrong when decoded/converted with FFmpeg.
> >
> > Should I be expecting Dolby Vision files to decode correctly? I mean,
> > it's very close, but just not quite right.
> I’m not sure, I think so? But when you are transcoding to h264 and yuv420p, the point is sort of moot.

The command line was an example. Encoding to yuv420p should not make
such a difference in the luminance and colours.

As I understand it, FFmpeg (the libav libraries) can convert HLD and
'standard' PQ from HDR to SDR acceptably. (VLC also does the job
admirably). With HLG I imagine that a LUT needs to be applied to
compress the peek whites and deep blacks. I don't quite know what
happens with PQ, perhaps its similar. But with Dolby Vision there is
the sub-layer of metadata.


> > $ ffmpeg -i 'LG Amaze Dolby Vision UHD 4K Demo.ts'  -sws_flags lanczos
> > -filter:v "scale=1920:1080:interl=0,format=yuv420p" -c:v libx264 -crf
> > 18 -an -y out.mkv
>
>
> I think it might have the capability to at least decode and remux the data since the mov demuxer just happens after hevc notices nal unit 62
> > [hevc @ 0x37c9ec0] Skipping NAL unit 62
> > Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'LG Amaze Dolby Vision UHD 4K Demo.ts':
> >  Metadata:
> >    major_brand     : mp42
> >    minor_version   : 1
> >    compatible_brands: mp42dby1isom
> >    creation_time   : 2017-04-13T20:09:18.000000Z
> >  Duration: 00:00:56.20, start: 0.000000, bitrate: 28362 kb/s
> >    Stream #0:0(und): Video: hevc (Main 10) (dvhe / 0x65687664),
> > yuv420p10le(tv), 3840x2160 [SAR 1:1 DAR 16:9], 27713 kb/s, 60 fps, 60
> > tbr, 60k tbn, 60 tbc (default)
> > ...
> > Stream mapping:
> >  Stream #0:0 -> #0:0 (hevc (native) -> h264 (libx264))
> > Press [q] to stop, [?] for help
> > [hevc @ 0x37f3380] Skipping NAL unit 62
> > [hevc @ 0x37fa1c0] Skipping NAL unit 62
> > [hevc @ 0x380ce80] Skipping NAL unit 62
> > [hevc @ 0x385de80] Skipping NAL unit 62
> > [hevc @ 0x386e700] Skipping NAL unit 62
> > [hevc @ 0x38d8940] Skipping NAL unit 62
> > [hevc @ 0x38e9080] Skipping NAL unit 62
> > [hevc @ 0x38f98c0] Skipping NAL unit 62
> > [hevc @ 0x390a140] Skipping NAL unit 62
> > [hevc @ 0x37f3380] Skipping NAL unit 62
> > [hevc @ 0x37fa1c0] Skipping NAL unit 62
> > [libx264 @ 0x37f2940] using SAR=1/1
> > [libx264 @ 0x37f2940] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
> > [hevc @ 0x380ce80] Skipping NAL unit 62
> > [libx264 @ 0x37f2940] profile Progressive High, level 4.2, 4:2:0, 8-bit
> > [libx264 @ 0x37f2940] 264 - core 157 r2969 d4099dd - H.264/MPEG-4 AVC
> > codec - Copyleft 2003-2019 - http://www.videolan.org/x264.html -
> > options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7
> > psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1
> > 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2
> > threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1
> > interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2
> > b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250
> > keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf
> > mbtree=1 crf=18.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40
> > aq=1:1.00
> > Output #0, matroska, to 'out.mkv':
> >  Metadata:
> >    major_brand     : mp42
> >    minor_version   : 1
> >    compatible_brands: mp42dby1isom
> >    encoder         : Lavf58.35.100
> >    Stream #0:0(und): Video: h264 (libx264) (H264 / 0x34363248),
> > yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 60 fps, 1k tbn, 60 tbc
> > (default)
> > ...
> > [hevc @ 0x385de80] Skipping NAL unit 62
> > [hevc @ 0x386e700] Skipping NAL unit 62
> > [hevc @ 0x38d8940] Skipping NAL unit 62
> > …
>
> But is it simply skipping or does it know what that signals? Also I’m not as familiar with mkv, but is H264 as the codec normal instead of avc? Can it handle the enhancement layer info?
>
> As far as “correctness” goes, the color probably is correct, as in it was decoded and interpolated  the way it is supposed to be, but obviously it’s not going to have the full range that you get from the output from a licensed hardware decoder after you transcode from the minimal/compatibility hevc main 10 to h264 42.

The colour (and luminance) which has been decoded, mapped between
colour-spaces, and and re-encoded is not correct. If you have a Dolby
Vision compatible TV you can see the difference very clearly. Do you
need me to point a camera at my TV to demonstrate :-)