x264 unterstützt sowohl 8-Bit- als auch 10-Bit-Ausgaben, und Sie müssen nichts Besonderes tun.

ffmpeg

Wenn Sie verwenden ffmpeg, 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 x264nach unterstützten Bittiefen suchen:

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

Früher mussten Sie x264 mit kompilieren --bit-depth=10und dann ffmpegentweder mit einer 8-Bit- oder einer 10-Bit-Libx264 verknüpfen, aber das ist jetzt unnötig. Weitere Informationen finden Sie unter Unify 8-Bit- und 10-Bit-CLI und -Bibliotheken .

Bearbeiten: 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

(ultraschnell und von geringer Qualität, da es sich um einen Machbarkeitsnachweis handelt, nicht um einen Qualitätstest.) Ich habe es nicht mit swscale kompiliert. (Es war unglücklich über ein RGB-Pix-FMT in libavutil oder so). Es tritt ein Fehler auf, wenn der Eingabefarbraum nicht übereinstimmt --output-csp i444, was eigentlich nett ist, wenn Sie nicht versehentlich x264 das Chroma heruntersampeln möchten. Es funktionierte gut, als ich es mit ein paar Frames fütterte und eine yuv444p14le.y4m10-Bit-Ausgabe erzeugte. (Es kann die Bittiefe abschneiden, aber ohne swscale kein Downsampling von Chroma.)

Zweiter Weg: Verwenden LD_LIBRARY_PATHSie , um eine 10-Bit-libx264.so auszuwählen

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 visuell etwas 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 ausprobiere.

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

Meine Quelle ist 48bit RGB. Ich fand heraus, dass correct_rnd keinen Einfluss auf die Ausgabe von mkv hatte. (Bit-identische Ergebnisse mit no -sws_flags, mit -sws_flags +accurate_rnd, und -vf scale=flags=accurate_rnd, bis auf ein paar Bits im mkv-Header, wahrscheinlich die randomisierte mkv-UUID. Selbst mit -qp 0, also ging ich nicht durch Rundungsfehler verloren. cmp -l f1 f2 | lessum Binärdateien zu vergleichen, die das sein könnten gleich nach einigen anfänglichen Unterschieden. Oder ssdeep -p. Vielleicht accurate_rndist dies jetzt die Standardeinstellung?)

Es gibt ein ffmpeg swscaler-Flag, das wichtig ist, wenn Sie ffmpeg Ihr Chroma heruntersampeln lassen: lanczos anstelle des standardmäßigen bicubic. (Ich nehme an, Lanczos gilt immer noch als die beste Wahl für hohe Qualität? Habe 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

Hinzufügen funktioniert nicht +lanczos:-sws_flags

[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, es mit Eingaben tiefer als 10 Bit zu füttern, 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 die Bittiefe zuzuführen, für die er kompiliert wurde. zB mit -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, x264 (die CLI) muss intern immer Pixelformate hochkonvertieren, der Code hat keine 8-Bit-Eingabe-, 10-Bit-Ausgabeversionen jeder Funktion. Außerdem denke ich, dass das Akzeptieren verschiedener Eingabebittiefen nur in der x264-CLI und nicht in der Bibliotheks-API liegt. Ich bin gespannt, was passiert, wenn Sie die API-Eingabe dort füttern, wo höhere Bits gesetzt sind ... (ffpeg erlaubt Ihnen dies nicht, ohne den Code zu hacken, also muss sich niemand Sorgen machen, 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

Wenn kein pix_fmt angegeben ist, wählt ffmpeg yuv444p10ledie RGB-Eingabe aus. Oder mit libx264rgb, es speist 8bit rgb an Funktionen, die 16bit erwarten (von denen 10 signifikant sind), und segfaults >.<. Ich werde das stromaufwärts 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 selbst eine Dual-Bit-Tiefe-Umgebung für ffmpeg oder jedes andere Programm zu bauen, das Sie mit mit hoher Bit-Tiefe kompilierten Versionen von libx264, libx265 und allem anderen, was Sie wollen, ausführen möchten . (Deshalb habe ich es "highdepth" genannt, nicht nur "10bit", um einen kürzeren Namen zu haben.)

Ende der Bearbeitung: Hier unten sind meine Abschweifungen ohne Neukompilierung. Und ein gutes Stück darüber, wie man ffmpeg für win64 querkompiliert

Ich habe das 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 bilden eine genaue Bitanordnung ab, und daher hat jede Kombination aus Format und Bittiefe einen anderen Namen. Ich denke, Sie haben erwartet -pix_fmt yuv422p, "in der gleichen Bittiefe wie meine Eingabe in 422 konvertieren" zu meinen.

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

Wie auch immer, hier ist ein Haufen nutzloser Ausgaben von einem Befehl, der nicht funktioniert, weil ich mein lokales x264 nicht neu kompiliert habe. (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 Incompatible pixel format 'yuv420p10le' for codec 'libx264', auto-selecting format 'yuv420p'Linie.

Wahrscheinlich brauchte ich nicht -profile, und mit einem x264 mit hoher Bittiefe würde es einfach funktionieren. (und möglicherweise 444 10bit auswählen, was ffmpeg aufruft yuva444p10le.) Ich denke , x264 könnte eine hohe Bittiefe akzeptieren yuv444p14le, würde aber immer noch nur 10bit h.264 erzeugen. Die cmdline x264 --fullhelpist ziemlich explizit in Bezug auf die Ausgabebittiefe von 8 bis 10, nicht höher. Seltsam, das -profile high10wird von 8bit x264 einfach stillschweigend ignoriert.

Intern verwendet x264, das für eine hohe Bittiefe kompiliert wurde, 16 bpp zum Speichern von 10-Bit-Daten, sodass es wahrscheinlich eine Bewegungssuche usw. mit 16-Bit-Werten durchführt. Und DCT könnte 16 Bit statt 10 Bit höher sein, es sei denn, es lässt sich durch das Ignorieren von 6 Bit Geschwindigkeit gewinnen. Dies könnte zu etwas anderen DCT-Koeffizienten führen, als wenn Sie vor DCT auf 10 Bit abrunden würden. (Sie erhalten also möglicherweise eine andere Ausgabe, wenn Sie vor dem Einspeisen in x264 in 10 Bit konvertieren, anstatt 12, 14 oder 16 Bit zu geben.) Ich sollte versuchen. Schauen Sie sich den Code an oder probieren Sie es aus, bevor Sie etwas erfinden. Vertrauen Sie diesem Absatz nicht. :P

(Bearbeiten: ffmpeg füttert x264-10bit nicht mit mehr als 10 Bit pro Komponente. Es wird swscale verwenden, 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 sie für hohe Bittiefe kompiliert werden. Dann könnten Sie beide Versionen gleichzeitig erstellen und ffmpeg mit beiden verknüpfen. Die ffmpeg libx264und libx264rgbWrapper könnten sich um den Aufruf der entsprechenden Version der API kümmern, abhängig vom Eingabestream. (Andernfalls benötigen Sie -c:v libx264-deepoder libx264rgb-deepfür insgesamt 4 verschiedene x264-„Codecs“ in ffmpeg.)

So kompilieren Sie ffmpeg für Windows

Bearbeiten: Für Windows gibt es meines Erachtens nichts so Bequemes wie LD_LIBRARY_PATHfür eine libx264-DLL. Daher ist es am besten, eine statische Binärdatei mit hoher Bittiefe und eine weitere für den normalen Gebrauch zu erstellen. High-Depth libx264 kann H.264 mit normaler Tiefe überhaupt nicht ausgeben. Nicht nur eine Geschwindigkeitsstrafe, es kann einfach nicht.

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

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

Dies dauerte beim ersten Durchlauf etwa 8 Stunden, da es mingw-cross-compile GCC zusammen mit allem anderen aus dem Quellcode erstellte. (gcc baut sich standardmäßig mehrmals zu Bootstrap neu auf, falls Sie es ursprünglich mit einem schlechten Compiler kompiliert haben.)

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

Mein Linux-Desktop ist in die Jahre gekommen. Ich habe einen Wintendo, den ich hauptsächlich für Spiele verwende. Seit ich angefangen habe, mit der Videocodierung herumzuspielen, finde ich die Quad-Core-Sandybridge auch dafür ziemlich nützlich, besonders. für x265. Wahrscheinlich haben einige der Funktionen von x265 nur asm-Versionen für AVX/SSE4, daher fällt es auf meiner SSSE3-Linux-Maschine (Conroe) auf C zurück. Das oder es ist bei 1 fps mehr bemerkbar ...

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

Und geben Sie den folgenden Befehl ein, um eine 4:2:2 10bit h.264- Datei zu erstellen:

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