kodowanie 4: 2: 2 w 10-bitach za pomocą libx264

10

Wierzę, że libx264 jest teraz w stanie wykonywać 10-bitowe kodowanie 4: 2: 2, ale wydaje mi się, że nie mogę go uruchomić. Używam ffmpeg (informacje poniżej), a także bezpośrednio wypróbowałem koder x264. próbowałem

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

i to daje niezły wynik 4: 2: 2, ale tylko przy 8-bitowej głębokości,

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

i próbowałem

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

i to daje mi błąd:

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

W pełnej dokumentacji x264 znajduję:

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

Może więc wykonywać 4: 2: 2 przy 10-bitowej głębokości, a nawet 4: 4: 4 przy 10 bitach, ale nic nie wskazuje na to, jak ustawić wyjściową głębię bitową. Istnieje opcja, --input-depth <integer> Specify input bit depth for raw inputale brak głębokości wyjściowego bitu.

dźgnięcie
źródło
2
Znalazłem to: x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf Najwyraźniej masz lepszą wydajność kompresji (rozmiar w porównaniu do jakości) z 10bit. Mogę zacząć używać 10-bitów regularnie, jeśli kodowanie nie jest dużo wolniejsze.
Peter Cordes,

Odpowiedzi:

12

x264 obsługuje wyjścia 8-bitowe i 10-bitowe i nie musisz robić nic specjalnego.

ffmpeg

Jeśli używasz ffmpeg, możesz zobaczyć, jakie formaty pikseli i głębokości bitów są obsługiwane przez libx264:

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

10-bitowe formaty pikseli to: yuv420p10le, yuv422p10le, yuv444p10le.

x264

Możesz także sprawdzić x264obsługiwane głębokości bitów:

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

Wcześniej musiałeś skompilować x264 --bit-depth=10, a następnie połączyć ffmpeggo z 8-bitowym lub 10-bitowym libx264, ale teraz nie jest to konieczne. Zobacz Unify 8-i 10-bitowy interfejs CLI i biblioteki, aby uzyskać więcej informacji.

Llogan
źródło
Cholera, to komplikuje sprawy. Potrzebuję więc dwóch plików binarnych ffmpeg połączonych z dwiema bibliotekami x264. Czy wiesz, czy gdzieś są jakieś statyczne wersje 10-bitowej wersji x264?
stib
Znajdź je tutaj: download.videolan.org/pub/x264/binaries Jeśli chcesz zbudować go sam, istnieje bardzo długi, skomplikowany proces instalowania mingw, yasm, git i gcc oraz mnóstwo mucking tutaj: doom10.org /index.php?topic=26.0 Ale nie mogłem go uruchomić, głównie z powodu głupiej zapory korporacyjnej, która nie pozwala na git.
stib
Może uda ci się przekonać Zeranoe do stworzenia takiej wersji. Przepraszam, jestem dość bezużyteczny, jeśli chodzi o system Windows.
llogan
Ja też, to jest problem. Wysłałem prośbę o kompilację, zobaczymy jak będzie.
stib
1
FWIW w dzisiejszych czasach libx264 to „oba”, wierzę ...
rogerdpack
6

edycja: Z powodzeniem stworzyłem 10-bitowy kod Ducks Take Off .

Pierwszy sposób: zbudowałem 10-bitowy plik binarny x264, który statycznie łączy 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

(ultraszybka i niska jakość, ponieważ jest to dowód koncepcji, a nie test jakości.) Nie skompilowałem go za pomocą swscale. (Był niezadowolony z fmt RGB pix w libavutil czy coś takiego). Występuje błąd, jeśli wejściowa przestrzeń kolorów nie jest zgodna --output-csp i444, co jest naprawdę fajne, jeśli nie chcesz przypadkowo mieć próbki x264 próbkowania barwy. Działa dobrze, gdy nakarmiłem go kilkoma ramkami yuv444p14le.y4m, generując 10-bitowy sygnał wyjściowy. (Może obcinać głębię bitową, ale nie może próbkować koloru bez skalowania.)

Drugi sposób: użyj, LD_LIBRARY_PATHaby wybrać 10-bitowy plik libx264.so

Możesz użyć tego samego binarnego pliku dynamicznego ffmpeg do wszystkiego.

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

Oczywiście przy tych ustawieniach jakości nie próbowałem niczego widzieć wizualnie. Chciałem tylko, aby działał szybko i nie marnował dużo miejsca na dysku, ponieważ zawsze próbuję tworzyć różne wersje plików.

Brak przesyłania potokowych danych y4m do osobnego procesu x264 spowodował, że osiągnęło 14 fps zamiast 12, więc przyzwoite przyspieszenie dla ultraszybkiego. Wolniejsze kodowanie przyćmiewa ten nad głową.

Moje źródło to 48bit RGB. Odkryłem, że dokładny_rnd nie miał wpływu na wyjściowy mkv. (wyniki identyczne pod względem bitów bez -sws_flags, z -sws_flags +accurate_rnd, i -vf scale=flags=accurate_rnd, z wyjątkiem kilku bitów w nagłówku mkv, prawdopodobnie losowy UUID mkv. Nawet z -qp 0, więc nie straciłem go na błąd zaokrąglania. cmp -l f1 f2 | lessaby porównać pliki binarne, które mogą być to samo po początkowej różnicy. Lub ssdeep -p. Może accurate_rndteraz jest domyślna?)

Istnieje jedna flaga swscaler ffmpeg, która ma znaczenie, jeśli pozwalasz ffmpeg na próbkowanie swojego chroma: lanczos zamiast domyślnego bicubic. (Zakładam, że lanczos jest nadal uważane za najlepszy wybór dla wysokiej jakości? Nie czytałem od dłuższego czasu.)

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

Dodawanie +lanczosdo -sws_flagsnie działa:

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

Jeśli spróbujesz wprowadzić go głębiej niż 10 bitów, ffmpeg odmawia.

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

W rzeczywistości sterownik libx264 ffmpeg zawsze nalega na podawanie x264 dokładnie takiej głębokości bitowej, jaką jest skompilowane. np. z -pix_fmt yuv420p:

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

x264.h mówi:

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

Myślę, że wewnętrznie x264 (CLI) zawsze musi konwertować w górę formaty pikseli, kod nie ma wejścia 8-bitowego, wersje 10-bitowe każdej funkcji. Myślę też, że akceptowanie różnych głębokości bitów wejściowych odbywa się tylko w interfejsie CLI x264, a nie w interfejsie API biblioteki. Jestem ciekawy, co dzieje się, gdy podajesz dane wejściowe API, w których ustawiono wyższe bity ... (ffpeg nie pozwala ci tego zrobić bez włamania się do kodu, więc nie jest to coś, o co trzeba się martwić.)

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

Bez określonego pix_fmt, ffmpeg wybiera, yuv444p10lekiedy otrzyma dane wejściowe rgb. Lub za pomocą libx264rgb, przekazuje 8bit rgb do funkcji, które oczekują 16bit (z czego 10 jest znaczących) i segfaults>. <. Pójdę to zgłosić ...

 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)

Zgłoszę to na początku.

W każdym razie okazuje się, że zbudowanie środowiska podwójnej głębi dla ffmpeg lub dowolnego innego programu, który chcesz uruchomić, z wersjami libx264, libx265 i wszystkim innym, co chcesz, było łatwe. . (Dlatego nazwałem to „highdepth”, a nie „10bit” dla krótszej nazwy.)

koniec edycji: poniżej są moje wędrówki bez ponownej kompilacji. I sporo o tym, jak skompilować krzyżowo ffmpeg dla win64

Próbowałem tego sam, ponieważ nie próbowałeś z cmdline, która próbowała zasilić wejście x264 o wysokiej głębi bitowej.

Nazwy formatu pikseli ffmpeg ( ffmpeg -pix_fmts) nie tylko określają aranżację, lecz odwzorowują na dokładną aranżację bitów, dlatego też każda kombinacja format + głębia bitowa ma inną nazwę. Myślę, że miałeś -pix_fmt yuv422pna myśli „konwersję na 422 na tej samej głębokości bitów co moje wejście”.

wikipedia mówi, że h.264 obsługuje głębokość 8-14 bitów tylko z Hi444PP, inne mają jedynie 10 bitów. Hi444PP jest jedynym profilem obsługującym predykcyjne bezstratne kodowanie, którego x264 używa dla -qp 0lub -crf 0. edycja: AFAICT, x264 nadal obsługuje kompilację tylko dla 8, 9 lub 10 bitów.

W każdym razie, oto kilka bezużytecznych danych wyjściowych z polecenia, które nie działa, ponieważ nie skompilowałem mojego lokalnego x264. (Ale powinno działać z przekompilowanym x264. Mogę edytować tę odpowiedź, jeśli chcę się nią bawić).

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)

Zwróć uwagę na Incompatible pixel format 'yuv420p10le' for codec 'libx264', auto-selecting format 'yuv420p'linię.

Prawdopodobnie nie potrzebowałem -profile, a przy dużej głębi x264 to po prostu zadziałałoby. (i potencjalnie wybierz 444 10 bitów, które wywołuje ffmpeg yuva444p10le.) Myślę, że duża głębia bitów x264 mogłaby zaakceptować yuv444p14le, ale nadal produkowałaby tylko 10 bitów h.264. Cmdline x264 --fullhelpjest dość wyraźny na temat głębokości bitów wyjściowych od 8 do 10, nie więcej. Dziwne, które -profile high10jest po prostu dyskretnie ignorowane przez 8bit x264.

Wewnętrznie x264 skompilowany dla dużej głębi bitowej wykorzystuje 16 bpp do przechowywania dowolnych 10-bitowych danych, więc prawdopodobnie wykonuje wyszukiwanie ruchu i tak dalej z wartościami 16-bitowymi. I może DCT wyższy niż 16-bitowy, a nie 10-bitowy, chyba że można uzyskać szybkość ignorowania 6 bitów. Może to generować nieco inne współczynniki DCT niż w przypadku zaokrąglenia w dół do 10 bitów przed DCT. (Więc potencjalnie możesz uzyskać inną moc wyjściową z konwersji do 10 bitów przed karmieniem do x264, w porównaniu z dawaniem jej 12, 14 lub 16 bitów.) Powinienem sondować. spójrz na kod lub wypróbuj go, zanim coś wymyślisz. Nie ufaj temu ustępowi. : P

(edycja: ffmpeg nie przesyła x264-10bit niczego więcej niż 10 bitów na komponent. Użyje swscale do zmniejszenia samej głębi bitowej).

Zastanawiam się, jak trudno byłoby łatać x264 i x265, aby używać różnych nazw dla zmiennych globalnych i funkcji API, gdy są one kompilowane dla dużej głębi bitów. Następnie możesz zbudować obie wersje naraz i połączyć ffmpeg z obiema. Ffmpeg libx264i libx264rgbowijarki mogą zadbać o wywołanie odpowiedniej wersji interfejsu API w zależności od strumienia wejściowego. (W przeciwnym razie potrzebujesz -c:v libx264-deeplub libx264rgb-deep, w sumie, 4 różne „kodeki” x264 w ffmpeg.)

Jak krzyżować kompilację ffmpeg dla Windows

edycja: W przypadku systemu Windows nie wydaje mi się, aby istniało coś tak wygodnego, jak LD_LIBRARY_PATHw przypadku biblioteki DLL libx264, więc najlepszym rozwiązaniem jest zbudowanie statycznego pliku binarnego o dużej głębokości i innego do normalnego użytku. Libx264 o dużej głębokości w ogóle NIE może wyprowadzać normalnej głębokości h.264. Nie tylko kara prędkości, po prostu nie może.

Najprostszym sposobem na skompilowanie własnego pliku ffmpeg (statyczny plik binarny) dla systemu Windows jest https://github.com/rdp/ffmpeg-windows-build-helpers . git klonuje repozytorium na komputerze z systemem Linux (a może innym systemie z działającym gcc, takim jak OS X?), a następnie uruchom

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

Pierwsze uruchomienie zajęło około 8 godzin, ponieważ zbudowano GCC z kompilacją mingw-cross-source ze źródła, wraz ze wszystkim innym. (gcc domyślnie kilkakrotnie przebudowuje się, aby uruchomić bootstrap, na wypadek, gdybyś pierwotnie kompilował go za pomocą złego kompilatora).

Możesz zaktualizować skrypt kompilacji git pull, a jego ponowne uruchomienie spowoduje pobranie najnowszych aktualizacji git dla ffmpeg, x264, x265 i być może niektórych innych projektów, które kompiluje ze źródła. (Dla większości po prostu pobiera tarballi.)

Mój pulpit z systemem Linux pokazuje swój wiek. Mam wintendo, którego najczęściej używam do gier. Odkąd zacząłem bawić się w kodowanie wideo, uważam, że jego czterordzeniowy Sandybridge jest do tego bardzo przydatny, szczególnie. dla x265. Prawdopodobnie niektóre funkcje x265 mają tylko wersje asm dla AVX / SSE4, więc wracają do C na mojej maszynie SSSE3 Linux (Conroe). To lub bardziej zauważalne przy 1 klatce na sekundę ...

Peter Cordes
źródło
Czy Stackexchange powiadamia ludzi o wprowadzaniu zmian? publikowanie komentarza na wypadek, gdyby tak nie było.
Peter Cordes,
jest to o wiele prostsze w OS X, w którym stosuje się dynamiczne linkowanie. Po prostu brew reinstall x264 --with-10-biti gotowe, ffmpeg użyje nowego smaku x264 :)
Nazwa wyświetlana
1
@SargeBorsch: celem tej odpowiedzi było zainstalowanie obu smaków W TYM SAMYM CZASIE, abyś mógł porównać 8-bitowy i 10-bitowy bez ponownej instalacji biblioteki. Dynamiczne łączenie OS X działa prawie tak samo jak Linux, w którym możesz podobnie zastąpić instalację libx264 innym smakiem, jeśli chcesz.
Peter Cordes,
@PeterCordes hmm, mój zły. Masz rację
Nazwa wyświetlana