
Il team di sviluppo di FFmpeg ha annunciato che hanno già scritto una nuova implementazione nativa del decoder di Vp8 con sole 1400 linee di codice nativo.
Questo risultato è stato ottenuto grazie alle somiglianze fra Vp8 e H.264 che ha consentito il riutilizzo del codice e, quindi, anche delle ottimizzazioni. Al momento il risultato è uguale a quello prodotto da libvpx di Google, ma gli sviluppatori sono confidenti di riuscire a superare le prestazioni del progetto originale in poco tempo.
Questa nuova implementazione consentirà di far maturare lo standard che nelle specifiche attuali è un po’ un cut&paste dei sorgenti del decoder originale. Se lo sviluppo procede con questo ritmo sarà interessante vedere cosa ci riserva il prossimo futuro.
Via | Gnome
pizzuco
28 giu 2010 - 16:47 - #1Ci vorrebbe una bella *fondazione* che coordinasse tutto come patrimonio e conoscenza dell’umanità.
as1a
28 giu 2010 - 16:48 - #2Il fatto che abbia così tanto codice condiviso mi preoccupa un pochino. Il decoder originale è più di 10 mila righe di codice e questo solo 1400. Una cosa del genere potrebbe andare a favore di mpeg-la in caso di una causa legale per brevetti.
sandro-kensan
28 giu 2010 - 23:54 - #3Che c’entra la brevità del codice di VP8 con Mpeg-la?
darkbasic
29 giu 2010 - 01:47 - #4C’entra che la brevità del codice è dovuta al pesante riutilizzo del codice di x264.
Andrea R
29 giu 2010 - 08:57 - #5Però è incredibile il talento di questa gente. I migliori programmatori sono nell’open source! La brevità del codice è dovuta alla bravura ed all’assenza di ottimizzazioni e gestione di situazioni particolari.
Darkbasic ha colto un aspetto forse rilevante, comunque c’è un altro file di 500 righe con funzioni matematiche specifiche. MPEG-LA è parte di un problema più grande e possiamo anche sperare che porti ad una sorta di guerra totale di brevetti e aiuti a buttare giù tutto il castello di carte che è stato costruito. I loro brevetti coprono fondamentalmente qualsiasi codec moderno a quanto pare.
sandro-kensan
29 giu 2010 - 17:40 - #6@ darkbasic
non è scritto e non credo che ci siano parti di codice comune tra VP8 e H.264 credo che ci siano delle parti di software che non riguardino propriamente la tecnologia di compressione e di decompressione come specificato dal comunicato in cui si cita la “intra prediction” che probabilmente è una predizione del prossimo frame:
* we can share code (and more importantly: optimizations) between FFmpeg’s VP8 decoder and decoders for previous versions of the VPx codec series (e.g. the entropy coder is highly similar compared to VP5/6). Thus, your phone’s future media player will be smaller and faster.
* since H.264 (the current industry standard video codec) and VP8 are highly similar, we can share code (and more importantly: optimizations) between FFmpeg’s H.264 and VP8 decoders (e.g. intra prediction). Thus, again, your desktop computer’s future media player will be smaller and faster.
* Since FFmpeg’s native VP3/Theora and Vorbis decoders (these are video/audio codecs praised by free software advocates) already perform better than the ones provided by Xiph (libvorbis/libtheora), it is highly likely that our native VP8 decoder will (once properly optimized) also perform better than Google’s libvpx. The pattern here is that since each libXYZ has to reinvent its own wheel, they’ll always fall short of reaching the top. FFmpeg comes closer simply because our existing wheels are like what you’d want on your next sports car.
* Making a video decoder is fun!
È interessante come le “well” siano quelle a partire da VP3 e con quelle si facciano tutti i codec fino al VP8, interessante il fatto che VP3 nasca molto prima di H.264 e quindi i brevetti USA sono di Xhip foundation. Questno viene sempre taciuto quando si parla di somiglianze tra VP8 e h.264.
sandro-kensan
29 giu 2010 - 17:44 - #7Scusate, errata wheel.