x264 поддерживает как 8-битные, так и 10-битные выходные данные, и вам не нужно делать ничего особенного.

ffmpeg

При использовании ffmpegвы можете увидеть, какие форматы пикселей и битовая глубина поддерживаются libx264:

$ ffmpeg -h encoder=libx264
  [...]
  Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p nv12 nv16 nv21 yuv420p10le yuv422p10le yuv444p10le nv20le

10-битные пиксельные форматы: yuv420p10le, yuv422p10le, yuv444p10le.

x264

Вы также можете проверить x264поддерживаемую битовую глубину:

$ x264 --help
  [...]
  Output bit depth: 8/10

Раньше вам приходилось компилировать x264 с помощью --bit-depth=10, а затем связывать ffmpegего либо с 8-битной, либо с 10-битной libx264, но теперь это не нужно. Дополнительную информацию см. в разделе Унификация 8-битного и 10-битного интерфейса командной строки и библиотек .

редактировать: я успешно сделал 10-битное кодирование Ducks Take Off .

Первый способ: я создал 10-битный двоичный файл x264, который статически связывает 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

(сверхбыстрый и низкокачественный, потому что это доказательство концепции, а не проверка качества.) Я не компилировал его с помощью swscale. (Он был недоволен изображением RGB в libavutil или чем-то в этом роде). Он выдает ошибку, если входное цветовое пространство не соответствует --output-csp i444, что на самом деле хорошо, если вы не хотите, чтобы x264 случайно понизил цветность. Он работал нормально, когда я скормил ему несколько кадров yuv444p14le.y4m, производя 10-битный вывод. (Он может обрезать битовую глубину, но не понижать цветность без swscale.)

Второй способ: используйте 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.)

Я, очевидно, не пытался увидеть что-либо визуально с такими настройками качества. Я просто хотел, чтобы он работал быстро и не тратил кучу места на диске, так как я всегда получаю много выходных файлов, когда пытаюсь что-то изменить.

Отсутствие передачи массивных данных 4 млн в отдельный процесс x264 привело к тому, что он работал со скоростью 14 кадров в секунду вместо 12, так что приличное ускорение для сверхбыстрой скорости. Более медленное кодирование затмит эти накладные расходы.

Мой источник 48-битный RGB. Я обнаружил, что correct_rnd не влияет на вывод mkv. (бит-идентичные результаты без -sws_flags, с -sws_flags +accurate_rndи -vf scale=flags=accurate_rnd, за исключением нескольких битов в заголовке mkv, вероятно, рандомизированный UUID mkv. Даже с -qp 0, поэтому я не терял его из-за ошибки округления. cmp -l f1 f2 | lessчтобы сравнить двоичные файлы, которые могут быть то же самое после некоторой первоначальной разницы. Или ssdeep -p. Может быть accurate_rnd, сейчас по умолчанию?)

Есть один флаг swscaler ffmpeg, который имеет значение, если вы позволяете 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

На самом деле драйвер libx264 ffmpeg всегда настаивает на подаче 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-битных выходных версий каждой функции. Кроме того, я думаю , что прием различной битовой глубины ввода находится только в интерфейсе командной строки x264, а не в API библиотеки. Мне любопытно, что происходит, когда вы подаете входные данные API, где установлены более высокие биты... (ffpeg не позволяет вам сделать это без взлома кода, поэтому никому не нужно беспокоиться об этом).

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 не указан, ffmpeg выбирает yuv444p10leпри вводе rgb. Или с libx264rgb, он передает 8-битный rgb функциям, которые ожидают 16-битный (10 из которых являются значимыми), и 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 бит» для более короткого имени.)

конец редактирования: ниже мои бредни без перекомпиляции. И немного о том, как кросс-компилировать ffmpeg для win64.

Пробовал это сам, так как вы не пробовали с командной строкой, которая пыталась передать ввод с высокой битовой глубиной в x264.

Имена форматов пикселей ffmpeg ( ffmpeg -pix_fmts) не просто определяют расположение, они сопоставляются с точным расположением битов, и поэтому каждая комбинация формат + битовая глубина имеет другое имя. Я думаю, вы ожидали, что -pix_fmt yuv422pэто будет означать «преобразовать в 422 с той же битовой глубиной, что и мой ввод».

википедия говорит, что h.264 поддерживает глубину 8-14 бит только с Hi444PP, другие - только до 10 бит. Hi444PP — единственный профиль, поддерживающий предиктивное кодирование без потерь, которое x264 использует для -qp 0или -crf 0. edit: 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 как раз бы работало. (и потенциально выберите 444 10 бит, который вызывает ffmpeg yuva444p10le.) Я думаю, что высокая битовая глубина x264 может принять yuv444p14le, но все равно будет производить только 10-битный h.264. Командная строка x264 --fullhelpдовольно четко указывает разрядность вывода от 8 до 10, не выше. Странно, что -profile high108bit x264 просто молча игнорирует.

Внутри x264, скомпилированный для высокой битовой глубины, использует 16bpp для хранения любых 10-битных данных, поэтому он, вероятно, выполняет поиск движения и т. Д. С 16-битными значениями. И может DCT выше 16 бит, а не 10 бит, если только скорость не будет увеличена за счет игнорирования 6 бит. Это может привести к немного другим коэффициентам DCT, чем если бы вы округляли до 10 бит перед DCT. (Таким образом, вы потенциально можете получить другой результат при преобразовании в 10-битное перед подачей на x264 по сравнению с 12-, 14- или 16-битным.) Я должен попробовать. посмотрите на код или попробуйте его, прежде чем что-то придумывать. Не верьте этому абзацу. :П

(редактировать: ffmpeg не будет передавать x264-10bit ничего более 10 бит на компонент. Он будет использовать swscale для уменьшения самой битовой глубины.)

Интересно, насколько сложно было бы исправить x264 и x265, чтобы использовать разные имена для глобальных переменных и функций API, при компиляции для высокой разрядности. Затем вы можете собрать обе версии одновременно и связать ffmpeg с обеими из них. ffmpeg libx264и libx264rgbобертки могут позаботиться о вызове соответствующей версии API в зависимости от входного потока. (В противном случае вам понадобится -c:v libx264-deepили libx264rgb-deep, всего 4 разных «кодека» x264 в ffmpeg.)

Как кросс-компилировать ffmpeg для Windows

edit: для окон я не думаю, что есть что-то более удобное, чем LD_LIBRARY_PATHдля DLL libx264, поэтому лучше всего по-прежнему создавать статический двоичный файл с высокой битовой глубиной и еще один для обычного использования. libx264 с высокой глубиной вообще НЕ МОЖЕТ выводить нормальную глубину h.264. Не просто штраф за скорость, он просто не может.

Самый простой способ скомпилировать собственный ffmpeg (статический двоичный файл) для Windows — с помощью https://github.com/rdp/ffmpeg-windows-build-helpers . git клонируйте репозиторий на машину с Linux (или, может быть, на другую систему с работающим gcc, например OS X?), затем запустите

./cross_compile_ffmpeg.sh --high-bitdepth=y --disable-nonfree=n --build-choice=win64

Это заняло около 8 часов для первого запуска, так как он собрал mingw-кросс-компиляцию GCC из исходного кода вместе со всем остальным. (по умолчанию gcc несколько раз перестраивает себя для начальной загрузки, если вы изначально компилировали его с помощью плохого компилятора.)

Вы можете обновить скрипт сборки с помощью git pull, и при его повторном запуске будут получены последние обновления git для ffmpeg, x264, x265 и, возможно, некоторых других проектов, которые он компилирует из исходного кода. (В большинстве случаев он просто загружает архивы.)

Мой рабочий стол Linux показывает свой возраст. У меня есть wintendo, который я в основном использую для игр. Поскольку я начал возиться с кодированием видео, я считаю, что его четырехъядерный процессор Sandybridge очень полезен для этого, особенно. для х265. Вероятно, некоторые из функций x265 имеют только ассемблерные версии для AVX/SSE4, поэтому на моей машине с SSSE3 Linux (Conroe) они возвращаются к C. Это или это более заметно на 1fps ...

Я скачал ffmpeg по ссылке https://sourceforge.net/projects/ffmpeg-hi/?source=typ_redirect

И ввел следующую команду для создания 10-битного файла h.264 4:2:2 :

ffmpeg-hi10-heaac.exe -i "im.mp4" -c:v libx264 -pix_fmt yuv422p10le yuv-high-.ts