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 ondersteunt zowel 8-bit als 10-bit output, en je hoeft niets speciaals te doen.

ffmpeg

Als u ffmpeg gebruikt, kunt u zien welke pixelindelingen en bitdiepten worden ondersteund door libx264:

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

10-bits pixelindelingen zijn: yuv420p10le, yuv422p10le, yuv444p10le.

x264

Je kunt ook x264 voor ondersteunde bitdiepten:

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

Voorheen moest je x264 compileren met --bit-depth=10, en koppel vervolgens uw ffmpeg aan een 8-bit of 10-bit libx264, maar dat is nu niet nodig. Zie Verenig 8-bit en 10-bit CLI en bibliotheken voor meer informatie.

Reacties

• Verdomme, dat maakt dingen com gepleit. Dus ik ‘ heb twee ffmpeg-binaire bestanden nodig die zijn gekoppeld aan de twee x264-bibliotheken. Weet je of er ergens statische builds zijn van de 10bit x264?
• Vind ze hier: download.videolan.org/pub/x264/binaries Als je het zelf wilt bouwen, is er een enorm langdradig proces waarbij mingw, yasm, git en gcc worden geïnstalleerd en er wordt hier veel gedoe: doom10.org/ index.php? topic = 26.0 Maar ik kon ‘ het niet aan het werk krijgen, voornamelijk vanwege een stomme bedrijfsfirewall die ‘ t allow git.
• Misschien kun je Zeranoe krijgen om een dergelijke build te leveren. Sorry, ik ‘ ben redelijk nutteloos als het op Windows aankomt.
• Ik ook, dat ‘ is de probleem. Ik ‘ heb een bouwverzoek gepost, we ‘ zullen zien hoe het gaat.
• FWIW tegenwoordig is libx264 ” beide ” Ik geloof …

bewerken: ik heb met succes een 10-bits codering gemaakt van Ducks Take Off .

Eerste manier: Ik heb een 10-bits x264-binair bestand gebouwd dat libx264 statisch koppelt.

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 

(ultrasnel en van lage kwaliteit omdat het een proof of concept is, geen kwaliteitstest.) compileerde het niet met swscale. (Het was ongelukkig over een RGB pix fmt in libavutil of zoiets). Het geeft een foutmelding als de invoer kleurenruimte “niet overeenkomt met --output-csp i444, wat eigenlijk prettig is als je niet per ongeluk x264 wilt downsamplen naar de chroma. Het werkte prima toen ik het een paar frames yuv444p14le.y4m toevoegde, wat 10-bits uitvoer opleverde. (Het kan bitdiepte afkappen, maar chroma niet downsamplen zonder swscale.)

Tweede manier: gebruik LD_LIBRARY_PATH om een 10bit libx264.so

U kunt voor alles hetzelfde dynamisch gekoppelde ffmpeg-bestand gebruiken.

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

Ik heb duidelijk niet geprobeerd om iets visueel te zien met die kwaliteitsinstellingen. Ik wilde gewoon dat het snel zou werken en geen hoop schijfruimte zou verspillen aangezien ik uiteindelijk altijd veel uitvoerbestanden maak als ik variaties op dingen probeer.

Door de enorme y4m-gegevens niet naar een apart x264-proces te pipen, ging het 14 fps in plaats van 12, dus een behoorlijke versnelling voor ultrasnel. Langzamere coderingen zullen die overhead verkleinen.

Mijn bron is 48bit RGB. Ik ontdekte dat accurate_rnd geen effect had op de output mkv. (Bit-identieke resultaten zonder -sws_flags, met -sws_flags +accurate_rnd, en -vf scale=flags=accurate_rnd, behalve een paar bits in de mkv-header, waarschijnlijk de gerandomiseerde mkv UUID. Zelfs met -qp 0, dus ik verloor het niet door afrondingsfouten. cmp -l f1 f2 | less om binaire bestanden te vergelijken die na een eerste verschil hetzelfde zouden kunnen zijn.Of ssdeep -p. Misschien is accurate_rnd nu de standaard?)

Er is één ffmpeg swscaler-vlag die er toe doet, als je “ffmpeg laat downsamplen van je chroma: lanczos in plaats van de standaard bicubisch. (Ik neem aan dat lanczos nog steeds wordt beschouwd als de beste keuze voor hoge kwaliteit? Ik heb het al een tijdje niet gelezen.)

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

+lanczos toevoegen aan -sws_flags werkt niet:

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

Als je probeert om de invoer dieper dan 10 bits in te voeren, weigert 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 

Eigenlijk staat de libx264-driver van ffmpeg er altijd op x264 exact in te voeren de bitdiepte waarvoor het is gecompileerd. bijv. met -pix_fmt yuv420p:

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

x264.h zegt:

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

Ik denk dat intern x264 (de CLI) altijd pixelformaten moet up-converteren, de code heeft geen 8-bits invoer, 10-bits uitvoerversies van elke functie . En ik denk ook dat het accepteren van verschillende invoerbitdieptes alleen in de x264 CLI zit, niet in de bibliotheek-API. Ik ben benieuwd wat er gebeurt als je de API-invoer invoert waar hogere bits zijn ingesteld … (ffpeg staat je niet toe dit te doen zonder de code te hacken, dus dit is niet iets waar iemand zich zorgen over hoeft te maken.)

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 

Zonder pix_fmt gespecificeerd, kiest ffmpeg yuv444p10le wanneer hij RGB-invoer krijgt. Of met libx264rgb, het voedt 8bit RGB naar functies die 16bit verwachten (waarvan er 10 significant zijn), en segfaults>. <. Ik zal dat stroomopwaarts rapporteren …

 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) 

Ik zal dat stroomopwaarts rapporteren.

Hoe dan ook, het bleek best makkelijk om voor mezelf een dual-bit-depth omgeving voor ffmpeg, of elk ander programma dat je wilt draaien met high-bit-depth-gecompileerde versies van libx264, libx265 en wat je maar wilt. (daarom noemde ik het “highdepth”, niet gewoon “10bit” voor een kortere naam.)

einde van bewerking: hieronder zijn mijn ramblings zonder opnieuw te compileren. En een goed stukje over hoe je ffmpeg voor win64 kunt cross-compileren

Ik heb dit zelf geprobeerd, aangezien je het niet probeerde met een cmdline die probeerde een hoge bitdiepte-invoer naar x264 te sturen.

ffmpeg pixelformaatnamen (ffmpeg -pix_fmts) specificeren niet alleen een rangschikking, ze verwijzen naar een exacte bitrangschikking, en dus heeft elke indeling + bitdiepte combo een andere naam. Ik denk dat je verwachtte dat -pix_fmt yuv422p zou betekenen “converteren naar 422 in dezelfde bitdiepte als mijn invoer”.

wikipedia zegt dat h.264 8-14 bit diepte alleen ondersteunt met Hi444PP, anderen zijn slechts tot 10 bit. Hi444PP is het enige profiel dat voorspellende, verliesvrije codering ondersteunt, die x264 gebruikt voor -qp 0 of -crf 0. edit: AFAICT, x264 ondersteunt nog steeds alleen het worden gecompileerd voor 8, 9 of 10 bits.

Hoe dan ook, hier is een hoop nutteloze uitvoer van een commando dat niet werkt omdat ik mijn lokale niet opnieuw heb gecompileerd. x264. (Maar het zou moeten werken met opnieuw gecompileerde x264. Ik zou dit antwoord kunnen bewerken als ik er zelf mee wil spelen.)

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) 

Let op de Incompatible pixel format "yuv420p10le" for codec "libx264", auto-selecting format "yuv420p" regel.

Waarschijnlijk had ik , en met een hoge bit-diepte x264, zou het gewoon werken. (en kies eventueel 444 10bit, die ffmpeg yuva444p10le aanroept.) Ik denk hoge bitdiepte x264 zou yuv444p14le, maar zou nog steeds alleen 10bit h.264 produceren. De cmdline x264 --fullhelp is vrij expliciet over de bitdiepte van de uitvoer van 8 tot 10, niet hoger. Vreemd dat -profile high10 gewoon stilletjes wordt genegeerd door 8bit x264.

Intern gebruikt x264 gecompileerd voor hoge bitdiepte 16 bpp voor het opslaan van 10 bit data, dus het doet waarschijnlijk beweging zoeken enzovoort met 16-bits waarden. En kan DCT hoger zijn dan 16 bit in plaats van 10 bit, tenzij er snelheid te behalen is door 6 bits te negeren. Dit kan iets andere DCT-coëfficiënten opleveren dan wanneer je vóór DCT naar beneden afrondt naar 10 bit. (Dus je krijgt mogelijk een andere output als je 10bit voordat ik naar x264 voer, versus 12, 14 of 16 bit.) Ik zou de code moeten bekijken of het proberen voordat ik dingen verzin. Vertrouw deze paragraaf niet. : P

(edit: ffmpeg zal x264-10bit niet meer dan 10 bits per component voeden. Het zal swscale gebruiken om de bitdiepte zelf te verkleinen.)

Ik vraag me af hoe moeilijk het zou zijn om x264 en x265 te patchen om verschillende namen te gebruiken voor globale variabelen en API-functies, wanneer gecompileerd voor hoge bit-diepte. Dan zou je beide versies tegelijk kunnen bouwen, en ffmpeg aan beide kunnen koppelen. De ffmpeg libx264 en libx264rgb wrappers kunnen ervoor zorgen dat de juiste versie van de api wordt aangeroepen, afhankelijk van de invoerstroom.(Anders “heb je -c:v libx264-deep of libx264rgb-deep nodig, voor in totaal 4 verschillende x264″ codecs “in ffmpeg.)

Hoe ffmpeg voor Windows te compileren

bewerken: voor Windows denk ik niet dat er iets zo handig is als LD_LIBRARY_PATH voor een libx264 DLL , dus je kunt het beste nog steeds een statisch binair bestand met hoge bitdiepte bouwen, en een ander voor normaal gebruik. Libx264 met hoge diepte CAN “T-output normale diepte h.264 helemaal. Niet alleen een snelheidsbeperking, het kan gewoon “t.

De gemakkelijkste manier om uw eigen ffmpeg (statisch binair bestand) voor Windows te compileren is met https://github.com/rdp/ffmpeg-windows-build-helpers . git clone de repo op een Linux-machine (of misschien een ander systeem met een werkende gcc, zoals OS X?), en voer vervolgens uit

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

Dit duurde ongeveer 8 uur voor de eerste run, aangezien het mingw-cross-compile GCC vanaf de broncode bouwde, samen met al het andere. (gcc stelt zichzelf standaard verschillende keer om te bootstrap, voor het geval je het oorspronkelijk aan het compileren was met een slechte compiler.)

Je kunt het build-script bijwerken met git pull, en het opnieuw starten zal haal de laatste git-updates voor ffmpeg, x264, x265, en misschien enkele van de andere projecten die het compileert uit de bron. (Voor de meeste downloadt het gewoon tarballs.)

Mijn Linux-desktop laat zijn leeftijd zien. Ik heb een wintendo dat ik meestal gebruik voor games. Sinds ik begon te rommelen met videocodering, merk ik dat de quad-core Sandybrid daar ook best handig voor, vooral. voor x265. Waarschijnlijk hebben sommige x265-functies alleen asm-versies voor AVX / SSE4, dus het valt terug naar C op mijn SSSE3 Linux-machine (Conroe). Dat of het is meer merkbaar bij 1 fps …

Opmerkingen

• Geeft stackexchange mensen een melding wanneer ik wijzigingen aanbreng? Een opmerking plaatsen voor het geval het doesn ‘ t.
• dit is een stuk eenvoudiger op OS X, waar dynamisch linken wordt gebruikt. Gewoon brew reinstall x264 --with-10-bit en je bent klaar, ffmpeg zal de nieuwe x264-smaak gebruiken 🙂
• @SargeBorsch: het punt van dit antwoord was om beide smaken TEGELIJKERTIJD te installeren, zodat je 8bit en 10bit kunt vergelijken zonder de bibliotheek. OS X dynamische koppeling werkt vrijwel hetzelfde als Linux ‘ s, waar je op dezelfde manier je libx264-installatie zou kunnen vervangen door de andere smaak als je dat zou willen.
• @PeterCordes hmm, mijn fout. Je hebt gelijk

Ik heb de ffmpeg gedownload van de link https://sourceforge.net/projects/ffmpeg-hi/?source=typ_redirect

En voer de onderstaande opdracht in om 4: 2: 2 1 0bit h.264 bestand:

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