редактирование: я успешно сделал 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-пикселем fmt в 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.)
Я явно не пытался увидеть что-либо визуально с этими настройками качества. Я просто хотел, чтобы он работал быстро и не тратил кучу дискового пространства, так как я всегда получаю много выходных файлов, когда пытаюсь варьировать вещи.
Отсутствие передачи огромных данных y4m в отдельный процесс x264 привело к тому, что скорость передачи составила 14 кадров в секунду вместо 12, что обеспечивает приличное ускорение для сверхбыстрых. Более медленные кодировки затмят эти издержки.
Мой источник 48-битный RGB. Я обнаружил, что correct_rnd не влиял на вывод mkv. (Бит-идентичные результаты без -sws_flags, с -sws_flags +accurate_rnd, и -vf scale=flags=accurate_rnd, за исключением нескольких битов в заголовке mkv, вероятно, случайный UDID mkv. Даже с -qp 0, так что я не потерял его из-за ошибки округления. cmp -l f1 f2 | lessДля сравнения двоичных файлов, которые могут быть то же самое после некоторой начальной разницы. Или ssdeep -p. Может быть accurate_rnd, по умолчанию сейчас?)
Существует один флаг ffmpeg swscaler, который имеет значение, если вы разрешаете 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-битных выходных версий каждой функции. Кроме того, я думаю, что принятие различных входных битовых глубин только в CLI 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, скомпилированными с большой битовой глубиной, и всем, что вам нужно , (Вот почему я назвал это "highdepth", а не просто "10bit" для более короткого имени.)
конец редактирования: ниже приведены мои записи без перекомпиляции. И немного о том, как кросс-компилировать ffmpeg для win64
Попробовал это сам, так как вы не пытались использовать команду cmdline, которая пыталась передать ввод с большой разрядностью в 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 это просто сработало бы. (и потенциально выбирают 444 10 бит, которые вызывает ffmpeg yuva444p10le.) Я думаю, что большая битовая глубина x264 могла бы принять yuv444p14le, но все равно выдаст только 10 бит h.264. Командная строка x264 --fullhelpдовольно явно говорит о глубине выходного бита от 8 до 10, не выше. Странно, что -profile high10просто тихо игнорируется 8-битной x264.
Внутренне x264, скомпилированный для большой битовой глубины, использует 16 бит / с для хранения любых 10-битных данных, поэтому он, вероятно, выполняет поиск движения и так далее с 16-битными значениями. И может DCT выше 16 бит, а не 10 бит, если только скорость игнорируется 6 битами. Это может привести к немного отличающимся коэффициентам DCT, чем если бы вы округлились до 10 бит до DCT. (Таким образом, вы потенциально можете получить другой результат от преобразования до 10 бит до подачи в x264, вместо того, чтобы дать ему 12, 14 или 16 бит.) Я должен попробовать. посмотрите на код или попробуйте, прежде чем что-то придумать. Не верь этому абзацу. :П
(edit: 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: для windows, я не думаю, что есть что-то более удобное, чем LD_LIBRARY_PATHдля libx264 DLL, поэтому лучше всего по-прежнему создавать статический двоичный файл большой глубины, а другой - для обычного использования. Высокая глубина 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 часов, так как он собрал MCCW-кросс-компиляцию GCC из исходного кода вместе со всем остальным. (По умолчанию gcc восстанавливает себя несколько раз до начальной загрузки, если вы изначально компилировали его с плохим компилятором.)
Вы можете обновить скрипт сборки с помощью git pull, и при повторном запуске он получит последние обновления git для ffmpeg, x264, x265 и, возможно, некоторых других проектов, которые он компилирует из исходного кода. (Для большинства это просто загружает tarballs.)
Мой рабочий стол Linux показывает свой возраст. У меня есть виндендо, которое я в основном использую для игр. Так как я начал возиться с кодированием видео, я считаю, что его четырехъядерный Sandybridge тоже очень полезен, особенно. для x265. Вероятно, некоторые функции x265 имеют только версии asm для AVX / SSE4, поэтому на моей машине с SSSE3 Linux (Conroe) она возвращается к C. Это или это более заметно на 1fps ...