chỉnh sửa: Tôi đã thực hiện thành công mã hóa 10 bit của Ducks Take Off .
Cách thứ nhất: Tôi đã xây dựng một nhị phân 10 bit x264 liên kết tĩnh 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
(cực nhanh và chất lượng thấp vì đó là bằng chứng về khái niệm, không phải kiểm tra chất lượng.) Tôi đã không biên dịch nó với swscale. (Thật không hài lòng về một fmt RGB RGB trong libavutil hoặc một cái gì đó). Nó báo lỗi nếu không gian màu đầu vào không khớp --output-csp i444, điều này thực sự tốt nếu bạn không muốn vô tình có x264 lấy mẫu màu. Nó hoạt động tốt khi tôi cho nó ăn một vài khung hình yuv444p14le.y4m, tạo ra đầu ra 10 bit. (Nó có thể cắt bớt độ sâu bit, nhưng không làm giảm sắc độ mà không có swscale.)
Cách thứ hai: sử dụng LD_LIBRARY_PATHđể chọn libx264.so 10 bit
Bạn có thể sử dụng cùng một nhị phân liên kết động ffmpeg cho mọi thứ.
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.)
Tôi rõ ràng đã không cố gắng nhìn thấy bất cứ điều gì trực quan với các cài đặt chất lượng đó. Tôi chỉ muốn nó chạy nhanh, và không lãng phí một loạt dung lượng đĩa vì tôi luôn luôn tạo ra nhiều tệp đầu ra khi thử các biến thể trên mọi thứ.
Việc không chuyển dữ liệu y4m khổng lồ sang một quy trình x264 riêng biệt khiến nó đạt tốc độ 14 khung hình / giây thay vì 12, vì vậy tốc độ cực nhanh cho tốc độ cực nhanh. Mã hóa chậm hơn sẽ lùn mà trên đầu.
Nguồn của tôi là 48 bit RGB. Tôi thấy rằng precision_rnd không ảnh hưởng đến mkv đầu ra. (kết quả chút giống hệt với không -sws_flags, với -sws_flags +accurate_rnd, và -vf scale=flags=accurate_rnd, ngoại trừ một vài bit trong tiêu đề mkv, có lẽ là mkv UUID ngẫu nhiên. Thậm chí với -qp 0, vì vậy tôi đã không mất nó làm tròn lỗi. cmp -l f1 f2 | lessđể so sánh tập tin nhị phân đó có thể là giống nhau sau một số khác biệt ban đầu. Hoặc ssdeep -p. Có lẽ accurate_rndbây giờ là mặc định?)
Có một cờ swscaler ffmpeg có vấn đề, nếu bạn để ffmpeg giảm mẫu màu của bạn: lanczos thay vì bicubic mặc định. (Tôi cho rằng lanczos vẫn được coi là lựa chọn tốt nhất cho chất lượng cao? Không đọc được một lúc.)
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
Thêm +lanczosvào -sws_flagskhông hoạt động:
[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!
Nếu bạn cố gắng cung cấp dữ liệu đầu vào sâu hơn 10 bit, ffmpeg sẽ từ chối.
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
Trên thực tế, trình điều khiển libx264 của ffmpeg luôn khăng khăng cho ăn x264 chính xác độ sâu bit được biên dịch. ví dụ với -pix_fmt yuv420p:
Incompatible pixel format 'yuv420p' for codec 'libx264', auto-selecting format 'yuv420p10le'
x264.h nói:
/* 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;
Tôi nghĩ rằng bên trong x264 (CLI) luôn phải chuyển đổi các định dạng pixel, mã không có đầu vào 8 bit, phiên bản đầu ra 10 bit cho mọi chức năng. Ngoài ra, tôi nghĩ rằng việc chấp nhận các độ sâu bit đầu vào khác nhau chỉ nằm trong x264 CLI, không phải API thư viện. Tôi tò mò chuyện gì sẽ xảy ra khi bạn cung cấp đầu vào API khi có các bit cao hơn được đặt ... (ffpeg không cho phép bạn làm điều này mà không hack mã, vì vậy đây không phải là điều ai cũng cần lo lắng về việc tránh.)
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
Không có pix_fmt được chỉ định, ffmpeg chọn yuv444p10lekhi đưa vào đầu vào rgb. Hoặc với libx264rgb, nó cung cấp rgb 8 bit cho các chức năng đang mong đợi 16 bit (10 trong số đó là đáng kể) và segfaults>. <. Tôi sẽ báo cáo rằng thượng nguồn ...
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)
Tôi sẽ báo cáo rằng ngược dòng.
Dù sao, hóa ra thật dễ dàng để xây dựng cho mình một môi trường có độ sâu hai bit cho ffmpeg hoặc bất kỳ chương trình nào khác mà bạn muốn chạy với các phiên bản libx264, libx265 được biên dịch sâu và bất cứ thứ gì khác bạn muốn . (Đó là lý do tại sao tôi gọi nó là "highdepth", không chỉ là "10 bit" cho một tên ngắn hơn.)
kết thúc chỉnh sửa: bên dưới đây là những lùm xùm của tôi mà không cần biên dịch lại. Và một chút về cách biên dịch chéo ffmpeg cho win64
Bản thân tôi đã thử điều này, vì bạn đã không thử với một cmdline đã cố gắng cung cấp đầu vào độ sâu bit cao cho x264.
Tên định dạng pixel ffmpeg ( ffmpeg -pix_fmts) không chỉ định một sắp xếp, chúng ánh xạ tới một sắp xếp bit chính xác và do đó, mỗi định dạng + kết hợp độ sâu bit có một tên khác nhau. Tôi nghĩ rằng bạn đang mong đợi -pix_fmt yuv422pcó nghĩa là "chuyển đổi thành 422 với độ sâu bit tương tự như đầu vào của tôi".
wikipedia cho biết h.264 chỉ hỗ trợ độ sâu 8-14 bit với Hi444PP, những người khác chỉ tối đa 10 bit. Hi444PP là hồ sơ duy nhất hỗ trợ mã hóa lossless dự đoán, mà x264 sử dụng cho -qp 0hoặc -crf 0. chỉnh sửa: AFAICT, x264 vẫn chỉ hỗ trợ được biên dịch cho 8, 9 hoặc 10 bit.
Dù sao, đây là một loạt các đầu ra vô dụng từ một lệnh không hoạt động vì tôi đã không biên dịch lại x264 cục bộ của mình. (Nhưng nó sẽ hoạt động với x264 được biên dịch lại. Tôi có thể chỉnh sửa câu trả lời này nếu tôi muốn tự chơi với nó.)
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)
Lưu ý các Incompatible pixel format 'yuv420p10le' for codec 'libx264', auto-selecting format 'yuv420p'dòng.
Có lẽ tôi không cần -profile, và với x264 độ sâu cao, nó sẽ hoạt động. (và có khả năng chọn 444 10 bit , mà ffmpeg gọi yuva444p10le.) Tôi nghĩ rằng độ sâu bit cao x264 có thể chấp nhận yuv444p14le, nhưng vẫn chỉ tạo ra 10 bit h.264. Cmdline x264 --fullhelpkhá rõ ràng về độ sâu bit đầu ra từ 8 đến 10, không cao hơn. Thật kỳ lạ khi -profile high10chỉ âm thầm bỏ qua 8bit x264.
Trong nội bộ, x264 được biên dịch cho độ sâu bit cao sử dụng 16bpp để lưu trữ bất kỳ dữ liệu 10 bit nào, do đó, nó có thể thực hiện tìm kiếm chuyển động và cứ thế với các giá trị 16 bit. Và DCT có thể cao hơn 16 bit thay vì 10 bit, trừ khi có tốc độ đạt được từ việc bỏ qua 6 bit. Điều này có thể tạo ra các hệ số DCT hơi khác so với khi bạn làm tròn xuống 10 bit trước DCT. (Vì vậy, bạn có khả năng nhận được đầu ra khác nhau từ chuyển đổi xuống 10 bit trước khi cung cấp cho x264, so với cung cấp 12, 14 hoặc 16 bit.) Tôi nên thăm dò. nhìn vào mã hoặc thử nó trước khi làm cho mọi thứ lên, mặc dù. Đừng tin vào đoạn này. : P
(chỉnh sửa: ffmpeg sẽ không cung cấp x264-10bit bất cứ thứ gì nhiều hơn 10 bit cho mỗi thành phần. Nó sẽ sử dụng swscale để giảm độ sâu bit.)
Tôi tự hỏi sẽ khó đến mức nào khi vá x264 và x265 để sử dụng các tên khác nhau cho các biến toàn cục và hàm API, khi được biên dịch cho độ sâu bit cao. Sau đó, bạn có thể xây dựng cả hai phiên bản cùng một lúc và có ffmpeg được liên kết với cả hai phiên bản. Các ffmpeg libx264và libx264rgbtrình bao bọc có thể đảm nhiệm việc gọi phiên bản api thích hợp tùy thuộc vào luồng đầu vào. (Nếu không, bạn cần -c:v libx264-deephoặc libx264rgb-deep, với tổng số 4 "codec" x264 khác nhau trong ffmpeg.)
Làm thế nào để biên dịch chéo ffmpeg cho windows
chỉnh sửa: Đối với các cửa sổ, tôi không nghĩ có gì thuận tiện như LD_LIBRARY_PATHđối với DLL libx264, vì vậy, cách tốt nhất của bạn vẫn là xây dựng một nhị phân tĩnh có độ sâu bit cao và một cái khác để sử dụng bình thường. Libx264 độ sâu cao KHÔNG thể xuất độ sâu bình thường h.264. Không chỉ là một hình phạt tốc độ, nó chỉ không thể.
Cách dễ nhất để biên dịch ffmpeg (nhị phân tĩnh) của riêng bạn cho windows là với https://github.com/rdp/ffmpeg-windows-build-helpers . git sao chép repo trên máy Linux (hoặc có thể là một hệ thống khác có gcc hoạt động, như OS X?), sau đó chạy
./cross_compile_ffmpeg.sh --high-bitdepth=y --disable-nonfree=n --build-choice=win64
Điều này mất khoảng 8 giờ cho lần chạy đầu tiên, vì nó đã xây dựng GCC biên dịch chéo từ nguồn, cùng với mọi thứ khác. (gcc mặc định tự xây dựng lại nhiều lần để bootstrap, trong trường hợp ban đầu bạn biên dịch nó với một trình biên dịch xấu.)
Bạn có thể cập nhật tập lệnh xây dựng git pullvà chạy lại, nó sẽ lấy các bản cập nhật git mới nhất cho ffmpeg, x264, x265 và có thể một số dự án khác mà nó biên dịch từ nguồn. (Đối với hầu hết nó chỉ tải tarball.)
Máy tính để bàn Linux của tôi đang hiển thị tuổi của nó. Tôi có một wintendo tôi chủ yếu sử dụng cho các trò chơi. Kể từ khi tôi bắt đầu loay hoay với mã hóa video, tôi thấy Sandybridge lõi tứ của nó cũng khá hữu ích cho điều đó, đặc biệt. cho x265. Có lẽ một số chức năng của x265 chỉ có phiên bản asm cho AVX / SSE4, do đó, nó quay trở lại C trên máy SSSE3 Linux của tôi (Conroe). Điều đó hoặc đáng chú ý hơn ở 1fps ...