แก้ไข: ฉันประสบความสำเร็จทำเข้ารหัส 10bit ของเป็ด 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 pix 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 fps แทน 12 ดังนั้นการเร่งความเร็วที่เหมาะสมสำหรับการทำงานเร็วมาก การเข้ารหัสที่ช้ากว่าจะแคระค่าใช้จ่ายนั้น
แหล่งที่มาของฉันคือ 48 บิต RGB ฉันพบว่า Accurate_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 downsample Chroma ของคุณตัวอย่าง: lanczos แทนที่จะเป็น bicubic เริ่มต้น (ฉันถือว่า 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 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ฟีด 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)
ฉันจะรายงานว่าต้นน้ำ
อย่างไรก็ตามมันกลับกลายเป็นว่ามันค่อนข้างยากที่จะสร้างตัวฉันเองในสภาพแวดล้อมแบบ dual-bit-depth สำหรับ ffmpeg หรือโปรแกรมอื่น ๆ ที่คุณต้องการรันด้วย libx264, libx265 และรุ่นอื่น ๆ ที่คุณต้องการ . (นั่นคือเหตุผลที่ฉันเรียกมันว่า "ความลึก" ไม่ใช่แค่ "10 บิต" สำหรับชื่อที่สั้นกว่า)
สิ้นสุดการแก้ไข: ด้านล่างนี่คือคำชมของฉันโดยไม่ต้องคอมไพล์ใหม่ และเป็นบิตที่ดีเกี่ยวกับวิธีการรวบรวม ffmpeg สำหรับ win64
พยายามทำสิ่งนี้ด้วยตัวเองเนื่องจากคุณไม่ได้ลองใช้ cmdline ที่พยายามป้อนอินพุตความลึกระดับสูงเป็น x264
ชื่อรูปแบบ ffmpeg pixel ( ffmpeg -pix_fmts) ไม่เพียง แต่ระบุการจัดเรียงเท่านั้น แต่จะแมปไปยังการจัดเรียงบิตที่แน่นอนดังนั้นแต่ละรูปแบบ + คำสั่งผสมความลึกบิตจะมีชื่อแตกต่างกัน ฉันคิดว่าคุณคาดหวังว่า-pix_fmt yuv422pจะหมายถึง "แปลงเป็น 422 ในระดับความลึกบิตเดียวกับอินพุตของฉัน"
wikipediaกล่าวว่า h.264 รองรับความลึก 8-14 บิตเฉพาะกับ Hi444PP เท่านั้นส่วนอื่น ๆ นั้นมีขนาดไม่เกิน 10 บิต Hi444PP เป็นรายเดียวที่รองรับการเข้ารหัสแบบ lossless ทำนายซึ่ง 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 บิต และอาจสูงกว่า 16 บิต DCT มากกว่า 10 บิตเว้นแต่ว่าจะได้รับความเร็วจากการละเว้น 6 บิต สิ่งนี้สามารถสร้างสัมประสิทธิ์ DCT ที่แตกต่างกันเล็กน้อยกว่าถ้าคุณปัดลงไปที่ 10 บิตก่อน DCT (ดังนั้นคุณอาจได้รับผลลัพธ์ที่แตกต่างจากการแปลงลงไปที่ 10 บิตก่อนที่จะให้อาหารเป็น x264 เทียบกับให้มัน 12, 14, หรือ 16 บิต) ฉันควรตรวจสอบ ลองดูรหัสหรือลองก่อนที่จะตัดสินใจทำ อย่าเชื่อถือวรรคนี้ : P
(แก้ไข: ffmpeg จะไม่ฟีด x264-10 บิตอะไรมากกว่า 10 บิตต่อองค์ประกอบมันจะใช้ swscale เพื่อลดความลึกของบิตเอง)
ฉันสงสัยว่ามันยากแค่ไหนที่จะแก้ไข x264 และ x265 เพื่อใช้ชื่อต่าง ๆ สำหรับตัวแปรทั่วโลกและฟังก์ชั่น API เมื่อคอมไพล์ด้วยความลึกระดับสูง จากนั้นคุณสามารถสร้างทั้งสองรุ่นพร้อมกันและมี ffmpeg เชื่อมโยงกับทั้งสองรุ่น ffmpeg libx264และlibx264rgbwrappers สามารถดูแลการเรียกเวอร์ชันที่เหมาะสมของ api ขึ้นอยู่กับอินพุตสตรีม (ไม่เช่นนั้นคุณจะต้องใช้-c:v libx264-deepหรือlibx264rgb-deepสำหรับ x264 "codec" ใน ffmpeg ที่ต่างกันทั้งหมด 4 รายการ)
วิธีการคอมไพล์ ffmpeg สำหรับ windows
แก้ไข: สำหรับ windows ฉันไม่คิดว่าจะมีอะไรที่สะดวกสบายLD_LIBRARY_PATHสำหรับ libx264 DLL ดังนั้นทางออกที่ดีที่สุดของคุณก็คือการสร้างไบนารีคงที่ที่มีความลึกสูงและอีกหนึ่งสำหรับการใช้งานปกติ libx264 ความลึกสูงไม่สามารถส่งออกความลึกปกติได้ที่ h.264 เลย ไม่ใช่แค่การลงโทษด้วยความเร็วเท่านั้น แต่ไม่สามารถทำได้
วิธีที่ง่ายที่สุดในการรวบรวม ffmpeg ของคุณเอง (ไบนารีคงที่) สำหรับ Windows อยู่กับhttps://github.com/rdp/ffmpeg-windows-build-helpers git โคลน repo บนเครื่องลีนุกซ์ (หรืออาจเป็นระบบอื่นที่มี gcc ที่ใช้งานได้, เช่น OS X?), จากนั้นเรียกใช้
./cross_compile_ffmpeg.sh --high-bitdepth=y --disable-nonfree=n --build-choice=win64
การดำเนินการนี้ใช้เวลาประมาณ 8 ชั่วโมงในการดำเนินการครั้งแรกเนื่องจากสร้าง GCC mingw-cross-compile จากแหล่งที่มาพร้อมกับสิ่งอื่น ๆ (ค่าเริ่มต้นของ gcc คือการสร้างตัวเองใหม่หลายครั้งเพื่อบู๊ตสแตรปในกรณีที่คุณรวบรวมมันด้วยคอมไพเลอร์ที่ไม่ดี)
คุณสามารถอัปเดตสคริปต์สร้างด้วยgit pullและเรียกใช้อีกครั้งจะดึงการปรับปรุง git ล่าสุดสำหรับ ffmpeg, x264, x265 และอาจจะมีโครงการอื่น ๆ ที่รวบรวมจากแหล่งที่มา (ส่วนใหญ่เป็นเพียงดาวน์โหลด tarballs)
เดสก์ท็อป Linux ของฉันกำลังแสดงอายุ ฉันมี Nintendo ที่ฉันใช้เป็นส่วนใหญ่สำหรับเกม ตั้งแต่ฉันเริ่มยุ่งกับการเข้ารหัสวิดีโอฉันพบว่า Sandybridge แบบ quad-core มันมีประโยชน์มากสำหรับสิ่งนั้นเช่นกัน สำหรับ x265 ฟังก์ชั่นบางอย่างของ x265 อาจมี asm เวอร์ชั่นสำหรับ AVX / SSE4 เท่านั้นดังนั้นมันจึงกลับไปใช้ C บนเครื่อง SSSE3 Linux ของฉัน (Conroe) หรือน่าสนใจกว่าที่ 1fps ...