ffmpeg-static_20130614_amd64.deb

Dipendenze: Depends: libc6 (>= 2.15), zlib1g (>= 1:1.2.0)
quindi qualsiasi distribuzione debian derivata a 64bit che soddisfi quei due pacchetti, dovrebbe andare bene. Per altre distribuzioni che non usano i deb, estraete dal pacchetto (con file-roller, ark) l’eseguibile e mettetelo dove più vi aggrada.

L’eseguibile (in /usr/bin) si chiama
ffmpeg-static
ed essendo statico comprende tutte le librerie, senza interferire con le lib di sistema.

Esempio di uso dei filtri di libvidstab

prima passata col filtro vidstabdetect:

ffmpeg-static -y -i test.mkv -vf vidstabdetect -an -f rawvideo /dev/null
che produrra solo il file transforms.trf, necessario al filtro vidstabtransform

seconda passata col filtro vidstabtransform

ffmpeg-static -i test.mkv -vf vidstabtransform -c:v libx264 -preset faster -tune film -b:v 850k -c:a libfdk_aac -b:a 112k -f matroska stabilizzato.mkv


Maggiori info sull’uso di libvidstab qua.

Lista dei filtri di ffmpeg qua.

Per la lista dei codecs supportati
ffmpeg-static -codecs

help per encoder (esempio libx264)
ffmpeg-static -h encoder=libx264

Per la lista dei filtri supportati
ffmpeg-static -filters

help per filtro (esempio crop)
ffmpeg-static -h filter=crop

Help completo online qui.

Qui invece trovate ffmpeg10-static

ffmpeg10-static_20130614_amd64.deb

che è la stessa versione ma compilata con libx264 con bit-depth=10,
se comprimete con codec libx264, otterrete dei file profile High 10, 10-bit.
Per usarlo lanciate:

ffmpeg10-static

Entrambe le versioni possono essere installate contemporaneamente,
e coesistere senza problemi con ffmpeg e avconv di sistema

ATTENZIONE:
Usate il software solo per uso personale, a vostro completo rischio e pericolo.

Solita piattaforma, debian sid 64, Intel Q8300, NVIDIA GeForce GT 440.

Ora non è più necessario modificare il configure, in presenza delle librerie OpenCL, il supporto viene attivato automaticamente. e si compila anche la libreria condivisa.
Anche via ffmpeg si può attivare OpenCL con
-x264opts opencl.

Senza OpenCL
$ time ./x264 --threads 0 --sar 4:3 \
--bitrate 1800 --preset fast --tune film \
-o video.mkv /media/scambio/Amazing_Caves_1080.wmv

real 1m22.962s
1 minuto e 23 secondi.

Con OpenCl
$ time ./x264 --threads 0 --opencl --sar 4:3 \
--bitrate 1800 --preset fast --tune film \
-o video.mkv /media/scambio/Amazing_Caves_1080.wmv

real 1m19.390s
1 minuto e 19 secondi circa.

Con il preset slow (rc-lookahead 50 contro rc-lookahead 20 di faster).

Senza OpenCL
$ time ./x264 --threads 0 --sar 4:3 \
--bitrate 1800 --preset slow --pass 1 --tune film \
-o /dev/null /media/scambio/Amazing_Caves_1080.wmv

real 0m59.130s
poco più di 59 secondi.

Con OpenCL
$ time ./x264 --threads 0 --sar 4:3 \
--bitrate 1800 --preset slow --opencl --pass 1 --tune film \
-o /dev/null /media/scambio/Amazing_Caves_1080.wmv

real 1m6.115s
1 minuto e 6 secondi.

Stessi risultati usando ffmpeg.

Senza OpenCL
$ time ffmpeg2 -y -i /media/scambio/Amazing_Caves_1080.wmv \
-threads 0 \
-c:v libx264 -preset slow -tune film \
-b:v 1800k -x264opts sar=4/3 \
-pass 1 -fastfirstpass 1 -an \
-f matroska /dev/null

real 0m59.253s

Con OpenCL
$ time ffmpeg2 -y -i /media/scambio/Amazing_Caves_1080.wmv \
-threads 0 \
-c:v libx264 -preset slow -tune film \
-b:v 1800k -x264opts opencl:sar=4/3 \
-pass 1 -fastfirstpass 1 -an \
-f matroska /dev/null

real 1m6.720s

Questi i carichi d lavoro della CPU nei 2 casi:

Uploaded with ImageShack.us

OpenCL più lenta della Cpu,
niente “miracoli velocistici” purtroppo.

Commit Opencl
Altri test.

Aggiunta la canvas rotation, che funziona bene, ed il seamless clone, che invece imballa Gimp per tempi lunghissimi anche con selezioni piccole, per poi offrire risultati che non si riescono a trascinare nella posizione voluta ed a stampare sull’immagine base, insomma c’è molto da lavorarci su.

Permane la lentezza della versione 2.9.1 rispetto alla 2.8.4, tale da sconsigliarne ancora l’uso.

Immagine del test dalla rete

Vediamo come fare

Con ffmpeg di sistema (che deve avere --enable-libx264 nella configurazione),
esempio con debian-multimedia:

ffmpeg version 1.0.7 Copyright (c) 2000-2013 the FFmpeg developers
built on May 14 2013 06:27:36 with gcc 4.7 (Debian 4.7.3-4)

o con una versione compilata da voi, ad esempio:

ffmpeg version N-53043-g6b13f54 Copyright (c) 2000-2013 the FFmpeg developers
built on May 14 2013 15:34:04 with gcc 4.7 (Debian 4.7.3-4)


cioè un 1.2+git-g6b13f54,
viene usata la libx264 di sistema, che è compilata a 8 bit.

Per comprimere a 10 bit è necessario ricompilare x264 con il supporto ai 10 bit.
Se avete come nel mio caso la libx264-132, potete scaricarvi uno snapshot, scompattarlo e compilarlo con:

./configure \
--prefix=/opt/x264-10 \
--extra-cflags='-g -O3 -fstack-protector \
--param=ssp-buffer-size=4 -Wformat -Werror=format-security ' \
--extra-ldflags='-Wl,-z,relro' \
--enable-static \
--enable-pic \
--bit-depth=10 \
--enable-visualize \
--disable-lavf \
--enable-shared

poi i soliti
make
sudo make install

installeranno la nuova lib in /opt/x264-10, senza disturbare il sistema.

Ora per far usare a ffmpeg la libreria, basta creare un wrapper:

#-------------------------------------
#!/bin/sh

ffmpeg "$@"
#-------------------------------------

salvatelo come

ffmpeg-x10bit

rendetelo eseguibile, e spostatelo in
/usr/local/bin/ffmpeg-x10bit

Ora se volete usare il normale 8bit lanciate ffmpeg,
se volete usare il 10bit lanciate ffmpeg-x10bit.

Qualche test.

10 bit

ffmpeg-x10bit -y -i /home/mc/test.mkv -t 00:03:00 -c:v libx264 -profile high10 -preset faster -tune film -b:v 730k -an -f matroska out2.mkv
ffmpeg version N-53043-g6b13f54 Copyright (c) 2000-2013 the FFmpeg developers
built on May 14 2013 15:34:04 with gcc 4.7 (Debian 4.7.3-4)
Input #0, matroska,webm, from '/home/mc/test.mkv':

real 0m52.385s

52 secondi per un video 720×406 di 3 minuti.

8 bit:

ffmpeg -y -i /home/mc/test.mkv -t 00:03:00 -c:v libx264 -profile high10 -preset faster -tune film -b:v 730k -an -f matroska out1.mkv
ffmpeg version N-53043-g6b13f54 Copyright (c) 2000-2013 the FFmpeg developers
built on May 14 2013 15:34:04 with gcc 4.7 (Debian 4.7.3-4)
Input #0, matroska,webm, from '/home/mc/test.mkv':

real 0m34.758s

Solo 35 secondi per lo stesso video.

Se sia il caso di aumentare il tempo di compressione per avere i 10 bit, onestamente non saprei dirvi, non noto particolari differenze ad occhio.

Tenete poi presente che x264 a 10bit non viene accelerato da VDPAU durante la visione, e quindi va tutto a carico della cpu.

Il gioco vale la candela?
Per me no, poi va a gusti.

PS.

Lo stesso giochetto, funziona anche con avconv

mc@debian64:~/develop-deb/libav/0.8.7$ time ./avconv-x10bit -y -i /home/test.mkv -t 00:03:00 -c:v libx264 -profile high10 -preset faster -tune film -b:v 730k -an -f matroska out1.mkv
avconv version 0.8.7, Copyright (c) 2000-2013 the Libav developers
built on May 14 2013 22:53:32 with gcc 4.7.3
[matroska,webm @ 0x2801000] Estimating duration from bitrate, this may be inaccurate
Input #0, matroska,webm, from '/home/test.mkv':

real 0m48.258s


VP9 è il successore di VP8, ed è (dovrebbe) un codec video HEVC

Bene facciamo qualche test.
Solita piattaforma, debian sid 64, cpu Intel Q8300.

Compilati libvpx (sia il ramo master che l’experimental, stessi risultati) e ffmpeg da git per avere il supporto a VP9:


./ffmpeg-vp9 -codecs | grep vp
ffmpeg version 1.1.git-90d35e5 Copyright (c) 2000-2013 the FFmpeg developers

D.V.L. vp3 On2 VP3
D.V.L. vp5 On2 VP5
D.V.L. vp6 On2 VP6
D.V.L. vp6a On2 VP6 (Flash version, with alpha channel)
D.V.L. vp6f On2 VP6 (Flash version)
DEV.L. vp8 On2 VP8 (decoders: vp8 libvpx ) (encoders: libvpx )
DEV.L. vp9 Google VP9 (decoders: libvpx-vp9 ) (encoders: libvpx-vp9 )
D.A.LS wavpack WavPack
D.S... vplayer VPlayer subtitle


Vediamo i parametri:


./ffmpeg-vp9 -h encoder=libvpx-vp9

Encoder libvpx-vp9 [libvpx VP9]:
Threading capabilities: no
Supported pixel formats: yuv420p
libvpx encoder AVOptions:
-cpu-used E..V.. Quality/Speed ratio modifier (from INT_MIN to INT_MAX)
-auto-alt-ref E..V.. Enable use of alternate reference frames (2-pass only) (from -1 to 1)
-lag-in-frames E..V.. Number of frames to look ahead for alternate reference frame selection (from -1 to INT_MAX)
-arnr-maxframes E..V.. altref noise reduction max frame count (from -1 to INT_MAX)
-arnr-strength E..V.. altref noise reduction filter strength (from -1 to INT_MAX)
-arnr-type E..V.. altref noise reduction filter type (from -1 to INT_MAX)
backward E..V..
forward E..V..
centered E..V..
-deadline E..V.. Time to spend encoding, in microseconds. (from INT_MIN to INT_MAX)
best E..V..
good E..V..
realtime E..V..
-error-resilient E..V.. Error resilience configuration
default E..V.. Improve resiliency against losses of whole frames
partitions E..V.. The frame partitions are independently decodable by the bool decoder, meaning that partitions can be decoded even though earlier partitions have been lost. Note that intra predicition is still done over the partition boundary.
-max-intra-rate E..V.. Maximum I-frame bitrate (pct) 0=unlimited (from -1 to INT_MAX)
-speed E..V.. (from -16 to 16)
-quality E..V.. (from INT_MIN to INT_MAX)
best E..V..
good E..V..
realtime E..V..
-vp8flags E..V..
error_resilient E..V.. enable error resilience
altref E..V.. enable use of alternate reference frames (VP8/2-pass only)
-arnr_max_frames E..V.. altref noise reduction max frame count (from 0 to 15)
-arnr_strength E..V.. altref noise reduction filter strength (from 0 to 6)
-arnr_type E..V.. altref noise reduction filter type (from 1 to 3)
-rc_lookahead E..V.. Number of frames to look ahead for alternate reference frame selection (from 0 to 25)
-crf E..V.. Select the quality for constant quality mode (from 0 to 63)


Via ai test, usate solo le 2 passate,
perchè a singola passata con VP9 non c’è alcun controllo del bitrate,
ed il risultato è *schifoso*.

VP9 pass1

time ./ffmpeg-vp9 -y -i /home/mc/test.mkv -t 00:00:30 -c:v libvpx-vp9 -strict -2 -quality good -b:v 600k -speed 16 -rc_lookahead 25 -pass 1 -an -f matroska /dev/null

real 0m15.460s


VP9 pass2

time ./ffmpeg-vp9 -y -i /home/mc/test.mkv -t 00:00:30 -c:v libvpx-vp9 -strict -2 -quality good -b:v 600k -speed 16 -rc_lookahead 25 -pass 2 -an -f matroska out2.mkv

real 6m31.734s


Seriamente?!
Un codec che per comprimere 30 secondi di un video 720×404
ci mette 6 minuti e 50 secondi (prima + seconda passata)?!

Per vedere il video codificato VP9 per ora l’unico modo è usare ffplay compilato con ffmpeg:

./ffplay-vp9 out.mkv -strict -2

La qualità non mi sembra nulla di speciale, potrei anche aspettare giorni di compressione per ottenere un video HD eccezionale a bitrate bassissimo, ma non è SICURAMENTE il caso di VP9, che è SOLO MOLTO MOLTO MOLTO LENTO.

Testato anche l’encoder vpxenc della libvpx, stessi risultati “diludenti”.

Meno male che è QUASI pronto …

Stesso test con VP8

time ./ffmpeg-vp9 -y -i /home/mc/test.mkv -t 00:00:30 -c:v libvpx -quality good -b:v 600k -speed 16 -rc_lookahead 25 -pass 1 -an -f matroska /dev/null

real 0m9.555s


VP8 pass2

time ./ffmpeg-vp9 -y -i /home/mc/test.mkv -t 00:00:30 -c:v libvpx -quality good -b:v 600k -speed 16 -rc_lookahead 25 -pass 2 -an -f matroska out3.mkv

real 0m7.120s


Circa 16 secondi per le due passate con VP8.

Stesso test con x264 profilo baseline.

time ./ffmpeg-vp9 -y -i /home/mc/test.mkv -t 00:00:30 -c:v libx264 -profile baseline -b:v 600k -pass 1 -an -f matroska /dev/null

real 0m2.652s


x264 pass2

time ./ffmpeg-vp9 -y -i /home/mc/test.mkv -t 00:00:30 -c:v libx264 -profile baseline -b:v 600k -pass 2 -an -f matroska out4.mkv

real 0m5.195s


Circa 8 secondi per x264.

Aspettiamo la futura implementazione free di un codec h265,
per vedere le potenzialitò di HEVC.

VP9 è “un treno di diludendo” (cit.)

Discussione su Doom9

Info sui commit qui.

Vediamo il test su Debian sid 64, CPU Intel Q8300, GPU NVIDIA GT 440.

Deshake senza OpenCL.

~time ffmpeg -y -i /media/scambio/Amazing_Caves_1080.wmv \
-vf deshake=opencl=0 \
-threads 0 -c:v libx264 \
-preset fast -tune film -an \
-f matroska -b:v 1800k video.mkv

real 4m19.541s

Deshake con OpenCL.

~time ffmpeg -y -i /media/scambio/Amazing_Caves_1080.wmv \
-vf deshake=opencl=1 \
-threads 0 -c:v libx264 \
-preset fast -tune film -an \
-f matroska -b:v 1800k video.mkv

real 2m12.312s

Unsharp senza OpenCL.

~time ffmpeg -y -i /media/scambio/Amazing_Caves_1080.wmv \
-vf unsharp=opencl=0 \
-threads 0 -c:v libx264 \
-preset fast -tune film -an \
-f matroska -b:v 1800k video.mkv

real 1m28.516s

Unsharp con OpenCL.

~time ffmpeg -y -i /media/scambio/Amazing_Caves_1080.wmv \
-vf unsharp=opencl=1 \
-threads 0 -c:v libx264 \
-preset fast -tune film -an \
-f matroska -b:v 1800k video.mkv

real 1m29.834s

Risultati controversi,
accelerazione quasi del 100% sullo stabilizzatore deskake,
mentre il più utile unsharp è anche leggermente più lento con OpenGL.
Mah.

Ho voluto fare qualche test su Debian sid 64, CPU Intel Q8300, GPU NVIDIA GT 440.
Versione x264-76a5c3a

Uploaded with ImageShack.us

Per attivare la compilazione di x264 con le librerie OpenCl su linux,
è necessario modificare il configure:

--- a/configure 2013-04-29 21:29:38.000000000 +0200
+++ b/configure 2013-05-02 16:11:24.000000000 +0200
@@ -1115,8 +1115,8 @@
# OpenCL support is only well tested on Windows/MinGW. If you
# wish to try it on an unsupported platform, swap the lines
# below. If OpenCL breaks, you get to keep both halves
- #opencl="yes"
- opencl="no"
+ opencl="yes"
+ #opencl="no"
fi
if [ "$opencl" = "yes" ]; then
log_check "looking for perl"
@@ -1125,7 +1125,7 @@
echo 'OpenCL support requires perl to compile.'
echo 'use --disable-opencl to compile without OpenCL.'
exit 1
- elif [[ $cross_prefix != "" && $host_os == mingw* ]] ; then
+ elif [[ $host_os != mingw* ]] ; then
if cc_check "CL/cl.h" "-lOpenCL"; then
echo 'HAVE_OPENCL=yes' >> config.mak
echo 'OPENCL_LIB=OpenCL' >> config.mak


configurazione di x264:

./configure \
--extra-cflags='-g -O3 -mtune=core2 -fstack-protector \
--param=ssp-buffer-size=4 -Wformat -Werror=format-security' \
--extra-ldflags='-Wl,-z,relro' \
--enable-static \
--enable-pic \
--enable-visualize

codifica normale:

~./x264 --threads 0 --sar 4:3 --bitrate 1800 \
--preset fast --tune film \
-o video.mkv /media/scambio/Amazing_Caves_1080.wmv
lavf [info]: 1440x1080p 0:1 @ 0/0 fps (vfr)
x264 [info]: using SAR=4/3
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
x264 [info]: profile High, level 4.0
x264 [info]: frame I:14 Avg QP:23.15 size: 85538
x264 [info]: frame P:1211 Avg QP:26.11 size: 11441
x264 [info]: frame B:812 Avg QP:29.11 size: 2906
x264 [info]: consecutive B-frames: 36.3% 24.8% 20.2% 18.7%
x264 [info]: kb/s:1640.28

real 1m22.482s

codifica con OpenCl:

~./x264 --threads 0 --opencl --sar 4:3 --bitrate 1800 \
--preset fast --tune film \
-o video.mkv /media/scambio/Amazing_Caves_1080.wmv
lavf [info]: 1440x1080p 0:1 @ 0/0 fps (vfr)
x264 [info]: using SAR=4/3
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GT 440
x264 [info]: profile High, level 4.0
x264 [info]: frame I:14 Avg QP:23.02 size: 83283
x264 [info]: frame P:1138 Avg QP:26.42 size: 11898
x264 [info]: frame B:885 Avg QP:28.41 size: 3023
x264 [info]: consecutive B-frames: 29.6% 31.2% 19.0% 20.2%
x264 [info]: kb/s:1637.39

real 1m20.106s

Ho fatto anche un test di codifica a 10Bit, con x264 configurato con:

./configure \
--extra-cflags='-g -O3 -mtune=core2 -fstack-protector \
--param=ssp-buffer-size=4 -Wformat -Werror=format-security' \
--extra-ldflags='-Wl,-z,relro' \
--enable-static \
--enable-pic \
--bit-depth=10 \
--enable-visualize

Codifica a 10 bit:

~./x264 --threads 0 --sar 4:3 --bitrate 1800 \
--preset fast --tune film \
-o video.mkv /media/scambio/Amazing_Caves_1080.wmv
lavf [info]: 1440x1080p 0:1 @ 0/0 fps (vfr)
x264 [info]: using SAR=4/3
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
x264 [info]: profile High 10, level 4.0, 4:2:0 10-bit
x264 [info]: frame I:14 Avg QP:33.94 size: 96241
x264 [info]: frame P:1455 Avg QP:38.01 size: 10247
x264 [info]: frame B:568 Avg QP:40.87 size: 2154
x264 [info]: consecutive B-frames: 44.7% 54.4% 0.1% 0.8%
x264 [info]: kb/s:1646.68

real 2m4.628s

Che dire, opencl non mi sembra fornire questa grande accelerazione.

“Mi stai diludendo” (cit.)

Home vid.stab e video demo.

Ovviamente per usarlo con ffmpeg occorre la libreria libvidstab (su debian sid non c’è, l’ho impacchettata da me), e compilare il git di ffmpeg con --enable-libvidstab

git libvidstab

I filtri da usare (in 2 passate) sono:

vidstabdetect

vidstabtransform

Help:

ffmpeg -h filter=vidstabdetect
ffmpeg -h filter=vidstabtransform

Altro stabilizzatore video presente in ffmpeg è deshake abilitato anche ad usare l’accelerazione hardware opencl.

Esempio:


ffmpeg -f lavfi -i \
" \
movie=1.mp4, scale=640:360,setdar=16/9,hqdn3d=4 [v1] ; amovie=1.mp4 [a1] ; \
movie=2.avi, scale=640:360,setdar=16/9 [v2] ; amovie=2.avi [a2] ; \
movie=3.flv, scale=640:360,setdar=16/9 [v3] ; amovie=3.flv [a3] ; \
[v1] [v2] [v3] concat=n=3 [out0] ; \
[a1] [a2] [a3] concat=n=3:v=0:a=1 [out1] \
" \
-threads 4 -c:v libx264 -preset faster -tune film \
-x264opts ref=4:bframes=4:direct=auto:aq-strength=1.3 \
-c:a libaacplus -b:a 32k -ar 48k -ac 2 -f matroska \
-ar 48k -ac 2 -b:a 32k -b:v 900k out.mkv

Se invece dovete unire più video omogenei (stesse dimensioni e codec) senza ricodifica,
potete usare il demuxer concat creando un file

lista.txt

contenente

# this is a comment
file '/path/to/file1'
file '/path/to/file2'
file '/path/to/file3'

e poi eseguite:

ffmpeg -f concat -i lista.txt -c copy output

esempio:
lista.txt

# commento
file 1.avi
file 2.avi
file 3.avi

e poi

ffmpeg -f concat -i lista.txt -c copy out.avi

Maggiori info qui.