Codierung 4: 2: 2 in 10-Bit mit libx264

9

Ich glaube, dass libx264 jetzt 10-Bit-4: 2: 2-Codierungen ausführen kann, aber ich kann es scheinbar nicht zum Laufen bringen. Ich verwende ffmpeg (Info unten) und habe auch den x264-Encoder direkt ausprobiert. ich habe es versucht

ffmpeg.exe -i input.mov -c:v libx264 -profile:v high422 -crf 20 -pix_fmt yuv422p output.mp4

und das ergibt eine schöne 4: 2: 2 Ausgabe, aber nur bei 8 Bit Tiefe,

[libx264 @ 00000000055a9de0] profile High 4:2:2, level 4.0, 4:2:2 8-bit

und ich habe es versucht

ffmpeg.exe -i input.mov -c:v libx264 -profile:v high10 -crf 20 -pix_fmt yuv422p output.mp4

und das gibt mir den Fehler:

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

In der x264 --fullhelp Dokumentation finde ich:

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

Es kann also 4: 2: 2 bei 10 Bit Tiefe und sogar 4: 4: 4 bei 10 Bit anscheinend tun, aber es gibt keinen Hinweis darauf, wie die Ausgabebittiefe eingestellt werden soll. Es gibt eine Option, --input-depth <integer> Specify input bit depth for raw inputaber nichts für die Ausgabebittiefe.

ffmpeg h.264 libx264 x264 stib
quelle
2
Ich habe folgendes gefunden: x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf Anscheinend erhalten Sie mit 10bit eine bessere Komprimierungseffizienz (Größe vs. Qualität). Ich könnte 10bit regelmäßig verwenden, wenn die Codierung nicht viel langsamer ist.
Peter Cordes

Antworten:

12

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

ffmpeg

Bei Verwendung können ffmpegSie 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 nicht mehr erforderlich. Weitere Informationen finden Sie unter Vereinheitlichen von 8-Bit- und 10-Bit-CLI und -Bibliotheken .

llogan
quelle
Verdammt, das macht die Sache kompliziert. Ich brauche 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?
Stib
Finden Sie sie hier, Sie werden: download.videolan.org/pub/x264/binaries Wenn Sie es selbst erstellen möchten, gibt es einen sehr langwierigen Prozess, der die Installation von mingw, yasm, git und gcc und viel Mist hier beinhaltet: doom10.org /index.php?topic=26.0 Aber ich konnte es nicht zum Laufen bringen, hauptsächlich wegen der dummen Unternehmensfirewall, die Git nicht zulässt.
Stib
Vielleicht können Sie Zeranoe dazu bringen, einen solchen Build bereitzustellen. Entschuldigung, ich bin ziemlich nutzlos, wenn es um Windows geht.
Llogan
Ich auch, das ist das Problem. Ich habe eine Build-Anfrage gepostet, wir werden sehen, wie es geht.
Stib
1
FWIW in diesen Tagen libx264 ist "beides", glaube ich ...
Rogerdpack
6

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

(Ultraschnelle und niedrige Qualität, da es sich um einen Proof of Concept handelt, nicht um einen Qualitätstest.) Ich 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 übereinstimmt. Dies --output-csp i444ist eigentlich hilfreich , wenn Sie nicht versehentlich möchten, dass x264 die Farbintensität herabsetzt . Es hat gut funktioniert, als ich ein paar Frames yuv444p14le.y4mmit 10-Bit-Ausgabe gespeist habe . (Es kann die Bittiefe abschneiden, aber die Farbintensität ohne swscale nicht herabsetzen.)

Zweiter Weg: Verwenden LD_LIBRARY_PATHSie diese Option, 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 etwas visuell zu sehen. Ich wollte nur, dass es schnell läuft und nicht viel Speicherplatz verschwendet, da ich beim Ausprobieren von Variationen immer viele Ausgabedateien erstelle.

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

Meine Quelle ist 48bit RGB. Ich fand, dass genaues_rnd keinen Einfluss auf die Ausgabe mkv hatte. (bitidentische Ergebnisse mit no -sws_flags, with -sws_flags +accurate_rndund -vf scale=flags=accurate_rnd, abgesehen von ein paar Bits im mkv-Header, wahrscheinlich der zufälligen mkv-UUID. Auch mit -qp 0, damit ich sie nicht durch Rundungsfehler verliere. cmp -l f1 f2 | lessum Binärdateien zu vergleichen, die die sein könnten Gleiches nach einem anfänglichen Unterschied. Oder ssdeep -p. Ist vielleicht accurate_rndjetzt die Standardeinstellung?)

Es gibt ein ffmpeg-swscaler-Flag, das wichtig ist, wenn Sie ffmpeg Ihr Chroma heruntersampeln lassen: lanczos anstelle des Standard-Bicubic. (Ich gehe davon aus, dass Lanczos immer noch als die beste Wahl für hohe Qualität angesehen wird? Ich habe eine Weile nicht gelesen.)

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 +lanczoszu -sws_flagsfunktioniert 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 mit der Bittiefe zu versorgen, für die es 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, intern muss x264 (die CLI) immer Pixelformate hochkonvertieren, der Code hat nicht 8-Bit-Eingänge, 10-Bit-Ausgangsversionen 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 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

Wenn keine pix_fmt angegeben ist, wählt ffmpeg, yuv444p10lewenn eine RGB-Eingabe erfolgt. Oder mit libx264rgbspeist es 8-Bit-RGB an Funktionen, die 16-Bit (von denen 10 signifikant sind) und Segfaults>. <Erwarten. 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 eine Umgebung mit zwei Bittiefen für ffmpeg oder ein anderes Programm zu erstellen, das Sie mit kompilierten Versionen von libx264, libx265 und allem anderen ausführen möchten . (Deshalb habe ich es "hohe Tiefe" genannt, nicht nur "10 Bit" für einen kürzeren Namen.)

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

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, sondern werden einer exakten Bitanordnung zugeordnet. Daher hat jede Kombination aus Format und Bittiefe einen anderen Namen. Ich denke, Sie hatten erwartet -pix_fmt yuv422p, "in der gleichen Bittiefe wie meine Eingabe in 422 konvertieren" zu bedeuten.

Wikipedia sagt, dass h.264 8-14 Bit Tiefe nur mit Hi444PP unterstützt, andere sind nur bis zu 10 Bit. Hi444PP ist das einzige Profil, das verlustfreie Vorhersagecodierung unterstützt, die x264 für -qp 0oder verwendet -crf 0. 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 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'Zeile.

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

Intern verwendet x264, das für eine hohe Bittiefe kompiliert wurde, 16 Bit / s zum Speichern von 10-Bit-Daten, sodass wahrscheinlich eine Bewegungssuche usw. mit 16-Bit-Werten durchgeführt wird. Und könnte DCT höher sein als 16 Bit anstatt 10 Bit, es sei denn, durch das Ignorieren von 6 Bit kann Geschwindigkeit gewonnen werden. Dies kann zu geringfügig anderen DCT-Koeffizienten führen, als wenn Sie vor der DCT auf 10 Bit abgerundet hätten. (Sie erhalten also möglicherweise eine andere Ausgabe, wenn Sie vor dem Einspeisen in x264 auf 10 Bit konvertieren, anstatt 12, 14 oder 16 Bit.) Ich sollte prob. Schauen Sie sich den Code an oder probieren Sie ihn aus, bevor Sie sich etwas ausdenken. Traue diesem Absatz nicht. : P.

(edit: ffmpeg speist x264-10bit nicht mehr als 10bit pro Komponente ein. Es wird swscale verwenden, um die Bittiefe selbst zu reduzieren.)

Ich frage mich, wie schwierig 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 libx264und die libx264rgbWrapper könnten dafür sorgen, dass die entsprechende Version der API abhängig vom Eingabestream aufgerufen wird. (Andernfalls benötigen Sie -c:v libx264-deepoder libx264rgb-deepfür insgesamt 4 verschiedene x264 "Codecs" in ffmpeg.)

Kompilieren von ffmpeg für Windows

Bearbeiten: Für Windows gibt es LD_LIBRARY_PATHmeines Erachtens nichts Bequemeres als für eine libx264-DLL. Daher ist es am besten, eine statische Binärdatei mit hoher Bittiefe und eine andere für den normalen Gebrauch zu erstellen. High-Depth Libx264 kann überhaupt keine normale Tiefe h.264 ausgeben. Nicht nur eine Geschwindigkeitsstrafe, es kann einfach nicht.

Der einfachste Weg, um 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-Computer (oder 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 ungefähr 8 Stunden für den ersten Lauf, da Mingw-Cross-Compile-GCC zusammen mit allem anderen aus dem Quellcode erstellt wurde. (gcc erstellt sich standardmäßig mehrmals neu, um Bootstrap zu erstellen, falls Sie es ursprünglich mit einem fehlerhaften Compiler kompiliert haben.)

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

Mein Linux-Desktop zeigt sein Alter. Ich habe ein Nintendo, das ich hauptsächlich für Spiele benutze. Seit ich angefangen habe, mit der Videokodierung herumzuspielen, finde ich die Quad-Core-Sandybridge auch dafür ziemlich nützlich, insb. für x265. Wahrscheinlich haben einige der Funktionen von x265 nur ASM-Versionen für AVX / SSE4, sodass auf meinem SSSE3-Linux-Computer (Conroe) auf C zurückgegriffen wird. Das oder es fällt bei 1fps deutlicher auf ...

Peter Cordes
quelle
Benachrichtigt stackexchange Personen, wenn ich Änderungen vornehme? einen Kommentar posten, falls dies nicht der Fall ist.
Peter Cordes
Dies ist unter OS X, wo dynamische Verknüpfungen verwendet werden, viel einfacher. Einfach brew reinstall x264 --with-10-bitund Sie sind fertig, ffmpeg wird die neue x264-Variante verwenden :)
Anzeigename
1
@SargeBorsch: Bei dieser Antwort ging es darum, beide Varianten gleichzeitig zu installieren, sodass Sie 8-Bit und 10-Bit vergleichen können, ohne die Bibliothek neu zu installieren. Die dynamische Verknüpfung mit OS X funktioniert fast genauso wie mit Linux, wo Sie Ihre libx264-Installation auf ähnliche Weise durch die andere Variante ersetzen können, wenn Sie möchten.
Peter Cordes
@ PeterCordes hmm, mein schlechtes. Sie haben Recht
Anzeigename