Some sources result in darker transcodes
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.
Comments (8)
-
-
Account Deleted 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
-
Account Deleted 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?
-
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.
-
Thanks for confirming, closing this issue
-
- changed status to resolved
-
Account Deleted Thanks. I'm still experimenting, but I think the key was the --colormatrix bt709 option.
-
Ah ok, agreed it might be an output/display issue. You may also want to look at other VUI fields.
- Log in to comment
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?