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

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

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

x264 [error]: high10 profile doesn"t support 4:2:2 [libx264 @ 00000000051ead60] Error setting profile high10. [libx264 @ 00000000051ead60] Possible profiles: baseline main high high10 high422 high444 

 --profile <string> Force the limits of an H.264 profile Overrides all settings. [...] - high10: No lossless. Support for bit depth 8-10. - high422: No lossless. Support for bit depth 8-10. Support for 4:2:0/4:2:2 chroma subsampling. - high444: Support for bit depth 8-10. Support for 4:2:0/4:2:2/4:4:4 chroma subsampling. 

x264 admite salidas de 8 y 10 bits, y no tienes que hacer nada especial.

ffmpeg

Si usa ffmpeg, puede ver qué formatos de píxeles y profundidades de bits son compatibles con libx264:

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

Los formatos de píxeles de 10 bits son: yuv420p10le, yuv422p10le, yuv444p10le.

x264

También puede marcar x264 para profundidades de bits admitidas:

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

Anteriormente, tenía que compilar x264 con --bit-depth=10, y luego vincule su ffmpeg a una libx264 de 8 o 10 bits, pero ahora no es necesario. Consulte Unifique las bibliotecas y la CLI de 8 y 10 bits para obtener más información.

Comentarios

• Maldita sea, eso hace que las cosas plegado. Entonces ‘ necesitaré dos binarios ffmpeg vinculados a las dos bibliotecas x264. ¿Sabes si hay compilaciones estáticas del x264 de 10 bits en algún lugar?
• Encuéntralas aquí: download.videolan.org/pub/x264/binaries Si quieres construirlo tú mismo, hay un proceso enormemente largo que implica la instalación de mingw, yasm, git y gcc y un montón de basura por aquí: doom10.org/ index.php? topic = 26.0 Pero no pude ‘ hacer que funcionara, principalmente debido al estúpido firewall corporativo que ganó ‘ t permite git.
• Tal vez puedas obtener Zeranoe para proporcionar dicha compilación. Lo siento, ‘ soy bastante inútil cuando se trata de Windows.
• Yo también, que ‘ es el problema. ‘ he publicado una solicitud de compilación, ‘ veremos cómo va.
• FWIW estos días libx264 es » ambos » Creo …

editar: Hice con éxito una codificación de 10 bits de Ducks Take Off .

Primera forma: Construí un binario x264 de 10 bits que enlaza estáticamente 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 

(ultrarrápido y de baja calidad porque es una prueba de concepto, no una prueba de calidad). no lo compilé con swscale. (No estaba contento con un formato de imagen RGB en libavutil o algo así). Se produce un error si el espacio de color de entrada «no coincide con --output-csp i444, lo cual es realmente bueno si no desea tener una disminución x264 accidental del croma. Funcionó bien cuando le di algunos fotogramas de yuv444p14le.y4m, produciendo una salida de 10 bits. (Puede truncar la profundidad de bits, pero no reducir el croma sin escala de escala.)

Segunda forma: use LD_LIBRARY_PATH para seleccionar una libx264.so de 10 bits

Puede usar el mismo binario vinculado dinámicamente ffmpeg para todo.

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

Obviamente no traté de ver nada visualmente con esa configuración de calidad. Solo quería que se ejecutara rápido y no desperdiciara un montón de espacio en disco ya que siempre termino creando muchos archivos de salida cuando intento variaciones de cosas.

No canalizar los datos masivos de y4m a un proceso x264 separado hizo que fueran 14 fps en lugar de 12, por lo que una aceleración decente para ultrarrápido. Las codificaciones más lentas empequeñecerán esa sobrecarga.

Mi fuente es RGB de 48 bits. Descubrí que exact_rnd no tenía ningún efecto en la salida mkv. (Resultados idénticos en bits sin -sws_flags, con -sws_flags +accurate_rnd y -vf scale=flags=accurate_rnd, excepto por algunos bits en el encabezado mkv, probablemente el UUID mkv aleatorio. Incluso con -qp 0, por lo que no lo estaba perdiendo por un error de redondeo. cmp -l f1 f2 | less para comparar archivos binarios que podrían ser iguales después de alguna diferencia inicial.O ssdeep -p. ¿Quizás accurate_rnd sea el predeterminado ahora?)

Hay un indicador ffmpeg swscaler que importa, si está permitiendo que ffmpeg reduzca la resolución de su croma: lanczos en lugar del predeterminado bicúbico. (¿Asumo que lanczos todavía se considera la mejor opción para alta calidad? No he leído por un tiempo).

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

Agregar +lanczos a -sws_flags no funciona:

[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 intenta alimentarlo con una entrada de más de 10 bits, ffmpeg se niega.

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 realidad, el controlador libx264 de ffmpeg siempre insiste en alimentar x264 exactamente la profundidad de bits para la que está compilado. Por ejemplo, con -pix_fmt yuv420p:

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

x264.h dice:

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

Creo que internamente x264 (la CLI) siempre tiene que convertir formatos de píxeles, el código no tiene entrada de 8 bits, versiones de salida de 10 bits de cada función . Y también, creo que la aceptación de varias profundidades de bits de entrada está solo en la CLI x264, no en la API de la biblioteca. Tengo curiosidad por saber qué sucede cuando alimenta la entrada de la API donde hay bits más altos establecidos … (ffpeg no le permite hacer esto sin piratear el código, por lo que esto no es algo que nadie deba preocuparse por evitar).

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 

Sin pix_fmt especificado, ffmpeg elige yuv444p10le cuando se le proporciona una entrada rgb. O con libx264rgb, alimenta rgb de 8 bits a funciones que esperan 16 bits (10 de las cuales son significativas) y segfaults>. <. Voy a informar que …

 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) 

Lo informaré en sentido ascendente.

De todos modos, resulta que fue bastante fácil construirme un entorno de doble profundidad de bits para ffmpeg, o cualquier otro programa que desee ejecutar con versiones compiladas de alta profundidad de bits de libx264, libx265 y cualquier otra cosa que desee. (Por eso lo llamé «highdepth», no sólo «10 bits» para un nombre más corto.)

fin de la edición: a continuación, aquí están mis divagaciones sin recompilar. Y un poco sobre cómo realizar una compilación cruzada de ffmpeg para win64

Lo intenté yo mismo, ya que no lo intentó con una línea de cmd que intentaba alimentar una entrada de alta profundidad de bits a x264.

Los nombres de formato de píxel de ffmpeg (ffmpeg -pix_fmts) no solo especifican una disposición, se asignan a una disposición de bits exacta y, por lo tanto, cada combinación de formato + profundidad de bits tiene un nombre diferente. Creo que esperabas que -pix_fmt yuv422p significara «convertir a 422 en la misma profundidad de bits que mi entrada».

wikipedia dice que h.264 admite una profundidad de 8-14 bits solo con Hi444PP, otros solo son de hasta 10 bits. Hi444PP es el único perfil que admite la codificación predictiva sin pérdidas, que x264 usa para -qp 0 o -crf 0. editar: AFAICT, x264 todavía solo admite la compilación para 8, 9 o 10 bits.

De todos modos, aquí hay un montón de resultados inútiles de un comando que no funciona porque no recompillé mi x264. (Pero debería funcionar con x264 recompilado. Podría editar esta respuesta si quiero jugar con él).

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) 

Tenga en cuenta la línea Incompatible pixel format "yuv420p10le" for codec "libx264", auto-selecting format "yuv420p".

Probablemente no necesitaba -profile, y con un x264 de alta profundidad de bits, simplemente funcionaría. (y potencialmente elegir 444 de 10 bits, que ffmpeg llama yuva444p10le). Yo creo alta profundidad de bits x264 podría aceptar yuv444p14le, pero aún produciría 10 bits h.264. La cmdline x264 --fullhelp es bastante explícita sobre la profundidad de bits de salida de 8 a 10, no más alta. Es extraño que -profile high10 sea ignorado silenciosamente por el x264 de 8 bits.

Internamente, x264 compilado para una alta profundidad de bits usa 16bpp para almacenar cualquier dato de 10 bits, por lo que probablemente hace movimiento búsqueda y así sucesivamente con valores de 16 bits. Y podría DCT más alto de 16 bits en lugar de 10 bits, a menos que se pueda ganar velocidad al ignorar 6 bits. Esto podría producir coeficientes de DCT ligeramente diferentes que si redondeara a 10 bits antes de DCT. (Por lo tanto, puede obtener una salida diferente al convertir a 10 bits antes de alimentar a x264, frente a darle 12, 14 o 16 bits.) Sin embargo, debería mirar el código o intentarlo antes de inventar cosas. No confíe en este párrafo. : P

(editar: ffmpeg no alimentará x264-10bit más de 10 bits por componente. Utilizará swscale para reducir la profundidad de bits en sí.)

Me pregunto qué tan difícil sería parchear x264 y x265 para usar diferentes nombres para las variables globales y las funciones de API, cuando se compile para una alta profundidad de bits. Luego, podría compilar ambas versiones a la vez y vincular ffmpeg con ambas. El ffmpeg libx264 y libx264rgb podrían encargarse de llamar a la versión apropiada de la API según el flujo de entrada.(De lo contrario, «necesitaría -c:v libx264-deep o libx264rgb-deep, para un total de 4″ códecs «x264 diferentes en ffmpeg).

Cómo realizar una compilación cruzada de ffmpeg para Windows

editar: Para Windows, no creo que haya nada tan conveniente como LD_LIBRARY_PATH para una DLL libx264 , por lo que lo mejor es crear un binario estático de alta profundidad de bits y otro para uso normal. Libx264 CAN «T de alta profundidad produce una profundidad normal h.264 en absoluto. No solo una penalización de velocidad, simplemente no puede «t.

La forma más fácil de compilar su propio ffmpeg (binario estático) para Windows es con https://github.com/rdp/ffmpeg-windows-build-helpers . git clona el repositorio en una máquina Linux (¿o tal vez en otro sistema con un gcc funcional, como OS X?), luego ejecuta

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

Esto tomó alrededor de 8 horas para la primera ejecución, ya que compiló mingw-cross-compile GCC desde la fuente, junto con todo lo demás. (gcc por defecto para reconstruirse a sí mismo varias veces para arrancar, en caso de que originalmente lo estuviera compilando con un compilador incorrecto).

Puede actualizar el script de compilación con git pull, y volver a ejecutarlo extraer las últimas actualizaciones de git para ffmpeg, x264, x265, y tal vez algunos de los otros proyectos que compila desde la fuente. (Para la mayoría, solo descarga archivos tar).

Mi escritorio Linux muestra su antigüedad. Tengo un wintendo que utilizo principalmente para juegos. Desde que comencé a jugar con la codificación de video, encuentro su Sandybrid de cuatro núcleos También es muy útil para eso, especialmente. para x265. Probablemente, algunas de las funciones de x265 sólo tienen versiones ASM para AVX / SSE4, por lo que recurre a C en mi máquina Linux SSSE3 (Conroe). Eso o es más notorio a 1 fps …

Comentarios

• ¿Stackexchange notifica a las personas cuando hago ediciones? Publicando un comentario en caso de que doesn ‘ t.
• esto es mucho más simple en OS X, donde se usa la vinculación dinámica. Simplemente brew reinstall x264 --with-10-bit y ya está, ffmpeg usará el nuevo sabor x264 🙂
• @SargeBorsch: el objetivo de esta respuesta era tener ambos sabores instalados AL MISMO TIEMPO, para que pueda comparar 8 bits y 10 bits sin reinstalar el La vinculación dinámica de OS X funciona prácticamente igual que Linux ‘ s, donde podría reemplazar de manera similar su instalación de libx264 con la otra versión si lo desea.
• @PeterCordes hmm, mi culpa. Tienes razón

Descargué el ffmpeg del enlace https://sourceforge.net/projects/ffmpeg-hi/?source=typ_redirect

E ingresó el siguiente comando para crear 4: 2: 2 1 0bit h.264 archivo:

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