codificação 4: 2: 2 em 10 bits com libx264

9

Acredito que a libx264 agora é capaz de fazer codificações de 10 bits 4: 2: 2, mas não consigo fazê-la funcionar. Estou usando o ffmpeg (informações abaixo) e também tentei o codificador x264 diretamente. eu tentei

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

e isso produz uma saída agradável de 4: 2: 2, mas apenas com 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, encontro:

  --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 executar 4: 2: 2 na profundidade de 10 bits e até 4: 4: 4 em 10 bits, aparentemente, mas não há indicação de como definir a profundidade do bit de saída. Existe uma opção, --input-depth <integer> Specify input bit depth for raw inputmas nada para a profundidade de bits de saída.

stib
fonte
2
Achei o seguinte: x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf Aparentemente, você obtém uma melhor eficiência de compactação (tamanho versus qualidade) com 10 bits. Eu poderia começar a usar 10 bits regularmente, se não for muito mais lento para codificar.
Peter Cordes

Respostas:

12

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

ffmpeg

Se estiver usando, ffmpegvocê poderá ver quais formatos de pixel e profundidade de bits são suportados pela 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 x264as profundidades de bits suportadas:

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

Anteriormente, era necessário compilar o x264 --bit-depth=10e vincular o seu ffmpega uma libx264 de 8 ou 10 bits, mas isso agora é desnecessário. Consulte Unificar CLI e bibliotecas de 8 e 10 bits para obter mais informações.

llogan
fonte
Porra, isso torna as coisas complicadas. Então, precisarei de dois binários ffmpeg vinculados às duas bibliotecas x264. Você sabe se há construções estáticas do x264 de 10 bits em algum lugar?
Stib
Encontre-os aqui, você pode: download.videolan.org/pub/x264/binaries Se você quiser construí-lo, há um processo extenso e extenso que envolve a instalação de mingw, yasm, git e gcc e muitas coisas por aqui: doom10.org /index.php?topic=26.0 Mas não consegui fazê-lo funcionar, principalmente devido ao estúpido firewall corporativo que não permite o git.
Stib
Talvez você consiga que Zeranoe forneça essa compilação. Desculpe, sou bastante inútil no que diz respeito ao Windows.
Llogan
Eu também, esse é o problema. Publiquei uma solicitação de compilação, veremos como ela vai.
Stib
11
FWIW estes dias libx264 é "ambos" Eu acredito ...
rogerdpack
6

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

Primeira maneira: criei um binário x264 de 10 bits que vincula estaticamente a 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

(qualidade ultra-rápida e baixa, porque é uma prova de conceito, não um teste de qualidade.) Não o compilei com escala de sws. (Foi infeliz sobre um pix pix fmt no libavutil ou algo assim). Ele errará se o espaço de cores de entrada não corresponder --output-csp i444, o que é realmente bom se você não quiser acidentalmente reduzir a amostra x264 no chroma. Funcionou bem quando eu alimentei alguns quadros deyuv444p14le.y4m , produzindo uma saída de 10 bits. (Ele pode truncar a profundidade do bit, mas não reduz a amostra do croma sem escala de escala.)

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

Você pode usar o mesmo binário vinculado dinâmico 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 ele fosse rápido, e não desperdiçasse muito espaço em disco, pois eu sempre acabava criando muitos arquivos de saída ao tentar variações nas coisas.

O fato de não canalizar os enormes dados do y4m para um processo x264 separado fez com que ele ficasse em 14 fps em vez de 12, portanto, uma aceleração decente para ultra-rápido. Codificações mais lentas superam essa sobrecarga.

Minha fonte é 48bit RGB. Descobri que o preciso_rnd não teve efeito sobre a saída mkv. (resultados idênticos a bit com no -sws_flags, with -sws_flags +accurate_rnde -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 por erro de arredondamento. cmp -l f1 f2 | lesspara comparar arquivos binários que podem ser os mesmo depois de alguma diferença inicial. Ou ssdeep -ptalvez accurate_rndseja o padrão agora?)

Existe um sinalizador ffmpeg swscaler que importa, se você estiver deixando o ffmpeg reduzir a amostra do seu chroma: lanczos em vez do bicúbico padrão. (Presumo que os lanczos ainda sejam considerados a melhor opção para alta qualidade? Não leiam há 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 +lanczosa -sws_flagsnã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 alimentá-lo com 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 ele foi 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 precisa converter os formatos de pixel, o código não tem entrada de 8 bits, versões de saída de 10 bits de todas as funções. Além disso, acho que a aceitação de várias profundidades de bits de entrada está 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 maiores definidos ... (o ffpeg não permite que você faça isso sem hackear o código, portanto, isso não é algo que ninguém precise 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, o ffmpeg escolhe yuv444p10lequando recebe entrada rgb. Ou então libx264rgb, alimenta 8 bits rgb a funções que esperam 16 bits (10 das quais são significativas) e segfaults>. <. Vou reportar isso a montante ...

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

De qualquer forma, foi muito fácil criar um ambiente de profundidade de bit duplo para o ffmpeg, ou qualquer outro programa que você queira executar com versões compiladas de alta profundidade de libx264, libx265 e qualquer outra coisa que você queira . (Foi por isso que chamei de "profundidade profunda", não apenas "10 bits" para um nome mais curto.)

fim da edição: abaixo estão minhas divagações sem recompilar. E um pouco sobre como compilar o ffmpeg para o win64

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

Os nomes de formato de pixel ffmpeg ( ffmpeg -pix_fmts) não apenas especificam um arranjo, eles mapeiam para um arranjo exato de bits e, portanto, cada combinação de formato + profundidade de bits tem um nome diferente. Eu acho que você esperava -pix_fmt yuv422psignificar "converter para 422 na mesma profundidade de bits que minha entrada".

A wikipedia diz que o h.264 suporta profundidade de 8 a 14 bits apenas no Hi444PP, enquanto outros têm apenas 10 bits. Hi444PP é o único perfil que suporta codificação preditiva sem perdas, que o x264 usa para -qp 0ou -crf 0. edit: AFAICT, x264 ainda suporta apenas a compilação de 8, 9 ou 10 bits.

Enfim, aqui está um monte de saída inútil de um comando que não funciona porque eu não recompilei meu x264 local. (Mas deve funcionar com o x264 recompilado. Talvez eu edite esta resposta se quiser brincar com ela.)

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 Incompatible pixel format 'yuv420p10le' for codec 'libx264', auto-selecting format 'yuv420p'linha.

Provavelmente eu não precisava -profile, e com um x264 de alta profundidade de bits, funcionaria. (e, potencialmente, escolha 444 10 bits, que o ffmpeg chama yuva444p10le.) Acho que a profundidade de bits alta x264 poderia aceitar yuv444p14le, mas ainda produziria apenas 10 bits h.264. O cmdline x264 --fullhelpé bastante explícito sobre a profundidade do bit de saída de 8 a 10, e não mais. Estranho que -profile high10é silenciosamente ignorado por 8bit x264.

Internamente, o x264 compilado para alta profundidade de bits usa 16bpp para armazenar dados de 10 bits, por isso provavelmente faz pesquisa de movimento e assim por diante com valores de 16 bits. E pode DCT maior que 16 bits em vez de 10 bits, a menos que haja velocidade a ser obtida ao ignorar 6 bits. Isso pode produzir coeficientes de DCT ligeiramente diferentes do que se você arredondasse para 10 bits antes do DCT. (Portanto, você potencialmente obtém uma saída diferente da conversão para 10 bits antes de alimentar x264, em comparação com 12, 14 ou 16 bits.) Eu deveria tentar. veja o código ou tente antes de inventar coisas. Não confie neste parágrafo. : P

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

Gostaria de saber como seria difícil corrigir o x264 e o x265 para usar nomes diferentes para variáveis ​​globais e funções da API, quando compiladas para obter profundidade de bits alta. Em seguida, você pode criar as duas versões ao mesmo tempo e ter o ffmpeg vinculado a ambas. O ffmpeg libx264e os libx264rgbwrappers podem chamar a versão apropriada da API, dependendo do fluxo de entrada. (Caso contrário, você precisaria -c:v libx264-deepou libx264rgb-deep, para um total de 4 "codecs" x264 diferentes em ffmpeg.)

Como cruzar a compilação do ffmpeg para windows

edit: Para Windows, não acho que exista algo tão conveniente quanto LD_LIBRARY_PATHpara uma DLL libx264; portanto, sua melhor aposta ainda é criar um binário estático de alta profundidade de bits e outro para uso normal. A libx264 de alta profundidade NÃO PODE produzir a profundidade normal h.264. Não é apenas uma penalidade de velocidade, simplesmente não pode.

A maneira mais fácil de compilar seu próprio ffmpeg (binário estático) para o Windows é com https://github.com/rdp/ffmpeg-windows-build-helpers . O git clona o repositório em uma máquina Linux (ou talvez em outro sistema com um gcc ativo, como o OS X?), depois 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 ele criou o GCC mingw-cross-compile a partir da fonte, junto com todo o resto. (o gcc assume o padrão de se reconstruir várias vezes para iniciar, caso você o tenha compilado originalmente com um compilador incorreto.)

Você pode atualizar o script de construção git pulle, ao executá-lo, obterá as atualizações mais recentes do git para ffmpeg, x264, x265 e talvez alguns dos outros projetos que ele compila a partir do código-fonte. (Para a maioria, basta baixar tarballs.)

Minha área de trabalho Linux está mostrando sua idade. Eu tenho um wintendo que uso principalmente para jogos. Desde que comecei a mexer com a codificação de vídeo, acho o seu Sandybridge quad-core bastante útil para isso também. para x265. Provavelmente, algumas das funções do x265 possuem apenas versões ASM para AVX / SSE4, portanto, estão voltando ao C na minha máquina Linux SSSE3 (Conroe). Isso ou é mais perceptível a 1fps ...

Peter Cordes
fonte
O stackexchange notifica as pessoas quando eu faço edições? postando um comentário, caso contrário.
Peter Cordes
isso é muito mais simples no OS X, onde a ligação dinâmica é usada. Simplesmente brew reinstall x264 --with-10-bite pronto, o ffmpeg usará o novo sabor x264 :)
Nome de exibição
11
@ SargeBorsch: o objetivo desta resposta era instalar os dois tipos ao mesmo tempo, para que você possa comparar 8 bits e 10 bits sem reinstalar a biblioteca. A vinculação dinâmica do OS X funciona da mesma maneira que a do Linux, onde você pode substituir sua instalação da libx264 de maneira semelhante pelo outro, se desejar.
Peter Cordes
@PeterCordes hmm, meu mal. Você está certo
Nome de exibição