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 stöder både 8-bitars och 10-bitars utgångar, och du behöver inte göra något speciellt.

ffmpeg

Om du använder ffmpeg kan du se vilka pixelformat och bitdjup som stöds av libx264:

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

10-bitars pixelformat är: yuv420p10le, yuv422p10le, yuv444p10le.

x264

Du kan också markera x264 för bitdjup som stöds:

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

Tidigare var du tvungen att kompilera x264 med --bit-depth=10 och länka sedan din ffmpeg till antingen en 8-bitars eller 10-bitars libx264, men det är nu onödigt. Se Förena 8-bitars och 10-bitars CLI och bibliotek för mer information.

Kommentarer

• Fan, det får saker att fungera plicerad. Så jag ’ jag behöver två ffmpeg-binärer kopplade till de två x264-biblioteken. Vet du om det finns statiska byggnader av 10bit x264 någonstans?
• Hitta dem här kommer du att: download.videolan.org/pub/x264/binaries Om du vill bygga det själv finns det en enorm långvarig process som installerar mingw, yasm, git och gcc och mycket mucking här: doom10.org/ index.php? topic = 26.0 Men jag kunde inte ’ inte få det att fungera, främst på grund av dum företags brandvägg som vann ’ t allow git.
• Kanske kan du få Zeranoe för att tillhandahålla en sådan byggnad. Tyvärr är jag ’ ganska värdelös när det gäller Windows.
• Så är jag, att ’ är problem. Jag ’ har lagt upp en byggförfrågan, vi ’ ser hur det går.
• FWIW idag är libx264 ” båda ” Jag tror …

edit: Jag skapade framgångsrikt en 10-bitars kod av Ducks Take Off .

Första vägen: Jag byggde en 10-bitars x264-binär som statiskt länkar 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 

(ultrasnabb och låg kvalitet eftersom det är ett bevis på konceptet, inte ett kvalitetstest.) Jag kompilerade inte den med stor skala. (Det var olyckligt med en RGB pix fmt i libavutil eller något). Det misslyckas om inmatningsfärgutrymmet inte matchar --output-csp i444, vilket faktiskt är trevligt om du inte av misstag vill ha x264 nedprov av kroman. Det fungerade bra när jag matade in det med några bildrutor med yuv444p14le.y4m, vilket gav 10 bitars utdata. (Det kan avkorta bitdjup, men inte nedprova chroma utan skalan.)

Andra sättet: använd LD_LIBRARY_PATH för att välja en 10-bitars libx264.so

Du kan använda samma ffmpeg dynamiskt länkade binära för allt.

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

Jag försökte självklart inte se något visuellt med dessa kvalitetsinställningar. Jag ville bara att det skulle gå snabbt och inte slösa bort en massa hårddiskutrymme eftersom jag alltid slutar skapa massor av utdatafiler när jag försöker variationer på saker.

Att inte lägga massiva y4m-data till en separat x264-process fick den att gå 14 bilder per sekund istället för 12, så en anständig hastighet för ultrasnabbt. Långsammare koder kommer att dvärga den overheaden.

Min källa är 48bit RGB. Jag fann att exact_rnd inte hade någon effekt på utdata-mkv. (Bit-identiska resultat utan -sws_flags med -sws_flags +accurate_rnd och -vf scale=flags=accurate_rnd, med undantag för några bitar i mkv-rubriken, förmodligen den randomiserade mkv UUID. Även med -qp 0, så jag tappade inte det till avrundningsfel. cmp -l f1 f2 | less för att jämföra binära filer som kan vara desamma efter en initial skillnad.Eller ssdeep -p. Kanske är accurate_rnd standard nu?)

Det finns en ffmpeg swscaler-flagga som betyder något, om du låter ffmpeg nedprova din chroma: lanszos istället för standard bicubic. (Jag antar att lanszos fortfarande anses vara det bästa valet för hög kvalitet? Har inte läst upp en stund.)

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

Att lägga till +lanczos till -sws_flags fungerar inte:

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

Om du försöker mata inmatningen djupare än 10 bitar, vägrar 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 

Faktiskt insisterar ffmpegs libx264-drivrutin alltid på att mata x264 exakt bitdjupet det kompileras för. t.ex. med -pix_fmt yuv420p:

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

x264.h säger:

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

Jag tror att internt x264 (CLI) alltid måste uppkonvertera pixelformat, koden har inte 8bit-ingång, 10bit-versioner av varje funktion . Och jag tror att acceptera olika ingångsbitdjup är bara i x264 CLI, inte bibliotekets API. Jag är nyfiken på vad som händer när du matar API-ingången där det finns högre bitar … (ffpeg tillåter dig inte att göra detta utan att hacka koden, så det här är inte något någon behöver oroa sig för att undvika.)

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 

Med ingen pix_fmt specificerad väljer ffmpeg yuv444p10le när den får rgb-ingång. Eller med libx264rgb, den matar 8bit rgb till funktioner som förväntar sig 16bit (varav 10 är signifikanta) och segfel>. <. Jag rapporterar det uppströms …

 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) 

Jag kommer att rapportera det uppströms.

Hur som helst, det visar sig att det var ganska lätt att bygga mig en dual-bit-depth-miljö för ffmpeg eller något annat program som du vill köra med hög-bit-djup-kompilerade versioner av libx264, libx265 och allt annat du vill. (Det är därför jag kallade det ”highdepth”, inte bara ”10bit” för ett kortare namn.)

slutet av redigeringen: nedan här är min vandring utan att kompilera om. Och en hel del om hur man korskompilerar ffmpeg för win64

Testade detta själv, eftersom du inte försökte med en cmdline som försökte mata in hög bitdjup till x264.

ffmpeg pixelformatnamn (ffmpeg -pix_fmts) anger inte bara ett arrangemang, de mappar till ett exakt bitarrangemang och därmed har varje format + bitdjupskombination ett annat namn. Jag tror att du förväntade dig att -pix_fmt yuv422p skulle betyda ”konvertera till 422 i samma bitdjup som min inmatning”.

wikipedia säger att h.264 stöder 8-14 bitars djup endast med Hi444PP, andra är bara upp till 10 bitar. Hi444PP är den enda profilen som stöder förutsägbar förlustfri kodning, som x264 använder för -qp 0 eller -crf 0. redigera: AFAICT, x264 stöder fortfarande bara att kompileras för 8, 9 eller 10 bitar.

Hur som helst, här är en massa värdelös utdata från ett kommando som inte fungerar eftersom jag inte kompilerade min lokala x264. (Men det borde fungera med omkompilerad x264. Jag kan redigera det här svaret om jag vill spela med det själv.)

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) 

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

Förmodligen behövde jag inte -profile, och med en x264 med hög bitdjup skulle det bara fungera. (och eventuellt välja 444 10bit, som ffmpeg kallar yuva444p10le.) Jag tror hög bitdjup x264 kan acceptera yuv444p14le, men skulle fortfarande bara producera 10bit h.264. Cmdline x264 --fullhelp är ganska tydlig angående utgående bitdjup från 8 till 10, inte högre. Konstigt att -profile high10 bara ignoreras tyst av 8bit x264.

Internt använder x264 för hög bitdjup 16bpp för att lagra 10 bitars data, så det gör förmodligen rörelse sökning och så vidare med 16-bitars värden. Och kan DCT öka 16 bitar snarare än 10 bitar, såvida det inte går att vinna med att ignorera 6 bitar. Detta kan ge lite annorlunda DCT-koefficienter än om du avrundade ner till 10 bitar före DCT. (Så du får potentiellt olika utdata från att konvertera ner till 10 bitar innan jag matar till x264, mot att ge den 12, 14 eller 16 bitar.) Jag borde noga titta på koden eller prova innan jag gör upp saker. Lita inte på det här stycket. : P

(redigera: ffmpeg matar inte x264-10bit något mer än 10 bitar per komponent. Det kommer att använda swscale för att minska själva bitdjupet.)

Jag undrar hur svårt det skulle vara att korrigera x264 och x265 för att använda olika namn för globala variabler och API-funktioner, när de kompileras för högbitdjup. Då kan du bygga båda versionerna samtidigt och ha ffmpeg länkade mot dem båda. Ffmpeg libx264 och libx264rgb omslag kan ta hand om att anropa lämplig version av api beroende på ingångsströmmen.(Annars behöver du -c:v libx264-deep eller libx264rgb-deep, för totalt 4 olika x264 ”codecs” i ffmpeg.)

Hur man korsar kompilera ffmpeg för windows

edit: För windows tror jag inte att det finns något så bekvämt som LD_LIBRARY_PATH för en libx264 DLL , så din bästa satsning är fortfarande att bygga en statisk binär med hög bitdjup, och en annan för normal användning. Högdjup libx264 KAN ”T inte mata ut normalt djup h.264 alls. Inte bara en hastighetsstraff, det kan bara ”.

Det enklaste sättet att kompilera din egen ffmpeg (statisk binär) för windows är med https://github.com/rdp/ffmpeg-windows-build-helpers . git klona repo på en Linux-maskin (eller kanske ett annat system med en fungerande gcc, som OS X?), kör sedan

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

Detta tog ungefär 8 timmar för första körningen, eftersom det byggde mingw-cross-compile GCC från källan, tillsammans med allt annat. (gcc har som standard att bygga om sig själv flera gånger för att starta upp, om du ursprungligen kompilerade den med en dålig kompilator.)

Du kan uppdatera build-skriptet med git pull och kör det igen dra de senaste gituppdateringarna för ffmpeg, x264, x265 och kanske några av de andra projekten som den sammanställer från källan. (För de flesta laddar det bara ner tarballs.)

Mitt Linux-skrivbord visar sin ålder. Jag har en Nintendo som jag mest använder för spel. Sedan jag började krossa med videokodning hittar jag dess fyrkärniga Sandybrid ge ganska användbart för det också, särskilt för x265. Förmodligen har några av x265 ”s funktioner bara asm-versioner för AVX / SSE4, så det faller tillbaka till C på min SSSE3 Linux-maskin (Conroe). Det eller det är mer märkbart vid 1fps …

Kommentarer

• Meddelar stackexchange människor när jag gör ändringar? Lägg upp en kommentar om det inte ’ t.
• detta är mycket enklare på OS X, där dynamisk länkning används. Helt enkelt brew reinstall x264 --with-10-bit och du är klar, ffmpeg kommer att använda den nya x264-smaken 🙂
• @SargeBorsch: poängen med det här svaret var att ha båda smakerna installerade SAMTIDIGT, så att du kan jämföra 8bit och 10bit utan att installera om OS X dynamisk länkning fungerar ungefär som Linux ’ s, där du på samma sätt kan ersätta din libx264-installation med den andra smaken om du vill.
• @PeterCordes hmm, min dåliga. Du har rätt

Jag laddade ner ffmpeg från länken https://sourceforge.net/projects/ffmpeg-hi/?source=typ_redirect

Och angav kommandot nedan för att skapa 4: 2: 2 1 0bit h.264 fil:

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