On Sun, 8 Dec 2019 at 10:03, Ted Park <kumowoon1...@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 :-) _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
