ffmpeg.exe -i input.mov -c:v libx264 -profile:v high422 -crf 20 -pix_fmt yuv422p output.mp4 

[libx264 @ 00000000055a9de0] profile High 4:2:2, level 4.0, 4:2:2 8-bit 

ffmpeg.exe -i input.mov -c:v libx264 -profile:v high10 -crf 20 -pix_fmt yuv422p output.mp4 

x264 [error]: high10 profile doesn"t support 4:2:2 [libx264 @ 00000000051ead60] Error setting profile high10. [libx264 @ 00000000051ead60] Possible profiles: baseline main high high10 high422 high444 

 --profile <string> Force the limits of an H.264 profile Overrides all settings. [...] - high10: No lossless. Support for bit depth 8-10. - high422: No lossless. Support for bit depth 8-10. Support for 4:2:0/4:2:2 chroma subsampling. - high444: Support for bit depth 8-10. Support for 4:2:0/4:2:2/4:4:4 chroma subsampling. 

x264 acceptă atât ieșiri de 8 biți, cât și ieșiri de 10 biți și nu trebuie să faceți nimic special.

ffmpeg

Dacă utilizați ffmpeg puteți vedea ce formate de pixeli și adâncimi de biți sunt acceptate de libx264:

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

Formatele de pixeli pe 10 biți sunt: yuv420p10le, yuv422p10le, yuv444p10le.

x264

De asemenea, puteți verifica x264 pentru adâncimi de biți acceptate:

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

Anterior trebuia să compilați x264 cu --bit-depth=10, apoi conectați ffmpeg la un libx264 pe 8 biți sau pe 10 biți, dar acum nu este necesar. Consultați Unificați CLI și biblioteci de 8 și 10 biți pentru mai multe informații.

Comentarii

• La naiba, asta face ca lucrurile să fie com plicată. Așadar, ‘ voi avea nevoie de două binarii ffmpeg legate de cele două biblioteci x264. Știți dacă există versiuni statice ale 10bit x264 oriunde?
• Găsiți-le aici, le veți: download.videolan.org/pub/x264/binaries Dacă doriți să o construiți singur, există un proces extrem de lung care invocă instalarea mingw, yasm, git și gcc și o mulțime de prostii aici: doom10.org/ index.php? topic = 26.0 Dar nu am putut ‘ să nu reușesc să funcționeze, în principal din cauza unui firewall corporativ stupid care a câștigat ‘ t permit git.
• Poate puteți obține Zeranoe pentru a furniza o astfel de versiune. Ne pare rău, ‘ sunt destul de inutil când vine vorba de Windows.
• La fel și eu, că ‘ sunt problemă. Am ‘ am postat o cerere de compilare, vom ‘ vom vedea cum merge.
• FWIW zilele acestea este libx264 ” ambele ” cred …

edit: Am realizat cu succes o codificare de 10 biți a Ducks Take Off .

Primul mod: Am construit un binar de 10 biți x264 care leagă static 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 

(calitate ultra rapidă și scăzută, deoarece este o dovadă a conceptului, nu un test de calitate.) nu l-am compilat cu swscale. (A fost nemulțumit de un pix RGB fmt în libavutil sau ceva de genul). Se erorează dacă spațiul de culoare de intrare nu se potrivește cu --output-csp i444, ceea ce este de fapt frumos dacă nu doriți să aveți din greșeală x264 pentru a minimiza croma. A funcționat bine când i-am alimentat câteva cadre de yuv444p14le.y4m, producând ieșire de 10 biți. (Poate trunchia adâncimea de biți, dar nu reduce cromatica fără swscale.)

A doua cale: utilizați LD_LIBRARY_PATH pentru a selecta un 10x libx264.so

Puteți folosi același binar ffmpeg dinamic legat pentru orice.

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.) 

Evident, nu am încercat să văd nimic vizual cu acele setări de calitate. Am vrut doar să ruleze rapid și să nu irosească o grămadă de spațiu pe disc deoarece întotdeauna ajung să creez o mulțime de fișiere de ieșire atunci când încerc variante de lucruri.

Neacordarea masivă a datelor y4m într-un proces separat x264 a făcut să meargă cu 14 fps în loc de 12, deci o accelerare decentă pentru ultra-rapid. Codurile mai lente vor depăși acea cheltuială.

Sursa mea este de 48 de biți RGB. Am constatat că accurate_rnd nu a avut niciun efect asupra ieșirii mkv. (Rezultate identice cu biții fără -sws_flags, cu -sws_flags +accurate_rnd și -vf scale=flags=accurate_rnd, cu excepția câtorva biți din antetul mkv, probabil UUID-ul mkv randomizat. Chiar și cu -qp 0, așa că nu o pierdeam din cauza unei erori de rotunjire. cmp -l f1 f2 | less pentru a compara fișierele binare care ar putea fi aceleași după o diferență inițială.Sau ssdeep -p. Poate că accurate_rnd este implicit acum?)

Există un steag ffmpeg swscaler care contează, dacă „lăsați ffmpeg să-ți reducă probele de chroma: lanczos în loc de implicit bicubic. (Presupun că lanczos este încă considerat cea mai bună alegere pentru calitate înaltă? Nu s-a citit o vreme.)

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

Adăugarea +lanczos la -sws_flags nu funcționează:

[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! 

Dacă încercați să o alimentați cu o adâncime mai mare de 10 biți, ffmpeg refuză.

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 

De fapt, driverul libx264 ffmpeg insistă întotdeauna pe alimentarea x264 exact adâncimea de biți pentru care este „compilată”. De ex. cu -pix_fmt yuv420p:

Incompatible pixel format "yuv420p" for codec "libx264", auto-selecting format "yuv420p10le" 

x264.h spune:

/* 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; 

Cred că intern x264 (CLI) trebuie întotdeauna să convertească formatele de pixeli, codul nu are versiuni de intrare de 8 biți, 10 biți de ieșire pentru fiecare funcție . Și, de asemenea, cred că acceptarea diferitelor adâncimi de biți de intrare este doar în CLI x264, nu în API-ul bibliotecii. Sunt curios ce se întâmplă atunci când alimentați intrarea API în care sunt setați biți mai mari … (ffpeg nu vă permite să faceți acest lucru fără a pirata codul, deci acest lucru nu este ceva pe care oricine trebuie să-și facă griji pentru a-l evita.)

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 

Fără pix_fmt specificat, ffmpeg alege yuv444p10le când i se dă intrare rgb. Sau cu libx264rgb, alimentează 8 biți rgb către funcții care așteaptă 16 biți (dintre care 10 sunt semnificativi) și segfaults>. <. Voi raporta asta în amonte …

 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) 

Voi raporta asta în amonte.

Oricum, se pare că a fost destul de drăguț să-mi construiesc un mediu dual-bit-depth pentru ffmpeg sau orice alt program pe care doriți să-l rulați cu versiuni compilate cu adâncime de bit mare ale libx264, libx265 și orice altceva doriți. (De aceea l-am numit „highdepth”, nu doar „10 biți” pentru un nume mai scurt.)

sfârșitul editării: mai jos sunt prezentările mele fără recompilare. Și un pic bun despre cum să compilezi ffmpeg pentru win64

Am încercat asta, deoarece nu ai încercat cu o linie de cmd care a încercat să alimenteze intrarea de adâncime de biți mare la x264.

Numele formatului de pixeli ffmpeg (ffmpeg -pix_fmts) nu specifică doar un aranjament, se mapează la un aranjament de biți exact și, astfel, fiecare combo format + adâncime de bit are un nume diferit. Cred că vă așteptați ca -pix_fmt yuv422p să însemne „convertiți la 422 în aceeași adâncime de biți ca și intrarea mea”.

wikipedia spune că h.264 acceptă adâncimea de 8-14 biți numai cu Hi444PP, altele au până la 10 biți. Hi444PP este singurul profil care acceptă codificare predictivă fără pierderi, pe care x264 îl folosește pentru -qp 0 sau -crf 0. edit: AFAICT, x264 încă acceptă doar compilarea pentru 8, 9 sau 10 biți.

Oricum, aici „o grămadă de ieșiri inutile dintr-o comandă care nu funcționează deoarece nu am recompilat localul meu x264. (Dar ar trebui să funcționeze cu x264 recompilat. Aș putea edita acest răspuns dacă vreau să mă joc eu însumi.)

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) 

Rețineți linia Incompatible pixel format "yuv420p10le" for codec "libx264", auto-selecting format "yuv420p".

Probabil că nu am nevoie de -profile și cu un adâncime de biți mare x264, ar funcționa. (și pot alege 444 10 biți, pe care ffmpeg îi numește yuva444p10le.) Cred că 6 adâncimea de biți mare x264 ar putea accepta yuv444p14le, dar ar produce totuși doar 10 biți h.264. Cmdline x264 --fullhelp este destul de explicit cu privire la adâncimea de biți de ieșire de la 8 la 10, nu mai mare. Ciudat că -profile high10 este ignorat în mod silențios de 8 biți x264.

Intern, x264 compilat pentru adâncimi mari de biți folosește 16 bpp pentru stocarea oricăror date de 10 biți, deci probabil face mișcare căutare și așa mai departe cu valori de 16 biți. Și s-ar putea ca DCT să fie mai mare de 16 biți decât de 10 biți, cu excepția cazului în care se poate obține viteza din ignorarea a 6 biți. Acest lucru ar putea produce coeficienți DCT ușor diferiți dacă ar fi rotunjit în jos la 10 biți înainte de DCT. 10 biți înainte de a alimenta la x264, față de a-i da 12, 14 sau 16 biți.) Ar trebui să mă uit la cod sau să-l încerc înainte să inventez lucruri. Nu aveți încredere în acest paragraf. : P

(edit: ffmpeg nu va câștiga x264-10 biți cu nimic mai mult de 10 biți per componentă. Se va folosi swscale pentru a reduce adâncimea de biți în sine.)

Mă întreb cât de greu ar fi să patch-uri x264 și x265 pentru a utiliza nume diferite pentru variabilele globale și funcțiile API, atunci când sunt compilate pentru adâncimea de biți mare. Apoi, puteți construi ambele versiuni simultan și aveți ffmpeg legat de ambele. Fmpmp libx264 și libx264rgb împachetările s-ar putea ocupa de apelarea versiunii corespunzătoare a API în funcție de fluxul de intrare.(În caz contrar, ar trebui să aveți -c:v libx264-deep sau libx264rgb-deep, pentru un total de 4 „codecuri” x264 diferite în ffmpeg.)

Cum se poate compila ffmpeg pentru Windows

edit: Pentru Windows, nu cred că există ceva la fel de convenabil ca LD_LIBRARY_PATH pentru un DLL libx264 , deci cel mai bun pariu este totuși să construiești un binar static de înaltă adâncime de biți și un altul pentru utilizare normală. Nu doar o penalizare a vitezei, ci doar poate „t.

Cel mai simplu mod de a compila propriul ffmpeg (binar static) pentru Windows este cu https://github.com/rdp/ffmpeg-windows-build-helpers . git clonează repo pe o mașină Linux (sau poate un alt sistem cu un gcc funcțional, cum ar fi OS X?), apoi rulați

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

Acest lucru a durat aproximativ 8 ore pentru prima rundă, deoarece a creat GCC mingw-cross-compile de la sursă, împreună cu orice altceva. (Gcc implicit se reconstruiește mai multe ori pentru bootstrap, în cazul în care ați fost compilat inițial cu un compilator defect.)

Puteți actualiza scriptul de construire cu git pull și îl veți rula din nou extrageți cele mai recente actualizări git pentru ffmpeg, x264, x265 și poate unele dintre celelalte proiecte pe care le compilează din sursă. (Pentru majoritatea descarcă doar tarball-uri.)

Desktop-ul meu Linux își arată vârsta. Am un joc pe care îl folosesc mai ales pentru jocuri. De când am început să mă joc cu codificarea video, îi găsesc Sandybridul cu patru nuclee sunt destul de utile și pentru asta, în special. pentru x265. Probabil că unele dintre funcțiile x265 au versiuni asm doar pentru AVX / SSE4, deci revine la C pe mașina mea SSSE3 Linux (Conroe). Asta sau „este mai vizibil la 1 fps …

Comentarii

• Stimularea stackexchange îi face oamenilor când fac editări? nu ‘ t.
• acest lucru este mult mai simplu pe OS X, unde este utilizată legarea dinamică. Pur și simplu brew reinstall x264 --with-10-bit și ați terminat, ffmpeg va folosi noua aromă x264 🙂
• @SargeBorsch: scopul acestui răspuns a fost să aveți ambele arome instalate ÎN ACEEAȘI TIMP, astfel încât să puteți compara 8 biți și 10 biți fără a reinstala bibliotecă. Conectarea dinamică OS X funcționează cam la fel ca Linux ‘ s, unde puteți înlocui în mod similar instalarea libx264 cu cealaltă aromă, dacă doriți.
• @PeterCordes hmm, răul meu. Ai dreptate

Am descărcat ffmpeg de pe linkul https://sourceforge.net/projects/ffmpeg-hi/?source=typ_redirect

Și a introdus comanda de mai jos pentru a crea 4: 2: 2 1 0bit h.264 fișier:

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