Uważam, że libx264 może teraz obsługiwać 10-bitowe kodowanie 4: 2: 2, ale Nie wydaje mi się, aby to działało. Używam ffmpeg (informacje poniżej), a także wypróbowałem bezpośrednio 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 ładne wyjście 4: 2: 2, ale tylko przy 8-bitowej głębi,

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

i już 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 dokumentacji 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. 

Więc może to zrobić 4: 2: 2 przy 10-bitowej głębi, a nawet 4: 4: 4 przy 10 bitach, ale tak ” Brak wskazówek, jak ustawić wyjściową głębię bitową. Jest opcja --input-depth <integer> Specify input bit depth for raw input, ale nie ma nic dla wyjściowej głębi bitowej.

Komentarze

Odpowiedź

x264 obsługuje zarówno 8-bitowe, jak i 10-bitowe wyjścia i nie musisz robić nic specjalnego.

ffmpeg

Jeśli używasz ffmpeg, możesz zobaczyć, jakie formaty pikseli i głębokości bitowe 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 zaznaczyć x264 dla obsługiwanych głębokości bitowych:

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

Wcześniej trzeba było skompilować x264 z --bit-depth=10, a następnie połącz swoje ffmpeg z 8-bitową lub 10-bitową biblioteką libx264, ale teraz jest to niepotrzebne. Zobacz Ujednolicić 8-bitowy i 10-bitowy interfejs CLI oraz biblioteki , aby uzyskać więcej informacji.

Komentarze

  • Cholera, to sprawia, że wszystko jest gotowe skomplikowany. Dlatego ' będę potrzebować dwóch plików binarnych ffmpeg połączonych z dwiema bibliotekami x264. Czy wiesz, czy gdziekolwiek istnieją statyczne kompilacje 10-bitowego x264?
  • Znajdziesz je tutaj: download.videolan.org/pub/x264/binaries Jeśli chcesz zbudować go samodzielnie, musisz wykonać bardzo długi i skomplikowany proces, w którym musisz zainstalować mingw, yasm, git i gcc, a także wiele innych rzeczy: doom10.org/ index.php? topic = 26.0 Ale nie mogłem ' nie uruchomić go, głównie z powodu głupiego korporacyjnego firewalla, który wygrał ' t zezwalaj na git.
  • Może uda ci się pobrać Zeranoe , aby zapewnić taką kompilację. Przepraszam, ' jestem dość bezużyteczny, jeśli chodzi o system Windows.
  • Tak, że ' jest problem. ' wysłałem żądanie kompilacji, ' zobaczymy, jak to działa.
  • FWIW obecnie libx264 jest ” oba ” Wierzę …

Odpowiedź

edycja: pomyślnie utworzyłem 10-bitowe kodowanie kaczki startujące .

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 

(ultraszybki i niskiej jakości, ponieważ jest to dowód koncepcji, a nie test jakości). nie skompilował go za pomocą swscale. (To było niezadowolone z powodu RGB pix fmt w libavutil lub coś w tym rodzaju). Wyświetla się błąd, jeśli wejściowa przestrzeń kolorów nie pasuje do --output-csp i444, co jest naprawdę fajne, jeśli nie chcesz przypadkowo próbować x264 w dół barwy. Działało dobrze, gdy podałem mu kilka ramek yuv444p14le.y4m, dając 10-bitowe wyjście. (Może obciąć głębię bitową, ale nie zmniejsza próbkowania barwy bez funkcji swscale.)

Drugi sposób: użyj LD_LIBRARY_PATH, aby wybrać 10-bitową bibliotekę libx264.so

Możesz użyć tego samego pliku binarnego połączonego dynamicznie 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 nie próbowałem nic zobaczyć wizualnie przy tych ustawieniach jakości. Chciałem tylko, aby działało szybko i nie marnowało dużo miejsca na dysku ponieważ zawsze robię dużo plików wyjściowych, próbując różnych rzeczy.

Brak przesyłania ogromnych danych y4m do oddzielnego procesu x264 sprawił, że osiągnęło 14 fps zamiast 12, więc przyzwoite przyspieszenie dla ultraszybkiego. Wolniejsze kodowanie przyćmiewa ten narzut.

Moje źródło to 48-bitowe RGB. Okazało się, że dokładny_rnd nie ma wpływu na wyjście mkv. (Identyczne bitowo wyniki 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 z losowym identyfikatorem UUID mkv. Nawet z -qp 0, więc nie straciłem go z powodu błędu zaokrąglania. cmp -l f1 f2 | less do porównania plików binarnych, które mogą być takie same po początkowej różnicy.Lub ssdeep -p. Może accurate_rnd jest teraz wartością domyślną?)

Jest jedna flaga swscaler ffmpeg, która ma znaczenie, jeśli „pozwalasz ffmpeg na próbkowanie chroma: lanczos zamiast domyślnej bicubic. (Zakładam, że lanczos jest nadal uważany za najlepszy wybór ze względu na wysoką jakość? Nie możesz czytać przez chwilę.)

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

Dodanie +lanczos do -sws_flags nie 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ć dane wejściowe głębiej niż 10 bitów, ffmpeg odmówi.

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łaściwie sterownik libx264 ffmpeg „s zawsze nalega na podanie dokładnie x264 głębokość bitowa, dla której została skompilowana, 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 8-bitowych wejść i 10-bitowych wersji wyjściowych każdej funkcji . I myślę , że akceptowanie różnych wejściowych głębokości bitowych jest tylko w CLI x264, a nie w API biblioteki. Ciekaw jestem, co się dzieje, gdy wprowadzasz dane wejściowe API, gdzie są ustawione wyższe bity … (ffpeg nie pozwala na zrobienie tego bez hakowania kodu, więc nie jest to coś, o co nikt nie powinien 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 parametru pix_fmt ffmpeg wybiera yuv444p10le, gdy ma dane wejściowe rgb. Lub z libx264rgb, dostarcza 8-bitowe rgb do funkcji, które oczekują 16-bitowego (z których 10 jest znaczących) i segfaults>. <. Zaraz zgłosimy to w górę …

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

W każdym razie, okazuje się, że zbudowanie własnej środowisko o podwójnej głębi bitowej dla ffmpeg lub dowolnego innego programu, który chcesz uruchomić ze skompilowanymi wersjami bibliotek libx264, libx265 i czegokolwiek innego, skompilowanymi z dużą głębią bitową. (Dlatego nazwałem to „highdepth”, a nie tylko „10 bitów” dla krótszej nazwy.)

koniec edycji: poniżej znajduje się moja wędrówka bez ponownej kompilacji. I trochę o tym, jak skompilować skrośnie ffmpeg dla win64

Próbowałem tego sam, ponieważ nie próbowałeś z linią cmd, która próbowała przekazać wejście o dużej głębi bitowej do x264.

Nazwy formatów pikseli ffmpeg (ffmpeg -pix_fmts) nie określają po prostu układu, odwzorowują one dokładny układ bitów, a zatem każda kombinacja format + głębia bitowa ma inną nazwę. Myślę, że spodziewałeś się, że -pix_fmt yuv422p będzie oznaczać „przekonwertowanie na 422 z taką samą głębią bitową jak moje dane wejściowe”.

wikipedia mówi, że h.264 obsługuje głębię 8-14 bitów tylko z Hi444PP, inne tylko do 10 bitów. Hi444PP to jedyny profil obsługujący predykcyjne kodowanie bezstratne, którego x264 używa dla -qp 0 lub -crf 0. edit: AFAICT, x264 nadal obsługuje kompilację tylko dla 8, 9 lub 10 bitów.

W każdym razie, tutaj jest kilka bezużytecznych danych wyjściowych polecenia, które nie działa, ponieważ nie skompilowałem ponownie 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 wiersz Incompatible pixel format "yuv420p10le" for codec "libx264", auto-selecting format "yuv420p".

Prawdopodobnie nie potrzebowałem -profile, a przy dużej głębi bitowej x264 to po prostu zadziała. (i potencjalnie wybierz 444 10-bitowe, które ffmpeg wywołuje yuva444p10le). Myślę, że duża głębia bitowa x264 może zaakceptować yuv444p14le, ale nadal produkowałby tylko 10-bitowy h.264. Linia cmd x264 --fullhelp dość wyraźnie określa wyjściową głębię bitową od 8 do 10, a nie wyższą. Dziwne, że -profile high10 jest po prostu cicho ignorowane przez 8-bitowe x264.

Wewnętrznie, x264 skompilowany dla dużej głębi bitowej używa 16bpp do przechowywania dowolnych 10-bitowych danych, więc prawdopodobnie wykonuje ruch wyszukiwanie i tak dalej z wartościami 16-bitowymi. I może DCT wyższe 16 bitów zamiast 10 bitów, chyba że można uzyskać prędkość ignorując 6 bitów. Może to spowodować nieco inne współczynniki DCT niż gdybyś zaokrąglił w dół do 10 bitów przed DCT. (Więc potencjalnie uzyskasz inny wynik z konwersji w dół do 10bit przed podaniem do x264, w porównaniu z 12, 14 lub 16 bitami.) Powinienem jednak spojrzeć na kod lub wypróbować go przed wymyśleniem. Nie ufaj temu paragrafowi. : P

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

Zastanawiam się, jak mocno byłoby łatką x264 i x265, aby używać różnych nazw dla zmiennych globalnych i funkcji API, po skompilowaniu w celu uzyskania dużej głębi bitowej. Następnie można zbudować obie wersje naraz i połączyć ffmpeg z nimi obiema. Funkcja ffmpeg libx264 i libx264rgb otoki mogą zadbać o wywołanie odpowiedniej wersji interfejsu API w zależności od strumienia wejściowego.(W przeciwnym razie „potrzebowałbyś -c:v libx264-deep lub libx264rgb-deep, łącznie 4 różne” kodeki „x264 w ffmpeg.)

Jak skompilować ffmpeg w systemie Windows

edycja: w przypadku systemu Windows nie wydaje mi się, aby było coś tak wygodnego jak LD_LIBRARY_PATH dla biblioteki DLL libx264 , więc najlepszym rozwiązaniem jest nadal zbudowanie statycznego pliku binarnego o dużej głębi bitowej i innego do normalnego użytku. Libx264 CAN o dużej głębi wyświetla w ogóle normalną głębokość h.264. Nie tylko ograniczenie szybkości, po prostu „t.

Najłatwiejszym sposobem skompilowania własnego ffmpeg (statycznego pliku binarnego) dla systemu Windows jest użycie https://github.com/rdp/ffmpeg-windows-build-helpers . git sklonować repozytorium na komputerze z systemem Linux (a może na innym systemie z działającym gcc, takim jak OS X?), a następnie uruchomić

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

Pierwsze uruchomienie zajęło około 8 godzin, ponieważ skompilował on mingw-cross-compile GCC ze źródeł, razem ze wszystkim innym. (gcc domyślnie odbudowuje się kilka razy do bootstrapu, na wypadek gdybyś kompilował go za pomocą złego kompilatora.)

Możesz zaktualizować skrypt kompilacji za pomocą git pull, a ponowne uruchomienie pobrać najnowsze aktualizacje 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 paczki z plikami).

Mój pulpit Linuksa pokazuje swój wiek. Mam a wintendo, którego używam głównie do gier. Odkąd zacząłem bawić się kodowaniem wideo, uważam, że czterordzeniowy Sandybrid do tego też całkiem przydatne, zwł. dla x265. Prawdopodobnie niektóre funkcje x265 mają tylko wersje ASM dla AVX / SSE4, więc na mojej maszynie SSSE3 Linux (Conroe) spada do C. To lub jest bardziej zauważalne przy 1 klatce na sekundę …

Komentarze

  • Czy stackexchange powiadamia ludzi, kiedy wprowadzam zmiany? Zamieszczając komentarz na wypadek, gdyby tak się stało nie ' t.
  • jest to o wiele prostsze w systemie OS X, gdzie używane jest dynamiczne łączenie. Po prostu brew reinstall x264 --with-10-bit i gotowe, ffmpeg użyje nowego smaku x264 🙂
  • @SargeBorsch: celem tej odpowiedzi było zainstalowanie obu smaków W TYM SAMYM CZASIE, więc możesz porównać 8bit i 10bit bez ponownej instalacji Biblioteka. Dynamiczne łączenie OS X działa prawie tak samo jak Linux ' s, gdzie w podobny sposób możesz zastąpić instalację libx264 innym smakiem, jeśli chcesz.
  • @PeterCordes hmm, moja wina. Masz rację

Odpowiedź

Pobrałem ffmpeg z linku https://sourceforge.net/projects/ffmpeg-hi/?source=typ_redirect

I wprowadził poniższe polecenie, aby utworzyć 4: 2: 2 1 0bit h.264 plik:

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

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *