Credo che libx264 sia ora in grado di eseguire codifiche 4: 2: 2 a 10 bit, ma Non riesco a farlo funzionare. Sto usando ffmpeg (informazioni sotto) e ho anche provato direttamente lencoder x264. Ho provato
ffmpeg.exe -i input.mov -c:v libx264 -profile:v high422 -crf 20 -pix_fmt yuv422p output.mp4
e questo produce un buon output 4: 2: 2, ma solo a 8 bit di profondità,
[libx264 @ 00000000055a9de0] profile High 4:2:2, level 4.0, 4:2:2 8-bit
e io “ho provato
ffmpeg.exe -i input.mov -c:v libx264 -profile:v high10 -crf 20 -pix_fmt yuv422p output.mp4
e questo mi dà lerrore:
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
Nella documentazione x264 –fullhelp I trova:
--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.
Quindi può fare 4: 2: 2 a 10 bit di profondità e anche 4: 4: 4 a 10 bit apparentemente, ma lì ” Nessuna indicazione su come impostare la profondità di bit di uscita. Cè unopzione --input-depth <integer> Specify input bit depth for raw input
ma niente per la profondità di bit di output.
Commenti
- Ho trovato questo: x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf Apparentemente si ottiene una migliore efficienza di compressione (dimensioni rispetto alla qualità) con 10 bit. Potrei iniziare a utilizzare 10 bit regolarmente, se ‘ t molto più lento da codificare.
Risposta
x264 supporta output sia a 8 bit che a 10 bit e non devi “fare nulla di speciale.
ffmpeg
Se utilizzi ffmpeg
puoi vedere quali formati di pixel e profondità di bit sono supportati da libx264:
$ ffmpeg -h encoder=libx264 [...] Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p nv12 nv16 nv21 yuv420p10le yuv422p10le yuv444p10le nv20le
I formati pixel a 10 bit sono: yuv420p10le, yuv422p10le, yuv444p10le.
x264
Puoi anche controllare x264
per le profondità di bit supportate:
$ x264 --help [...] Output bit depth: 8/10
In precedenza dovevi compilare x264 con --bit-depth=10
, quindi collega il tuo ffmpeg
a una libx264 a 8 o 10 bit, ma ora non è più necessario. Consulta Unifica CLI e librerie a 8 e 10 bit per ulteriori informazioni.
Commenti
- Dannazione, questo fa sì che le cose com plicato. Quindi ‘ avrò bisogno di due binari ffmpeg collegati alle due librerie x264. Sai se ci sono build statiche di x264 a 10 bit ovunque?
- Trovale qui: download.videolan.org/pub/x264/binaries Se vuoi costruirlo da solo, cè un processo estremamente lungo che invoca linstallazione di mingw, yasm, git e gcc e un sacco di cose da fare qui: doom10.org/ index.php? topic = 26.0 Ma non sono riuscito ‘ a farlo funzionare, principalmente a causa dello stupido firewall aziendale che ha vinto ‘ t consentire git.
- Forse puoi ottenere Zeranoe per fornire tale build. Mi spiace, ‘ sono abbastanza inutile quando si tratta di Windows.
- Anchio, che ‘ è il problema. ‘ ho pubblicato una richiesta di compilazione, ‘ vedremo come va.
- FWIW in questi giorni libx264 è ” entrambi ” Credo …
Risposta
edit: ho creato con successo una codifica a 10 bit di Ducks Take Off .
Primo modo: Ho creato un binario x264 a 10 bit che collega staticamente 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
(ultraveloce e di bassa qualità perché “è una prova di concetto, non un test di qualità). non lho compilato con swscale. (Non era contento di un pix fmt RGB in libavutil o qualcosa del genere). Viene visualizzato un errore se lo spazio dei colori di input non corrisponde a --output-csp i444
, il che è effettivamente utile se non si desidera eseguire accidentalmente il downsampling x264 della crominanza. Ha funzionato bene quando ho inserito alcuni fotogrammi di yuv444p14le.y4m
, producendo un output a 10 bit. (Può troncare la profondità di bit, ma non eseguire il downsampling della crominanza senza swscale.)
Secondo modo: utilizzare LD_LIBRARY_PATH
per selezionare una libx264.so a 10 bit
Puoi usare lo stesso binario ffmpeg con collegamento dinamico per tutto.
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.)
Ovviamente non ho provato a vedere nulla visivamente con quelle impostazioni di qualità. Volevo solo che funzionasse velocemente, senza sprecare un mucchio di spazio su disco dato che finisco sempre per creare molti file di output quando provo variazioni sulle cose.
Non convogliare i massicci dati y4m a un processo x264 separato ha fatto andare 14 fps invece di 12, quindi una velocità decente per ultraveloce. Una codifica più lenta farà impallidire questo sovraccarico.
La mia sorgente è RGB a 48 bit. Ho scoperto che accurate_rnd non ha avuto alcun effetto sulloutput mkv. (Risultati identici a bit senza -sws_flags
, con -sws_flags +accurate_rnd
e -vf scale=flags=accurate_rnd
, ad eccezione di alcuni bit nellintestazione mkv, probabilmente lUUID mkv casuale. Anche con -qp 0
, quindi non lo stavo perdendo per errore di arrotondamento. cmp -l f1 f2 | less
per confrontare file binari che potrebbero essere gli stessi dopo qualche differenza iniziale.Oppure ssdeep -p
. Forse accurate_rnd
è limpostazione predefinita adesso?)
Cè un flag di swscaler ffmpeg che conta, se “stai lasciando che ffmpeg esegua il downsampling della crominanza: lanczos invece del valore predefinito bicubico. (Presumo che Lanczos sia ancora considerata la scelta migliore per lalta qualità? Non leggo per un po .)
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
Laggiunta di +lanczos
a -sws_flags
non “funziona:
[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 provi a inserire un input più profondo di 10 bit, ffmpeg rifiuta.
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
In realtà, il driver libx264 di ffmpeg “insiste sempre per alimentare esattamente x264 la profondità di bit per cui è compilato. Ad esempio con -pix_fmt yuv420p
:
Incompatible pixel format "yuv420p" for codec "libx264", auto-selecting format "yuv420p10le"
x264.h dice:
/* 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;
Penso che internamente x264 (la CLI) debba sempre convertire i formati pixel, il codice non ha input a 8 bit, versioni di output a 10 bit di ogni funzione . Inoltre, penso che laccettazione di varie profondità di bit di input sia solo nella CLI x264, non nellAPI della libreria. Sono curioso di sapere cosa succede quando fornisci linput dellAPI dove sono impostati bit più alti … (ffpeg non ti consente di farlo senza hackerare il codice, quindi questo non è qualcosa che nessuno deve preoccuparsi di evitare.)
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
Senza pix_fmt specificato, ffmpeg sceglie yuv444p10le
quando viene fornito un input rgb. O con libx264rgb
, alimenta rgb a 8 bit a funzioni che prevedono 16 bit (10 dei quali significativi) e segfaults>. <. Lo segnalerò a monte …
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)
Lo segnalerò a monte.
Ad ogni modo, è stato davvero facile crearmi un ambiente a doppia profondità per ffmpeg, o qualsiasi altro programma che desideri eseguire con versioni compilate ad alta profondità di bit di libx264, libx265 e qualsiasi altra cosa tu voglia. (Ecco perché lho chiamato “profondità elevata”, non solo “10 bit” per un nome più breve.)
fine della modifica: di seguito sono riportate le mie divagazioni senza ricompilazione. E un bel po su come eseguire la compilazione incrociata di ffmpeg per win64
Ho provato io stesso, dal momento che non hai provato con una linea cmd che ha cercato di fornire input ad alta profondità di bit a x264.
nomi di formato pixel ffmpeg (ffmpeg -pix_fmts
) non si limita a specificare una disposizione, ma mappano a una disposizione di bit esatta e quindi ogni combinazione formato + profondità di bit ha un nome diverso. Penso che ti aspettavi che -pix_fmt yuv422p
significasse “converti in 422 con la stessa profondità di bit del mio input”.
wikipedia dice che h.264 supporta la profondità di 8-14 bit solo con Hi444PP, altri sono solo fino a 10 bit. Hi444PP è lunico profilo che supporta la codifica predittiva senza perdite, che x264 utilizza per -qp 0
o -crf 0
. modifica: AFAICT, x264 supporta ancora la compilazione solo per 8, 9 o 10 bit.
Comunque, ecco “un mucchio di output inutile da un comando che non funziona perché non ho” ricompilato il mio locale x264. (Ma dovrebbe funzionare con x264 ricompilato. Potrei modificare questa risposta se voglio giocarci da solo.)
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)
Nota la riga Incompatible pixel format "yuv420p10le" for codec "libx264", auto-selecting format "yuv420p"
.
Probabilmente “non avevo bisogno di -profile
e con un x264 ad alta profondità di bit, funzionerebbe. (e potenzialmente scegli 444 10 bit, che ffmpeg chiama yuva444p10le
.) penso la profondità di bit elevata x264 potrebbe accettare yuv444p14le
, ma produrrebbe comunque solo 10 bit h.264. Il cmdline x264 --fullhelp
è piuttosto esplicito sulla profondità di bit di output da 8 a 10, non superiore. Strano che -profile high10
venga ignorato silenziosamente da 8 bit x264.
Internamente, x264 compilato per unelevata profondità di bit utilizza 16 bpp per memorizzare dati a 10 bit, quindi probabilmente esegue il movimento ricerca e così via con valori a 16 bit. E potrebbe DCT maggiore di 16 bit anziché 10 bit, a meno che non ci sia velocità da guadagnare ignorando 6 bit. Ciò potrebbe produrre coefficienti DCT leggermente diversi rispetto a quelli arrotondati per difetto a 10 bit prima di DCT. (Quindi si ottiene potenzialmente un output diverso dalla conversione in 10 bit prima di passare a x264, invece di dargli 12, 14 o 16 bit.) Dovrei probabilmente guardare il codice o provarlo prima di inventare qualcosa, però. Non fidarti di questo paragrafo. : P
(modifica: ffmpeg non alimenta x264-10bit più di 10 bit per componente. Userà swscale per ridurre la profondità di bit stessa.)
Mi chiedo quanto sia difficile sarebbe applicare la patch x264 e x265 per utilizzare nomi diversi per le variabili globali e le funzioni API, quando compilate per unelevata profondità di bit. Quindi potresti creare entrambe le versioni contemporaneamente e avere ffmpeg collegato a entrambe. Il ffmpeg libx264
e libx264rgb
potrebbero occuparsi di chiamare la versione appropriata dellAPI a seconda del flusso di input.(Altrimenti “ti occorrono -c:v libx264-deep
o libx264rgb-deep
, per un totale di 4 diversi” codec “x264 in ffmpeg.)
Come eseguire la compilazione incrociata di ffmpeg per Windows
modifica: per Windows, non credo che ci sia qualcosa di così conveniente come LD_LIBRARY_PATH
per una DLL libx264 , quindi la soluzione migliore è ancora costruire un binario statico ad alta profondità di bit e un altro per uso normale. Libx264 ad alta profondità PU “T emettere una profondità normale h.264. Non solo una penalità di velocità, può semplicemente “t.
Il modo più semplice per compilare il tuo ffmpeg (binario statico) per Windows è con https://github.com/rdp/ffmpeg-windows-build-helpers . git clona il repository su una macchina Linux (o forse un altro sistema con un gcc funzionante, come OS X?), quindi esegui
./cross_compile_ffmpeg.sh --high-bitdepth=y --disable-nonfree=n --build-choice=win64
Ci sono volute circa 8 ore per la prima esecuzione, dal momento che ha compilato GCC mingw-cross-compile dai sorgenti, insieme a tutto il resto. (gcc per impostazione predefinita si ricostruisce diversi volte al bootstrap, nel caso in cui lo stavi compilando originariamente con un cattivo compilatore.)
Puoi aggiornare lo script di compilazione con git pull
, e rieseguirlo lo farà estrarre gli ultimi aggiornamenti git per ffmpeg, x264, x265 e forse alcuni degli altri progetti che compila dai sorgenti (per la maggior parte scarica solo tarball)
Il mio desktop Linux mostra la sua età. un wintendo che uso principalmente per i giochi. Da quando ho iniziato a scherzare con la codifica video, trovo il suo quad-core Sandybrid ge molto utile anche per quello, specialmente. per x265. Probabilmente alcune delle funzioni di x265 hanno solo versioni asm per AVX / SSE4, quindi ricade su C sulla mia macchina Linux SSSE3 (Conroe). Questo o “è più evidente a 1 fps …
Commenti
- Stackexchange avvisa le persone quando apporto modifiche? Postando un commento nel caso in cui ‘ t.
- questo è molto più semplice su OS X, dove viene utilizzato il collegamento dinamico. Semplicemente
brew reinstall x264 --with-10-bit
e il gioco è fatto, ffmpeg utilizzerà il nuovo sapore x264 🙂 - @SargeBorsch: il punto di questa risposta era di avere entrambi i gusti installati nello STESSO TEMPO, in modo da poter confrontare 8 bit e 10 bit senza reinstallare il Il collegamento dinamico di OS X funziona più o meno come Linux ‘ s, dove potresti sostituire in modo simile la tua installazione di libx264 con laltra versione, se lo desideri.
- @PeterCordes hmm, colpa mia. Hai ragione
Risposta
Ho scaricato ffmpeg dal link https://sourceforge.net/projects/ffmpeg-hi/?source=typ_redirect
E ha inserito il comando seguente per creare 4: 2: 2 1 File a 0 bit h.264:
ffmpeg-hi10-heaac.exe -i "im.mp4" -c:v libx264 -pix_fmt yuv422p10le yuv-high-.ts