Some sources result in darker transcodes

[Former user]

I transcoded Star Wars episodes I and II using this command and it worked perfectly. The source was an mkv with the copied streams from the bluray:

ffmpeg -i in.mkv -pass 1 -map 0 -c:v libx265 -b:v 3M -an -sn -f matroska -y /dev/null && \ ffmpeg -i in.mkv -pass 2 -map 0 -c:v libx265 -b:v 3M -c:a copy -c:s copy -y out.mkv

However, when I did episode 3, the result was distinctly darker than the original. I attach a representative screenshot from the original and the transcode. x265 is version 1.8.

[Deepthi Nandakumar]

x265 does not perform any such image processing operations. Can you reproduce the same using only an x265 commandline (use ffmpeg for Matroska to yuv conversion, check result here and then feed into x265)?

Was this an 8-bit or 10-bit source?

[Former user]

Sorry, I don't understand what you mean that x265 doesn't perform such operations. Also I don't know how to convert as you suggest, nor how to determine if the source is 8-bit or 10-bit. Here is a link to 1 minute of the source (216 MB). https://www.dropbox.com/s/h1a5yird75n3am6/Episode3_1minute.mkv?dl=0

[Former user]

OK, I finally managed to convert a minute of the video to raw YUV using ffmpeg, and then used x265 to transcode it to an HEVC stream with desired 2-pass parameters. Then I managed to create screenshots of each stream.

The screenshots from the two streams are virtually identical, and both are darker than the shots of the original source (which is 8-bit by the way).

So I guess this is ffmpeg doing this rather than x265? Any ideas how/why?

[Ma0]

I encoded your sample with 2-pass 8-bit x265, second pass was:

i:\k>ffmpeg -i Episode3_1minute.mkv -vf crop=1920:820 -loglevel warning -f yuv4mpegpipe - | x265 --y4m - --preset placebo --subm
e 7 --merange 121 --deblock -1 --rdoq-level 1 --colormatrix bt709 --bitrate 3000 --pass 2 -o w.hevc
y4m  [info]: 1920x820 fps 24000/1001 i420p8 sar 1:1 unknown frame count
raw  [info]: output file: w.hevc
x265 [info]: HEVC encoder version 1.8+191-375ce77b8c35
x265 [info]: build info [Windows][MSVC 1900][64 bit] 8bit+10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: frame threads / pool features       : 2 / wpp(13 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge         : star / 121 / 7 / 5
x265 [info]: Keyframe min / max / scenecut       : 23 / 250 / 40
x265 [info]: Lookahead / bframes / badapt        : 60 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 1
x265 [info]: References / ref-limit  cu / depth  : 5 / 0 / 0
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : ABR-3000 kbps / 0.60
x265 [info]: tools: rect amp rd=6 psy-rd=0.30 rdoq=1 psy-rdoq=1.00 tskip
x265 [info]: tools: signhide tmvp b-intra strong-intra-smoothing
x265 [info]: tools: deblock(tC=-1:B=-1) sao stats-read
x265 [info]: frame I:      9, Avg QP:13.75  kb/s: 34508.49
x265 [info]: frame P:    234, Avg QP:16.33  kb/s: 12057.97
x265 [info]: frame B:   1219, Avg QP:22.19  kb/s: 949.39
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 3.3% 0.4% 3.3% 2.5% 7.0% 59.7% 10.3% 9.5% 4.1%

encoded 1462 frames in 2696.25s (0.54 fps), 2933.96 kb/s, Avg QP:21.20

Result file is not darker.

[Deepthi Nandakumar]

Thanks for confirming, closing this issue

[Former user]

Thanks. I'm still experimenting, but I think the key was the --colormatrix bt709 option.

[Deepthi Nandakumar]

Ah ok, agreed it might be an output/display issue. You may also want to look at other VUI fields.