Link alla notizia: http://news.hwupgrade.it/11509.html

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

Click sul link per visualizzare la notizia.

Concordo in pieno.....

Vorrei dire che in linux con mplayer e un xp 1600+ e kt266A comprimo a 50fps x cui se e' vero che richiede il 300% di risorse CPU rispetto a mpeg4 direi che la compressione software e' teoricamente possibile, considerando una cpu tipo P4 o FX con Dual Channel, SSE2,cache + grandi, bus a 800Mhz e clock di 3.2Ghz teorici o PR-Rated.
Certo lo faranno solo in pochi :(, ma almeno loro si divertiranno ;).
Comunque tutti i dati riportati da lithium riguardano compressioni sino a 100Kbit, sarei curioso di sapere a 1000Kbit come si comporta anche se dalla curva sembra che all'aumentare della banda aumenti anche il vantaggio del nuovo codec.
Sarebbe anche interessante vedere le immagini dei filmati che genera a 100Kbit, no?

cosssssssssssa? si son decisi finalmente ad aggiungere qualcosa su litium? sembra quasi strano!

con il dispendio di energia necessario, è sicuramente improponibile un codec del genere allo stato attuale in dispositivi embedded

avvelenato che cercava giusto una videofotocamera su SD

nessuno ti vieta di collaborare :D

il problema della potenza di calcolo e' facilmente aggirabile, la reale questione e' se c'e' un necessita' di avere un nuovo formato di compressione, in realta' qualunque formato sia possibile codificarlo mediante DSP puo' essere codificato in hardware, il mpeg2 gia' si pone come standard per qualunque tipo di compressione video ben superiore al mpeg4, forse piu' in la' tutti vorremo il mpeg5....al posto degli attuali divx, ma allora i DVD a cosa servono se su un cd posso metterci un film intero di pari qualita'?!?!
ad ogni modo xvid,divx,mp1,mp2, poi alla fine tutti preferiscono il mJpeg o addirittura l'uncompressed per lavorare visto che sistemi con un tera di memoria fissa e 2 giga di ram sono alla portato di un utente medio e non di uno studio di produzione.....
per noi comuni mortali i divx funzionano bene ma anche i mpeg2 con quel che costano oggi i masterizzatori dvd non e' una scelta tanto sbagliata....

L'articolo l'ho letto prima che uscisse su HWupgrade ..:D
Mi sono cercato subito sto codec H.264 è ho trovato il vanguard VSS H.264 che ho immediatamente provato .
L'ho testato sul vob3(circa 850MB) di blackhawkdown (xmpeg 5.03-aviwriter)
con un bit rate di 500kbit (no audio/si resize/720x576 block16) .
Dopo 3h30' di codifica (athlon XP 1900+ ,ecsk7s6a,1giga ram etc)
ho ottenuto un file di 80MB che paragonato a il medesimo in divx 5.1.1 presenta una evidente minore blocchettizzazione.
comunque c'è da dire che il divx è risultato di 75mb .(forse la discrepanza in mega tra le due codifiche è in parte colpa mia per aver settato VSS keyframe every 30fps e divx5.1.1 keyframe max 300)
I setytaggi delcodec VSS erano pochi tuttavia non ho capito cos'era il quantizer che escludeva la scelta del bitrate e nemmeno come attivare un dual pass.
Con divx 5.1.1 ho codificato il medesimo file in 40 minuti utilizzando l'algorithmo MIHA e settaggi standard.
La mia inmpressione è stata positiva riguardo la qualità ottenuta specie ad alta compressione ma non è fruibile per il notevole tempo di codifica richiesto.
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:rolleyes:

la reale questione e' se c'e' un necessita' di avere un nuovo formato di compressione,
ADSL 256........640 =video ONdemand ovviamente compressi a sufficienza per far stare in 500kbit sia video che audio.
So che telecom sta testando i codec e precisamente wmv real8
quictime mpeg-4 , H.264 .
500kbit è un bit rate scelto per garantire uno streaming senza troppi problemi in caso di congestione.
Gli UP a 256 una necessita per evitare che i pacchetti di risposta (vedi protTCPIP) di una contemporanea navigazione internet blocchino lo streaming.
Una vocina mi dice che se non sara sufficiente l'upgrade a 640 verra portato a 1200(ma non ci conterei troppo)
:oink:

bah...
bei sogni... al momento ci manca tutto l'hw per leggerlo nei lettori da casa e le reti per usarlo... sopprattutto in italia...
Se solo la telecom si decidesse a investire di più nelle SUE reti...
Sono curioso di vedere quanti anni ci vorranno ancora perchè fuori città si possa avere un'alternativa al modem analogico...

-__-*

x avvelenato:
non ho capito il tuo commento!

comunque il tempo di compressione dipende anche dalla risoluzione ovviamente io mi riferivo a 768x576 acquisito dalla mia scheda tv.
I sistemi embedded attuali sono anche 400mhz e forse acquisendo da una scheda tv teorica alla risoluzione di un embedded (mi sembra massimo 640x200 o qualcosa di simile) forse ce la farebbero, certo attaccati alla spina ;)!

x tarun:
ho gia' visto molte tv dall'america in streaming a 500kbit non so' che formato usavano (mi sembra real) la qualia' era discreta, certo questo nuovo codec promette di migliorarla di 1 bel pò.
riguardo telecom aggiungo che quando uscirono le prime adsl x tutti (256/128) avevo ancora una 640/128 e devo dire che mi dispiacque passare a 256 xche' perdevo la maggior parte dei servizi di streaming (che sono tra i 300 e i 500kbit) ma il portafoglio ne fu grato :D!

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:rolleyes:

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

se tutta italia avesse la 1200 la RIAA arriverebbe con i le bombe nucleari :D
Tolto questo bella news, mi affascina il mondo degli algoritmi di compressione!

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... ;)

io ho preso per buono quanto riportato da lithium, ma penso che tu ne sappia ovviamente di più!

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

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"?

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.

non è che qualcuno può postare il link da cui scaricare questo codec?

http://www.vsofts.com/codec/h264.html

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!

Originariamente inviato da lucusta
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),[/b]

anche meno, credo: http://ffmpeg.sf.net

grazie mille
Ho anche un'altro problema
DVD2AVI non mi da errore e chiude l'applicazione che software mi consigliate di usare con l'H264, quanto meno voglio vedere com'è

Bisogna considerare l'uso pratico che ne farebbe un utente "medio" su una macchina 1.2 ghz quando questa era una configurazione entry-livel (in pratica si parla di duron e celeron da 1 ghz a 1.5 ghz) poco ottimizzata e carica.
Del tipo: installo il software in dotazione, spingo il bottone in basso a destra, e funziona.
La diffusione di questo codec con questa funzione e' legata appunto alla potenza dei PC entry-livel usati da utenti normali, e si avra' nel prossimo anno con cpu da 3ghz.
Vi ricordo che si parla di streaming in real-time, modalita' usata per servizzi in boardcasting di larga diffusione, soprattutto come WebTV e teleconferenza, e non di un ripp da dvd.

Prova ad usare virtualdub a me funge senza problemi.
Comunque ho notato che tende (VSSH.264)a creare file con un bitrate maggiore di quanto impostato (GSPOT 2.21).
Ho pure verificato che la decompressione è si meno gravosa della compressione ma comunque mi ciucciava il 100% di cpu contro un 33%medio richiesto da dvd(vob) o divx5.1.1(moltosimili)
Athlon xp 1900+(1600ghz)+1giga ram+ecsk76a

Finalmete mpeg4 mi aveva un po deluso allora questo nuovo formato credo nn lo farà

Originariamente inviato da azrael
cosssssssssssa? si son decisi finalmente ad aggiungere qualcosa su litium? sembra quasi strano!

se paghi te per gli articoli ne mettiamo anche uno la mese
:rolleyes: