редагувати: Я успішно зробив 10-бітовий кодекс злітати качок .
Перший спосіб: я створив 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
(надшвидка і низька якість, тому що це доказ концепції, а не тест якості.) Я не склав її з високою шкалою. (Це було нещасно з приводу того, що RGB pix fmt в libavutil чи щось таке). Він помиляється, якщо вхідний --output-csp i444кольоровий простір не збігається , що насправді приємно, якщо ви не хочете випадково х264 зменшити зразок кольоровості. Це добре спрацювало, коли я подав йому кілька кадрів yuv444p14le.y4m, даючи 10-бітний вихід. (Він може скоротити трохи глибини, але не зменшити кольорову прикладність без високої шкали.)
Другий спосіб: 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. Я виявив, що Accu_rnd не впливає на вихідний MKV. (бітові ідентичні результати без -sws_flags, з -sws_flags +accurate_rnd, -vf scale=flags=accurate_rndза винятком декількох біт у заголовку mkv, ймовірно, рандомізований mkv UUID. Навіть при -qp 0цьому я не втрачав його до помилки округлення. cmp -l f1 f2 | lessПорівняти бінарні файли, які можуть бути те саме після деякої початкової різниці. Або, ssdeep -pможливо, accurate_rndзараз за замовчуванням?)
Є один прапор ffmpeg swscaler, який має значення, якщо ви дозволяєте ffmpeg зменшити зразок своєї кольоровості: 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
Власне, драйвер fbmpeg 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-бітові вихідні версії кожної функції. Крім того, я думаю, що прийняття різних глибин вхідних бітів відбувається саме в x264 CLI, а не в 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, він подає 8bit rgb до функцій, які очікують 16bit (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. Cmdline x264 --fullhelpдосить явний щодо глибини вихідного біту від 8 до 10, не вище. Дивно, що -profile high108bit x264 просто мовчки ігнорується.
Внутрішньо x264, компільований для великої глибини бітів, використовує 16bpp для зберігання будь-яких 10-бітових даних, тому, ймовірно, здійснює пошук руху та інше з 16-бітовими значеннями. І може бути DCT вище 16 біт, а не 10 біт, якщо не буде швидкості, якщо ігнорувати 6 біт. Це може призвести до дещо інших коефіцієнтів DCT, ніж якщо ви округлили до 10 біт до DCT. (Таким чином, ви потенційно отримуєте інший вихід від перетворення вниз на 10 біт до подачі на x264, порівняно з наданням йому 12, 14 або 16 біт.) Я повинен задати питання. погляньте на код або спробуйте його, перш ніж складати речі. Не довіряйте цьому абзацу. : P
(редагувати: ffmpeg не подаватиме x264-10bit нічого більше 10 біт на компонент. Він буде використовувати Swscale для зменшення глибини біта.)
Цікаво, як важко було б виправити x264 та x265, щоб використовувати різні імена для глобальних змінних та функцій API, коли компілювались на високу глибину. Тоді ви можете створити обидві версії одразу та з'єднати ffmpeg проти обох. Ffmpeg libx264та libx264rgbобгортки можуть подбати про виклик відповідної версії api залежно від вхідного потоку. (Інакше вам знадобиться -c:v libx264-deepабо libx264rgb-deep, у цілому, для різних 4 x264 "кодеків" у ffmpeg.)
Як перехрестити компілювати ffmpeg для Windows
редагувати: Для Windows, я не думаю, що є щось таке зручне, як 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-cross-компіляцію GCC з джерела разом із усім іншим. (gcc за замовчуванням відновлює себе кілька разів для завантаження, якщо ви спочатку компілювали його з поганим компілятором.)
Ви можете оновити скрипт збірки git pull, і при повторному запуску він витягне останні оновлення git для ffmpeg, x264, x265 та, можливо, деяких інших проектів, які він компілює з джерела. (Для більшості він просто завантажує тарболи.)
Мій робочий стіл Linux показує свій вік. У мене є wintendo, який я в основному використовую для ігор. З того моменту, як я почав псуватися з кодуванням відео, я вважаю його чотириядерний Sandybridge досить корисним і для цього. для x265. Напевно, деякі з функцій x265 мають лише версії ASM для AVX / SSE4, тому вона повертається до C на моїй машині Linux SSSE3 (Conroe). Це чи помітніше в 1 кадрі в секунду ...