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øtter både 8-biters og 10-biters utganger, og du trenger ikke å gjøre noe spesielt.

ffmpeg

Hvis du bruker ffmpeg, kan du se hvilke pikselformater og bitdybder som støttes av libx264:

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

10-biters pikselformater er: yuv420p10le, yuv422p10le, yuv444p10le.

x264

Du kan også sjekke x264 for bitdybder som støttes:

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

Tidligere måtte du kompilere x264 med --bit-depth=10, og knytt deretter ffmpeg til enten en 8-biters eller 10-bit libx264, men det er nå unødvendig. Se Forene 8-biters og 10-biters CLI og biblioteker for mer info.

Kommentarer

• Damn, that makes things com plisert. Så jeg ‘ jeg trenger to ffmpeg-binærfiler knyttet til de to x264-bibliotekene. Vet du om det er statiske konstruksjoner av 10bit x264 hvor som helst?
• Finn dem her vil du: download.videolan.org/pub/x264/binaries Hvis du vil bygge den selv, er det en veldig langvarig prosess som installerer mingw, yasm, git og gcc og mye mucking rundt her: doom10.org/ index.php? topic = 26.0 Men jeg kunne ikke ‘ ikke få det til å fungere, hovedsakelig på grunn av dum bedriftsbrannmur som vant ‘ t allow git.
• Kanskje du kan få Zeranoe til å gi en slik bygging. Beklager, jeg ‘ er ganske ubrukelig når det gjelder Windows.
• Det er jeg også at ‘ er problem. Jeg ‘ har lagt ut en byggeforespørsel, vi ‘ ser hvordan det går.
• FWIW i disse dager er libx264 » begge » Jeg tror …

edit: Jeg laget en 10-biters kode av Ducks Take Off .

Første vei: Jeg bygde en 10bit x264 binær som statisk kobler 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 

(ultra rask og lav kvalitet fordi den er et bevis på konseptet, ikke en kvalitetstest.) Jeg kompilerte den ikke med skala. (Det var ulykkelig med en RGB pix fmt i libavutil eller noe). Det feiler hvis inngangsfargerommet ikke samsvarer med --output-csp i444, noe som faktisk er hyggelig hvis du ikke ved et uhell vil ha x264 nedsprøve på kroma. Det fungerte bra da jeg matet det noen rammer med yuv444p14le.y4m, og produserte 10-biters utgang. (Det kan avkutte bitdybde, men ikke nedprøve kroma uten swscale.)

Andre måte: bruk LD_LIBRARY_PATH for å velge en 10-biters libx264.so

Du kan bruke den samme ffmpeg dynamisk koblede binæren for 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 prøvde tydeligvis ikke å se noe visuelt med disse kvalitetsinnstillingene. Jeg ville bare at den skulle løpe fort, og ikke kaste bort en haug med diskplass siden jeg alltid ender med å lage mange utdatafiler når jeg prøver varianter på ting.

Hvis jeg ikke førte de enorme y4m-dataene til en egen x264-prosess, fikk den 14 fps i stedet for 12, så det er en anstendig hastighet for ultrahurtig. Langsommere koder vil dverge den overhead.

Kilden min er 48bit RGB. Jeg fant ut at accurate_rnd ikke hadde noen innvirkning på utdata-mkv. (Bit-identiske resultater uten -sws_flags med -sws_flags +accurate_rnd og -vf scale=flags=accurate_rnd, bortsett fra noen få biter i mkv-overskriften, sannsynligvis den randomiserte mkv UUID. Selv med -qp 0, så jeg mistet det ikke til avrundingsfeil. cmp -l f1 f2 | less for å sammenligne binære filer som kan være de samme etter en innledende forskjell.Eller ssdeep -p. Kanskje accurate_rnd er standard nå?)

Det er ett ffmpeg swscaler-flagg som betyr noe, hvis du lar ffmpeg nedprøve på chroma: lanczos i stedet for standard bicubic. (Jeg antar at lanczos fremdeles blir sett på som det beste valget for høy kvalitet? Har ikke lest det 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

Legge til +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 å mate inngangen dypere enn 10 bits, nekter 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 alltid på å mate x264 nøyaktig bitdybden den er kompilert for. f.eks. med -pix_fmt yuv420p:

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

x264.h sier:

/* 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 tror internt x264 (CLI) må alltid konvertere pixelformater, koden har ikke 8bit inngang, 10bit utgangsversjoner av hver funksjon . Og jeg tror også at akseptering av forskjellige inngangsbitdybder bare er i x264 CLI, ikke bibliotekets API. Jeg er nysgjerrig på hva som skjer når du mater API-inngangen der det er høyere biter satt … (ffpeg tillater deg ikke å gjøre dette uten å hacke koden, så dette er ikke noe noen trenger å bekymre seg for å unngå.)

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 

Uten pix_fmt spesifisert, velger ffmpeg yuv444p10le når den får rgb-inngang. Eller med libx264rgb, den mater 8bit rgb til funksjoner som forventer 16bit (hvorav 10 er signifikante), og segfaults>. <. Jeg rapporterer det oppstrø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 oppstrøms.

Uansett viser det seg at det var ganske darn enkelt å bygge meg en dual-bit dybdemiljø for ffmpeg, eller et hvilket som helst annet program du vil kjøre med høy-bit dybdekompilerte versjoner av libx264, libx265 og alt annet du vil. (Derfor kalte jeg det «highdepth», ikke bare «10bit» for et kortere navn.)

slutten av redigeringen: nedenfor her er det jeg snakker uten å kompilere på nytt. Og litt om hvordan du kan krysskompilere ffmpeg for win64

Prøvde dette selv, siden du ikke prøvde med en cmdline som prøvde å mate høy bitdybdeinngang til x264.

ffmpeg pikselformatnavn (ffmpeg -pix_fmts) spesifiserer ikke bare et arrangement, de tilordnes til et nøyaktig bitarrangement, og dermed har hvert format + bitdybdekombinasjon et annet navn. Jeg tror du forventet -pix_fmt yuv422p å bety «konvertere til 422 i samme bitdybde som min inngang».

wikipedia sier h.264 bare støtter 8-14 bit dybde med Hi444PP, andre er bare opptil 10bit. Hi444PP er den eneste profilen som støtter prediktiv tapsfri koding, som x264 bruker til -qp 0 eller -crf 0. edit: AFAICT, x264 støtter fremdeles bare å bli kompilert for 8, 9 eller 10bits.

Uansett, her «er det en haug med unyttig utdata fra en kommando som ikke fungerer fordi jeg ikke kompilerte min lokale x264. (Men det skal fungere med omkompilert x264. Jeg kan redigere dette svaret hvis jeg vil leke med det selv.)

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) 

Legg merke til Incompatible pixel format "yuv420p10le" for codec "libx264", auto-selecting format "yuv420p" linjen.

Sannsynligvis trengte jeg ikke -profile, og med en x264 med høy bitdybde, ville det bare fungere. (og potensielt velg 444 10bit, som ffmpeg kaller yuva444p10le.) Jeg tror høy bitdybde x264 kunne godta yuv444p14le, men vil fremdeles bare produsere 10bit h.264. Cmdline x264 --fullhelp er ganske eksplisitt om utgangsbitdybde fra 8 til 10, ikke høyere. Rart at -profile high10 bare blir ignorert lydløst av 8bit x264.

Internt, x264 kompilert for høy bitdybde, bruker 16bpp for lagring av 10bit-data, så det gjør sannsynligvis bevegelse søk og så videre med 16bit-verdier. Og kanskje DCT høyere 16bit i stedet for 10bit, med mindre det er hastighet å oppnå ved å ignorere 6 bits. Dette kan gi litt forskjellige DCT-koeffisienter enn hvis du avrundes ned til 10bit før DCT. (Så du får potensielt forskjellig utgang fra å konvertere ned til 10bit før mating til x264, mot å gi den 12, 14 eller 16bit.) Jeg burde sannsynligvis se på koden eller prøve den før jeg lager ting, skjønt. Ikke stol på dette avsnittet. : P

(rediger: ffmpeg vil ikke mate x264-10bit noe mer enn 10 bit per komponent. Den vil bruke swscale for å redusere selve bitdybden.)

Jeg lurer på hvor vanskelig det ville være å lappe x264 og x265 for å bruke forskjellige navn for globale variabler og API-funksjoner, når de kompileres for høy bitdybde. Da kan du bygge begge versjonene på en gang, og ha ffmpeg koblet mot dem begge. Ffmpeg libx264 og libx264rgb wrappers kan ta seg av å ringe den riktige versjonen av api, avhengig av inngangsstrømmen.(Ellers trenger du -c:v libx264-deep eller libx264rgb-deep, for totalt 4 forskjellige x264 «kodeker» i ffmpeg.)

Hvordan krysse kompilere ffmpeg for windows

redigere: For windows tror jeg ikke det er noe så praktisk som LD_LIBRARY_PATH for en libx264 DLL , så det beste alternativet er fortsatt å bygge en statisk binær med høy bitdybde, og en annen for normal bruk. Libx264 med høy dybde KAN «T i det hele tatt sende ut normal dybde h.264. Ikke bare fartsstraff, det kan bare «t.

Den enkleste måten å kompilere din egen ffmpeg (statisk binær) for windows er med https://github.com/rdp/ffmpeg-windows-build-helpers . git klone repoen på en Linux-maskin (eller kanskje et annet system med en fungerende gcc, som OS X?), og kjør deretter

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

Dette tok omtrent 8 timer for første løp, siden den bygde mingw-cross-compile GCC fra kilden, sammen med alt annet. (gcc er standard for å gjenoppbygge seg selv flere ganger for å starte opp, i tilfelle du opprinnelig kompilerte den med en dårlig kompilator.)

Du kan oppdatere build-skriptet med git pull, og kjøre det på nytt trekk de siste git-oppdateringene for ffmpeg, x264, x265, og kanskje noen av de andre prosjektene den kompilerer fra kilden. (For de fleste laster det bare ned tarballer.)

Linux-skrivebordet mitt viser alderen. Jeg har en wintendo jeg bruker mest for spill. Siden jeg begynte å rote med videokoding, finner jeg den firekjernede Sandybrid ge ganske nyttig for det også, spesielt for x265. Sannsynligvis har noen av funksjonene på x265 «bare asm-versjoner for AVX / SSE4, så den faller tilbake til C på min SSSE3 Linux-maskin (Conroe). Det eller det er mer merkbart ved 1 bilder per sekund …

Kommentarer

• Varsler stackexchange folk når jeg gjør endringer? Legger ut en kommentar i tilfelle det ikke ‘ t.
• dette er mye enklere på OS X, hvor dynamisk lenking brukes. Bare brew reinstall x264 --with-10-bit og du er ferdig, ffmpeg vil bruke den nye x264-smaken 🙂
• @SargeBorsch: poenget med dette svaret var å ha begge smakene installert SAMTIDIG, slik at du kan sammenligne 8bit og 10bit uten å installere bibliotek. OS X dynamisk lenking fungerer stort sett det samme som Linux ‘ s, hvor du på samme måte kan erstatte libx264-installasjonen din med den andre smaken hvis du vil.
• @PeterCordes hmm, min dårlige. Du har rett

Jeg lastet ned ffmpeg fra lenken https://sourceforge.net/projects/ffmpeg-hi/?source=typ_redirect

Og skrev inn kommandoen nedenfor for å opprette 4: 2: 2 1 0bit h.264 fil:

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