編集：アヒルの離陸の10ビットエンコードに成功しました。
最初の方法：libx264を静的にリンクする10ビットx264バイナリをビルドしました。
cp -al x264-git x264-10bit # instead of changing my normal git checkout
cd x264-10bit
./configure --extra-cflags=-march=native --enable-static --disable-interlaced --bit-depth=10
make -j2
sudo install x264 /usr/local/bin/x264-10bit
mkfifo pipe.y4m
ffmpeg -v verbose -i in -pix_fmt yuv420p10le -strict experimental -f yuv4mpegpipe pipe.y4m
(open another shell window / tab / screen(1) window):
x264 pipe.y4m --crf 30 --preset ultrafast -o 10bit-420.mkv
（超高速で低品質です。品質テストではなく、概念実証のためです。）swscaleでコンパイルしていません。（libavutilなどのRGB pix fmtについては不満でした）。入力カラースペースが一致しない場合はエラーになります--output-csp i444。これは、x264で誤ってクロマをダウンサンプリングしたくない場合に実際に便利です。私がそれに数フレームを供給したときそれはうまく働きyuv444p14le.y4m、10ビットの出力を生成しました。（ビット深度を切り捨てることはできますが、swscaleなしでクロマをダウンサンプリングすることはできません。）
2番目の方法：を使用LD_LIBRARY_PATHして10ビットlibx264.soを選択する
すべてに同じffmpegダイナミックリンクバイナリを使用できます。
cp -al x264-git x264-10bit # instead of changing my normal git checkout
cd x264-10bit
./configure --extra-cflags=-march=native '--libdir=/usr/local/lib/high-bit-depth-codec' '--includedir=/usr/local/lib/high-bit-depth-codec/include' --disable-cli --enable-shared --disable-interlaced --bit-depth=10
make -j2
sudo make install-lib-shared # this Makefile target depends on install-lib-dev, hence setting --includedir
alias highdepth-ffmpeg='LD_LIBRARY_PATH=/usr/local/lib/high-bit-depth-codec ffmpeg'
highdepth-ffmpeg -v verbose -framerate 50 -f image2 \
-pattern_type glob -i ./3_DucksTakeOff_720p50_CgrLevels_SINC_FILTER_SVTdec05_/'*'.sgi \
-pix_fmt yuv420p10le -crf 30 -preset ultrafast \
-sws_flags +accurate_rnd+print_info \
with_ld_path.420p10.accurate_rnd.mkv
ffmpeg version N-68044-gb9dd809 Copyright (c) 2000-2015 the FFmpeg developers
built on Jan 14 2015 23:21:08 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
configuration: --enable-gpl --enable-version3 --enable-nonfree --disable-doc --disable-ffserver --enable-libbluray --enable-libschroedinger --enable-libtheora --enable-libx264 --enable-libx265 --enable-libmp3lame --enable-libopus --enable-libwebp --enable-libvpx --disable-outdev=oss --disable-indev=oss --disable-encoder=vorbis --enable-libvorbis --enable-libfdk-aac --disable-encoder=aac --disable-decoder=jpeg2000 --enable-libvidstab
libavutil 54. 16.100 / 54. 16.100
libavcodec 56. 20.100 / 56. 20.100
libavformat 56. 18.101 / 56. 18.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 7.101 / 5. 7.101
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
Input #0, image2, from './3_DucksTakeOff_720p50_CgrLevels_SINC_FILTER_SVTdec05_/*.sgi':
Duration: 00:00:10.00, start: 0.000000, bitrate: N/A
Stream #0:0: Video: sgi, rgb48be, 1280x720, 50 tbr, 50 tbn, 50 tbc
[graph 0 input from stream 0:0 @ 0x1b6d8c0] w:1280 h:720 pixfmt:rgb48be tb:1/50 fr:50/1 sar:0/1 sws_param:flags=2
[auto-inserted scaler 0 @ 0x1b7dae0] w:iw h:ih flags:'0x41004' interl:0
[format @ 0x1b7e940] auto-inserting filter 'auto-inserted scaler 0' between the filter 'Parsed_null_0' and the filter 'format'
SwScaler: reducing / aligning filtersize 1 -> 4
Last message repeated 1 times
SwScaler: reducing / aligning filtersize 1 -> 1
SwScaler: reducing / aligning filtersize 9 -> 8
[swscaler @ 0x1b500c0] bicubic scaler, from rgb48be to yuv420p10le using MMXEXT
[swscaler @ 0x1b500c0] 1280x720 -> 1280x720
[auto-inserted scaler 0 @ 0x1b7dae0] w:1280 h:720 fmt:rgb48be sar:0/1 -> w:1280 h:720 fmt:yuv420p10le sar:0/1 flags:0x41004
[libx264 @ 0x1b78da0] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
[libx264 @ 0x1b78da0] profile High 10, level 3.2, 4:2:0 10-bit
[libx264 @ 0x1b78da0] 264 - core 144 r2525+2 6a4fca8 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=1 psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=3 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=0 intra_refresh=0 rc=crf mbtree=0 crf=30.0 qcomp=0.60 qpmin=0 qpmax=81 qpstep=4 ip_ratio=1.40 aq=0
Output #0, matroska, to 'with_ld_path.420p10.accurate_rnd.mkv':
Metadata:
encoder : Lavf56.18.101
Stream #0:0: Video: h264 (libx264) (H264 / 0x34363248), yuv420p10le, 1280x720, q=-1--1, 50 fps, 1k tbn, 50 tbc
Metadata:
encoder : Lavc56.20.100 libx264
Stream mapping:
Stream #0:0 -> #0:0 (sgi (native) -> h264 (libx264))
Press [q] to stop, [?] for help
No more output streams to write to, finishing.e=00:00:09.84 bitrate=12060.2kbits/s
frame= 500 fps= 14 q=-1.0 Lsize= 14714kB time=00:00:10.00 bitrate=12053.5kbits/s
video:14709kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.031423%
Input file #0 (./3_DucksTakeOff_720p50_CgrLevels_SINC_FILTER_SVTdec05_/*.sgi):
Input stream #0:0 (video): 500 packets read (2765056000 bytes); 500 frames decoded;
Total: 500 packets (2765056000 bytes) demuxed
Output file #0 (with_ld_path.420p10.accurate_rnd.mkv):
Output stream #0:0 (video): 500 frames encoded; 500 packets muxed (15062147 bytes);
Total: 500 packets (15062147 bytes) muxed
[libx264 @ 0x1b78da0] frame I:2 Avg QP:43.00 size:144760
[libx264 @ 0x1b78da0] frame P:498 Avg QP:49.83 size: 29663
[libx264 @ 0x1b78da0] mb I I16..4: 100.0% 0.0% 0.0%
[libx264 @ 0x1b78da0] mb P I16..4: 5.1% 0.0% 0.0% P16..4: 79.3% 0.0% 0.0% 0.0% 0.0% skip:15.6%
[libx264 @ 0x1b78da0] coded y,uvDC,uvAC intra: 67.8% 60.5% 41.9% inter: 50.1% 16.3% 2.8%
[libx264 @ 0x1b78da0] i16 v,h,dc,p: 5% 54% 33% 8%
[libx264 @ 0x1b78da0] i8c dc,h,v,p: 53% 39% 6% 3%
[libx264 @ 0x1b78da0] kb/s:12049.24
(same bitrate and stats as with the y4m pipe,
so it behaves the same with the same input data... good.)
これらの品質設定では、視覚的に何も見ようとはしませんでした。物事のバリエーションを試すときに常に大量の出力ファイルを作成することになるので、高速で実行し、大量のディスク領域を無駄にしないようにしたかっただけです。
大量のy4mデータを別のx264プロセスにパイプしないと、12 fpsではなく14 fpsになり、超高速の適切なスピードアップが実現しました。エンコードが遅いほど、オーバーヘッドが小さくなります。
私のソースは48ビットRGBです。correct_rndが出力mkvに影響を与えないことがわかりました。（ビット同一なしとの結果は-sws_flags、と-sws_flags +accurate_rnd、と-vf scale=flags=accurate_rnd、MKVヘッダ内の数ビット、おそらく無作為化MKV UUIDを除く。でもで-qp 0、私は丸め誤差にそれを失うことはなかったので。 cmp -l f1 f2 | lessであるかもしれないバイナリファイルを比較します最初の違いの後で同じです。またはssdeep -p。たぶんaccurate_rnd今ではデフォルトですか？）
重要なffmpeg swscalerフラグが1つあります。ffmpegにクロマをダウンサンプリングさせる場合、デフォルトのバイキュービックではなくlanczosです。（私はlanczosが依然として高品質の最良の選択と見なされていると思いますか？しばらく読んでいません。）
highdepth-ffmpeg -i in -pix_fmt yuv420p10le ...encode...opts...
-vf scale=flags=lanczos -sws_flags +accurate_rnd+print_info with_ld_path.420p10.accurate_rnd.lanczos.mkv
への追加+lanczosは-sws_flags機能しません：
[format @ 0x28e4940] auto-inserting filter 'auto-inserted scaler 0' between the filter 'Parsed_null_0' and the filter 'format'
[swscaler @ 0x28b60c0] Exactly one scaler algorithm must be chosen, got 204
[auto-inserted scaler 0 @ 0x28e3ae0] Failed to configure output pad on auto-inserted scaler 0
Error opening filters!
10ビットよりも深い入力を入力しようとすると、ffmpegは拒否します。
highdepth-ffmpeg ... -pix_fmt yuv444p14le
[graph 0 input from stream 0:0 @ 0x36ec9c0] w:1280 h:720 pixfmt:rgb48be tb:1/50 fr:50/1 sar:0/1 sws_param:flags=2
Incompatible pixel format 'yuv444p14le' for codec 'libx264', auto-selecting format 'yuv444p10le'
[Parsed_scale_0 @ 0x36e2a00] w:1280 h:720 fmt:rgb48be sar:0/1 -> w:1280 h:720 fmt:yuv444p10le sar:0/1 flags:0x200
[libx264 @ 0x3701d80] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
[libx264 @ 0x3701d80] profile High 4:4:4 Predictive, level 3.2, 4:4:4 10-bit
実際、ffmpegのlibx264ドライバーは常に、コンパイル対象のビット深度に正確にx264を供給することを要求しています。例-pix_fmt yuv420p：
Incompatible pixel format 'yuv420p' for codec 'libx264', auto-selecting format 'yuv420p10le'
x264.hさんのコメント：
/* x264_bit_depth:
* Specifies the number of bits per pixel that x264 uses. This is also the
* bit depth that x264 encodes in. If this value is > 8, x264 will read
* two bytes of input data for each pixel sample, and expect the upper
* (16-x264_bit_depth) bits to be zero.
* Note: The flag X264_CSP_HIGH_DEPTH must be used to specify the
* colorspace depth as well. */
X264_API extern const int x264_bit_depth;
内部的にはx264（CLI）は常にピクセル形式をアップコンバートする必要があると思います。コードにはすべての関数の8ビット入力、10ビット出力バージョンはありません。また、さまざまな入力ビット深度の受け入れは、ライブラリAPIではなく、x264 CLIでのみ行われると思います。より高いビットが設定されているAPI入力をフィードするとどうなるか知りたいのですが...
frame.c:370: So this is why ffmpeg can't give 8-bit input to libx264
#if HIGH_BIT_DEPTH
if( !(src->img.i_csp & X264_CSP_HIGH_DEPTH) )
{
x264_log( h, X264_LOG_ERROR, "This build of x264 requires high depth input. Rebuild to support 8-bit input.\n" );
return -1;
}
#else
pix_fmtが指定されていないyuv444p10le場合、rgmp 入力が与えられると、ffmpegが選択します。またはlibx264rgb、を使用すると、16ビット（そのうちの10ビットが重要）を期待する関数に8ビットRGBを供給し、segfaults>。<になります。その上流を報告します...
highdepth-ffmpeg -v verbose -framerate 50 -f image2 -pattern_type glob -i ./3_DucksTakeOff_720p50_CgrLevels_SINC_FILTER_SVTdec05_/'*'.sgi -qp 0 -preset ultrafast -sws_flags print_info+accurate_rnd -frames 2 -c:v libx264rgb lossless.rgb.mkv
ffmpeg version N-68044-gb9dd809 Copyright (c) 2000-2015 the FFmpeg developers
built on Jan 14 2015 23:21:08 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
configuration: --enable-gpl --enable-version3 --enable-nonfree --disable-doc --disable-ffserver --enable-libbluray --enable-libschroedinger --enable-libtheora --enable-libx264 --enable-libx265 --enable-libmp3lame --enable-libopus --enable-libwebp --enable-libvpx --disable-outdev=oss --disable-indev=oss --disable-encoder=vorbis --enable-libvorbis --enable-libfdk-aac --disable-encoder=aac --disable-decoder=jpeg2000 --enable-libvidstab
libavutil 54. 16.100 / 54. 16.100
libavcodec 56. 20.100 / 56. 20.100
libavformat 56. 18.101 / 56. 18.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 7.101 / 5. 7.101
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
Input #0, image2, from './3_DucksTakeOff_720p50_CgrLevels_SINC_FILTER_SVTdec05_/*.sgi':
Duration: 00:00:10.00, start: 0.000000, bitrate: N/A
Stream #0:0: Video: sgi, rgb48be, 1280x720, 50 tbr, 50 tbn, 50 tbc
[graph 0 input from stream 0:0 @ 0x1eb9660] w:1280 h:720 pixfmt:rgb48be tb:1/50 fr:50/1 sar:0/1 sws_param:flags=2
[auto-inserted scaler 0 @ 0x1eba120] w:iw h:ih flags:'0x41000' interl:0
[format @ 0x1eb94c0] auto-inserting filter 'auto-inserted scaler 0' between the filter 'Parsed_null_0' and the filter 'format'
SwScaler: reducing / aligning filtersize 1 -> 4
Last message repeated 1 times
SwScaler: reducing / aligning filtersize 1 -> 1
Last message repeated 1 times
[swscaler @ 0x1eba480] bicubic scaler, from rgb48be to rgb24 using MMXEXT
[swscaler @ 0x1eba480] 1280x720 -> 1280x720
[auto-inserted scaler 0 @ 0x1eba120] w:1280 h:720 fmt:rgb48be sar:0/1 -> w:1280 h:720 fmt:rgb24 sar:0/1 flags:0x41000
No pixel format specified, rgb24 for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.
[libx264rgb @ 0x1ecf020] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
[libx264rgb @ 0x1ecf020] profile High 4:4:4 Predictive, level 3.2, 4:4:4 10-bit
[libx264rgb @ 0x1ecf020] 264 - core 144 r2525+2 6a4fca8 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=0 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=0 chroma_qp_offset=0 threads=3 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=0 intra_refresh=0 rc=cqp mbtree=0 qp=0
Output #0, matroska, to 'lossless.rgb.mkv':
Metadata:
encoder : Lavf56.18.101
Stream #0:0: Video: h264 (libx264rgb) (H264 / 0x34363248), rgb24, 1280x720, q=-1--1, 50 fps, 1k tbn, 50 tbc
Metadata:
encoder : Lavc56.20.100 libx264rgb
Stream mapping:
Stream #0:0 -> #0:0 (sgi (native) -> h264 (libx264rgb))
Press [q] to stop, [?] for help
No more output streams to write to, finishing.
Segmentation fault (core dumped)
上流に報告します。
とにかく、ffmpeg、またはlibx264、libx265などの高ビット深度でコンパイルされたバージョンで実行したい他のプログラム用のデュアルビット深度環境を自分で構築するのは非常に簡単でした。（それが、短い名前の「10ビット」だけではなく、「高深度」と呼んだ理由です。）
編集の終わり：以下は、再コンパイルせずに私のとりとめのないものです。そして、win64用のffmpegをクロスコンパイルする方法についての良いビット
高いビット深度の入力をx264にフィードしようとするコマンドラインを試していないので、これを自分で試してみました。
ffmpegピクセル形式名（ffmpeg -pix_fmts）は、配置を指定するだけでなく、正確なビット配置にマップするため、各形式+ビット深度の組み合わせには異なる名前が付けられます。-pix_fmt yuv422p「私の入力と同じビット深度で422に変換する」という意味を期待していたと思います。
ウィキペディアによると、h.264は8〜14ビットの深さをHi444PPでのみサポートし、その他は10ビットまでです。Hi444PPは、x264が-qp 0またはに使用する予測ロスレスコーディングをサポートする唯一のプロファイルです-crf 0。編集：AFAICT、x264はまだ8、9、または10ビット用にコンパイルされていることのみをサポートしています。
とにかく、ここでは、ローカルx264を再コンパイルしなかったために機能しないコマンドからの無用な出力がたくさんあります。（ただし、再コンパイルされたx264で動作するはずです。この答えを自分で再生したい場合は、編集する場合があります。）
ffmpeg -v verbose -framerate 50 -f image2 -pattern_type glob -i ./3_DucksTakeOff_720p50_CgrLevels_SINC_FILTER_SVTdec05_/'*'.sgi -c:v libx264 -pix_fmt yuv420p10le -profile high10 yuv-high.mkv
ffmpeg version N-68044-gb9dd809 Copyright (c) 2000-2015 the FFmpeg developers
built on Jan 14 2015 23:21:08 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
configuration: --enable-gpl --enable-version3 --enable-nonfree --disable-doc --disable-ffserver --enable-libbluray --enable-libschroedinger --enable-libtheora --enable-libx264 --enable-libx265 --enable-libmp3lame --enable-libopus --enable-libwebp --enable-libvpx --disable-outdev=oss --disable-indev=oss --disable-encoder=vorbis --enable-libvorbis --enable-libfdk-aac --disable-encoder=aac --disable-decoder=jpeg2000 --enable-libvidstab
libavutil 54. 16.100 / 54. 16.100
libavcodec 56. 20.100 / 56. 20.100
libavformat 56. 18.101 / 56. 18.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 7.101 / 5. 7.101
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
Input #0, image2, from './3_DucksTakeOff_720p50_CgrLevels_SINC_FILTER_SVTdec05_/*.sgi':
Duration: 00:00:10.00, start: 0.000000, bitrate: N/A
Stream #0:0: Video: sgi, rgb48be, 1280x720, 50 tbr, 50 tbn, 50 tbc
Please use -profile:a or -profile:v, -profile is ambiguous
File 'yuv-high.mkv' already exists. Overwrite ? [y/N] y
[graph 0 input from stream 0:0 @ 0x24797e0] w:1280 h:720 pixfmt:rgb48be tb:1/50 fr:50/1 sar:0/1 sws_param:flags=2
Incompatible pixel format 'yuv420p10le' for codec 'libx264', auto-selecting format 'yuv420p'
[auto-inserted scaler 0 @ 0x24938c0] w:iw h:ih flags:'0x4' interl:0
[format @ 0x2494680] auto-inserting filter 'auto-inserted scaler 0' between the filter 'Parsed_null_0' and the filter 'format'
[auto-inserted scaler 0 @ 0x24938c0] w:1280 h:720 fmt:rgb48be sar:0/1 -> w:1280 h:720 fmt:yuv420p sar:0/1 flags:0x4
[libx264 @ 0x248eda0] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
[libx264 @ 0x248eda0] profile High, level 3.2
[libx264 @ 0x248eda0] 264 - core 144 r2525+2 6a4fca8 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - 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=3 lookahead_threads=1 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=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, matroska, to 'yuv-high.mkv':
Metadata:
encoder : Lavf56.18.101
Stream #0:0: Video: h264 (libx264) (H264 / 0x34363248), yuv420p, 1280x720, q=-1--1, 50 fps, 1k tbn, 50 tbc
Metadata:
encoder : Lavc56.20.100 libx264
Stream mapping:
Stream #0:0 -> #0:0 (sgi (native) -> h264 (libx264))
Press [q] to stop, [?] for help
No more output streams to write to, finishing.e=00:00:09.02 bitrate=18034.6kbits/s
frame= 500 fps=6.6 q=-1.0 Lsize= 21568kB time=00:00:09.96 bitrate=17739.6kbits/s
video:21564kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.020773%
Input file #0 (./3_DucksTakeOff_720p50_CgrLevels_SINC_FILTER_SVTdec05_/*.sgi):
Input stream #0:0 (video): 500 packets read (2765056000 bytes); 500 frames decoded;
Total: 500 packets (2765056000 bytes) demuxed
Output file #0 (yuv-high.mkv):
Output stream #0:0 (video): 500 frames encoded; 500 packets muxed (22081186 bytes);
Total: 500 packets (22081186 bytes) muxed
[libx264 @ 0x248eda0] frame I:2 Avg QP:29.33 size:131874
[libx264 @ 0x248eda0] frame P:257 Avg QP:31.07 size: 75444
[libx264 @ 0x248eda0] frame B:241 Avg QP:33.54 size: 10073
[libx264 @ 0x248eda0] consecutive B-frames: 3.6% 96.4% 0.0% 0.0%
[libx264 @ 0x248eda0] mb I I16..4: 0.1% 71.9% 28.0%
[libx264 @ 0x248eda0] mb P I16..4: 0.0% 4.5% 1.1% P16..4: 36.1% 37.6% 19.6% 0.0% 0.0% skip: 1.0%
[libx264 @ 0x248eda0] mb B I16..4: 0.0% 0.2% 0.1% B16..8: 34.3% 2.6% 1.1% direct: 9.6% skip:52.2% L0: 6.2% L1:46.6% BI:47.2%
[libx264 @ 0x248eda0] 8x8 transform intra:78.4% inter:60.4%
[libx264 @ 0x248eda0] coded y,uvDC,uvAC intra: 98.3% 95.3% 85.9% inter: 51.7% 34.8% 12.8%
[libx264 @ 0x248eda0] i16 v,h,dc,p: 5% 77% 4% 14%
[libx264 @ 0x248eda0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 2% 43% 11% 3% 5% 2% 16% 2% 16%
[libx264 @ 0x248eda0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 3% 40% 9% 4% 6% 3% 17% 2% 16%
[libx264 @ 0x248eda0] i8c dc,h,v,p: 47% 40% 6% 7%
[libx264 @ 0x248eda0] Weighted P-Frames: Y:1.2% UV:0.4%
[libx264 @ 0x248eda0] ref P L0: 70.9% 26.5% 1.8% 0.7% 0.0%
[libx264 @ 0x248eda0] ref B L0: 99.5% 0.5%
[libx264 @ 0x248eda0] kb/s:17664.40
$ x264 --fullhelp | less
...
Output bit depth: 8 (configured at compile time)
Incompatible pixel format 'yuv420p10le' for codec 'libx264', auto-selecting format 'yuv420p'行に注意してください。
おそらく私は必要としませんでした-profile、そして高ビット深度のx264でそれはうまくいくでしょう。（そして、ffmpegが呼び出す444 10 ビットyuva444p10leを選択する可能性があります。）私は、高ビット深度のx264は受け入れられると思いますyuv444p14leが、それでも10 ビットh.264しか生成しません。cmdline x264 --fullhelpは、8〜10の出力ビット深度についてかなり明示的であり、それ以上ではありません。奇妙なことに-profile high10、8ビットx264によって単に黙って無視されます。
内部的には、高ビット深度向けにコンパイルされたx264は10ビットデータの格納に16bppを使用するため、おそらくモーション検索などを16ビット値で実行します。また、6ビットを無視することで得られる速度がない限り、DCTは10ビットではなく16ビットより高い可能性があります。これは、DCTの前に10ビットに切り捨てた場合とは少し異なるDCT係数を生成する可能性があります。（つまり、x264にフィードする前に10ビットに変換した場合と、12、14、または16ビットに変換した場合では、出力が異なる可能性があります。）ただし、コードを確認するか、作成する前に試してください。この段落を信用しないでください。：P
（編集：ffmpegは、コンポーネントごとに10ビットを超えるx264-10bitをフィードしません。それは、swscaleを使用してビット深度自体を減らします。）
高ビット深度用にコンパイルした場合、x264とx265にパッチを適用してグローバル変数とAPI関数に異なる名前を使用するのはどれほど難しいかと思います。次に、両方のバージョンを一度にビルドし、それらの両方に対してffmpegをリンクさせることができます。ffmpeg libx264とlibx264rgbラッパーは、入力ストリームに応じて、適切なバージョンのAPIの呼び出しを処理します。（それ以外の場合は、-c:v libx264-deepまたはlibx264rgb-deep、ffmpegで合計4つの異なるx264 "コーデック"が必要になります。）
Windows用のffmpegをクロスコンパイルする方法
編集：Windowsの場合LD_LIBRARY_PATH、libx264 DLL ほど便利なものはないと思うので、高ビット深度の静的バイナリをビルドし、通常の使用のためにもう1つビルドするのが最善の策です。高深度libx264は、通常の深度h.264を出力できません。速度のペナルティだけでなく、それは不可能です。
Windows用に独自のffmpeg（静的バイナリ）をコンパイルする最も簡単な方法は、https：//github.com/rdp/ffmpeg-windows-build-helpersを使用することです。Linuxマシン（または多分OS Xのようなgccが動作する別のシステム）でリポジトリをgit cloneし、次に実行します。
./cross_compile_ffmpeg.sh --high-bitdepth=y --disable-nonfree=n --build-choice=win64
ソースからmingw-cross-compile GCCを構築しているため、これには他のすべてのものと一緒に、最初の実行に約8時間かかりました。（gccはデフォルトでブートストラップするために数回再構築します。これは、元々悪いコンパイラでコンパイルしていた場合に備えてです。）
でビルドスクリプトを更新できます。git pull再実行すると、ffmpeg、x264、x265、およびソースからコンパイルした他のプロジェクトの最新のgit更新が取得されます。（ほとんどの場合、tarballをダウンロードするだけです。）
私のLinuxデスクトップは時代を示しています。主にゲームで使用するwintendoがあります。私はビデオエンコーディングをいじり始めたので、クアッドコアのSandybridgeも特に便利だと思います。x265用。おそらく、x265の一部の関数にはAVX / SSE4のasmバージョンしかないため、私のSSSE3 Linuxマシン（Conroe）ではCにフォールバックしています。それか1fpsでもっと目立ちます...