Tecnologia e non solo

maggio 12, 2013

VP9 è “quasi” pronto?

Filed under: Debian,Video — telperion @ 3:53 pm

VP9 Codec Nears Completion

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

ffmpeg version 1.1.git-cd43a7e Copyright (c) 2000-2013 the FFmpeg developers
built on May 12 2013 13:44:36 with gcc 4.7 (Debian 4.7.3-3)

Input #0, matroska,webm
Duration: 00:44:05.50, start: 0.000000, bitrate: 846 kb/s
Stream #0:0(eng): Video: h264 (High), yuv420p, 720x404, SAR 1:1 DAR 180:101, 25 fps
[libvpx-vp9 @ 0x20da340] v1.2.0-2099-gb4e3909
Output #0, matroska, to '/dev/null':
Stream #0:0(eng): Video: vp9 (libvpx-vp9) ([255][255][255][255] / 0xFFFFFFFF), yuv420p, 720x404 [SAR 1:1 DAR 180:101], q=-1--1, pass 1, 600 kb/s, 1k tbn, 25 tbc (default)

frame= 748 fps= 49 q=0.0 Lsize= 1kB time=00:00:00.00 bitrate=N/A
video:0kB audio:0kB subtitle:0 global headers:0kB muxing overhead inf%

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

ffmpeg version 1.1.git-cd43a7e Copyright (c) 2000-2013 the FFmpeg developers
built on May 12 2013 13:44:36 with gcc 4.7 (Debian 4.7.3-3)

Input #0, matroska,webm
Duration: 00:44:05.50, start: 0.000000, bitrate: 846 kb/s
Stream #0:0(eng): Video: h264 (High), yuv420p, 720x404, SAR 1:1 DAR 180:101, 25 fps
[libvpx-vp9 @ 0x20da340] v1.2.0-2099-gb4e3909
Output #0, matroska, to 'out2.mkv':
Stream #0:0(eng): Video: vp9 (libvpx-vp9) ([255][255][255][255] / 0xFFFFFFFF), yuv420p, 720x404 [SAR 1:1 DAR 180:101], q=-1--1, pass 2, 600 kb/s, 1k tbn, 25 tbc (default)

frame= 748 fps=1.9 q=0.0 Lsize= 2193kB time=00:00:30.00 bitrate= 598.9kbits/s
video:2187kB audio:0kB subtitle:0 global headers:0kB muxing overhead 0.282936%

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

frame= 748 fps= 79 q=0.0 Lsize= 1kB time=00:00:00.00 bitrate=N/A
video:0kB audio:0kB subtitle:0 global headers:0kB muxing overhead inf%

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

frame= 748 fps=106 q=0.0 Lsize= 2201kB time=00:00:30.00 bitrate= 601.0kbits/s
video:2195kB audio:0kB subtitle:0 global headers:0kB muxing overhead 0.282946%

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

frame= 748 fps=290 q=-1.0 Lsize= 2229kB time=00:00:30.00 bitrate= 608.6kbits/s
video:2223kB audio:0kB subtitle:0 global headers:0kB muxing overhead 0.279619%

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

frame= 748 fps=147 q=-1.0 Lsize= 2219kB time=00:00:30.00 bitrate= 605.9kbits/s
video:2213kB audio:0kB subtitle:0 global headers:0kB muxing overhead 0.280793%

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

Annunci

2 commenti

  1. Ho letto una decina di articoli vari su VP9, tutte “annunciazione annunciazione” è giù a leccare il deretano a BigG, ci fosse UN CANE che ha fatto un test per verificare le “annunciazioni” di cui scrive, ecchekkk..
    Comunque qua la roadmap:
    https://groups.google.com/a/webmproject.org/forum/?fromgroups=#!topic/webm-discuss/UzoX7owhwB0
    A fine maggio farò un altro test e vediamo se le cose migliorano.

    Commento di telperion — maggio 13, 2013 @ 10:51 pm

  2. Tu sei il cane pioniere 😀
    Sempre interessanti prove sul tuo blog…sprattutto quello di gimp con le fighe da paura ahah

    Commento di Luigi — maggio 20, 2013 @ 11:09 am


RSS feed for comments on this post.

%d blogger hanno fatto clic su Mi Piace per questo: