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 podporuje 8bitové i 10bitové výstupy a nemusíte dělat nic zvláštního.

ffmpeg

Pokud používáte ffmpeg, uvidíte, jaké formáty pixelů a bitové hloubky podporuje libx264:

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

Formáty 10bitových pixelů jsou: yuv420p10le, yuv422p10le, yuv444p10le.

x264

Můžete také zkontrolovat x264 pro podporované bitové hloubky:

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

Dříve jste museli kompilovat x264 s --bit-depth=10 a poté propojte svůj ffmpeg s 8bitovým nebo 10bitovým libx264, ale to je nyní zbytečné. Viz Unify 8-bit and 10-bit CLI and libraries for more info.

Komentáře

• Sakra, to dělá věci kom komplikovaný. Takže ‚ budu potřebovat dva binární soubory ffmpeg propojené se dvěma knihovnami x264. Víte, jestli existují statické verze 10bit x264 kdekoli?
• Zde je najdete: download.videolan.org/pub/x264/binaries Pokud si ho chcete postavit sami, je zde nesmírně dlouhý proces, který vyžaduje instalaci mingw, yasm, git a gcc a spoustu potíží zde: doom10.org/ index.php? topic = 26.0 Ale nemohl jsem ‚ jej dostat do práce, hlavně kvůli hloupému firemnímu firewallu, který vyhrál ‚ t allow git.
• Možná můžete získat Zeranoe , aby takové sestavení poskytlo. Je nám líto, ale ‚ jsem docela zbytečný, pokud jde o Windows.
• Stejně tak jsem, že ‚ problém. ‚ jsem zveřejnil žádost o sestavení, ‚ uvidíme, jak to půjde.
• FWIW dnes je libx264 “ oba “ Věřím …

edit: Úspěšně jsem vytvořil 10bitové kódování Kachny vzlétnout .

První způsob: Postavil jsem 10bitový binární soubor x264, který staticky propojuje 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 

(ultrarychlý a nízký, protože je to důkaz koncepce, nikoli test kvality.) I nezkompiloval jsem to pomocí swscale. (Bylo to nešťastné ohledně RGB pix fmt v libavutilu nebo tak něco). Chybuje, pokud vstupní barevný prostor neodpovídá --output-csp i444, což je ve skutečnosti hezké, pokud nechcete, aby náhodně x264 převzorkoval chroma. Fungovalo to dobře, když jsem to nakrmil několika snímky yuv444p14le.y4m, které produkovaly 10bitový výstup. (Může zkrátit bitovou hloubku, ale ne převzorkovat chroma bez swscale.)

Druhý způsob: pomocí LD_LIBRARY_PATH vyberte 10bitové libx264.so

Pro vše můžete použít stejný dynamický binární soubor 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.) 

Při těchto nastaveních kvality jsem se očividně nepokusil vidět nic vizuálně. Chtěl jsem jen, aby běžel rychle a neztrácel spoustu místa na disku protože při pokusech o různé varianty věcí vždy skončím s vytvářením spousty výstupních souborů.

Nepřipojování obrovských dat y4m k samostatnému procesu x264 způsobovalo, že namísto 12 šlo o 14 fps, takže na ultrarychlé slušné zrychlení. Pomalejší kódování tuto režii převyšuje.

Můj zdroj je 48bitový RGB. Zjistil jsem, že přesný_rnd neměl žádný vliv na výstupní mkv. (Bitově shodné výsledky bez -sws_flags, s -sws_flags +accurate_rnd a -vf scale=flags=accurate_rnd, s výjimkou několika bitů v záhlaví mkv, pravděpodobně randomizovaného mkv UUID. I s -qp 0, takže jsem to neztratil kvůli chybě zaokrouhlování. cmp -l f1 f2 | less porovnat binární soubory, které by po určitém počátečním rozdílu mohly být stejné.Nebo ssdeep -p. Možná accurate_rnd je nyní výchozí?)

Existuje jeden příznak ffmpeg swscaler, na kterém záleží, pokud necháte ffmpeg převzorkovat vaši chroma: lanczos místo výchozího bikubický. (Předpokládám, že lanczos je stále považován za nejlepší volbu pro vysokou kvalitu? Na chvíli se nepřečte.)

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

Přidání +lanczos do -sws_flags nefunguje:

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

Pokud se pokusíte přenést vstup hlubší než 10 bitů, ffmpeg to odmítne.

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 

Ovladač libx264 ffmpeg ve skutečnosti vždy trvá na tom, aby byl x264 napájen přesně bitovou hloubku, pro kterou je kompilován. např. s -pix_fmt yuv420p:

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

x264.h říká:

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

Myslím, že interně x264 (CLI) musí vždy převádět pixelové formáty, kód nemá 8bitový vstup, 10bitový výstupní formát každé funkce . A také si myslím , že přijímání různých vstupních bitových hloubek je pouze v rozhraní CLI x264, nikoli v rozhraní API knihovny. Jsem zvědavý, co se stane, když přivádíte vstup API tam, kde jsou nastaveny vyšší bity … (ffpeg vám to neumožňuje bez hacknutí kódu, takže se toho nemusí někdo obávat, aby se tomu vyhnul.)

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 

Když není zadán pix_fmt, volí ffmpeg yuv444p10le při zadávání vstupu rgb. Nebo s libx264rgb, napájí 8bitový rgb funkcím, které očekávají 16bitový (z toho 10 významných), a segfaults>. <. Ohlásím to proti proudu …

 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) 

Budu to hlásit proti proudu.

Každopádně se ukázalo, že bylo celkem snadné postavit se prostředí dvoubitové hloubky pro ffmpeg nebo jakýkoli jiný program, který chcete spustit, s kompilovanými verzemi libx264, libx265 a čehokoli jiného, co chcete. (Proto jsem jej nazval „vysokou hloubkou“, ne jen „10bit“ pro kratší název.)

konec úpravy: níže jsou moje ramblings bez překompilování. A dobrá informace o tom, jak křížově kompilovat ffmpeg pro win64

Zkoušel jsem to sám, protože jste se nepokusili použít cmdline, který se pokusil přenést vstup vysoké bitové hloubky na x264.

názvy formátů pixelů ffmpeg (ffmpeg -pix_fmts) pouze neurčují uspořádání, mapují se na přesné uspořádání bitů, a proto má každé kombinované pole formát + bitová hloubka jiný název. Myslím, že jste očekávali, že -pix_fmt yuv422p bude znamenat „převést na 422 ve stejné bitové hloubce jako můj vstup“.

wikipedia říká, že h.264 podporuje 8-14 bitovou hloubku pouze s Hi444PP, jiné jsou pouze do 10 bitů. Hi444PP je jediný profil, který podporuje prediktivní bezztrátové kódování, které x264 používá pro -qp 0 nebo -crf 0. edit: AFAICT, x264 stále podporuje pouze kompilaci pro 8, 9 nebo 10 bitů.

Každopádně, tady je spousta zbytečného výstupu z příkazu, který nefunguje, protože jsem svůj lokální server znovu nezkompiloval x264. (Ale mělo by to fungovat s překompilovaným x264. Tuto odpověď bych mohl upravit, pokud si s ní budu chtít hrát sám.)

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) 

Všimněte si řádku Incompatible pixel format "yuv420p10le" for codec "libx264", auto-selecting format "yuv420p".

Pravděpodobně jsem a s x264 s vysokou bitovou hloubkou by to prostě fungovalo. (a potenciálně vybrat 444 10 bitů, které ffmpeg volá yuva444p10le.) vysoká bitová hloubka x264 by mohla přijmout yuv444p14le, ale stále by produkoval pouze 10bit h.264. Cmdline x264 --fullhelp je docela explicitní ohledně výstupní bitové hloubky od 8 do 10, ne vyšší. Je divné, že -profile high10 je 8bit x264 jen tiše ignorován.

Interně x264 kompilovaný pro vysokou bitovou hloubku používá 16bpp pro ukládání jakýchkoli 10bitových dat, takže pravděpodobně dělá pohyb hledat a tak dále s 16bitovými hodnotami. A může být DCT vyšší 16 bitů než 10 bitů, pokud není možné získat rychlost ignorováním 6 bitů. To by mohlo produkovat mírně odlišné DCT koeficienty, než kdybyste zaokrouhlili dolů na 10 bitů před DCT. (Takže potenciálně získáte jiný výstup od převodu dolů na 10 bitů před odesláním na x264, oproti tomu, že mu dáte 12, 14 nebo 16 bitů.) Měl bych se prob. Podívat na kód nebo to zkusit před tím, než něco vymyslíte. Nedůvěřujte tomuto odstavci. : P

(edit: ffmpeg nebude napájet x264-10bit nic více než 10 bitů na komponentu. K zmenšení bitové hloubky použije swscale.)

Zajímalo by mě, jak těžké bylo by to opravit x264 a x265, aby se při kompilaci pro vysokou bitovou hloubku používaly různé názvy globálních proměnných a funkcí API. Pak byste mohli sestavit obě verze najednou a mít proti nim ffmpeg propojené. ffmpeg libx264 a libx264rgb by se mohly postarat o volání příslušné verze rozhraní API v závislosti na vstupním proudu.(Jinak potřebujete -c:v libx264-deep nebo libx264rgb-deep, celkem 4 různé x264 „kodeky“ ve ffmpeg.)

Jak překládat kompilaci ffmpeg pro Windows

upravit: U Windows si nemyslím, že je něco tak pohodlného jako LD_LIBRARY_PATH pro knihovnu libx264 , takže vaším nejlepším řešením je stále vybudovat statický binární soubor s vysokou bitovou hloubkou a další pro normální použití. Libx264 CAN „T s vysokou hloubkou může vůbec generovat normální hloubku h.264. Nejde jen o rychlostní trest, prostě to může „t.

Nejjednodušší způsob, jak sestavit vlastní ffmpeg (statický binární soubor) pro Windows, je https://github.com/rdp/ffmpeg-windows-build-helpers . git naklonujte repo na stroji s Linuxem (nebo možná v jiném systému s fungujícím gcc, jako je OS X?), poté spusťte

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

První spuštění trvalo přibližně 8 hodin, protože vytvořilo mingw-cross-compile GCC ze zdroje spolu se vším ostatním. (gcc je výchozí, aby se několikrát přestavovalo krát na bootstrap, pokud jste jej původně kompilovali se špatným kompilátorem.)

Skript sestavení můžete aktualizovat pomocí git pull a znovu jej spustit vytáhněte nejnovější aktualizace git pro ffmpeg, x264, x265 a možná i některé další projekty, které kompiluje ze zdroje. (Pro většinu stáhne pouze tarballs.)

Moje linuxová plocha ukazuje svůj věk. Mám Wintendo, které většinou používám pro hry. Od té doby, co jsem začal hrát s kódováním videa, najdu jeho čtyřjádrový Sandybrid i to je docela užitečné, zvláště pro x265. Pravděpodobně některé z funkcí x265 mají pouze asm verze pro AVX / SSE4, takže na mém stroji s Linuxem SSSE3 (Conroe) klesá zpět na C. To nebo ono je to patrnější při rychlosti 1 s / s …

Komentáře

• Upozorňuje stackexchange lidi, když provedu úpravy? Zveřejnění komentáře pro případ, že by doesn ‚ t.
• to je v OS X, kde se používá dynamické propojení, mnohem jednodušší. Jednoduše brew reinstall x264 --with-10-bit a jste hotovi, ffmpeg použije novou příchuť x264 🙂
• @SargeBorsch: cílem této odpovědi bylo mít obě příchutě nainstalované SOUČASNĚ, takže můžete porovnávat 8bitové a 10bitové bez opětovné instalace knihovna. Dynamické propojení OS X funguje téměř stejně jako Linux ‚ s, kde můžete svou instalaci libx264 podobně nahradit jinou příchutí, pokud chcete.
• @PeterCordes hmm, my bad. Máte pravdu

Stáhl jsem ffmpeg z odkazu https://sourceforge.net/projects/ffmpeg-hi/?source=typ_redirect

A zadáním následujícího příkazu vytvoříte 4: 2: 2 1 0bit h.264 soubor:

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