Je crois que libx264 est maintenant capable de faire des encodages 10 bits 4: 2: 2, mais Je ne parviens pas à le faire fonctionner. Jutilise ffmpeg (info ci-dessous), et jai également essayé directement lencodeur x264. Jai 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 jai essayé
ffmpeg.exe -i input.mov -c:v libx264 -profile:v high10 -crf 20 -pix_fmt yuv422p output.mp4
et cela me donne lerreur:
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 I find:
--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.
Donc, il peut faire 4: 2: 2 à 10 bits de profondeur, et même 4: 4: 4 à 10 bits apparemment, mais là » s aucune indication sur la façon de régler la profondeur de bits de sortie. Il existe une option --input-depth <integer> Specify input bit depth for raw input
mais rien pour la profondeur de bits de sortie.
Commentaires
- Jai 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 10 bits. Je pourrais commencer à utiliser le 10 bits régulièrement, sil nest ‘ que lencodage est beaucoup plus lent.
Réponse
x264 prend en charge les sorties 8 bits et 10 bits, et vous navez rien à faire de spécial.
ffmpeg
Si vous utilisez ffmpeg
, 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 x264
pour les profondeurs de bits prises en charge:
$ x264 --help [...] Output bit depth: 8/10
Auparavant, vous deviez compiler x264 avec --bit-depth=10
, puis associez votre ffmpeg
à une libx264 8 bits ou 10 bits, mais cela nest plus nécessaire. Voir Unifiez la CLI 8 bits et 10 bits et les bibliothèques pour plus dinformations.
Commentaires
- Bon sang, ça rend les choses com pliqué. Jai donc ‘ besoin de deux binaires ffmpeg liés aux deux bibliothèques x264. Savez-vous sil existe des versions statiques du 10 bits x264 nimporte où?
- Trouvez-les ici, vous allez: download.videolan.org/pub/x264/binaries Si vous voulez le construire vous-même, il existe un processus extrêmement long qui consiste à installer mingw, yasm, git et gcc et beaucoup de choses à faire ici: doom10.org/ index.php? topic = 26.0 Mais je nai pas pu ‘ le faire fonctionner, principalement à cause dun pare-feu dentreprise stupide qui a gagné ‘ t autorise git.
- Vous pouvez peut-être demander à Zeranoe de fournir une telle compilation. Désolé, je ‘ m assez inutile quand il sagit de Windows.
- Moi aussi, ce ‘ est le problème. Jai ‘ posté une demande de compilation, nous ‘ verrons comment ça se passe.
- FWIW ces jours-ci libx264 est » les deux » Je crois …
Réponse
edit: Jai réussi à encoder 10 bits de Ducks Take Off .
Première manière: Jai construit un binaire 10 bits x264 qui lie 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 cest une preuve de concept, pas un test de qualité.) I je ne lai pas compilé avec swscale. (Il était mécontent dun RVB pix fmt dans libavutil ou quelque chose du genre). Il se trompe si lespace de couleurs dentrée ne correspond pas à --output-csp i444
, ce qui est en fait bien si vous ne voulez pas avoir accidentellement x264 sous-échantillonner la chrominance. Cela a bien fonctionné lorsque je lui ai fourni quelques images de 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_PATH
pour sélectionner une libx264.so 10 bits
Vous pouvez utiliser le même binaire lié de manière 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.)
De toute évidence, je nai pas essayé de voir quoi que ce soit de manière visuelle avec ces paramètres de qualité. Je voulais juste quil fonctionne vite et ne gaspille pas beaucoup despace disque puisque je finis toujours par créer beaucoup de fichiers de sortie lorsque jessaye des variantes.
Ne pas acheminer les données massives y4m vers un processus x264 séparé le faisait passer à 14 ips au lieu de 12, donc une accélération décente pour lultra-rapide. Des encodages plus lents éclipseront cette surcharge.
Ma source est RVB 48 bits. Jai trouvé que precise_rnd navait aucun effet sur la sortie mkv. (Résultats identiques au bit sans -sws_flags
, avec -sws_flags +accurate_rnd
et -vf scale=flags=accurate_rnd
, à lexception de quelques bits dans len-tête mkv, probablement lUUID mkv aléatoire. Même avec -qp 0
, donc je ne lai pas perdu à cause dune erreur darrondi. cmp -l f1 f2 | less
pour comparer des fichiers binaires qui pourraient être les mêmes après une différence initiale.Ou ssdeep -p
. Peut-être que accurate_rnd
est la valeur par défaut maintenant?)
Il y a un drapeau ffmpeg swscaler qui compte, si vous « laissez ffmpeg sous-échantillonner votre chroma: lanczos au lieu de la valeur par défaut bicubic. (Je suppose que les lanczos sont toujours considérés comme le meilleur choix pour la haute qualité? Je nai pas lu pendant 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
Lajout de +lanczos
à -sws_flags
ne 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 lui donner une entrée supérieure à 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 alimenter exactement x264 la profondeur de bits pour laquelle il est 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 quen interne x264 (la CLI) doit toujours convertir les formats de pixels à la hausse, le code na pas dentrée 8 bits, les 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 lentrée de lAPI où il y a des bits plus élevés … (ffpeg ne vous permet pas de faire cela sans pirater le code, donc ce nest pas quelque chose que quiconque doit sinquié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
En labsence de pix_fmt spécifié, ffmpeg choisit yuv444p10le
lorsque lentrée rgb est donnée. Ou avec libx264rgb
, il alimente en RVB 8 bits des fonctions qui attendent 16 bits (dont 10 sont significatives) et des segfaults>. <. Je » vais le signaler 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 « vais le signaler en amont.
Quoi quil en soit, il sest avéré que cétait sacrément facile de me construire un environnement à double profondeur de bits pour ffmpeg, ou tout autre programme que vous souhaitez exécuter avec des versions compilées à haute profondeur de bits de libx264, libx265, et tout ce que vous voulez. (Cest pourquoi je lai appelé « highdepth », pas juste « 10 bits » pour un nom plus court.)
fin dédition: voici mes divagations sans recompilation. Et une bonne partie de la compilation croisée de ffmpeg pour win64
Jai essayé cela moi-même, car vous navez 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 simplement une disposition, ils correspondent à une disposition exacte de bits, et ainsi chaque combinaison format + profondeur de bits a un nom différent. Je pense que vous vous attendiez à ce que -pix_fmt yuv422p
signifie « convertir en 422 dans la même profondeur de bits que mon entrée ».
wikipedia indique que h.264 prend en charge la profondeur de 8 à 14 bits uniquement avec Hi444PP, dautres 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 0
ou -crf 0
. edit: AFAICT, x264 ne supporte toujours que la compilation pour 8, 9 ou 10 bits.
Quoi quil en soit, voici « un tas de sorties inutiles dune commande qui ne fonctionne pas parce que je nai pas » recompilé mon local x264. (Mais cela devrait fonctionner avec x264 recompilé. Je pourrais modifier cette réponse si je veux jouer avec moi-même.)
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 ligne Incompatible pixel format "yuv420p10le" for codec "libx264", auto-selecting format "yuv420p"
.
Je nai probablement pas besoin de -profile
, et avec une profondeur de bits x264 élevée, cela fonctionnerait. (et éventuellement choisir 444 10 bits, que ffmpeg appelle yuva444p10le
.) Je pense une profondeur de bits élevée x264 pourrait accepter yuv444p14le
, mais ne produirait toujours que 10 bits h.264. La cmdline x264 --fullhelp
est assez explicite sur la profondeur de bits de sortie de 8 à 10, pas plus. Bizarre que -profile high10
soit simplement ignoré en silence par 8 bits x264.
En interne, x264 compilé pour une profondeur de bits élevée utilise 16 bpp pour stocker des données 10 bits, donc il fait probablement du mouvement recherche et ainsi de suite avec des valeurs 16 bits. Et il se peut que le DCT soit supérieur à 16 bits plutôt quà 10 bits, à moins quil ne soit possible de gagner en vitesse en ignorant 6 bits. Cela pourrait produire des coefficients DCT légèrement différents de ceux arrondis à 10 bits avant DCT. (Vous obtiendrez donc potentiellement une sortie différente de la conversion en 10 bits avant dalimenter x264, contre 12, 14 ou 16 bits.) Je devrais probablement regarder le code ou lessayer avant de créer des trucs, cependant. Ne faites pas confiance à ce paragraphe. : P
(edit: ffmpeg ne va pas nourrir x264-10 bits plus de 10 bits par composant. Il utilisera swscale pour réduire la profondeur de bits lui-même.)
Je me demande à quel point ce serait de patcher x264 et x265 pour utiliser des noms différents pour les variables globales et les fonctions API, une fois compilées pour une profondeur de bits élevée. Ensuite, vous pouvez créer les deux versions à la fois et avoir ffmpeg lié aux deux. Le ffmpeg libx264
et libx264rgb
pourraient prendre soin dappeler la version appropriée de lAPI en fonction du flux dentrée.(Sinon, vous aurez besoin de -c:v libx264-deep
ou libx264rgb-deep
, pour un total de 4 « codecs » x264 différents dans ffmpeg.)
Comment faire une compilation croisée de ffmpeg pour Windows
edit: Pour Windows, je ne pense pas quil y ait quelque chose daussi pratique que LD_LIBRARY_PATH
pour une DLL libx264 , donc votre meilleur pari est toujours de construire un binaire statique à haute profondeur de bits, et un autre pour une utilisation normale. Libx264 haute profondeur CAN « T produit une profondeur normale h.264 du tout. Pas seulement une pénalité de vitesse, cela peut simplement « t.
Le moyen le plus simple de compiler votre propre ffmpeg (binaire statique) pour Windows est avec https://github.com/rdp/ffmpeg-windows-build-helpers . git clonez le dépôt sur une machine Linux (ou peut-être un autre système avec un gcc fonctionnel, comme OS X?), puis exécutez
./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 mingw-cross-compile GCC à partir des sources, avec tout le reste. (gcc par défaut se reconstruit plusieurs fois pour démarrer, au cas où vous le compiliez à lorigine avec un mauvais compilateur.)
Vous pouvez mettre à jour le script de construction avec git pull
, et le relancer tirez les dernières mises à jour de git pour ffmpeg, x264, x265, et peut-être certains des autres projets quil compile à partir des sources. (Pour la plupart, il ne fait que télécharger des archives tar.)
Mon bureau Linux montre son âge. Jai une Nintendo que jutilise principalement pour les jeux. Depuis que jai commencé à jouer avec lencodage vidéo, je trouve son quad-core Sandybrid ge assez utile pour ça aussi, en particulier. pour x265. Probablement certaines des fonctions de x265 nont que des versions asm pour AVX / SSE4, donc elles retombent en C sur ma machine Linux SSSE3 (Conroe). Cest ou cest plus visible à 1fps …
Commentaires
- Est-ce que stackexchange avertit les gens quand je fais des modifications? Publier un commentaire au cas où il ‘ t.
- cest beaucoup plus simple sous OS X, où la liaison dynamique est utilisée. Simplement
brew reinstall x264 --with-10-bit
et vous avez terminé, ffmpeg utilisera la nouvelle saveur x264 🙂 - @SargeBorsch: le but de cette réponse était davoir les deux saveurs installées EN MÊME TEMPS, donc vous pouvez comparer 8 bits et 10 bits sans réinstaller le La liaison dynamique OS X fonctionne à peu près de la même manière que les ‘ de Linux, où vous pouvez également remplacer votre installation libx264 par lautre version si vous le souhaitez.
- @PeterCordes hmm, mon mauvais. Vous avez raison
Réponse
Jai téléchargé le ffmpeg à partir du lien https://sourceforge.net/projects/ffmpeg-hi/?source=typ_redirect
Et entrez la commande ci-dessous pour créer 4: 2: 2 1 0bit h.264 fichier:
ffmpeg-hi10-heaac.exe -i "im.mp4" -c:v libx264 -pix_fmt yuv422p10le yuv-high-.ts