ELV - codec lossless libero

La prima fase del progetto ha riguardato la ricerca e analisi delle soluzioni esistenti. In particolare nel (non troppo variegato, in realtà) panoramama dei codec video lossless sono stati scelti quelli che rispondevano alle seguenti caratteristiche:

  • Lavorano in RGB
  • Sono multipiattaforma
  • Hanno una implementazione open source (anche se la licenza può essere restrittiva)

I candidati selezionati sono Huffyuv, H.264 lossless e ffv1.

L'obiettivo quindi è stato ottenere un codec che avesse performance più soddisfacenti delle soluzioni esistenti, a livello sia del rapporto di compressione sia delle prestazioni in riproduzione.

Durante tutta la fase di sviluppo e testing la sorgente principale utilizzata è stata un estratto dal video Tears of steel realizzato dalla Blender Foundation, di cui sono disponibili i singoli fotogrammi in formato PNG. Questo video è anche stato utilizzato per i primi confronti con gli altri codec considerati.

La fase di implementazione si è concentrata all'inizio sulla scelta delle tecnologie da utilizzare: il linguaggio di programmazione (C), i tipi di filtri, l'algoritmo di codifica dell'entropia (LZMA), il formato contenitore (custom), il build system (make). È stata data molta importanza alla scelta di un design parallelizzabile in modo efficiente, alla riduzione al minimo delle dipendenze a runtime e alla modularità del progetto. Il nome prescelto è ELV, acronimo di Efficient Lossless Video.

Una volta fissati i componenti e le tecnologie di fondo è iniziata la parte algoritmica vera e propria, che si può considerare suddivisa in tre sezioni:

  • La libreria libelv, che da un lato esporta funzioni per organizzare, codificare e quindi comprimere un insieme di fotogrammi e per disporre il risultato nel contenitore, mentre dall'altro implementa un parser, un decompressore e varie funzioni di ricostruzione per invertire il processo e riottenere i singoli fotogrammi non compressi: è scritta in ANSI C puro e ha come unica dipendenza la liblzma, è quindi portabile su praticamente qualsiasi sistema operativo. Inoltre tutte le funzioni sono thread-safe. Alla libreria si accompagna un header pubblico (elv.h) che permette a terzi di scrivere facilmente programmi che sfruttano il codec e/o il contenitore ELV.
  • L'eseguibile elvc, il cui scopo è leggere una cartella contenente un insieme di fotogrammi e da questi produrre in output un video in formato elv. Si appoggia alla libelv descritta sopra, si occupa di gestire un insieme di dimensione variabile di worker threads che si occupano dei calcoli veri e propri, nonché di serializzarne il risultato e produrre un file elv corrispondente alle specifiche. Per il suo utilizzo dei pthreads richiede un sistema compatibile POSIX.
  • L'eseguibile elvplay, ovvero un basico lettore multimediale che è in grado di riprodurre un file generato da elvc. Anch'esso completamente parallelizzato, oltre a libelv si serve di SDL2 per interagire col server grafico e mostrare a schermo i fotogrammi una volta ricostruiti. Allo scopo di avere una riproduzione il più possibile fedele, vengono utilizzati i timer ad altissima risoluzione (un nanosecondo) forniti dai sistemi POSIX moderni. Inoltre, l'utilizzo estensivo della tecnica del memory mapping rende consigliabile l'utilizzo di un sistema a 64 bit se si lavora su file di dimensioni medio-grandi.

Una volta ottenuto un sistema funzionante, stabile e sufficientemente performante sono iniziati i confronti con le altre soluzioni considerate, che hanno dato risultati preliminari promettenti:

GB in output (ratio) Realtime play Fps in codifica
ELV 7.01 (32%) Si 0.5
HuffYUV 11.21 (52%) Si 11.0
H.264 lossless 8.19 (38%) Si 8.1
Ffv1 6.42 (29%) No 5.7

A questo punto si è verificato il panorama legale della situazione, allo scopo di controllare l'esistenza di brevetti che potessero in qualche modo impedire l'implementazione. Sono stati utilizzati sia il motore di ricerca del USPTO (United states patents and trademark office) sia Google Patents. Fortunatamente la maggior parte dei brevetti sembrano riguardare soluzioni lossy, oppure sono scaduti negli ultimi anni.

L'ultima parte del lavoro ha riguardato i posssibili sviluppi futuri, allo scopo individuare tecniche per migliorare sia le performance sia il rapporto di compressione. Queste le possibili strade individuate:

  • Un sistema di motion compensation più sofisticato (three-step-search)
  • Double buffering in riproduzione
  • Utilizzo di una coda e di un thread-pool per massimizzare l'uso del processore in compressione, in particolare durante le fasi di I/O

Download ultimo snapshot Download della tesi

tesi/elv.txt · Last modified: 2016/04/17 19:31 by alberto.mattea
CC Attribution-Share Alike 4.0 International
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0