LRTimelapse Forum

I have tried to render video with the following settings:
Codec: H.265/HEVC
Output Size: 4K UHD
Frame rate: 29.97
Speed: 1:1
Quality: Ultra High
Color Sampling: 444
Gamut: Wide (BT.2020)

LRTimelapse seems to ignore Color Sampling setting and produces 4:2:0 chroma sampling video file. To me this is a bug.

Here is the metadata of the produced video file:

Code:
Video

ID                             : 1

Format                         : HEVC

Format/Info                    : High Efficiency Video Coding

Format profile                 : Main 10@L5@Main

Codec ID                       : hvc1

Codec ID/Info                  : High Efficiency Video Coding

Duration                       : 36 s 671 ms

Bit rate                       : 247 Mb/s

Width                          : 3 840 pixels

Height                         : 2 160 pixels

Display aspect ratio           : 16:9

Frame rate mode                : Constant

Frame rate                     : 29.970 (29970/1000) FPS

Color space                    : YUV

Chroma subsampling             : 4:2:0

Bit depth                      : 10 bits

Scan type                      : Progressive

Bits/(Pixel*Frame)             : 0.992

Stream size                    : 1.05 GiB (100%)

Writing library                : x265 2.9+9-f74003e88622:[Windows][GCC 8.2.1][64 bit] 10bit

Encoding settings              : cpuid=1111039 / frame-threads=4 / numa-pools=28 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x2160 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=8 / scenecut=40 / radl=0 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=8.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=9 / transfer=14 / colormatrix=9 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-mv-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei

Language                       : English

Encoded date                   : UTC 2020-01-29 06:30:12

Tagged date                    : UTC 2020-01-29 06:30:12

Color range                    : Limited

Color primaries                : BT.2020

Transfer characteristics       : BT.2020 (10-bit)

Matrix coefficients            : BT.2020 non-constant

Codec configuration box        : hvcC

Thanks for reporting, you seem to be right. I'll investigate this and provide a fix in the next update.

May be cool if support for 12 bit HEVC is also added. It seems to default to 10 bit. Though this is not a bug anymore but a feature enhancement.

Is there a particular reason why you are not using ProRes as export codec from LRTimelapse? H.265 is more a payback codec, not so much for master usage for further cutting in video editing programs... I'd recommend ProRes, it will most likely deliver better performance when cutting in a video program.

> Is there a particular reason why you are not using ProRes as export codec from LRTimelapse?

Good question. This is for projects were timelapse is only one part of a sequence. In that case I:
1. Use ProRes for all intermediaries.
2. I, however, store 444 12bit HEVC into long term archive just in case I will want to come back to this later. I do not store ProRes long term for space considerations.

Obviously in the above use case I do not necessarily need LRTimelapse to support HEVC 444 12bit as having ProRes I can use external tool to compress it into HEVC.
So overall this bug and the 12bit feature are not critical for me.

Just a thought and maybe a bit off topic here: don't you keep your raw files? Personally, I keep my Raw files for the long term archive, it often happens, that I need to reedit them etc. I consider the exported intermediaries and the rendered files as temporary, I do not backup them at all, just leave it until I delete it eventually because I can always recreate it.

I keep the raw files as well but frankly I have no guarantee that LRTimelapse will exist in 10 years and if it will then if it will still be able to read the metadata in .lrt folder after so many years. For that reason I preferred to also save the intermediary but in 444 HEVC rather than ProRes. HEVC is still quite adequate in quality.
Second reason is It is handy to have already rendered into video timelapses if from time to time I create a sequence out of many of them. E.g. extracts of the last year or over 10 years, or for specific places over many years, etc. Redoing it at that time is just too much work for little gain.

But I understand your suggested work flow as well.

All the editing info abd metadata are in the XMP files. The .lrt folder only holds previews. Although I'm quite confident, that LRTimelapse will still be around in 10 years, you won't need it for exporting - therefore it's just a matter of an availability of Lightroom in 10 years.

altim

Gunther

altim

Gunther

altim

Gunther

altim

Gunther