Eu acredito que libx264 agora é capaz de fazer codificações 4: 2: 2 de 10 bits, mas Não consigo fazer funcionar. Estou usando o ffmpeg (informações abaixo) e também tentei o codificador x264 diretamente. Já tentei

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

e isso produz uma boa saída 4: 2: 2, mas apenas em profundidade de 8 bits,

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

e eu tentei

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

e isso me dá o erro:

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 

Na documentação 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. 

Portanto, ele pode fazer 4: 2: 2 em profundidade de 10 bits e até 4: 4: 4 em 10 bits aparentemente, mas lá ” Não há indicação de como definir a profundidade de bits de saída. Existe uma opção --input-depth <integer> Specify input bit depth for raw input, mas nada para a profundidade de bits de saída.

Comentários

Resposta

x264 suporta saídas de 8 e 10 bits, e você não precisa fazer nada especial.

ffmpeg

Se usar ffmpeg, você pode ver quais formatos de pixel e profundidades de bits são compatíveis com libx264:

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

Os formatos de pixel de 10 bits são: yuv420p10le, yuv422p10le, yuv444p10le.

x264

Você também pode verificar x264 para profundidades de bits suportadas:

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

Anteriormente, você tinha que compilar x264 com --bit-depth=10 e, em seguida, vincule seu ffmpeg a uma libx264 de 8 ou 10 bits, mas isso agora é desnecessário. Consulte Unifique a CLI e as bibliotecas de 8 e 10 bits para obter mais informações.

Comentários

  • Droga, isso torna as coisas com plicado. Portanto, ‘ vou precisar de dois binários ffmpeg vinculados às duas bibliotecas x264. Você sabe se existem compilações estáticas do 10bit x264 em algum lugar?
  • Encontre-as aqui: download.videolan.org/pub/x264/binaries Se você quiser construí-lo sozinho, há um processo extremamente demorado que envolve a instalação do mingw, yasm, git e gcc e muita sujeira por aqui: doom10.org/ index.php? topic = 26.0 Mas não consegui ‘ fazê-lo funcionar, principalmente devido ao estúpido firewall corporativo que venceu ‘ t permitir git.
  • Talvez você possa obter o Zeranoe para fornecer tal compilação. Desculpe, eu ‘ sou bastante inútil quando se trata de Windows.
  • Eu também, que ‘ é o problema. Eu ‘ postei uma solicitação de compilação, ‘ veremos como funciona.
  • FWIW atualmente, libx264 é ” ambos ” Eu acredito …

Resposta

editar: fiz com sucesso uma codificação de 10 bits de Ducks Take Off .

Primeira maneira: Eu construí um binário x264 de 10 bits que liga estaticamente 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 e de baixa qualidade porque é uma prova de conceito, não um teste de qualidade.) I não compilou com swscale. (Fiquei insatisfeito com um pix fmt RGB na libavutil ou algo assim). Ocorre um erro se o espaço de cores de entrada não corresponder a --output-csp i444, o que é realmente bom se você não quiser acidentalmente reduzir a resolução do croma de x264. Funcionou bem quando alimentei alguns frames de yuv444p14le.y4m, produzindo uma saída de 10 bits. (Pode truncar a profundidade de bits, mas não reduzir o croma sem escala.)

Segunda maneira: use LD_LIBRARY_PATH para selecionar um libx264.so de 10 bits

Você pode usar o mesmo binário vinculado dinamicamente ffmpeg para tudo.

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 não tentei ver nada visualmente com essas configurações de qualidade. Eu só queria que executasse rápido e não desperdiçasse muito espaço em disco já que sempre acabo criando muitos arquivos de saída quando tento variações nas coisas.

Não canalizar os enormes dados y4m para um processo x264 separado fez com que fossem 14 fps em vez de 12, portanto, um aumento decente para ultrarrápido. Codificações mais lentas diminuirão essa sobrecarga.

Minha fonte é RGB de 48 bits. Descobri que o precisão_rnd não teve efeito no mkv de saída. (Resultados idênticos em bits sem -sws_flags, com -sws_flags +accurate_rnd e -vf scale=flags=accurate_rnd, exceto por alguns bits no cabeçalho mkv, provavelmente o UUID mkv aleatório. Mesmo com -qp 0, então eu não estava perdendo para o erro de arredondamento. cmp -l f1 f2 | less para comparar arquivos binários que podem ser os mesmos após alguma diferença inicial.Ou ssdeep -p. Talvez accurate_rnd seja o padrão agora?)

Há um sinalizador swscaler ffmpeg que importa, se você “está permitindo que o ffmpeg reduza a resolução do seu chroma: lanczos em vez do padrão bicúbico. (Presumo que lanczos ainda seja considerado a melhor escolha para alta qualidade? Não leu por um tempo.)

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

Adicionar +lanczos a -sws_flags não 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! 

Se você tentar inserir mais de 10 bits, o ffmpeg recusa.

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 

Na verdade, o driver libx264 do ffmpeg sempre insiste em alimentar o x264 exatamente a profundidade de bits para a qual é compilado. por exemplo, com -pix_fmt yuv420p:

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

x264.h diz:

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

Eu acho que internamente x264 (a CLI) sempre tem que converter formatos de pixel, o código não tem entrada de 8 bits, versões de saída de 10 bits de cada função . E também, acho que a aceitação de várias profundidades de bits de entrada ocorre apenas na CLI x264, não na API da biblioteca. Estou curioso para saber o que acontece quando você alimenta a entrada da API onde há bits mais altos definidos … (ffpeg não permite que você faça isso sem hackear o código, então isso não é algo que ninguém precisa se preocupar em 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 

Sem pix_fmt especificado, ffmpeg escolhe yuv444p10le quando recebe a entrada rgb. Ou com libx264rgb, ele alimenta 8 bits rgb para funções que esperam 16 bits (10 dos quais são significativos) e segfaults>. <. Eu” irei relatar que upstream …

 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) 

Vou relatar isso upstream.

De qualquer forma, descobri que foi muito fácil construir um ambiente dual-bit-depth para ffmpeg, ou qualquer outro programa que você deseja executar com versões compiladas de alta profundidade de bits de libx264, libx265, e qualquer outra coisa que você quiser. (É por isso que eu chamei de “highdepth”, não apenas “10 bits” para um nome mais curto.)

fim da edição: abaixo, aqui estão minhas divagações sem recompilar. E uma boa parte sobre como fazer a compilação cruzada de ffmpeg para win64

Tentei sozinho, já que você não tentou com um cmdline que tentava alimentar uma entrada de alta profundidade de bits para x264.

nomes de formato de pixel ffmpeg (ffmpeg -pix_fmts) não apenas especifique um arranjo, eles mapeiam para um arranjo de bits exato e, portanto, cada combinação de formato + profundidade de bits tem um nome diferente. Acho que você esperava que -pix_fmt yuv422p significasse “converter para 422 na mesma profundidade de bits da minha entrada”.

wikipedia diz que h.264 suporta profundidade de 8-14 bits apenas com Hi444PP, outros são de até 10 bits. Hi444PP é o único perfil que suporta codificação preditiva sem perdas, que x264 usa para -qp 0 ou -crf 0. editar: AFAICT, x264 ainda suporta apenas ser compilado para 8, 9 ou 10 bits.

De qualquer forma, aqui está um monte de saída inútil de um comando que não funciona porque eu não recompilei meu local x264. (Mas deve funcionar com x264 recompilado. Posso editar esta resposta se quiser brincar com ele sozinho.)

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) 

Observe a linha Incompatible pixel format "yuv420p10le" for codec "libx264", auto-selecting format "yuv420p".

Provavelmente eu não precisava -profile, e com um x264 de alta profundidade de bits, ele simplesmente funcionaria. (e possivelmente escolher 444 de 10 bits, que o ffmpeg chama de yuva444p10le.) Eu acho que x264 com profundidade de bits alta poderia aceitar yuv444p14le, mas ainda assim só produziria h.264 de 10 bits. O cmdline x264 --fullhelp é bastante explícito sobre a profundidade de bits de saída de 8 a 10, não superior. Estranho que -profile high10 seja silenciosamente ignorado por 8 bits x264.

Internamente, x264 compilado para alta profundidade de bits usa 16bpp para armazenar dados de 10 bits, então provavelmente faz movimento pesquisa e assim por diante com valores de 16 bits. E o DCT pode ser superior a 16 bits em vez de 10 bits, a menos que haja velocidade a ser ganha ao ignorar 6 bits. Isso pode produzir coeficientes DCT ligeiramente diferentes do que se arredondasse para 10 bits antes do DCT. (Assim, você pode obter resultados diferentes convertendo para 10 bits antes de alimentar x264, versus dar a ele 12, 14 ou 16 bits.) No entanto, devo examinar o código ou experimentá-lo antes de inventar coisas. Não confie neste parágrafo. : P

(editar: ffmpeg não alimenta x264-10bit nada mais do que 10 bits por componente. Ele usará swscale para reduzir a própria profundidade de bits.)

Eu me pergunto o quão difícil seria corrigir x264 e x265 para usar nomes diferentes para variáveis globais e funções API, quando compilados para alta profundidade de bits. Então, você poderia construir as duas versões de uma vez e ter ffmpeg vinculado a ambas. O ffmpeg libx264 e libx264rgb os wrappers poderiam se encarregar de chamar a versão apropriada da API dependendo do fluxo de entrada.(Caso contrário, você “d precisaria de -c:v libx264-deep ou libx264rgb-deep, para um total de 4 x264″ codecs “diferentes no ffmpeg.)

Como fazer compilação cruzada de ffmpeg para windows

editar: Para windows, não acho que haja algo tão conveniente quanto LD_LIBRARY_PATH para uma DLL libx264 , então sua melhor aposta ainda é construir um binário estático de alta profundidade de bits e outro para uso normal. A libx264 de alta profundidade PODE “T produzir a profundidade normal h.264 de todo. Não apenas uma penalidade de velocidade, ele simplesmente pode “t.

A maneira mais fácil de compilar seu próprio ffmpeg (binário estático) para Windows é com https://github.com/rdp/ffmpeg-windows-build-helpers . git clona o repo em uma máquina Linux (ou talvez outro sistema com um gcc funcionando, como OS X?) e execute

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

Isso levou cerca de 8 horas para a primeira execução, uma vez que construiu o GCC mingw-cross-compile a partir do código-fonte, junto com todo o resto. (o padrão do gcc é reconstruir a si mesmo vários vezes para inicializar, caso você o estivesse compilando originalmente com um compilador ruim.)

Você pode atualizar o script de compilação com git pull e executá-lo novamente extraia as últimas atualizações do git para ffmpeg, x264, x265 e talvez alguns dos outros projetos que compila a partir do código-fonte. (Para a maioria, ele apenas baixa tarballs.)

Meu desktop Linux está mostrando sua idade. um wintendo que eu uso principalmente para jogos. Desde que comecei a mexer com a codificação de vídeo, acho que seu quad-core Sandybrid ge muito útil para isso também, esp. para x265. Provavelmente, algumas das funções do x265 “s só têm versões ASM para AVX / SSE4, por isso está caindo para C na minha máquina SSSE3 Linux (Conroe). Isso ou é mais perceptível a 1 fps …

Comentários

  • O stackexchange notifica as pessoas quando eu faço edições? Postando um comentário caso isso não ‘ t.
  • isso é muito mais simples no OS X, onde a vinculação dinâmica é usada. Simplesmente brew reinstall x264 --with-10-bit e pronto, ffmpeg usará o novo sabor x264 🙂
  • @SargeBorsch: o objetivo desta resposta era ter os dois tipos instalados AO MESMO TEMPO, para que você possa comparar 8 bits e 10 bits sem reinstalar o biblioteca. A vinculação dinâmica do OS X funciona quase da mesma forma que o Linux ‘ s, onde você pode substituir a instalação do libx264 por outra versão, se desejar.
  • @PeterCordes hmm, que pena. Você está certo

Resposta

Baixei o ffmpeg do link https://sourceforge.net/projects/ffmpeg-hi/?source=typ_redirect

E digite o comando abaixo para criar 4: 2: 2 1 0bit h.264 arquivo:

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

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *