Archiving pro-res to h264

[TEB]

hi. Im trying to make a "good enough" mezz format for our internal workflow using x264.
Source is prores 4:2:2hq 10bit and im using the the following ffmpeg string:
ffmpeg -i arthur.mov -c:v libx264 -crf 10 -profile:v high422 -pix_fmt yuv422p -c:a copy -map 0:v -map 0:a output_crf10_422_10bit.mp4

For 4:2:0 8bit im using :

ffmpeg -i arthur.mov -c:v libx264 -crf 10 -c:a copy -map 0:v -map 0:a output_crf10_422_10bit.mp4

Question:
1. Why are the output files the same size?
2. How can one check if ffmpeg has 10bit support inbuilt?

br TE

[sneaker_ger]

1. Conincidence. If you want smaller file increase CRF.
2. Open output file in MediaInfo and check if it is 10 bit. Currently x264 bitdepth is set at compile time. (This will change with future version.)

[benwaggoner]

I'd also recommend setting --level and then maxrate and bufsize appropriately to make sure you retain hardware decode compatibility.

I did a bunch of testing around this as part of an EMA effort a few years ago, and it seemed we could reliably get ProRes quality from H.264 at 25-50% the files size with a 1 sec GOP, and about 65% with IDR-only. HEVC offered some substantial further improvements, so you might want to consider that instead.

[TEB]

I'd also recommend setting --level and then maxrate and bufsize appropriately to make sure you retain hardware decode compatibility.

I did a bunch of testing around this as part of an EMA effort a few years ago, and it seemed we could reliably get ProRes quality from H.264 at 25-50% the files size with a 1 sec GOP, and about 65% with IDR-only. HEVC offered some substantial further improvements, so you might want to consider that instead.

Interessting! Well, HW decode compatibility isnt that important as the target for these files are a potential future re-encode for our whole library to future codecs (hevc, AV1, etc..)

Could u reccomend a good HEVC CRF archiving syntax?

br TE

[TEB]

So to followup on this one:

*Compiled a "10bit" version of FFmpeg 3.4.1 (x264 10bit)
*sourcefile UHD SDR file in prores 4:2:2 10bit format
*Ran this archiving profile:

ffmpeg-10bit -i file_SDR_Master_trimmed_500frames.mov \
-c:v libx264 \
-profile:v high422 \
-crf 12 \
-preset medium \
-pix_fmt yuv422p10le -strict experimental \
-c:a copy -map 0:v -map 0:a \
out.mkv

*Tried preset Veryslow to Veryfast:
778M test_SDR_H264_crf10_422_10bit_fast.mkv fps:9,3 SSIM: All:0.890732 (9.615051) average:31.682199
773M test_SDR_H264_crf10_422_10bit_medium.mkv fps:8 SSIM: All:0.890707 (9.614075) average:31.681771
754M test_SDR_H264_crf10_422_10bit_slower.mkv fps:2 SSIM: All:0.890549 (9.607819) average:31.680318
769M test_SDR_H264_crf10_422_10bit_slow.mkv fps:3,8 SSIM: All:0.890470 (9.604679) average:31.679459
715M test_SDR_H264_crf10_422_10bit_veryfast.mkv fps:15 SSIM: All:0.894817 (9.780536) average:31.727429
728M test_SDR_H264_crf10_422_10bit_veryslow.mkv fps:1,2 SSIM: All:0.890294 (9.597711) average:31.677987

*Comment1: I have no idea why the veryfast one is smaller than the veryslow one
*Comment2: I have no idea why the SSIM and PSNR values are so low.. Subjectively watching them doesn't reveal anything but that the quality is excellent..

ssim/psnr calculation syntax:
ffmpeg-10bit -i test_SDR_Master_trimmed_500frames.mov -i test_SDR_H264_crf10_422_10bit_veryslow.mkv -lavfi "ssim;[0:v][1:v]psnr" -f null -

UPDATE: After some work with the ffmpeg devs there seems to be something wrong in the MKV muxer.. So when choosing mp4, all was correct..