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 unterstützt sowohl 8-Bit- als auch 10-Bit-Ausgänge, und Sie müssen nichts Besonderes tun.

ffmpeg

Wenn Sie ffmpeg verwenden, können Sie sehen, welche Pixelformate und Bittiefen von libx264 unterstützt werden:

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

10-Bit-Pixelformate sind: yuv420p10le, yuv422p10le, yuv444p10le.

x264

Sie können auch x264 für unterstützte Bittiefen:

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

Zuvor mussten Sie x264 mit --bit-depth=10 und verknüpfen Sie dann Ihre ffmpeg entweder mit einer 8-Bit- oder einer 10-Bit-libx264, aber das ist jetzt nicht mehr erforderlich. Siehe Vereinheitlichen Sie 8-Bit- und 10-Bit-CLI und -Bibliotheken für weitere Informationen.

Kommentare

• Verdammt, das macht die Dinge com pliziert. Ich ‚ benötige also zwei ffmpeg-Binärdateien, die mit den beiden x264-Bibliotheken verknüpft sind. Wissen Sie, ob es irgendwo statische Builds des 10bit x264 gibt?
• Hier finden Sie sie: download.videolan.org/pub/x264/binaries Wenn Sie es selbst erstellen möchten, gibt es einen sehr langwierigen Prozess, bei dem Mingw, Yasm, Git und Gcc installiert werden und hier viel herumgespielt wird: doom10.org/ index.php? topic = 26.0 Aber ich konnte ‚ nicht zum Laufen bringen, hauptsächlich aufgrund einer dummen Unternehmensfirewall, die ‚ t erlaube git.
• Vielleicht kannst du Zeranoe dazu bringen, einen solchen Build bereitzustellen. Entschuldigung, ich ‚ bin ziemlich nutzlos, wenn es um Windows geht.
• Also bin ich, dass ‚ das ist Problem. Ich ‚ habe eine Build-Anfrage gepostet, wir ‚ werden sehen, wie es geht.
• FWIW in diesen Tagen ist libx264 “ beide “ Ich glaube …

edit: Ich habe erfolgreich eine 10-Bit-Codierung von Ducks Take Off erstellt.

Erster Weg: Ich habe eine 10-Bit-x264-Binärdatei erstellt, die libx264 statisch verknüpft.

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 

(ultraschnelle und niedrige Qualität, da dies ein Proof of Concept ist, kein Qualitätstest.) I. habe es nicht mit swscale kompiliert. (Es war unglücklich über ein RGB-Bild in libavutil oder so). Es tritt ein Fehler auf, wenn der Eingabefarbraum nicht mit --output-csp i444 übereinstimmt. Dies ist eigentlich hilfreich, wenn Sie nicht möchten, dass x264 versehentlich die Farbintensität heruntertastet. Es hat gut funktioniert, als ich ein paar Frames von yuv444p14le.y4m eingezogen habe und eine 10-Bit-Ausgabe erzeugt habe. (Die Bittiefe kann abgeschnitten werden, die Farbintensität wird jedoch nicht ohne swscale heruntergerechnet.)

Zweiter Weg: Verwenden Sie LD_LIBRARY_PATH, um eine 10-Bit-libx264.so

Sie können für alles dieselbe dynamisch verknüpfte ffmpeg-Binärdatei verwenden.

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

Ich habe offensichtlich nicht versucht, mit diesen Qualitätseinstellungen etwas visuell zu sehen. Ich wollte nur, dass es schnell läuft und nicht viel Speicherplatz verschwendet da ich am Ende immer viele Ausgabedateien erstelle, wenn ich Variationen von Dingen versuche.

Wenn die massiven y4m-Daten nicht an einen separaten x264-Prozess weitergeleitet werden, werden 14 fps statt 12 erreicht, was für ultraschnelle Geschwindigkeit eine anständige Beschleunigung darstellt. Langsamere Codierungen stellen diesen Overhead in den Schatten.

Meine Quelle ist 48-Bit-RGB. Ich habe festgestellt, dass sure_rnd keinen Einfluss auf die Ausgabe mkv hat (bitidentische Ergebnisse ohne -sws_flags, mit -sws_flags +accurate_rnd und -vf scale=flags=accurate_rnd, mit Ausnahme einiger Bits im mkv-Header, wahrscheinlich der randomisierten mkv-UUID. Auch mit -qp 0, damit ich es nicht durch Rundungsfehler verliere. cmp -l f1 f2 | less, um Binärdateien zu vergleichen, die nach einem anfänglichen Unterschied möglicherweise gleich sind.Oder ssdeep -p. Vielleicht ist accurate_rnd jetzt die Standardeinstellung?)

Es gibt ein ffmpeg-Swscaler-Flag, das wichtig ist, wenn Sie ffmpeg Ihre Chroma: lanczos anstelle der Standardeinstellung heruntersampeln lassen bikubisch. (Ich gehe davon aus, dass Lanczos immer noch als die beste Wahl für hohe Qualität angesehen wird? Haben Sie eine Weile nicht nachgelesen.)

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

Das Hinzufügen von +lanczos zu -sws_flags funktioniert nicht:

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

Wenn Sie versuchen, die Eingabe tiefer als 10 Bit einzugeben, lehnt ffmpeg ab.

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 

Tatsächlich besteht der libx264-Treiber von ffmpeg immer darauf, x264 genau einzugeben Die Bittiefe, für die es kompiliert wurde. Beispiel: -pix_fmt yuv420p:

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

x264.h sagt:

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

Ich denke, intern muss x264 (die CLI) immer Pixelformate hochkonvertieren, der Code hat keine 8-Bit-Eingabe- und 10-Bit-Ausgabeversionen jeder Funktion . Außerdem denke ich, dass das Akzeptieren verschiedener Eingabebittiefen nur in der x264-CLI erfolgt, nicht in der Bibliotheks-API. Ich bin gespannt, was passiert, wenn Sie die API-Eingabe mit höheren gesetzten Bits füttern … (ffpeg erlaubt Ihnen dies nicht, ohne den Code zu hacken, daher muss sich niemand darum kümmern, dies zu vermeiden.)

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 

Ohne Angabe von pix_fmt wählt ffmpeg yuv444p10le, wenn eine RGB-Eingabe erfolgt. Oder mit libx264rgb speist es 8-Bit-RGB an Funktionen ein, die 16-Bit (von denen 10 signifikant sind) und Segfaults> erwarten. <. Ich werde dies Upstream melden …

 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) 

Ich werde das stromaufwärts melden.

Wie auch immer, es stellte sich heraus, dass es verdammt einfach war, mir eine zu bauen Dual-Bit-Tiefenumgebung für ffmpeg oder jedes andere Programm, das Sie mit kompilierten Versionen von libx264, libx265 und allem anderen ausführen möchten. (Deshalb habe ich es „hohe Tiefe“ genannt, nicht nur „10bit“ für einen kürzeren Namen.)

Ende der Bearbeitung: Hier sind meine Streifzüge ohne Neukompilierung. Und ein gutes Stück über das Cross-Kompilieren von ffmpeg für win64

Ich habe es selbst versucht, da Sie es nicht mit einer cmdline versucht haben, die versucht hat, x264 Eingaben mit hoher Bittiefe zuzuführen.

ffmpeg Pixelformatnamen (ffmpeg -pix_fmts) geben nicht nur eine Anordnung an, sie werden einer exakten Bitanordnung zugeordnet, und daher hat jede Kombination aus Format und Bittiefe einen anderen Namen. Ich glaube, Sie haben erwartet, dass -pix_fmt yuv422p „in dieselbe Bittiefe wie meine Eingabe in 422 konvertieren“ bedeutet.

wikipedia sagt, dass h.264 nur mit Hi444PP 8-14 Bit Tiefe unterstützt, andere sind nur bis zu 10 Bit. Hi444PP ist das einzige Profil, das prädiktive verlustfreie Codierung unterstützt, die x264 für -qp 0 oder -crf 0 verwendet. edit: AFAICT, x264 unterstützt immer noch nur das Kompilieren für 8, 9 oder 10 Bit.

Wie auch immer, hier ist eine Reihe nutzloser Ausgaben eines Befehls, der nicht funktioniert, weil ich meinen lokalen Befehl nicht neu kompiliert habe x264. (Aber es sollte mit neu kompiliertem x264 funktionieren. Ich könnte diese Antwort bearbeiten, wenn ich selbst damit spielen möchte.)

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) 

Beachten Sie die Zeile Incompatible pixel format "yuv420p10le" for codec "libx264", auto-selecting format "yuv420p".

Wahrscheinlich brauchte ich und mit einem x264 mit hoher Bittiefe würde es einfach funktionieren. (und möglicherweise 444 10bit auswählen, das ffmpeg yuva444p10le aufruft.) Ich denke, hohe Bittiefe x264 könnte yuv444p14le, würde aber immer noch nur 10bit h.264 produzieren. Die cmdline x264 --fullhelp ist ziemlich explizit für die Ausgabebittiefe von 8 bis 10, nicht höher. Seltsam, dass -profile high10 von 8bit x264 nur stillschweigend ignoriert wird.

Intern verwendet x264, das für eine hohe Bittiefe kompiliert wurde, 16bpp zum Speichern von 10-Bit-Daten, sodass es wahrscheinlich Bewegungen ausführt Suche und so weiter mit 16bit Werten. Und möglicherweise ist die DCT um 16 Bit höher als um 10 Bit, es sei denn, durch das Ignorieren von 6 Bit kann eine Geschwindigkeit erzielt werden. Dies kann zu geringfügig anderen DCT-Koeffizienten führen, als wenn Sie vor der DCT auf 10 Bit abgerundet haben 10 Bit vor dem Einspeisen in x264, statt 12, 14 oder 16 Bit.) Ich sollte mir wahrscheinlich den Code ansehen oder ihn ausprobieren, bevor ich etwas erfasse. Traue diesem Absatz nicht. : P

(edit: ffmpeg füttert x264-10bit nicht mehr als 10 Bit pro Komponente. Es wird swscale verwendet, um die Bittiefe selbst zu reduzieren.)

Ich frage mich, wie schwer Es wäre, x264 und x265 zu patchen, um unterschiedliche Namen für globale Variablen und API-Funktionen zu verwenden, wenn diese für eine hohe Bittiefe kompiliert werden. Dann könnten Sie beide Versionen gleichzeitig erstellen und ffmpeg mit beiden verknüpfen. Das ffmpeg libx264 und libx264rgb könnten dafür sorgen, dass die entsprechende Version der API abhängig vom Eingabestream aufgerufen wird.(Andernfalls benötigen Sie -c:v libx264-deep oder libx264rgb-deep für insgesamt 4 verschiedene x264 „Codecs“ in ffmpeg.)

So kompilieren Sie ffmpeg für Windows

Bearbeiten: Für Windows gibt es meiner Meinung nach nichts so Bequemes wie LD_LIBRARY_PATH für eine libx264-DLL Daher ist es immer noch am besten, eine statische Binärdatei mit hoher Bittiefe und eine andere für den normalen Gebrauch zu erstellen. Libx264 mit hoher Tiefe KANN überhaupt keine normale Tiefe h.264 ausgeben. Dies ist nicht nur eine Geschwindigkeitsstrafe, sondern kann auch „t.

Der einfachste Weg, ein eigenes ffmpeg (statische Binärdatei) für Windows zu kompilieren, ist mit https://github.com/rdp/ffmpeg-windows-build-helpers . git klont das Repo auf einem Linux-Computer (oder einem anderen System mit einem funktionierenden gcc wie OS X?) und führt dann

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

Dies dauerte ungefähr 8 Stunden für den ersten Lauf, da zusammen mit allem anderen GCC aus dem Quellcode erstellt wurde (gcc erstellt standardmäßig mehrere neu Mal zum Bootstrap, falls Sie es ursprünglich mit einem fehlerhaften Compiler kompiliert haben.)

Sie können das Build-Skript mit git pull aktualisieren und es erneut ausführen Ziehen Sie die neuesten Git-Updates für ffmpeg, x264, x265 und möglicherweise einige der anderen Projekte, die es aus dem Quellcode kompiliert. (Für die meisten werden nur Tarballs heruntergeladen.)

Mein Linux-Desktop zeigt sein Alter an Ein Nintendo, das ich hauptsächlich für Spiele verwende. Seit ich mit der Videokodierung herumgespielt habe, finde ich seinen Quad-Core-Sandybrid ge auch dafür ziemlich nützlich, insb. für x265. Wahrscheinlich haben einige der x265-Funktionen nur asm-Versionen für AVX / SSE4, daher wird auf meinem SSSE3-Linux-Computer (Conroe) auf C zurückgegriffen. Das oder es macht sich bei 1fps besser bemerkbar …

Kommentare

• Benachrichtigt stackexchange Personen, wenn ich Änderungen vornehme? ‚ t.
• Dies ist unter OS X, wo dynamische Verknüpfungen verwendet werden, viel einfacher. Einfach brew reinstall x264 --with-10-bit und wenn Sie fertig sind, wird ffmpeg die neue x264-Variante verwenden 🙂
• @SargeBorsch: Der Sinn dieser Antwort bestand darin, beide Varianten gleichzeitig zu installieren, sodass Sie 8bit und 10bit vergleichen können, ohne die neu zu installieren Die dynamische Verknüpfung von OS X funktioniert fast genauso wie die von Linux ‚, bei der Sie Ihre libx264-Installation auf ähnliche Weise durch die andere Variante ersetzen können, wenn Sie möchten.
• @PeterCordes hmm, mein Schlechtes. Sie haben Recht

Ich habe das ffmpeg vom Link https://sourceforge.net/projects/ffmpeg-hi/?source=typ_redirect

Geben Sie den folgenden Befehl ein, um 4: 2: 2 1 0bit h.264 Datei:

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