Compressione dei filmati: dall'H.261 all' MPEG4 AVC

Compressione dei filmati: dall'H.261 all' MPEG4 AVC

Segnaliamo un interessante articolo in italiano sulle compresisoni video più recenti

di pubblicata il , alle 17:19 nel canale Programmi
 
26 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
frankie29 Dicembre 2003, 23:41 #11
Originariamente inviato da tarun
Vorrei provare quei codec di cui si parla nell'articolo di lithium che si chiamano trasformate vavelet o qualcosa del genere ma non sò dove trovarli


Se il codec MPEG X è basato sulla discrete cosine trasform cioè sulla idct che poi è la stessa che sta alla base del JPEG

H264 è basa to sulla wavelet transform, alla base del jp2 cioè del jpeg2000 (visionabile sempre su lithium)

Questo spiega il maggior tempo necessari alla codifica, ma con tutti i vantaggi della tecnologia jpeg2000 in fase di streaming e di decompressione (meno gravosa)

Il problema di questi nuovi codec è la penetrabilità del mercato... già il jpeg2000 sarebbe una manna dal cielo per PDA cellulari e macchine fotografiche
MA
la potenza di calcolo e la diffusione popolare del formato ne limitano l'uso stesso, anche se molti lettori di immagini lo supportano
Kicco_lsd30 Dicembre 2003, 01:09 #12
se tutta italia avesse la 1200 la RIAA arriverebbe con i le bombe nucleari
Tolto questo bella news, mi affascina il mondo degli algoritmi di compressione!
cdimauro30 Dicembre 2003, 07:25 #13
Originariamente inviato da frankie
Questo spiega il maggior tempo necessari alla codifica, ma con tutti i vantaggi della tecnologia jpeg2000 in fase di streaming e di decompressione (meno gravosa)

Sto lavorando a un decoder JPEG 2000 per la mia tesi di laurea, e non mi sembra che la fase di decompressione sia meno gravosa. Al contrario, l'utilizzo dell'EBCOT come algoritmo per la codifica entropica & aritmetica mi sembra decisamente più oneroso in termini di tempo di calcolo rispetto al Run-Length & Huffman utilizzati finora dai vari JPEG e MPEG... Senza contare che EBCOT suddivide le informazioni in "bitplane", mentre attualmente vengono utilizzati direttamente i coefficienti quantizzati e passati direttamente a RLE & Huff.
Il problema di questi nuovi codec è la penetrabilità del mercato... già il jpeg2000 sarebbe una manna dal cielo per PDA cellulari e macchine fotografiche

Lo sarà in un futuro non molto lontano: il decoder (e l'encoder, di cui si occupa un altro staff) è stato commissionato da una multinazionale che si sta cominciando a muovere in questa direzione...
frankie30 Dicembre 2003, 10:14 #14
io ho preso per buono quanto riportato da lithium, ma penso che tu ne sappia ovviamente di più!
avvelenato30 Dicembre 2003, 10:32 #15

erpazzo

credo che la mia fosse la speranza che questo meraviglioso standard non faccia la fine dell'OGG (bellissimo formato difficile da supportare via hw; le uniche che ci hanno provato, iRiver ad esempio, vedono il consumo energetico raddoppiare)

comunque in effetti non so per quale motivo ho diretto il messaggio proprio a te! forse prima di scrivere quel commento ne avevo scritto un altro, forse avevo quotato qualcosa di tuo per commentarlo.. giuro che non ricordo, chiedo venia!

avvelenato sempre più sconfusionato
gia1230 Dicembre 2003, 11:17 #16
Giusto 2 giorni fa avevo provato a encodare lo stesso piccolo file con 7 codec: divx, xvid, wmv 9, real 9, flash streaming, vp6 e H.264. 5 ad occhio si equivalgono, mentre il flash streaming è chiaramente peggio e l' H.264 è chiaramente meglio, oltre che lentissimo. Anche qui http://www.divxmania.it/articolo/3889 c'è un articoletto (con errori di ortografia inglese) e mi era venuta voglia di provare 'sti codec ancor + avanzati basati su wavelet transformation, ma ne ho trovato, forse, solo uno per linux, forse. Ma quando si parla di "streaming"....in che senso con un codec come H.264 che crea un normale file avi, e non real o wmv o flash o quicktime.....in che senso "streaming"?
lucusta30 Dicembre 2003, 11:51 #17
la codifica software in tempo reale gia' con l'mpeg4 e' abbastanza gravosa (richiede minimo un pc 1.2 ghz su formati di 352x288 con audio mono a 22khz), applicare un algoritmo che considera l'intera forma d'onda invece che il solo intorno dei punti e' come passare nel campo grafico dal 2D al 3D, percio' la considerazione che il costo di potenza sia superiore di un rapporto 1 a 3 e' quasi ottimistica.
Ad oggi solo con HW dedicato si potrebbe concepire un uso pratico in real-time, sia in codifica che decodifica combinata, e credo che solo con PC di ultima generazione (quelli che si trovano solo sui listini, e non nella classica distribuzione), potrebbe diventare fattibile.
Comunque basta aspettare l'adeguamento naturale degli entry-livel sia HW che per le telecomunicazioni per farla diventare operativa.
Ricordo che quando codificai il mio primo mpeg4 ci misi 8 ore e nel leggerlo perdevo qualche frame, oggi lo faccio in 30 minuti e lo leggo con un PDA.
Fa' solo impressione pensare che ci vorra' un PDA da 1.5 ghz per leggere i nuovi formati, ma credo anche che siano gia' in studio.
M8630 Dicembre 2003, 13:37 #18
non è che qualcuno può postare il link da cui scaricare questo codec?
gia1230 Dicembre 2003, 13:44 #19
ErPazzo7430 Dicembre 2003, 18:04 #20
x avvelenato:
fa' niente! ciaozzzz

x lucusta:
dipende molto dal programma (e quindi dall'implementazione del codec) che usi come puoi vedere nel mio primo post quel che dici non e' vero.
Il mio XP acquisisce dalla scheda TV e in tempo reale comprime alla risoluzione di 768x576 col 50% di occupazione cpu. Per acquisite a 352 basta molto - di 1.2Ghz, considera che la complessita' cala col quadrato.

Auguri ragazzi!

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^