Answers.Body: <p>edit: I successfully made a 10bit encode of <a href="http://forum.doom9.org/showthread.php?t=135034" rel="noreferrer">Ducks Take Off</a>.</p>
  
  <h2>First way: I built a 10bit x264 binary that statically links libx264.</h2>
  
  <pre><code>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
  </code></pre>
  
  <p>(ultrafast and low quality because it's a proof of concept, not a quality test.)
  I didn't compile it with swscale.  (It was unhappy about an RGB pix fmt in libavutil or something).  It errors out if the input colorspace doesn't match <code>--output-csp i444</code>, which is actually nice if you don't want to accidentally have x264 downsample the chroma.  It worked fine when I fed it a few frames of <code>yuv444p14le.y4m</code>, producing 10bit output.  (It can truncate bit depth, but not downsample chroma without swscale.)</p>
  
  <h2>Second way: use <code>LD_LIBRARY_PATH</code> to select a 10bit libx264.so</h2>
  
  <p>You can use the same ffmpeg dynamic-linked binary for everything.  </p>
  
  <pre><code>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 -&gt; 4
      Last message repeated 1 times
  SwScaler: reducing / aligning filtersize 1 -&gt; 1
  SwScaler: reducing / aligning filtersize 9 -&gt; 8
  [swscaler @ 0x1b500c0] bicubic scaler, from rgb48be to yuv420p10le using MMXEXT
  [swscaler @ 0x1b500c0] 1280x720 -&gt; 1280x720
  [auto-inserted scaler 0 @ 0x1b7dae0] w:1280 h:720 fmt:rgb48be sar:0/1 -&gt; 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 -&gt; #0:0 (sgi (native) -&gt; 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.)
  </code></pre>
  
  <p>I obviously didn't try to see anything visually with those quality settings.  I just wanted it to run fast, and not waste a bunch of disk space since I always end up making lots of output files when trying variations on things.</p>
  
  <p>Not piping the massive y4m data to a separate x264 process made it go 14 fps instead of 12, so a decent speedup for ultrafast.  Slower encodes will dwarf that overhead.</p>
  
  <p>My source is 48bit RGB.  I found that accurate_rnd had no effect on the output mkv. (bit-identical results with no <code>-sws_flags</code>, with <code>-sws_flags +accurate_rnd</code>, and <code>-vf scale=flags=accurate_rnd</code>, except for a few bits in the mkv header, probably the randomized mkv UUID.  Even with <code>-qp 0</code>, so I wasn't losing it to rounding error.  <code>cmp -l f1 f2 | less</code> to compare binary files that might be the same after some initial difference.  Or <code>ssdeep -p</code>.  Maybe <code>accurate_rnd</code> is the default now?)</p>
  
  <p>There is one ffmpeg swscaler flag that matters, if you're letting ffmpeg downsample your chroma:  lanczos instead of the default bicubic.  (I assume lanczos is still regarded as the best choice for high quality?  Haven't read up for a while.)</p>
  
  <p><code>highdepth-ffmpeg -i in -pix_fmt yuv420p10le ...encode...opts...<br>
  -vf scale=flags=lanczos -sws_flags +accurate_rnd+print_info  with_ld_path.420p10.accurate_rnd.lanczos.mkv</code></p>
  
  <p>Adding <code>+lanczos</code> to <code>-sws_flags</code> doesn't work:</p>
  
  <pre><code>[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!
  </code></pre>
  
  <p>If you try to feed it input deeper than 10 bits, ffmpeg refuses.</p>
  
  <pre><code>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 -&gt; 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
  </code></pre>
  
  <p>Actually, ffmpeg's libx264 driver always insists on feeding x264 exactly the bit-depth it's compiled for.  e.g. with <code>-pix_fmt yuv420p</code>:</p>
  
  <pre><code>Incompatible pixel format 'yuv420p' for codec 'libx264', auto-selecting format 'yuv420p10le'
  </code></pre>
  
  <p>x264.h says:</p>
  
  <pre><code>/* 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 &gt; 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;
  </code></pre>
  
  <p>I think internally x264 (the CLI) always has to up-convert pixel formats, the code doesn't have 8bit input, 10bit output versions of every function.  And also, I <em>think</em> the accepting of various input bit depths is just in the x264 CLI, not the library API.  I'm curious what happens when you feed the API input where there are higher bits set...  (ffpeg doesn't allow you to do this without hacking the code, so this isn't something anyone needs to worry about avoiding.)</p>
  
  <pre><code>frame.c:370:  So this is why ffmpeg can't give 8-bit input to libx264
  #if HIGH_BIT_DEPTH
      if( !(src-&gt;img.i_csp &amp; 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
  </code></pre>
  
  <p>With no pix_fmt specified, ffmpeg chooses <code>yuv444p10le</code> when given rgb input.  Or with <code>libx264rgb</code>, it feeds 8bit rgb to functions that are expecting 16bit (10 of which are significant), and segfaults >.&lt;.  I'll go report that upstream...</p>
  
  <pre><code> 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 -&gt; 4
      Last message repeated 1 times
  SwScaler: reducing / aligning filtersize 1 -&gt; 1
      Last message repeated 1 times
  [swscaler @ 0x1eba480] bicubic scaler, from rgb48be to rgb24 using MMXEXT
  [swscaler @ 0x1eba480] 1280x720 -&gt; 1280x720
  [auto-inserted scaler 0 @ 0x1eba120] w:1280 h:720 fmt:rgb48be sar:0/1 -&gt; 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 -&gt; #0:0 (sgi (native) -&gt; h264 (libx264rgb))
  Press [q] to stop, [?] for help
  No more output streams to write to, finishing.
  Segmentation fault (core dumped)
  </code></pre>
  
  <p>I'll report that upstream.</p>
  
  <p>Anyway, it turns out it was pretty darn easy to build myself a dual-bit-depth environment for ffmpeg, or any other program you want to run with high-bit-depth-compiled versions of libx264, libx265, and anything else you want.  (That's why I called it "highdepth", not just "10bit" for a shorter name.)</p>
  
  <h2>end of edit: below here are my ramblings without recompiling.  And a good bit about how to cross-compile ffmpeg for win64</h2>
  
  <p>Tried this myself, since you didn't try with a cmdline that tried to feed high bit depth input to x264.</p>
  
  <p>ffmpeg pixel format names (<code>ffmpeg -pix_fmts</code>) don't just specify an arrangement, they map to an exact bit arrangement, and thus each format+bit-depth combo has a different name.  I think you were expecting <code>-pix_fmt yuv422p</code> to mean "convert to 422 in the same bit depth as my input".</p>
  
  <p><a href="http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC" rel="noreferrer">wikipedia</a> says h.264 supports 8-14 bit depth only with Hi444PP, others are only up to 10bit.  Hi444PP is the only profile that supports predictive lossless coding, which x264 uses for <code>-qp 0</code> or <code>-crf 0</code>.  edit: AFAICT, x264 still only supports being compiled for 8, 9, or 10bits.</p>
  
  <p>Anyway, here's a bunch of useless output from a command that doesn't work because I didn't recompile my local x264.  (But it should work with recompiled x264.  I might edit this answer if I want to play with it myself.)</p>
  
  <p><code>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</code></p>
  
  <pre><code>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 -&gt; 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 -&gt; #0:0 (sgi (native) -&gt; 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)
  </code></pre>
  
  <p>Note the <code>Incompatible pixel format 'yuv420p10le' for codec 'libx264', auto-selecting format 'yuv420p'</code> line.</p>
  
  <p>Probably I didn't need <code>-profile</code>, and with a high-bit-depth x264, it would just work.  (and potentially pick 444 10bit, which ffmpeg calls <code>yuva444p10le</code>.)  I <em>think</em> high bit depth x264 could accept <code>yuv444p14le</code>, but would still only produce 10bit h.264.  The cmdline <code>x264 --fullhelp</code> is pretty explicit about output bit depth from 8 to 10, not higher.  Weird that <code>-profile high10</code> is just silently ignored by 8bit x264.</p>
  
  <p>Internally, x264 compiled for high bit depth uses 16bpp for storing any 10bit data, so it probably does motion search and so on with 16bit values.  And might DCT higher 16bit rather than 10bit, unless there's speed to be gained from ignoring 6 bits.  This could produce slightly different DCT coefficients than if you rounded down to 10bit before DCT.  (So you potentially get different output from converting down to 10bit before feeding to x264, vs. giving it 12, 14, or 16bit.)  I should prob. look at the code or try it before making stuff up, though.  Don't trust this paragraph. :P</p>
  
  <p>(edit: ffmpeg won't feed x264-10bit anything more than 10bits per component.  It will use swscale to reduce the bit depth itself.)</p>
  
  <p>I wonder how hard it would be to patch x264 and x265 to use different names for global variables and API functions, when compiled for high-bit-depth.  Then you could build both versions at once, and have ffmpeg linked against both of them.  The ffmpeg <code>libx264</code> and <code>libx264rgb</code> wrappers could take care of calling the appropriate version of the api depending on the input stream.  (Otherwise you'd need <code>-c:v libx264-deep</code> or <code>libx264rgb-deep</code>, for a total of 4 different x264 "codecs" in ffmpeg.)</p>
  
  <h2>How to cross compile ffmpeg for windows</h2>
  
  <p>edit: For windows, I don't think there's anything as convenient as <code>LD_LIBRARY_PATH</code> for a libx264 DLL, so your best bet is still to build a high-bit-depth static binary, and another one for normal use.  High-depth libx264 CAN'T output normal depth h.264 at all.  Not just a speed penalty, it just can't.</p>
  
  <p>The easiest way to compile your own ffmpeg (static binary) for windows is with <a href="https://github.com/rdp/ffmpeg-windows-build-helpers" rel="noreferrer">https://github.com/rdp/ffmpeg-windows-build-helpers</a>.  git clone the repo on a Linux machine (or maybe another system with a working gcc, like OS X?), then run</p>
  
  <p><code>./cross_compile_ffmpeg.sh --high-bitdepth=y --disable-nonfree=n --build-choice=win64</code></p>
  
  <p>This took about 8 hours for the first run, since it built mingw-cross-compile GCC from source, along with everything else.  (gcc defaults to rebuilding itself several times to bootstrap, in case you were originally compiling it with a bad compiler.)</p>
  
  <p>You can update the build script with <code>git pull</code>, and re-running it will pull the latest git updates for ffmpeg, x264, x265, and maybe some of the other projects it compiles from source.  (For most it just downloads tarballs.)</p>
  
  <p>My Linux desktop is showing its age.  I have a wintendo I mostly use for games.  Since I started messing around with video encoding, I find its quad-core Sandybridge pretty useful for that, too, esp. for x265.  Probably some of x265's functions only have asm versions for AVX/SSE4, so it's falling back to C on my SSSE3 Linux machine (Conroe).  That or it's more noticable at 1fps...</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-01-17T21:51:41.457Z
Answers.Text: Does stackexchange notify people when I make edits?  posting a comment in case it doesn't.
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-12-29T09:32:59.410Z
Answers.Text: this is a lot simpler on OS X, where dynamic linking is used. Simply `brew reinstall x264 --with-10-bit` and you are done, ffmpeg will use the new x264 flavor :)
Answers.UserDisplayName: Display Name
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-12-29T15:54:36.760Z
Answers.Text: @SargeBorsch: the point of this answer was to have both flavours installed AT THE SAME TIME, so you can compare 8bit and 10bit without reinstalling the library.  OS X dynamic linking works pretty much the same as Linux's, where you could similarly replace your libx264 install with the other flavour if you wanted.
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-12-30T16:04:44.567Z
Answers.Text: @PeterCordes hmm, my bad. You are right
Answers.UserDisplayName: Display Name
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-01-16T06:31:08.800Z
Answers.LastActivityDate: 2015-01-17T21:56:21.093Z
Answers.LastEditDate: 2015-01-17T21:56:21.093Z
Answers.UserDisplayName: Peter Cordes
Answers.Body: <p>I downloaded the ffmpeg from the link
  <a href="https://sourceforge.net/projects/ffmpeg-hi/?source=typ_redirect" rel="nofollow noreferrer">https://sourceforge.net/projects/ffmpeg-hi/?source=typ_redirect</a></p>
  <p>And entered the below command to create <strong>4:2:2 10bit h.264</strong> file:</p>
  <pre><code>ffmpeg-hi10-heaac.exe -i &quot;im.mp4&quot; -c:v libx264 -pix_fmt yuv422p10le yuv-high-.ts
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2017-08-02T06:46:53.043Z
Answers.LastActivityDate: 2020-07-10T14:17:01.993Z
Answers.LastEditDate: 2020-07-10T14:17:01.993Z
Answers.UserDisplayName: user19639
Answers.Body: <h1>x264 supports both 8-bit and 10-bit outputs, and you don't have to do anything special.</h1>
  
  <h3><code>ffmpeg</code></h3>
  
  <p>If using <code>ffmpeg</code> you can see what pixel formats and bit depths are supported by libx264:</p>
  
  <pre><code>$ ffmpeg -h encoder=libx264
    [...]
    Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p nv12 nv16 nv21 yuv420p10le yuv422p10le yuv444p10le nv20le
  </code></pre>
  
  <p>10-bit pixel formats are: yuv420p10le, yuv422p10le, yuv444p10le.</p>
  
  <h3><code>x264</code></h3>
  
  <p>You can also check <code>x264</code> for supported bit depths:</p>
  
  <pre><code>$ x264 --help
    [...]
    Output bit depth: 8/10
  </code></pre>
  
  <p>Previously you had to compile x264 with <code>--bit-depth=10</code>, and then link your <code>ffmpeg</code> to either an 8-bit or 10-bit libx264, but that is now unnecessary. See <a href="https://git.videolan.org/?p=x264.git;a=commit;h=71ed44c7312438fac7c5c5301e45522e57127db4" rel="noreferrer">Unify 8-bit and 10-bit CLI and libraries</a> for more info.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-12-03T05:58:44.523Z
Answers.Text: Damn, that makes things complicated. So I'll need two ffmpeg binaries linked against the two x264 libraries. Do you know if there are static builds of the 10bit x264 anywhere?
Answers.UserDisplayName: stib
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-12-03T07:15:51.987Z
Answers.Text: Find them here you will: http://download.videolan.org/pub/x264/binaries/ 
  
  If you want to build it yourself there is a hugely long winded process invoving installing mingw, yasm, git and gcc and lots of mucking around here: http://doom10.org/index.php?topic=26.0 But I couldn't get it to work, mainly due to stupid corporate firewall which won't allow git.
Answers.UserDisplayName: stib
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-12-03T07:45:31.957Z
Answers.Text: Maybe you can get [Zeranoe](http://ffmpeg.zeranoe.com/builds/) to provide such a build. Sorry, I'm fairly useless when it comes to Windows.
Answers.UserDisplayName: llogan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-12-04T07:03:11.217Z
Answers.Text: So am I, that's the problem. I've posted a build request, we'll see how it goes.
Answers.UserDisplayName: stib
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-11-29T05:02:07.870Z
Answers.Text: FWIW these days libx264 is "both" I believe...
Answers.UserDisplayName: rogerdpack
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2014-12-03T04:11:49.630Z
Answers.LastActivityDate: 2018-11-29T19:23:12.177Z
Answers.LastEditDate: 2018-11-29T19:23:12.177Z
Answers.UserDisplayName: llogan
Body: <p>I believe that libx264 is now capable of doing 10-bit 4:2:2 encodings, but I can't seem to get it to work. I'm using ffmpeg (info below), and I've also tried the x264 encoder directly. I've tried </p>
  
  <pre><code>ffmpeg.exe -i input.mov -c:v libx264 -profile:v high422 -crf 20 -pix_fmt yuv422p output.mp4
  </code></pre>
  
  <p>and that produces nice 4:2:2 output, but only at 8 bit depth,</p>
  
  <pre><code>[libx264 @ 00000000055a9de0] profile High 4:2:2, level 4.0, 4:2:2 8-bit
  </code></pre>
  
  <p>and I've tried</p>
  
  <pre><code>ffmpeg.exe -i input.mov -c:v libx264 -profile:v high10 -crf 20 -pix_fmt yuv422p output.mp4
  </code></pre>
  
  <p>and that gives me the error:</p>
  
  <pre><code>x264 [error]: high10 profile doesn't support 4:2:2
  [libx264 @ 00000000051ead60] Error setting profile high10.
  [libx264 @ 00000000051ead60] Possible profiles: baseline main high high10 high422 high444
  </code></pre>
  
  <p>In the x264 --fullhelp documentation I find:</p>
  
  <pre><code>  --profile &lt;string&gt;      Force the limits of an H.264 profile
                                Overrides all settings.
                                [...]
                                - high10:
                                  No lossless.
                                  Support for bit depth 8-10.
                                - high422:
                                  No lossless.
                                  Support for bit depth 8-10.
                                  Support for 4:2:0/4:2:2 chroma subsampling.
                                - high444:
                                  Support for bit depth 8-10.
                                  Support for 4:2:0/4:2:2/4:4:4 chroma subsampling.
  </code></pre>
  
  <p>So it can do 4:2:2 at 10 bit depth, and even 4:4:4 at 10 bits apparently, but there's no indication of how to set the output bit depth. There is an option <code>--input-depth &lt;integer&gt; Specify input bit depth for raw input</code> but nothing for output bit depth.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-01-17T23:37:23.830Z
Comments.Text: I found this: http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf  Apparently you get better compression efficiency (size vs. quality) with 10bit.  I might start using 10bit regularly, if it isn't much slower to encode.
Comments.UserDisplayName: Peter Cordes
Tags: <ffmpeg><h.264><libx264><x264>
Title: encoding 4:2:2 in 10-bit with libx264
UserDisplayName: stib
ThreadText: # encoding 4:2:2 in 10-bit with libx264
  
  (Asked by: username_0 on 2014-12-03)
  
  I believe that libx264 is now capable of doing 10-bit 4:2:2 encodings, but I can't seem to get it to work. I'm using ffmpeg (info below), and I've also tried the x264 encoder directly. I've tried
  
  ```
  ffmpeg.exe -i input.mov -c:v libx264 -profile:v high422 -crf 20 -pix_fmt yuv422p output.mp4
  
  ```
  
  and that produces nice 4:2:2 output, but only at 8 bit depth,
  
  ```
  [libx264 @ 00000000055a9de0] profile High 4:2:2, level 4.0, 4:2:2 8-bit
  
  ```
  
  and I've tried
  
  ```
  ffmpeg.exe -i input.mov -c:v libx264 -profile:v high10 -crf 20 -pix_fmt yuv422p output.mp4
  
  ```
  
  and that gives me the error:
  
  ```
  x264 [error]: high10 profile doesn't support 4:2:2
  [libx264 @ 00000000051ead60] Error setting profile high10.
  [libx264 @ 00000000051ead60] Possible profiles: baseline main high high10 high422 high444
  
  ```
  
  In the x264 --fullhelp documentation I find:
  
  ```
    --profile <string>      Force the limits of an H.264 profile
                                Overrides all settings.
                                [...]
                                - high10:
                                  No lossless.
                                  Support for bit depth 8-10.
                                - high422:
                                  No lossless.
                                  Support for bit depth 8-10.
                                  Support for 4:2:0/4:2:2 chroma subsampling.
                                - high444:
                                  Support for bit depth 8-10.
                                  Support for 4:2:0/4:2:2/4:4:4 chroma subsampling.
  
  ```
  
  So it can do 4:2:2 at 10 bit depth, and even 4:4:4 at 10 bits apparently, but there's no indication of how to set the output bit depth. There is an option `--input-depth <integer> Specify input bit depth for raw input` but nothing for output bit depth.
  
  **Tags:** ffmpeg, h.264, libx264, x264
  
  > **Comments:**
  > **username_1**: I found this: http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf  Apparently you get better compression efficiency (size vs. quality) with 10bit.  I might start using 10bit regularly, if it isn't much slower to encode.  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_4 on 2014-12-03. Score: 17 | Accepted answer
  
  # x264 supports both 8-bit and 10-bit outputs, and you don't have to do anything special.
  
  ### `ffmpeg`
  
  If using `ffmpeg` you can see what pixel formats and bit depths are supported by libx264:
  
  ```
  $ ffmpeg -h encoder=libx264
    [...]
    Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p nv12 nv16 nv21 yuv420p10le yuv422p10le yuv444p10le nv20le
  
  ```
  
  10-bit pixel formats are: yuv420p10le, yuv422p10le, yuv444p10le.
  
  ### `x264`
  
  You can also check `x264` for supported bit depths:
  
  ```
  $ x264 --help
    [...]
    Output bit depth: 8/10
  
  ```
  
  Previously you had to compile x264 with `--bit-depth=10`, and then link your `ffmpeg` to either an 8-bit or 10-bit libx264, but that is now unnecessary. See [Unify 8-bit and 10-bit CLI and libraries](https://git.videolan.org/?p=x264.git;a=commit;h=71ed44c7312438fac7c5c5301e45522e57127db4) for more info.
  
  > **Comments:**
  > **username_0**: Damn, that makes things complicated. So I'll need two ffmpeg binaries linked against the two x264 libraries. Do you know if there are static builds of the 10bit x264 anywhere?  
  > **username_0**: Find them here you will: http://download.videolan.org/pub/x264/binaries/   If you want to build it yourself there is a hugely long winded process invoving installing mingw, yasm, git and gcc and lots of mucking around here: http://doom10.org/index.php?topic=26.0 But I couldn't get it to work, mainly due to stupid corporate firewall which won't allow git.  
  > **username_4**: Maybe you can get [Zeranoe](http://ffmpeg.zeranoe.com/builds/) to provide such a build. Sorry, I'm fairly useless when it comes to Windows.  
  > **username_0**: So am I, that's the problem. I've posted a build request, we'll see how it goes.  
  > **username_5**: FWIW these days libx264 is "both" I believe...  
  
  ---
  
  ### Answer by username_1 on 2015-01-16. Score: 7
  
  edit: I successfully made a 10bit encode of [Ducks Take Off](http://forum.doom9.org/showthread.php?t=135034).
  
  ## First way: I built a 10bit x264 binary that statically links libx264.
  
  ```
  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
  
  ```
  
  (ultrafast and low quality because it's a proof of concept, not a quality test.)
  I didn't compile it with swscale. (It was unhappy about an RGB pix fmt in libavutil or something). It errors out if the input colorspace doesn't match `--output-csp i444`, which is actually nice if you don't want to accidentally have x264 downsample the chroma. It worked fine when I fed it a few frames of `yuv444p14le.y4m`, producing 10bit output. (It can truncate bit depth, but not downsample chroma without swscale.)
  
  ## Second way: use `LD_LIBRARY_PATH` to select a 10bit libx264.so
  
  You can use the same ffmpeg dynamic-linked binary for everything.
  
  ```
  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.)
  
  ```
  
  I obviously didn't try to see anything visually with those quality settings. I just wanted it to run fast, and not waste a bunch of disk space since I always end up making lots of output files when trying variations on things.
  
  Not piping the massive y4m data to a separate x264 process made it go 14 fps instead of 12, so a decent speedup for ultrafast. Slower encodes will dwarf that overhead.
  
  My source is 48bit RGB. I found that accurate\_rnd had no effect on the output mkv. (bit-identical results with no `-sws_flags`, with `-sws_flags +accurate_rnd`, and `-vf scale=flags=accurate_rnd`, except for a few bits in the mkv header, probably the randomized mkv UUID. Even with `-qp 0`, so I wasn't losing it to rounding error. `cmp -l f1 f2 | less` to compare binary files that might be the same after some initial difference. Or `ssdeep -p`. Maybe `accurate_rnd` is the default now?)
  
  There is one ffmpeg swscaler flag that matters, if you're letting ffmpeg downsample your chroma: lanczos instead of the default bicubic. (I assume lanczos is still regarded as the best choice for high quality? Haven't read up for a while.)
  
  `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`
  
  Adding `+lanczos` to `-sws_flags` doesn't work:
  
  ```
  [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!
  
  ```
  
  If you try to feed it input deeper than 10 bits, ffmpeg refuses.
  
  ```
  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
  
  ```
  
  Actually, ffmpeg's libx264 driver always insists on feeding x264 exactly the bit-depth it's compiled for. e.g. with `-pix_fmt yuv420p`:
  
  ```
  Incompatible pixel format 'yuv420p' for codec 'libx264', auto-selecting format 'yuv420p10le'
  
  ```
  
  x264.h says:
  
  ```
  /* 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;
  
  ```
  
  I think internally x264 (the CLI) always has to up-convert pixel formats, the code doesn't have 8bit input, 10bit output versions of every function. And also, I *think* the accepting of various input bit depths is just in the x264 CLI, not the library API. I'm curious what happens when you feed the API input where there are higher bits set... (ffpeg doesn't allow you to do this without hacking the code, so this isn't something anyone needs to worry about avoiding.)
  
  ```
  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
  
  ```
  
  With no pix\_fmt specified, ffmpeg chooses `yuv444p10le` when given rgb input. Or with `libx264rgb`, it feeds 8bit rgb to functions that are expecting 16bit (10 of which are significant), and segfaults >.<. I'll go report that upstream...
  
  ```
   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)
  
  ```
  
  I'll report that upstream.
  
  Anyway, it turns out it was pretty darn easy to build myself a dual-bit-depth environment for ffmpeg, or any other program you want to run with high-bit-depth-compiled versions of libx264, libx265, and anything else you want. (That's why I called it "highdepth", not just "10bit" for a shorter name.)
  
  ## end of edit: below here are my ramblings without recompiling. And a good bit about how to cross-compile ffmpeg for win64
  
  Tried this myself, since you didn't try with a cmdline that tried to feed high bit depth input to x264.
  
  ffmpeg pixel format names (`ffmpeg -pix_fmts`) don't just specify an arrangement, they map to an exact bit arrangement, and thus each format+bit-depth combo has a different name. I think you were expecting `-pix_fmt yuv422p` to mean "convert to 422 in the same bit depth as my input".
  
  [wikipedia](http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC) says h.264 supports 8-14 bit depth only with Hi444PP, others are only up to 10bit. Hi444PP is the only profile that supports predictive lossless coding, which x264 uses for `-qp 0` or `-crf 0`. edit: AFAICT, x264 still only supports being compiled for 8, 9, or 10bits.
  
  Anyway, here's a bunch of useless output from a command that doesn't work because I didn't recompile my local x264. (But it should work with recompiled x264. I might edit this answer if I want to play with it myself.)
  
  `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)
  
  ```
  
  Note the `Incompatible pixel format 'yuv420p10le' for codec 'libx264', auto-selecting format 'yuv420p'` line.
  
  Probably I didn't need `-profile`, and with a high-bit-depth x264, it would just work. (and potentially pick 444 10bit, which ffmpeg calls `yuva444p10le`.) I *think* high bit depth x264 could accept `yuv444p14le`, but would still only produce 10bit h.264. The cmdline `x264 --fullhelp` is pretty explicit about output bit depth from 8 to 10, not higher. Weird that `-profile high10` is just silently ignored by 8bit x264.
  
  Internally, x264 compiled for high bit depth uses 16bpp for storing any 10bit data, so it probably does motion search and so on with 16bit values. And might DCT higher 16bit rather than 10bit, unless there's speed to be gained from ignoring 6 bits. This could produce slightly different DCT coefficients than if you rounded down to 10bit before DCT. (So you potentially get different output from converting down to 10bit before feeding to x264, vs. giving it 12, 14, or 16bit.) I should prob. look at the code or try it before making stuff up, though. Don't trust this paragraph. :P
  
  (edit: ffmpeg won't feed x264-10bit anything more than 10bits per component. It will use swscale to reduce the bit depth itself.)
  
  I wonder how hard it would be to patch x264 and x265 to use different names for global variables and API functions, when compiled for high-bit-depth. Then you could build both versions at once, and have ffmpeg linked against both of them. The ffmpeg `libx264` and `libx264rgb` wrappers could take care of calling the appropriate version of the api depending on the input stream. (Otherwise you'd need `-c:v libx264-deep` or `libx264rgb-deep`, for a total of 4 different x264 "codecs" in ffmpeg.)
  
  ## How to cross compile ffmpeg for windows
  
  edit: For windows, I don't think there's anything as convenient as `LD_LIBRARY_PATH` for a libx264 DLL, so your best bet is still to build a high-bit-depth static binary, and another one for normal use. High-depth libx264 CAN'T output normal depth h.264 at all. Not just a speed penalty, it just can't.
  
  The easiest way to compile your own ffmpeg (static binary) for windows is with <https://github.com/rdp/ffmpeg-windows-build-helpers>. git clone the repo on a Linux machine (or maybe another system with a working gcc, like OS X?), then run
  
  `./cross_compile_ffmpeg.sh --high-bitdepth=y --disable-nonfree=n --build-choice=win64`
  
  This took about 8 hours for the first run, since it built mingw-cross-compile GCC from source, along with everything else. (gcc defaults to rebuilding itself several times to bootstrap, in case you were originally compiling it with a bad compiler.)
  
  You can update the build script with `git pull`, and re-running it will pull the latest git updates for ffmpeg, x264, x265, and maybe some of the other projects it compiles from source. (For most it just downloads tarballs.)
  
  My Linux desktop is showing its age. I have a wintendo I mostly use for games. Since I started messing around with video encoding, I find its quad-core Sandybridge pretty useful for that, too, esp. for x265. Probably some of x265's functions only have asm versions for AVX/SSE4, so it's falling back to C on my SSSE3 Linux machine (Conroe). That or it's more noticable at 1fps...
  
  > **Comments:**
  > **username_1**: Does stackexchange notify people when I make edits?  posting a comment in case it doesn't.  
  > **username_2**: this is a lot simpler on OS X, where dynamic linking is used. Simply `brew reinstall x264 --with-10-bit` and you are done, ffmpeg will use the new x264 flavor :)  
  > **username_1**: @SargeBorsch: the point of this answer was to have both flavours installed AT THE SAME TIME, so you can compare 8bit and 10bit without reinstalling the library.  OS X dynamic linking works pretty much the same as Linux's, where you could similarly replace your libx264 install with the other flavour if you wanted.  
  > **username_2**: @username_1 hmm, my bad. You are right  
  
  ---
  
  ### Answer by username_3 on 2017-08-02. Score: 1
  
  I downloaded the ffmpeg from the link
  <https://sourceforge.net/projects/ffmpeg-hi/?source=typ_redirect>
  
  And entered the below command to create **4:2:2 10bit h.264** file:
  
  ```
  ffmpeg-hi10-heaac.exe -i "im.mp4" -c:v libx264 -pix_fmt yuv422p10le yuv-high-.ts
  
  ```
  
  
  ---
  
  