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 understøtter både 8-bit og 10-bit output, og du behøver ikke gøre noget særligt.

ffmpeg

Hvis du bruger ffmpeg, kan du se, hvilke pixelformater og bitdybder der understøttes af libx264:

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

10-bit pixelformater er: yuv420p10le, yuv422p10le, yuv444p10le.

x264

Du kan også kontrollere x264 for understøttede bitdybder:

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

Tidligere var du nødt til at kompilere x264 med --bit-depth=10, og link derefter din ffmpeg til enten en 8-bit eller 10-bit libx264, men det er nu unødvendigt. Se Foren 8-bit og 10-bit CLI og biblioteker for mere info.

Kommentarer

• Damn, det gør tingene com pliceret. Så jeg ‘ behøver to ffmpeg-binære filer, der er knyttet til de to x264-biblioteker. Ved du, om der er statiske builds af 10bit x264 et vilkårligt sted?
• Find dem her, du vil: download.videolan.org/pub/x264/binaries Hvis du vil bygge det selv, er der en enorm langvarig proces, der installerer mingw, yasm, git og gcc og masser af mucking rundt her: doom10.org/ index.php? topic = 26.0 Men jeg kunne ikke ‘ ikke få det til at fungere, hovedsageligt på grund af dum virksomhedsfirewall, der vandt ‘ t tillad git.
• Måske kan du få Zeranoe til at give en sådan opbygning. Undskyld, jeg ‘ er temmelig ubrugelig, når det kommer til Windows.
• Det er jeg også, at ‘ er det problem. Jeg ‘ har sendt en buildanmodning, vi ‘ vil se, hvordan det går.
• FWIW i disse dage er libx264 ” begge ” Jeg tror …

edit: Jeg lavede en 10bit-kode med Ducks Take Off .

Første vej: Jeg byggede en 10bit x264 binær, der statisk forbinder 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 

(ultrahurtig og lav kvalitet, fordi det er et bevis på konceptet, ikke en kvalitetstest.) Jeg kompilerede det ikke med skala. (Det var utilfreds med en RGB pix fmt i libavutil eller noget). Det fejler, hvis inputfarverummet ikke matcher --output-csp i444, hvilket faktisk er rart, hvis du ikke ved et uheld vil have x264 downsample af chroma. Det fungerede fint, da jeg fodrede det et par rammer yuv444p14le.y4m, hvilket gav 10bit output. (Det kan afkorte bitdybde, men ikke nedprøve chroma uden swscale.)

Anden måde: brug LD_LIBRARY_PATH til at vælge en 10bit libx264.so

Du kan bruge den samme ffmpeg dynamisk linkede binære til alt.

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

Jeg forsøgte naturligvis ikke at se noget visuelt med disse kvalitetsindstillinger. Jeg ville bare have det til at køre hurtigt og ikke spilde en masse diskplads da jeg altid ender med at lave masser af outputfiler, når jeg prøver variationer på ting.

Hvis jeg ikke rør de massive y4m-data til en separat x264-proces, fik det 14 fps i stedet for 12, så en anstændig hastighed til ultrafast. Langsomme koder vil dværge det overhead.

Min kilde er 48bit RGB. Jeg fandt ud af, at accurate_rnd ikke havde nogen effekt på output mkv. (Bit-identiske resultater uden -sws_flags med -sws_flags +accurate_rnd og -vf scale=flags=accurate_rnd bortset fra et par bit i mkv-headeren, sandsynligvis den randomiserede mkv UUID. Selv med -qp 0, så jeg mistede det ikke til afrundingsfejl. cmp -l f1 f2 | less for at sammenligne binære filer, der muligvis er de samme efter en indledende forskel.Eller ssdeep -p. Måske er accurate_rnd standard nu?)

Der er et ffmpeg swscaler-flag, der betyder noget, hvis du lader ffmpeg nedprøve din chroma: lanczos i stedet for standard bicubic. (Jeg antager, at lanczos stadig betragtes som det bedste valg for høj kvalitet? Har du ikke læst et stykke tid.)

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

Tilføjelse af +lanczos til -sws_flags fungerer ikke:

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

Hvis du prøver at fremføre input dybere end 10 bit, nægter 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 

Faktisk insisterer ffmpegs libx264-driver altid på at fodre x264 nøjagtigt bitdybden, den er sammensat til. f.eks. med -pix_fmt yuv420p:

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

x264.h siger:

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

Jeg synes internt x264 (CLI) skal altid konvertere pixelformater, koden har ikke 8bit input, 10bit outputversioner af hver funktion . Og også, jeg tror accept af forskellige inputbitdybder er bare i x264 CLI, ikke biblioteks-APIen. Jeg er nysgerrig efter, hvad der sker, når du fodrer API-input, hvor der er højere bitsæt … (ffpeg tillader dig ikke at gøre dette uden at hacke koden, så dette er ikke noget, nogen har brug for at bekymre sig om at undgå.)

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 

Uden pix_fmt er angivet, vælger ffmpeg yuv444p10le, når den får rgb-input. Eller med libx264rgb, den føder 8bit rgb til funktioner, der forventer 16bit (hvoraf 10 er signifikante), og segfaults>. <. Jeg rapporterer det opstrø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) 

Jeg rapporterer det opstrøms.

I hvert fald viser det sig, at det var ret darn let at bygge mig en dual-bit dybdemiljø til ffmpeg eller ethvert andet program, du vil køre med høj-bit dybdekompilerede versioner af libx264, libx265 og alt andet, du ønsker. (Derfor kaldte jeg det “highdepth”, ikke bare “10bit” for et kortere navn.)

afslutning på redigering: nedenfor her er mine spøgelser uden at kompilere igen. Og en god smule om, hvordan man krydskompilerer ffmpeg til win64

Forsøgte dette selv, da du ikke prøvede med en cmdline, der forsøgte at føde høj bitdybdeindgang til x264.

ffmpeg pixelformatnavne (ffmpeg -pix_fmts) angiver ikke bare et arrangement, de kortlægges til et nøjagtigt bitarrangement, og dermed har hvert format + bitdybdekombination et andet navn. Jeg tror, du forventede -pix_fmt yuv422p at betyde “konvertere til 422 i samme bitdybde som mit input”.

wikipedia siger, at h.264 kun understøtter 8-14 bit dybde med Hi444PP, andre er kun op til 10 bit. Hi444PP er den eneste profil, der understøtter forudsigelig tabsfri kodning, som x264 bruger til -qp 0 eller -crf 0. rediger: AFAICT, x264 understøtter stadig kun kompilering til 8, 9 eller 10bits.

Alligevel er her en masse ubrugelig output fra en kommando, der ikke fungerer, fordi jeg ikke kompilerede min lokale x264. (Men det skal fungere med genkompileret x264. Jeg kan redigere dette svar, hvis jeg selv vil lege med det.)

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) 

Bemærk Incompatible pixel format "yuv420p10le" for codec "libx264", auto-selecting format "yuv420p" linjen.

Sandsynligvis havde jeg ikke brug for -profile, og med en x264 med høj bitdybde ville det bare fungere. (og vælg muligvis 444 10bit, som ffmpeg kalder yuva444p10le.) Jeg tror høj bitdybde x264 kunne acceptere yuv444p14le, men ville stadig kun producere 10bit h.264. Cmdline x264 --fullhelp er ret eksplicit med hensyn til outputbitdybde fra 8 til 10, ikke højere. Underligt, at -profile high10 bare ignoreres lydløst af 8bit x264.

Internt bruger x264 til høj bitdybde 16bpp til lagring af 10bit-data, så det bevæger sig sandsynligvis søgning og så videre med 16bit-værdier. Og måske DCT højere 16bit snarere end 10bit, medmindre der opnås hastighed ved at ignorere 6 bits. Dette kan producere lidt forskellige DCT-koefficienter, end hvis du afrundede til 10bit før DCT. (Så du får potentielt forskellige output fra konvertering ned til 10bit før fodring til x264, versus at give det 12, 14 eller 16bit.) Jeg skulle sandsynligvis se på koden eller prøve den, før jeg laver ting, dog. Stol ikke på dette afsnit. : P

(rediger: ffmpeg foder ikke x264-10bit noget mere end 10 bit pr. Komponent. Det bruger swscale til at reducere selve bitdybden.)

Jeg spekulerer på, hvor hårdt det ville være at lappe x264 og x265 for at bruge forskellige navne til globale variabler og API-funktioner, når de kompileres til høj bit-dybde. Derefter kan du oprette begge versioner på én gang og have ffmpeg knyttet til dem begge. Ffmpeg libx264 og libx264rgb wrappers kunne sørge for at kalde den passende version af api afhængigt af inputstrømmen.(Ellers har du brug for -c:v libx264-deep eller libx264rgb-deep, i alt 4 forskellige x264 “codecs” i ffmpeg.)

Sådan krydser du kompilering af ffmpeg til windows

redigering: For windows tror jeg ikke, der er noget så praktisk som LD_LIBRARY_PATH til en libx264 DLL , så din bedste chance er stadig at opbygge en statisk binær med høj bitdybde og en anden til normal brug. Libx264 med høj dybde KAN “T overhovedet ikke udsende normal dybde h.264. Ikke bare en hastighedsstraf, det kan bare “t.

Den nemmeste måde at kompilere din egen ffmpeg (statisk binær) til windows er med https://github.com/rdp/ffmpeg-windows-build-helpers . git klon repoen på en Linux-maskine (eller måske et andet system med en fungerende gcc, som OS X?), og kør derefter

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

Dette tog ca. 8 timer for første løb, da det byggede mingw-cross-compile GCC fra kilden sammen med alt andet. (gcc er standard for at genopbygge sig selv flere gange til bootstrap, hvis du oprindeligt kompilerede det med en dårlig compiler.)

Du kan opdatere build-scriptet med git pull, og det igen kører træk de nyeste git-opdateringer til ffmpeg, x264, x265 og måske nogle af de andre projekter, den kompilerer fra kilden. (For de fleste downloader det bare tarballs.)

Mit Linux-skrivebord viser sin alder. Jeg har en wintendo jeg mest bruger til spil. Siden jeg begyndte at rode rundt med videokodning, finder jeg dens firekerne Sandybrid ge ret nyttigt til det også, esp. til x265. Sandsynligvis har nogle af x265 “s funktioner kun asm-versioner til AVX / SSE4, så det falder tilbage til C på min SSSE3 Linux-maskine (Conroe). Det eller det er mere bemærkelsesværdigt ved 1 fps …

Kommentarer

• Underretter stackexchange folk, når jeg foretager ændringer? Sender en kommentar, hvis det gør ikke ‘ t.
• dette er meget enklere på OS X, hvor dynamisk sammenkædning bruges. Simpelthen brew reinstall x264 --with-10-bit og du er færdig, ffmpeg bruger den nye x264-smag 🙂
• @SargeBorsch: pointen med dette svar var at have begge varianter installeret SAMTIDIGT, så du kan sammenligne 8bit og 10bit uden at geninstallere bibliotek. OS X dynamisk sammenkædning fungerer stort set det samme som Linux ‘ s, hvor du på samme måde kunne erstatte din libx264-installation med den anden smag, hvis du ville.
• @PeterCordes hmm, min dårlige. Du har ret

Jeg downloadede ffmpeg fra linket https://sourceforge.net/projects/ffmpeg-hi/?source=typ_redirect

Og indtastede kommandoen nedenfor for at oprette 4: 2: 2 1 0bit h.264 fil:

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