encodage 4: 2: 2 en 10 bits avec libx264

9

Je crois que libx264 est maintenant capable de faire des encodages 10: 4: 2: 2, mais je n'arrive pas à le faire fonctionner. J'utilise ffmpeg (info ci-dessous), et j'ai également essayé directement l'encodeur x264. J'ai essayé

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

et cela produit une belle sortie 4: 2: 2, mais seulement à une profondeur de 8 bits,

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

et j'ai essayé

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

et cela me donne l'erreur:

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

Dans la documentation x264 --fullhelp, je trouve:

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

Il peut donc faire 4: 2: 2 à 10 bits de profondeur, et même 4: 4: 4 à 10 bits apparemment, mais il n'y a aucune indication sur la façon de définir la profondeur de bits de sortie. Il y a une option --input-depth <integer> Specify input bit depth for raw inputmais rien pour la profondeur de bits de sortie.

ffmpeg h.264 libx264 x264 stib
la source
2
J'ai trouvé ceci: x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf Apparemment, vous obtenez une meilleure efficacité de compression (taille vs qualité) avec 10bit. Je pourrais commencer à utiliser 10 bits régulièrement, s'il n'est pas beaucoup plus lent à encoder.
Peter Cordes

Réponses:

12

x264 prend en charge les sorties 8 bits et 10 bits, et vous n'avez rien à faire de spécial.

ffmpeg

Si ffmpegvous utilisez, vous pouvez voir quels formats de pixels et profondeurs de bits sont pris en charge par libx264:

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

Les formats de pixels 10 bits sont: yuv420p10le, yuv422p10le, yuv444p10le.

x264

Vous pouvez également vérifier x264les profondeurs de bits prises en charge:

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

Auparavant, vous deviez compiler x264 avec --bit-depth=10, puis lier votre ffmpegà une libx264 8 bits ou 10 bits, mais ce n'est désormais plus nécessaire. Voir Unify CLI 8 bits et 10 bits et bibliothèques pour plus d'informations.

llogan
la source
Merde, ça complique les choses. J'ai donc besoin de deux fichiers binaires ffmpeg liés aux deux bibliothèques x264. Savez-vous s'il existe des versions statiques du 10 bits x264 quelque part?
stib
Trouvez-les ici, vous pourrez: download.videolan.org/pub/x264/binaries Si vous voulez le construire vous-même, il y a un processus extrêmement long invitant à installer mingw, yasm, git et gcc et beaucoup de déblayage ici: doom10.org /index.php?topic=26.0 Mais je n'ai pas pu le faire fonctionner, principalement à cause d'un pare-feu d'entreprise stupide qui ne permet pas à git.
stib
Vous pouvez peut-être demander à Zeranoe de fournir une telle version. Désolé, je suis assez inutile en ce qui concerne Windows.
llogan
Moi aussi, c'est ça le problème. J'ai posté une demande de build, nous verrons comment ça se passe.
stib
1
FWIW ces jours-ci, libx264 est "les deux" je crois ...
rogerdpack
6

edit: J'ai réussi à faire un encodage 10 bits de Ducks Take Off .

Première façon: j'ai construit un binaire 10 bits x264 qui relie statiquement libx264.

cp -al x264-git x264-10bit  # instead of changing my normal git checkout
cd x264-10bit
./configure --extra-cflags=-march=native --enable-static --disable-interlaced --bit-depth=10
make -j2
sudo install x264 /usr/local/bin/x264-10bit

mkfifo pipe.y4m
ffmpeg -v verbose -i in -pix_fmt yuv420p10le -strict experimental -f yuv4mpegpipe pipe.y4m
   (open another shell window / tab / screen(1) window):
x264 pipe.y4m --crf 30 --preset ultrafast -o 10bit-420.mkv

(ultra rapide et de faible qualité car c'est une preuve de concept, pas un test de qualité.) Je ne l'ai pas compilé avec swscale. (Il était mécontent d'un fmt de pixels RVB dans libavutil ou quelque chose). Il génère des erreurs si l'espace colorimétrique d'entrée ne correspond pas --output-csp i444, ce qui est en fait bien si vous ne voulez pas accidentellement x264 sous-échantillonner la chrominance. Cela a bien fonctionné lorsque je l'ai alimenté en quelques images yuv444p14le.y4m, produisant une sortie 10 bits. (Il peut tronquer la profondeur de bits, mais pas sous-échantillonner la chrominance sans swscale.)

Deuxième méthode: utilisez LD_LIBRARY_PATHpour sélectionner une libx264.so 10 bits

Vous pouvez utiliser le même binaire lié dynamique ffmpeg pour tout. 

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

Évidemment, je n'ai pas essayé de voir quoi que ce soit visuellement avec ces paramètres de qualité. Je voulais juste qu'il fonctionne rapidement et ne gaspille pas beaucoup d'espace disque car je finis toujours par faire beaucoup de fichiers de sortie lorsque j'essaie de varier les choses.

Ne pas diriger les données massives y4m vers un processus x264 séparé l'a fait passer à 14 images par seconde au lieu de 12, donc une accélération décente pour ultra-rapide. Des encodages plus lents éclipseront cette surcharge.

Ma source est RVB 48 bits. J'ai trouvé que precise_rnd n'avait aucun effet sur la sortie mkv. (résultats identiques en bits avec non -sws_flags, avec -sws_flags +accurate_rndet -vf scale=flags=accurate_rnd, à l'exception de quelques bits dans l'en-tête mkv, probablement l'UUID mkv aléatoire. Même avec -qp 0, donc je ne le perdais pas en raison d'une erreur d'arrondi. cmp -l f1 f2 | lesspour comparer les fichiers binaires qui pourraient être le même après une différence initiale. Ou ssdeep -p. Peut accurate_rnd- être est-ce la valeur par défaut maintenant?)

Il y a un indicateur swfaler ffmpeg qui compte, si vous laissez ffmpeg sous-échantillonner votre chroma: lanczos au lieu du bicubique par défaut. (Je suppose que les lanczos sont toujours considérés comme le meilleur choix pour la haute qualité? Je n'ai pas lu depuis un moment.)

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

L'ajout +lanczosà -sws_flagsne fonctionne pas:

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

Si vous essayez de l'alimenter en entrée de plus de 10 bits, ffmpeg refuse.

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

En fait, le pilote libx264 de ffmpeg insiste toujours pour fournir à x264 exactement la profondeur de bits pour laquelle il a été compilé. par exemple avec -pix_fmt yuv420p:

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

x264.h dit:

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

Je pense qu'en interne, x264 (CLI) doit toujours convertir les formats de pixels, le code n'a pas d'entrée 8 bits, versions de sortie 10 bits de chaque fonction. Et aussi, je pense que l'acceptation de différentes profondeurs de bits d'entrée se fait uniquement dans la CLI x264, pas dans l'API de la bibliothèque. Je suis curieux de savoir ce qui se passe lorsque vous alimentez l'entrée API où des bits plus élevés sont définis ... (ffpeg ne vous permet pas de le faire sans pirater le code, donc ce n'est pas quelque chose que personne ne doit s'inquiéter d'éviter).

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

Sans pix_fmt spécifié, ffmpeg choisit yuv444p10lelorsqu'il reçoit une entrée rgb. Ou avec libx264rgb, il alimente 8 bits rgb aux fonctions qui attendent 16 bits (dont 10 sont significatifs), et segfaults>. <. Je vais rapporter ça en amont ...

 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)

Je signalerai cela en amont.

Quoi qu'il en soit, il s'est avéré qu'il était assez facile de me créer un environnement à double profondeur de bit pour ffmpeg ou tout autre programme que vous souhaitez exécuter avec des versions compilées à haute profondeur de libx264, libx265 et tout ce que vous voulez . (C'est pourquoi je l'ai appelé "highdepth", pas seulement "10bit" pour un nom plus court.)

fin du montage: ci-dessous voici mes divagations sans recompilation. Et un peu sur la façon de compiler de manière croisée ffmpeg pour win64

J'ai essayé cela moi-même, car vous n'avez pas essayé avec une cmdline qui a essayé de fournir une entrée à haute profondeur de bits à x264.

Les noms de format de pixel ffmpeg ( ffmpeg -pix_fmts) ne spécifient pas seulement un arrangement, ils sont mappés sur un arrangement de bits exact, et donc chaque combo format + profondeur de bits a un nom différent. Je pense que vous vous attendiez -pix_fmt yuv422pà dire "convertir en 422 dans la même profondeur de bits que mon entrée".

wikipedia indique que le h.264 prend en charge la profondeur de 8-14 bits uniquement avec Hi444PP, d'autres ne sont que jusqu'à 10 bits. Hi444PP est le seul profil qui prend en charge le codage prédictif sans perte, que x264 utilise pour -qp 0ou -crf 0. edit: AFAICT, x264 ne supporte toujours que la compilation pour 8, 9 ou 10 bits.

Quoi qu'il en soit, voici un tas de sorties inutiles d'une commande qui ne fonctionne pas car je n'ai pas recompilé mon x264 local. (Mais cela devrait fonctionner avec les x264 recompilés. Je pourrais éditer cette réponse si je veux jouer avec.)

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)

Notez la Incompatible pixel format 'yuv420p10le' for codec 'libx264', auto-selecting format 'yuv420p'ligne.

Je n'en avais probablement pas besoin -profile, et avec un x264 à profondeur de bits élevée, cela fonctionnerait tout simplement. (et potentiellement choisir 444 10 bits, que ffmpeg appelle yuva444p10le.) Je pense que la profondeur de bits élevée x264 pourrait accepter yuv444p14le, mais ne produirait tout de même que 10 bits h.264. La ligne de commande x264 --fullhelpest assez explicite sur la profondeur de bits de sortie de 8 à 10, pas plus. Étrange qui -profile high10est juste silencieusement ignoré par 8 bits x264.

En interne, x264 compilé pour une profondeur de bits élevée utilise 16 bpp pour stocker toutes les données 10 bits, il effectue donc probablement une recherche de mouvement et ainsi de suite avec des valeurs 16 bits. Et le DCT pourrait être supérieur à 16 bits plutôt qu'à 10 bits, à moins qu'il n'y ait de la vitesse à gagner en ignorant 6 bits. Cela pourrait produire des coefficients DCT légèrement différents que si vous arrondissiez à 10 bits avant DCT. (Donc, vous obtenez potentiellement une sortie différente de la conversion en 10 bits avant de l'alimenter en x264, par rapport à 12, 14 ou 16 bits.) Je devrais essayer. regardez le code ou essayez-le avant de faire des trucs, cependant. Ne faites pas confiance à ce paragraphe. : P

(edit: ffmpeg n'alimentera pas x264-10bit plus de 10 bits par composant. Il utilisera swscale pour réduire la profondeur de bits elle-même.)

Je me demande à quel point il serait difficile de patcher x264 et x265 pour utiliser des noms différents pour les variables globales et les fonctions API, une fois compilés pour une grande profondeur de bits. Ensuite, vous pouvez créer les deux versions à la fois et avoir ffmpeg lié aux deux. Le ffmpeg libx264et les libx264rgbwrappers pourraient prendre soin d'appeler la version appropriée de l'API en fonction du flux d'entrée. (Sinon, vous auriez besoin -c:v libx264-deepou libx264rgb-deep, pour un total de 4 "codecs" x264 différents dans ffmpeg.)

Comment croiser compiler ffmpeg pour Windows

edit: Pour Windows, je ne pense pas qu'il y ait quelque chose d'aussi pratique que LD_LIBRARY_PATHpour une DLL libx264, donc votre meilleur pari est toujours de construire un binaire statique à grande profondeur de bits, et un autre pour une utilisation normale. La libx264 haute profondeur NE PEUT PAS produire de profondeur normale h.264. Pas seulement une pénalité de vitesse, cela ne peut tout simplement pas.

La façon la plus simple de compiler votre propre ffmpeg (binaire statique) pour Windows est avec https://github.com/rdp/ffmpeg-windows-build-helpers . git clone le dépôt sur une machine Linux (ou peut-être un autre système avec un gcc fonctionnel, comme OS X?), puis lancez

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

Cela a pris environ 8 heures pour la première exécution, car il a construit le GCC mingw-cross-compile à partir de la source, avec tout le reste. (gcc par défaut se reconstruit plusieurs fois pour démarrer, au cas où vous le compiliez à l'origine avec un mauvais compilateur.)

Vous pouvez mettre à jour le script de construction avec git pull, et le relancer tirera les dernières mises à jour git pour ffmpeg, x264, x265, et peut-être certains des autres projets qu'il compile à partir de la source. (Pour la plupart, il télécharge simplement les archives tar.)

Mon bureau Linux montre son âge. J'ai une Nintendo que j'utilise principalement pour les jeux. Depuis que j'ai commencé à jouer avec l'encodage vidéo, je trouve son Sandybridge quadricœur assez utile pour cela aussi, en particulier. pour x265. Probablement, certaines des fonctions de x265 n'ont que des versions asm pour AVX / SSE4, donc elles retombent en C sur ma machine Linux SSSE3 (Conroe). Cela ou c'est plus visible à 1fps ...

Peter Cordes
la source
Stackexchange informe-t-il les gens lorsque j'effectue des modifications? poster un commentaire au cas où il ne le ferait pas.
Peter Cordes
c'est beaucoup plus simple sous OS X, où la liaison dynamique est utilisée. Simplement brew reinstall x264 --with-10-bitet vous avez terminé, ffmpeg utilisera la nouvelle saveur x264 :)
Nom d'affichage
1
@SargeBorsch: le point de cette réponse était d'avoir les deux versions installées EN MÊME TEMPS, afin que vous puissiez comparer 8 bits et 10 bits sans réinstaller la bibliothèque. La liaison dynamique OS X fonctionne à peu près de la même manière que Linux, où vous pouvez également remplacer votre installation libx264 par l'autre version si vous le souhaitez.
Peter Cordes
@PeterCordes hmm, mon mauvais. Vous avez raison
Afficher le nom