Dolby Vision

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Dolby Vision

Mark Himsley-2
Hi,

There are some 4K Dolby Vision files around, like the one linked to
directly from this page of this site, which are not decoded with the
correct colours using git master head FFmpeg (compiled last weekend).

https://4kmedia.org/lg-amaze-dolby-vision-uhd-4k-demo/

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.

Thanks :-)

Example command line:

$ 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
ffmpeg version N-95915-g18507b4-shared_linux_x86_64_201911301603
Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.12) 20160609
  configuration: --extra-version=shared_linux_x86_64_201911301603
--extra-cflags=' ' --extra-libs=' -lpthread -lm' --pkg-config-flags=
--cross-prefix= --arch=x86_64 --target-os=linux --prefix=/opt/ffbuild
--enable-gpl --enable-version3 --enable-nonfree --disable-ffplay
--disable-dxva2 --enable-libxml2 --enable-openssl --enable-libmp3lame
--enable-libspeex --enable-libtheora --enable-libvorbis
--enable-libopus --enable-libxvid --enable-libvpx --enable-libfdk-aac
--enable-libx264 --enable-libx265 --enable-libopenjpeg --enable-libaom
--enable-libxcb --enable-decklink
  libavutil      56. 36.101 / 56. 36.101
  libavcodec     58. 64.101 / 58. 64.101
  libavformat    58. 35.100 / 58. 35.100
  libavdevice    58.  9.101 / 58.  9.101
  libavfilter     7. 67.100 /  7. 67.100
  libswscale      5.  6.100 /  5.  6.100
  libswresample   3.  6.100 /  3.  6.100
  libpostproc    55.  6.100 / 55.  6.100
[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)
    Metadata:
      creation_time   : 2017-04-13T20:09:18.000000Z
      handler_name    : video handler
      encoder         : DOVI Coding
    Stream #0:1(und): Audio: eac3 (ec-3 / 0x332D6365), 48000 Hz,
5.1(side), fltp, 640 kb/s (default)
    Metadata:
      creation_time   : 2017-04-13T20:09:18.000000Z
      handler_name    : sound handler
    Side data:
      audio service type: main
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)
    Metadata:
      creation_time   : 2017-04-13T20:09:18.000000Z
      handler_name    : video handler
      encoder         : Lavc58.64.101 libx264
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
[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
[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 62kB time=00:00:00.00 bitrate=N/A
speed=   0x
[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
[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
[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
[hevc @ 0x380ce80] Skipping NAL unit 62
[hevc @ 0x385de80] Skipping NAL unit 62kB time=00:00:00.00 bitrate=N/A
speed=   0x
[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
[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 621kB time=00:00:00.06 bitrate=
99.4kbits/s speed=0.0442x
[hevc @ 0x380ce80] Skipping NAL unit 62
<SNIP - nothing interesting in here>
[hevc @ 0x38f98c0] Skipping NAL unit 62
[hevc @ 0x390a140] Skipping NAL unit 62
[hevc @ 0x37f3380] Skipping NAL unit 624kB time=00:00:54.95
bitrate=27572.6kbits/s speed=0.292x
[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
frame= 3372 fps= 18 q=-1.0 Lsize=  184967kB time=00:00:56.15
bitrate=26985.2kbits/s speed=0.296x
video:184940kB audio:0kB subtitle:0kB other streams:0kB global
headers:0kB muxing overhead: 0.014368%
[libx264 @ 0x37f2940] frame I:23    Avg QP:17.12  size:372237
[libx264 @ 0x37f2940] frame P:1397  Avg QP:21.18  size:103814
[libx264 @ 0x37f2940] frame B:1952  Avg QP:25.00  size: 18334
[libx264 @ 0x37f2940] consecutive B-frames: 22.3%  1.2%  1.1% 75.4%
[libx264 @ 0x37f2940] mb I  I16..4: 22.5% 50.1% 27.3%
[libx264 @ 0x37f2940] mb P  I16..4:  0.7%  5.0%  1.1%  P16..4: 42.2%
13.8% 13.0%  0.0%  0.0%    skip:24.2%
[libx264 @ 0x37f2940] mb B  I16..4:  0.1%  0.7%  0.5%  B16..8: 29.7%
3.9%  1.9%  direct: 3.3%  skip:59.9%  L0:34.9% L1:50.8% BI:14.3%
[libx264 @ 0x37f2940] 8x8 transform intra:66.6% inter:58.6%
[libx264 @ 0x37f2940] coded y,uvDC,uvAC intra: 83.7% 60.1% 24.9%
inter: 23.1% 16.1% 6.0%
[libx264 @ 0x37f2940] i16 v,h,dc,p: 41% 16%  7% 36%
[libx264 @ 0x37f2940] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 19% 14%  6%
10%  7% 14%  7% 13%
[libx264 @ 0x37f2940] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 13% 17% 11%  7%
12%  9% 13%  7% 11%
[libx264 @ 0x37f2940] i8c dc,h,v,p: 63% 19% 13%  5%
[libx264 @ 0x37f2940] Weighted P-Frames: Y:8.7% UV:5.0%
[libx264 @ 0x37f2940] ref P L0: 68.6% 13.3% 11.9%  6.1%  0.1%
[libx264 @ 0x37f2940] ref B L0: 88.4%  9.2%  2.4%
[libx264 @ 0x37f2940] ref B L1: 93.4%  6.6%
[libx264 @ 0x37f2940] kb/s:26957.74


--
Mark Himsley
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Dolby Vision

kumowoon1025
> 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.

> $ 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.

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Dolby Vision

Mark Himsley-2
On Sun, 8 Dec 2019 at 10:03, Ted Park <[hidden email]> 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 :-)
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Dolby Vision

Carl Eugen Hoyos-2
In reply to this post by Mark Himsley-2
Am Sa., 7. Dez. 2019 um 15:43 Uhr schrieb Mark Himsley <[hidden email]>:

> There are some 4K Dolby Vision files around, like the one linked to
> directly from this page of this site, which are not decoded with the
> correct colours using git master head FFmpeg (compiled last weekend).
>
> https://4kmedia.org/lg-amaze-dolby-vision-uhd-4k-demo/

https://trac.ffmpeg.org/ticket/7624
There is a patch discussed on the FFmpeg development mailing list
that can fix the issue on Intel (?) cpus.

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Dolby Vision

kumowoon1025
In reply to this post by Mark Himsley-2
> 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 :-)

I understand that the colors are different, I was saying it is being decoded the way an hevc decoder should. I didn’t realize it would look “wrong” as in a completely different transfer function used on it until I actually downloaded the file… That file only has a single stream, with no enhancement layer for the dolby HDR metadata. It just has the base layer with the “rpu” with all of the info your TV’s decoder can use, but are simply discarded, as far as I can tell. This is the correct behavior though, and the hevc stream is being decoded “correctly,” but in this case it is not sdr/hdr compliant so the base layer decoded the way it’s supposed to be doesn’t look right. I can’t help but think any fix to this would have to rely on such heuristics to convert between color models, but even before the transfer functions, dolby uses different primaries, so the best we could hope for is an approximation. This is just the profile in the reference file you linked, in practice most distribution paths wouldn’t have only the single layer non-compatible dolby vision stream, I assume this was meant to be demo material on floor display TV units or something.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".