Úgy gondolom, hogy a libx264 mostantól képes 10 bites 4: 2: 2 kódolásra, de Úgy tűnik, hogy nem sikerül működni. Az ffmpeg-et (információ lent) használom, és az x264 kódolót is kipróbáltam közvetlenül. Megpróbáltam 

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

és ez szép 4: 2: 2 kimenetet eredményez, de csak 8 bites mélységben, 

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

és megpróbáltam 

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

és ez adja a hibát: 

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

Az x264 –fullhelp dokumentációjában 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.

Tehát 10: 4 mélységben 4: 2: 2, és 10 bitnél 4: 4: 4 látszólag is képes, de ott ” s nincs utalás a kimeneti bitmélység beállítására. Van egy opció --input-depth <integer> Specify input bit depth for raw input, de a kimeneti bitmélységhez semmi.

Megjegyzések

Válasz

x264 egyaránt támogatja a 8 bites és a 10 bites kimeneteket, és nem kell semmi különöset tennie.

ffmpeg

A ffmpeg használatakor láthatja, hogy a libx264 milyen képpontformátumokat és bites mélységeket támogat: 

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

A 10 bites képpontformátumok a következők: yuv420p10le, yuv422p10le, yuv444p10le.

x264

A x264 a támogatott bitmélységekhez: 

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

Korábban le kellett fordítanod az x264-et a --bit-depth=10, majd kapcsolja a ffmpeg fájlt egy 8 vagy 10 bites libx264-hez, de ez most felesleges. Lásd: Egyesítse a 8-bites és 10-bites CLI-t és könyvtárakat további információkért.

Megjegyzések

  • A francba, ezáltal a dolgok com plikázott. Tehát ‘ két ffmpeg bináris fájlra van szükségem, amelyek összekapcsolódnak a két x264 könyvtárral. Tudja, hogy vannak-e statikus felépítései a 10 bites x264-nek?
  • Itt megtalálja őket: download.videolan.org/pub/x264/binaries Ha saját maga akarja megépíteni, akkor egy rendkívül hosszú folyamat folytatja a mingw, yasm, git és gcc telepítését, és sok muffogást itt: doom10.org/ index.php? topic = 26.0 De nem tudtam ‘ működésbe hozni, főleg a hülye vállalati tűzfal miatt, amely ‘ t allow git.
  • Talán megszerezheti a Zeranoe -ot, hogy biztosítson ilyen összeállítást. Sajnálom, én ‘ elég haszontalan vagyok, amikor a Windowsról van szó.
  • Így vagyok én is, hogy ‘ probléma. ‘ létrehozási kérelmet küldtem, ‘ megnézzük, hogy megy.
  • FWIW manapság a libx264 ” mindkettő ” azt hiszem …

Válasz

szerkesztés: Sikeresen elkészítettem egy 10 bites kódolást a kacsák felszállásáról .

Első út: Építettem egy 10 bites x264-es bináris verziót, amely statikusan összekapcsolja a libx264-et. 

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

(ultragyors és alacsony minőségű, mert a koncepció bizonyítéka, nem minőségi teszt.) nem állította össze swscale-mel. (Boldogtalan volt egy RGB pix fmt a libavutilban vagy ilyesmi miatt). Hibát jelent, ha a bemeneti színtér nem felel meg a --output-csp i444 szónak, ami valóban jó, ha nem akarja, hogy véletlenül x264 lemásolja a kromát. Remekül működött, amikor néhány képkockát yuv444p14le.y4m adtam hozzá, 10 bites kimenetet produkálva. (Csonkíthatja a bitmélységet, de nem csökkentheti a kromát swscale nélkül.)

Második út: a LD_LIBRARY_PATH segítségével válassza ki a 10 bites libx264.so

Mindenhez ugyanazt az ffmpeg dinamikusan kapcsolt bináris fájlt használhatja. 

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

Nyilvánvalóan nem próbáltam vizuálisan látni semmit ezeken a minőségi beállításokon. Csak azt akartam, hogy gyorsan fusson, és ne pazaroljon el egy csomó lemezterületet mivel mindig sok kimeneti fájlt készítek, amikor kipróbálom a dolgok variációit.

Ha a masszív y4m adatokat külön x264 folyamathoz nem csatoltam, akkor 12 fps helyett 14 képkocka / mp sebességet tett meg, tehát megfelelő sebességgyorsítás az ultragyors. A lassabb kódolás eltörli ezt a rezsit.

A forrásom 48 bites RGB. Megállapítottam, hogy a pontos_rnd nem volt hatással az mkv kimenetre (bit-azonos eredmények -sws_flags, a -sws_flags +accurate_rnd és -vf scale=flags=accurate_rnd szavakkal, kivéve néhány bitet az mkv fejlécben, valószínűleg a randomizált mkv UUID-t. Még -qp 0, ezért nem veszítettem el a kerekítési hiba miatt. cmp -l f1 f2 | less összehasonlítani azokat a bináris fájlokat, amelyek némi kezdeti eltérés után azonosak lehetnek.Vagy ssdeep -p. Lehet, hogy most a accurate_rnd az alapértelmezett?)

Van egy ffmpeg swscaler zászló, ami számít, ha az ffmpeg-et hagyja, hogy az alapértelmezett helyett lecsökkenjen a chroma: lanczos bicubic. (Feltételezem, hogy a lanczókat még mindig a legjobb választásnak tekintik a kiváló minőség érdekében? Haven egy darabig nem olvassa fel.)

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

A +lanczos hozzáadása a -sws_flags fájlhoz nem működik: 

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

Ha 10 bitnél mélyebb bemenetet próbál meg betáplálni, az ffmpeg elutasítja. 

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

Valójában az ffmpeg libx264 illesztőprogramja mindig ragaszkodik az x264 pontos adagolásához. az a bitmélység, amelyre lefordították. Pl .: -pix_fmt yuv420p: 

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

x264.h azt mondja: 

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

Úgy gondolom, hogy az x264-nek (a CLI) belsőleg mindig fel kell konvertálnia a pixel formátumokat, a kódnak nincs 8 bites bemenete, minden funkció 10 bites kimeneti verziója . És azt is gondolom, hogy a különböző bemeneti bitmélységek elfogadása csak az x264 CLI-ben van, nem pedig a könyvtár API-ban. Kíváncsi vagyok, mi történik, ha az API bemenetet betáplálja, ahol magasabb bitek vannak beállítva … (Az ffpeg nem teszi lehetővé ezt a kód feltörése nélkül, ezért senkinek sem kell aggódnia, hogy elkerülje.) 

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

Ha pix_fmt nincs megadva, az ffmpeg az rgb bemenet megadásakor yuv444p10le -t választja. Vagy a libx264rgb, 8 bites rgb-vel látja el azokat a függvényeket, amelyek 16bit-re számítanak (ebből 10 jelentős), és a szegfaults> értékeket. … 

 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)

Jelentem ezt az áramlási irányban.

Mindenesetre kiderült, hogy baromi könnyű volt magam megépíteni egy kettős bitmélységű környezet az ffmpeg-hez, vagy bármely más programhoz, amelyet futtatni akar a libx264, libx265 és bármi más nagybetűs mélységgel lefordított változataival. (Ezért hívtam “highdepth” -nek, nem pedig csak “10bit” egy rövidebb névnél.)

a szerkesztés vége: az alábbiakban újrakezdés nélkül vannak a zűrzavaraim. És egy jó kicsit arról, hogyan lehet az ffmpeg-et átfordítani a win64-hez

Ezt én is kipróbáltam, mivel nem próbálkoztál olyan cmdline-szal, amely nagy bitmélységű bemenetet próbált megadni az x264-be.

ffmpeg pixel formátum nevek (ffmpeg -pix_fmts) nem csak elrendezést adnak meg, hanem pontosan egy bit elrendezéshez társítják, és így minden egyes formátum + bitmélység kombinációnak más neve van. Azt hiszem, arra számítottál, hogy az -pix_fmt yuv422p jelentése “konvertálás 422-re ugyanolyan bitmélységben, mint a bemenetem”.

wikipedia szerint a h.264 csak a Hi444PP-vel támogatja a 8-14 bites mélységet, mások csak 10bit-ig terjednek. A Hi444PP az egyetlen olyan profil, amely támogatja a prediktív veszteségmentes kódolást, amelyet x264 a -qp 0 vagy a -crf 0 esetén használ. edit: AFAICT, x264 továbbra is csak a 8, 9 vagy 10 bites fordítást támogatja.

Mindenesetre itt egy csomó haszontalan kimenet egy olyan parancsból, amely nem működik, mert nem fordítottam át a helyi x264. (De működnie kell az újrafordított x264-tel. Lehet, hogy szerkesztem ezt a választ, ha magam akarok játszani vele.)

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)

Vegye figyelembe a Incompatible pixel format "yuv420p10le" for codec "libx264", auto-selecting format "yuv420p" sort.

Valószínűleg nem kellett “div id =” 7bc257bb15 ” >

, és nagy bitmélységű x264-el csak működne. (és potenciálisan 444 10bit-t válasszon, amelyet az ffmpegyuva444p10le-nek hív.) Azt hiszem, hogy az x264 nagy bitmélységyuv444p14le, de akkor is csak 10 bites h.264-et produkálna. A cmdlinex264 --fullhelpmeglehetősen egyértelmű a kimeneti bit mélysége 8-10 között, nem nagyobb. Furcsa, hogy a-profile high10t csak csendben figyelmen kívül hagyja a 8 bites x264.

Belsőleg a nagy bitmélységre fordított x264 16 bp-t használ a 10 bites adatok tárolásához, így valószínűleg mozgást végez keresés és így tovább 16 bites értékekkel. És lehet, hogy a DCT magasabb lesz a 16 bites helyett a 10 bites, hacsak nem érhető el sebesség a 6 bites figyelmen kívül hagyásával. Ez kissé eltérő DCT-együtthatókat eredményezhet, mint ha a DCT előtt lefelé kerekítenél 10 bitesre. (Tehát potenciálisan más kimenetet kapsz, ha lefelé konvertálsz 10bit az x264-es betáplálás előtt, szemben 12, 14 vagy 16bit adásával.) Valószínűleg meg kellene néznem a kódot, vagy ki kell próbálnom, mielőtt elkészíteném a dolgokat. : P

(edit: az ffmpeg nem adta meg az x264-10bit elemet 10 bitesnél többet komponensenként. Swscale-t használ a bitmélység csökkentésére.)

Kíváncsi vagyok, milyen nehéz az x264 és az x265 javítása lenne, ha a globális változókhoz és az API függvényekhez különböző neveket használnánk, amikor nagy bitmélységre vannak lefordítva. Akkor egyszerre felépítheti mindkét verziót, és az ffmpeg mindkettőhöz kapcsolódik. Az ffmpeg libx264 és a libx264rgb csomagolók gondoskodhatnak az api megfelelő verziójának hívásáról a bemeneti folyamtól függően.(Egyébként -c:v libx264-deep vagy libx264rgb-deep szükséges, összesen 4 különböző x264 “kodek” az ffmpeg-ben.)

Hogyan lehet keresztezni az ffmpeg for windows fordítását

szerkesztés: Windows esetén nem hiszem, hogy bármi olyan kényelmes lenne, mint a LD_LIBRARY_PATH egy libx264 DLL-hez , így a legjobb megoldás még mindig egy nagy bitmélységű statikus bináris fájl létrehozása, és egy másik normál használatra. Nagy mélységű libx264 CAN “T normál mélységű h.264 kimenetet eredményezhet. Nem csak sebességbüntetés, hanem egyszerűen nem is képes.

Saját ffmpeg (statikus bináris) fordításának legegyszerűbb módja a Windows számára a https://github.com/rdp/ffmpeg-windows-build-helpers . git klónozza a repót egy Linux gépen (vagy esetleg egy másik, működő gcc-vel rendelkező rendszeren, például OS X?), majd futtassa

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

Ez körülbelül 8 órát vett igénybe az első futtatáskor, mivel minden mással együtt forrásból építette a mingw-cross-compile GCC-t. (A gcc alapértelmezés szerint többször is újjáépíti magát alkalommal, ha eredetileg rossz fordítóval fordítottad.)

A build szkriptet a git pull fájlmal frissítheted, és újra futtathatod húzza le az ffmpeg, x264, x265 és talán néhány más projekt legfrissebb git frissítéseit forrásból. (A legtöbb számára csak a tarballokat tölti le.)

A Linuxos asztalom megmutatja korát. egy wintendót, amelyet főleg játékokra használok. Mivel videokódolással kezdtem el kavarogni, megtalálom a négymagos Sandybrid-et ge ehhez is elég hasznos, esp. x265 esetén. Valószínűleg az x265 “funkciók egy részének csak az AVX / SSE4 verziói vannak, ezért az SSSE3 Linux gépemen (Conroe) visszaáll a C értékre. Ez vagy ez jobban észrevehető 1 kép / mp sebességgel …

Megjegyzések

  • Értesíti a stackexchange az embereket, ha szerkesztek? nem ‘ t.
  • ez sokkal egyszerűbb az OS X-en, ahol dinamikus összekapcsolást használnak. Egyszerűen brew reinstall x264 --with-10-bit és kész, az ffmpeg az új x264 zamatot fogja használni 🙂
  • @SargeBorsch: Ennek a válasznak az volt a lényege, hogy mindkét ízt azonos időben telepítették, így összehasonlíthatja a 8 bites és 10 bites fájlokat anélkül, hogy újratelepítené a könyvtár. Az OS X dinamikus összekapcsolása nagyjából ugyanúgy működik, mint a Linux ‘ s, ahol hasonló módon helyettesítheti a libx264 telepítést a másik aromával, ha akarja.
  • @PeterCordes hmm, rossz. Igazad van

Válasz

Az ffmpeg-et a https://sourceforge.net/projects/ffmpeg-hi/?source=typ_redirect

És az alábbi paranccsal létrehozta a 4: 2: 2 1 0bit h.264 fájl: 

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

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük