Newsgroup: it.comp.software.divx
Titolo: Dimensione file da DIVX a MPEG

Ciao a tutti,
non sto a tediarvi con la solita solfa "come faccio a passare da DIVX a
DVD?", ho solo una semplice domanda: è normale che, trasformando un DIVX in
MPEG2 le dimensioni del file aumentino, oppure dovrebbe restare uguale
[tipo: DIVX 800MB=MPEG 800MB], e in quel caso sto sbagliando qualcosa?
Grazie a tutti, JollyRoger.

 aumentino
Se pensi che un normale film di due ore sta in un DVD doppio strato
(fino a 9 GB)...
-- 
Saluti, Kap - ICQ 19857429 - ¥'s Fan #01 - 
www.lordkap.it
 - VCC
Fai agli altri quello che farebbero a te. - Richard M. Nixon

 (fino a 9 GB)...
Si, questo è vero... ma è anche vero che un DVD ha varie "cose" [chiedo
scusa per il linguaggio per niente tecnico] che il DIVX non ha... e poi il
DIVX è compresso mentre i file DVD no [un pò come paragonare MP3 e WAVE, o
BITMAP e JPEG], ecco perchè, comprimendo appunto il DVD in DIVX, ed
eventualmente levando audio, sottotitoli e altre cose, scendiamo anche a
7/800MB.
Ma se si fa il percorso inverso, cioè si parte da un DIVX, quindi già
compresso e via dicendo, e lo si trasforma in file .mpeg, non dovrebbe
rimanere delle stesse dimensioni?
Alla fine dei conti, cioè che è stato "eliminato" con la compressione, non
lo si può ricreare, no?
Bada bene, se lo chiedo è proprio perchè, non essendo esperto, non so se sto
dicendo cose giuste o cavolate.
Ciao, JollyRoger.

 e poi il DIVX è compresso mentre i file DVD no
Appunto. Quindi il formato MPEG2 è un formato che, a parità di qualità,
richiede una dimensione del filmato molto più grande.
Quindi se passi dal Divx all'MPEG2 ti dovrai aspettare una crescita
della dimensione. A meno che tu non voglia lasciargli lo stesso bitrate
(in quel caso allora risulteranno uguali), ma poi la qualità sarà
infima.
-- 
Saluti, Kap - ICQ 19857429 - ¥'s Fan #01 - 
www.lordkap.it
 - VCC
Meglio desinare ad erbe dove regna l'amore,
che avere un bue nella stalla dove governa l'odio. - Proverbi 15, 17

 lo si può ricreare, no?
Qui ti sbagli, infatti la compressione non elimina, ma, appunto, comprime.
Per fare un esempio banale:
- "tatatatatatatatatata" (formato non compresso)
- 10"ta" (formato compresso)
Se torni al formato non compresso ovviamente le dimensioni torneranno ad
essere quelle originali.
In realtà questo non è del tutto esatto (ci sarebbe da parlare per mezz'ora)
ma dà l'idea...

 ma dà l'idea...
Non è che non sia "del tutto esatto", è "del tutto sbagliato"!
Non ci vuole mezz'ora basta ricordare che il concetto di compressione negli
algoritmi video e audio si basa sulle nostre percezioni, quindi viene
eliminato tutto ciò che il nostro occhio non può vedere, o il nostro
orecchio non può sentire. Per questo si parla di codec lossy, cioè a
perdita di informazioni, al contario dei compressori non lossy che
necessariamente non perdono nulla, come zip, rar, 7zip e altri.
Quello che hai riportato tu è un esempio di compressione non lossy con la
quale otterresti ben poco, prova a comprimere un video con rar...
Bye, Giubbe
-- 
HomePage e FAQ: 
http://giubbe.altervista.org
Inutile scrivere in privato, non ricevo le email

 BITMAP e JPEG],
Sbagliato. Il DVD è compresso, tanto è vero che occupa solo 9GB al posto
dei circa 50GB del video non compresso (come bitmap o wave).
La grandezza del file finale dipende solo dalla durata del file e dal
bitrate scelto, come giustamente sottolineato da Lord.


 quale otterresti ben poco, prova a comprimere un video con rar...
Ovviamente sě, ma la ragione č che (come ho giŕ spiegato sopra) negli
algoritmi lossy i due tipi di compressione si sovrappongono.
La prova che dovresti fare č quella di provare a salvare un file video in
formato RGB non compresso e provare poi a zippare il tutto, in quel caso la
differenza si vede eccome!

 comprime in 3 dimensioni mentre mpeg solo in 2).
cosa intendi con 2 o 3 dimensioni?
imho, il fattore che piu' influisce sulla "economia" dei DivX rispetto ai
DVD e' il basso rapporto medio tra numero di keyframes e numero totale di
frames: nei DVD tale rapporto e' fisso, uno stream video e' una sequenza
di GOP (group of pitcures), che hanno tutti questo schema: IPPPPPPPPPPPPP
di preciso non so quali siano i vincoli, ma quando testavo la libreria
libmpeg2 riscontrai (su tutti i miei DVD) che il pattern era sempre lo
stesso... quindi il rapporto tra I-frames e P-frames e' costante e
abbastanza alto (1/13 o 1/14...); nei DivX, invece, in media tale rapporto
e' molto piu' basso: di solito, nei codec come DivX e XviD all'utente e'
consigliato di impostare un certo parametro "max key int" a un valore pari
a circa 10 volte il framerate (i valori piu' usati sono 250 e 300); tali
codec usano questo criterio per decidere quando codificare un frame come
I-frame:
- se i precedenti "max key int" frames non sono I-frame, allora il
  successivo viene codificato come I-frame;
- se dall'analisi dei vettori movimento risulta che non c'e' convenienza
  a codificare il corrente frame come P-frame, allora viene codificato
  come I-frame (cio' avviene solitamente quando c'e' stato un cambio di
  scena nel film, uno stacco nelle riprese) e i codec permettono all'utente
  di regolare un parametro "threshold" ("soglia") di "scene change
  detection"
gli I-frame tipicamente occupano molto piu' spazio dei P-frame (i B-frame
occupano ancora meno), quindi, questa strategia comporta una discreta
riduzione dello spazio occupato, nella maggior parte dei DVD convertiti
in DivX (senza considerare altri fattori)

 differenza si vede eccome!
Ok, ma cosa vuoi dimostrare? Tu dicevi che il divx è un algoritmo non lossy
e questo è palesemente sbagliato.
Comunque lo sto facendo, per ora sono passato da 127 MB a 4,1GB, adesso sto
comprimendo con rar e ci vuole una mezz'ora. Non ho tempo di aspettare,
qusta sera ti dierò quanto ha compresso.
Bye


 infima.
Perfetto, quello che volevo sentire. ^_______^
Grazie!

 terra della domanda non ho ritenuto fosse il caso.
Infatti, io stavo solo chiedendo conferma che fosse normale l'aumento di
dimensioni del file passando da un DIVX ad un MPEG.
Puro e semplice, senza disquisizioni tecniche. ;-)
Ciao!

 bitrate scelto, come giustamente sottolineato da Lord.
Ok, grazie.
Saluti!

 frames:
Molto interessante come teoria... sarebbe utile poter valutare la curva di
degradazione della qualità in rapporto al variare del "max key int" su un
filmato tipo... (più facile a dirsi che a farsi).
Tempo fa avevo fatto qualche prova, e mi era sembrato che, nel range
30 -300, a parità di bitrate non vi fossero grandi variazioni di qualità
mentre scendendo al di sotto dei 30 la degradazione risultasse evidente,
però la valutazione l'ho fatta a occhio e quindi vale quello che vale.
Se hai qualche link a test più seri del mio...

 qusta sera ti dierò quanto ha compresso.
Beh, potevi usare un file più piccolo, comunque, come stasera avrai modo di
notare, la riduzione di dimensioni si attesterà intorno al 70% almeno,
questo è la dimostrazione che la compressione standard ha tutt'altro che un
ruolo marginale nella compressione dei files multimediali.

filmato tipo... (più facile a dirsi che a farsi).
Ecco una valutazione oggettiva.
Questi i dati:
File originale di partenza 5384 frames per 156KB
mpeg2source("F:\clip\prova.d2v")
crop(10,0,702,572)
LanczosResize(608,448)
Tutti i file sono stati codificati senza b-frame con quality 2, in modo da
valutare solo l'influenza del keyframe.
Codifica a 1 keyframe per frame: Totale keyFrame 5384 per 356KB
Codifica a 30 Keyframe per frame: Totale keyFrame 238 per 99KB
Codifica a 300 keyframe per frame: Totale KeyFrame 71 per 80 KB
Codifica a 3000 keyframe per frame: Totale KeyFrame 62 per 79 KB
Il numero reale di keyframe varia rispetto a quello inserito perchè il
codec decide da solo dove metterlo, se lo ritiene necessario (come diceva
Frank).
Visivamente non ho riscontrato alcun cambiamento. Ho calcolato il SSIM:
1--> 0.983164     
30 --> 0.980727
300--> 0.979469
3000-> 0.979392
Come si vede all'aumentare del keyframe diminuisce un po' la qualità (il
valore ottimale è 1). E' una differenza così ridotta che il lieve benificio
introddotto dai pochi keyframe non riesce ad alleviare il grosso diffetto,
cioè la necessità di un computer veloce e la ridotta possibilità di seek.
Il keyframe singolo non l'ho scelto a caso, al contrario degli altri bassi,
è l'unico che in alcune circostanze è usato nella codifica reale.
Bye


 156KB
Scusate, ovviamente le dimensioni sono in Megabyte, non in Kbyte. Sorry.
Bye, Giubbe


 ruolo marginale nella compressione dei files multimediali.
Questo non dimostra un bel niente, anzi visti i risultati conferma quanto
ho detto all'inizio, e cioè che la compressione non lossy (se c'è) è molto
molto marginale. Ti spiego.
Il file che ho trattato è lo stesso dell'altro post (mi devo scusare per le
dimensioni, quelle corrette sono 157 MB). Questo file è passato da 157 MB a
4,1 GB (non compresso) e da qui è diventato 1,4GB compresso con RAR. Lo
stesso file compresso alla massima qualità (standard, keyframe 300) è
diventato 79 MB. Ora come è possibile che la compressione standard (non
lossy) influisca per il 50% ("importanta equiparabile") quando esiste una
differenza così marcata tra il rar e il DivX?
Bye, Giubbe


 Se hai qualche link a test più seri del mio...
nope

 cioè la necessità di un computer veloce e la ridotta possibilità di seek.
a questo punto non ho mica capito qual e' il valore migliore da usare :-)

 3000-> 0.979392
Vogliate scusarmi, per un non precisato motivo quella ciofeca di codec mi
si è resettata durante la terza e quarta codifica, reintroducendo i
keyframe. I valori corretti sono:
Codifica a 300 keyframe per frame: Totale KeyFrame 86 per 92 MB
Codifica a 3000 keyframe per frame: Totale KeyFrame 77 per 91 KB
300 --> 0.980318
3000 --> 0.980222
Ricapitolando:
1--> 0.983164     
30 --> 0.980727
300 --> 0.980318
3000 --> 0.980222
Quindi le conclusioni restano inalterate. Volendo, questo è servito a
dimostrare come l'introduzione del b-frame riduca (di poco) la qualità.
bye


 a questo punto non ho mica capito qual e' il valore migliore da usare :-)
Quello che hai sempre usato, un valore compreso tra 250 e 300. Riservando
il keyframe per ogni frame (1) per casi particolari.
Come giustamente sottolineavi tu nlla codifica a bitrate fisso il codec non
può rispettare tutte le condizioni che gli vengono imposte e non è detto
che la qualità rimanga inalterata al variare del numero di keyframe. Sai
che ti dico? Ora ci provo, voglio vedere cosa combina se gli impongo una
dimensione finale di 50MB!


> se dici "a parita' di bitrate" e' normale che la qualita' peggiori:
Infatti, è quello che si voleva ottenere nel test, quello che mi chiedevo è:
qual'è la curva "max keyframe" /qualità?
Dal test di giubbe sembra che la curva sia logaritmica (cosa che ci si
aspettava), per cui si dovrebbe poter trovare un "max keyframe" minimo oltre
il quale la qualità (o, a parità di qualità, le dimensioni) si riducono
rapidamente.
IMHO 300 frame sono troppi per ottenere un agile seek, credo che, valutando
i dati di quel test (ma anche dalle mie prove empiriche), un valore di
compromesso accettabile potrebbe assestarsi tra i 30 e i 60 frame.

 compromesso accettabile potrebbe assestarsi tra i 30 e i 60 frame.
Purtroppo un valore basso di keyframe per intervallo (intendo il valore da
mettere nella casella) produce un file facilmente leggibile solo da PC
potenti (in verità molto diffusi oggi), e può provocare diffetti nei
lettori stand-alone. Un valore troppo alto (se manetnuto dal codec...)
invece produce un seek inadeguato.
Per ora in giro si è sempre consigliato valori compresi tra i 250 e 300 e
non abbiamo mai riscontrato problemi.
Adesso sto facendo il test a 1 con dimensioni fisse: 50 MB. Per ora posso
dirti che il file è venuto 51 MB, poi vi dico r risultati.


 differenza così marcata tra il rar e il DivX?
Con "importanza per lo meno equiparabile" intendevo confrontabile.

 dimensione finale di 50MB!
Questa volta la situazione si č ribaltata (come previsto da te), la
differenza č cosě elevata che č anche visibile, comunque in maniera
oggettiva:
1 --> 5384 keyframe --> 0.879793
300 --> 85 keyFrames --> 0.971080
Il file , in entrambi i casi č di 51MB. Il file con impostato il valore di
300 si vede notevolmente meglio.


 definirsi marginale).
Semplicemente perchè ho compresso un file tipo BMP.
Sono partito da un file di dimensioni 4.1 GB e ho ottenuto in un caso un
file da 1,4 GB e nell'altro di 90 MB.
Cosa significa "equiparabile"?
Con quale algoritmo ho portato il file alle dimensioni del MB?
Allora partendo da un file non compresso sono arrivato alla dimensione di
1.4 GB, cioè ho ridotto il file di un terzo. Posso supporre che la stessa
riduzione la possa ottenere sul file trattato in modo lossy, quindi ho un
file pre-nonlossy di 270MB, applico l'algoritmo standard e ottengo 90 MB,
giusto?
Se è così sono passato da 4.1 GB a 270 MB con l'algoritmo lossy e poi a 90
MB con quello non lossy. Io continuo a vedere un apporto marginale (15 a
3). Certo, tu potresti ribbattere con altri valori, per questo ti chiedo un
link in cui questa cosa viene spiegata altrimenti non si arriva da nessuna
parte.
Anche se questo non era il discorso da cui siamo partiti si fa
interessante, ma solo se mi fornisci un link valido. 
Bye


 3).
Stavo giusto pensando che forse questa stima č ottimistica, nel senso che
l'apporto del non lossy sia ancora inferiore.
Ho provato a comprimere altre immagini jpeg ottenendo come risultato una
compressione nulla o poco piů. Tu mi ha detto che l'algoritmo di
compressione standard usato non č molto potente ed inoltre si applica a
blocchi, in questo caso mi sarei aspettato una maggiore compressione che
non č avvenuta.
Posso dedurre che i dati creati dall'algoritmo lossy siano poco
comprimibili, tanto poco che il "cattivo" algoritmo non lossy possa fare
bene il suo dovere?
Se č cosě cosa mi vieta di pensare che anche nello mpeg sia la stessa
cosa, riducendo ulteriormente la parte dell'algoritmo non lossy?
Bye, Giubbe
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 effettivamente 5384 keyframe, nel secondo 238 e cosě via.
i rapporti sono i "key int medi effettivi" (le ampiezze medie degli
intervalli per ogni keyframe); ad esempio, nell'ultimo caso hai
specificato un "max key int" di 3000, ma e' quasi certo che quel valore
non sia mai stato raggiunto, perche' il filmato che hai usato era lungo
solo 5384 frames e il codec ha generato 62 keyframes (in media, quindi,
ha generato un keyframe ogni 86 frame); in altre parole, il codec ha
generato i keyframes solo sui cambi di scena e non perche' ha raggiunto
il valore massimo; se tu avessi specificato un valore di "max key int"
pari a 2000 o anche 1000, credo che avresti ottenuto piu' o meno lo
stesso risultato...
nioltre, cambiando tipo di filmati, ottieni risultati molto diversi:
questo e' un filmato acquisito da Rai Nettuno:
frames = 5500
keyframes = 19
key int medio = 289.473684
questo e' un videoclip musicale:
frames = 5474
keyframes = 226
key int medio = 24.221238
il "max key int" che avevo specificato in partenza era 300 per entrambi,
ma mentre nel primo caso, tale limite e' stato raggiunto molte volte dal
codec (perche' le lezioni del nettuno hanno lunghe sequenze senza stacchi)
nel secondo caso non viene mai raggiunto (perche' nel videoclip gli
stacchi si susseguono continuamente, e questo rende molto meno efficace
la "motion compensation").
e' per questi motivi che mi sembra piu' appropriato associare i
risultati delle tue prove ai "key int medi" ottenuti, invece che ai
valori impostati (1,30,300,3000).
a proposito del tuo test:
cos'e' il SSIM e come si calcola?
ad ogni modo, un "key int medio" pari a 24, come nel caso del videoclip,
sebbene sia basso nell'ambito dei DivX, e' sempre abbastanza piu' alto
rispetto ai DVD, che hanno un key int fisso pari a 12 (o 15); e questo,
secondo me, e' il principale fattore che influisce sulla differenza tra
DVD e DivX in termini di rapporto dimensioni/qualita'...

 9"6"              (stringa filtrata con lossy e poi compressa con lossless)
hai ragione quando dici che la compressione jpeg comprende una parte
lossy e una lossless, ma le due fasi sono separate: prima si applica una
trasformata (la trasformata discreta del coseno, DCT) all'immagine di
partenza (ripartita in blocchi) poi si effettua una quantizzazione
(questa e' la parte lossy) sui coefficienti di Fourier cosi' ottenuti,
e infine si applica una codifica di Huffman (lossless) sui coefficienti,
e questo e' cio' che viene memorizzato nel file; per ricostruire
l'immagine si procede al contrario: decomprimendo lo stream di Huffman
si ricavano prima i coefficienti e poi da questi le corrispondenti parti
dell'immagine.
da come l'hai spiegato tu, sembra invece che l'immagine venga prima
"uniformata" allo scopo di essere ben comprimibile da una codifica di
Huffman, ma non e' cosi...
ti faccio un altro esempio di compressione lossy che non ha niente a
che fare con la compressione lossless:
una rete neurale feed forward a tre strati, che ha tante unita' di
ingresso quante unita' di uscita e che venga addestrata per calcolare
la funzione identita' (i campioni ingresso-uscita sono del tipo x-x);
se il numero di unita' intermedio (le unita' "nascoste") e' maggiore
o uguale al numero di unita' di ingresso e di uscita, allora la rete
potra' effettivamente convergere al calcolo esatto della funzione
di identita'; il caso interessante pero', lo si ha, addestrando una
rete con un numero di unita' nascoste inferiore; e' chiaro che la
rete non potra' calcolare esattamente la funzione identita', pero'
scegliendo un campione rappresentativo di cio' che ci interessa
comprimere (ad esempio, immagini) si possono ottenere risultati
accettabili. una volta che la rete e' addestrata, si puo' scomporre
in due parti: la prima, che consiste dello strato di ingresso e
di quello intermedio, verra' usato come encoder (o compressore),
mentre la seconda, che consiste dello strato intermedio e di
quello di uscita, verra' usato come decoder (o decompressore).
questo e' un esempio di compressione lossy che non ha niente a
che vedere con la compressione lossless...

 lossless.
Se tu chiami "filtro" la Trasformata Disreta del coseno (DTC) base degli
algoritmi mpeg direi che non si può proseguire. Senza contare che questa
funzione matematica non mi risulta che uniformi alcunchè.
Io ho detto e ribadisco che quanto da te espresso ad inizio thread è
errato, poi hai corretto aggiungendo la puntualizzazione circa il tipo
doppio di compressione.
Ti avevo chiesto un link, ma ancora latita, allora ci penso io, da
wikipedia: 
http://en.wikipedia.org/wiki/MPEG
Qui viene detto come si crea un mpeg, ma da nessuna parte c'è scritto che
la compressione lossy e quella standard apportano lo stesso benificio.
Quello che ti chiedo è un link autorevole dove si possa evincere ciò che
sostieni tu, non voglio esempi semplicistici.
Grazie, Giubbe


 non voglio esempi semplicistici.
Sì, questo l'ho capito, mi chiedo se tu abbia capito la frase del mio post
iniziale, da te tra l'altro puntualmente contestata:
"ci sarebbe da parlare per mezz'ora".

 DVD e DivX in termini di rapporto dimensioni/qualita'...
Trascurando che uno è mpeg4 e l'altro un mpeg2 allora sono d'accordo con
te.
Bye.


 l'apporto del non lossy sia ancora inferiore.
Il fatto è che in realtà i due tipi di compressione non sono separabili
concettualmente, infatti il semplice algoritmo lossy non è un vero algoritmo
di compressione se considerato separatamente da un algoritmo di compressione
standard.
Quando, in generale, si parla di compressione lossy si intende *sempre*
un'associazione di filtro lossy + compressione standard.
Mi spiego meglio: l'algoritmo lossy non è altro che un filtro il cui scopo è
quello di rendere le immagini molto comprimibili tramite un algoritmo
lossless.
Infatti con la sola applicazione del filtro lossy a una bitmap si otterrebbe
semplicemente un'immagine bitmap, diversa nel contenuto, ma delle stesse
dimensioni dell'originale.


 "ci sarebbe da parlare per mezz'ora".
Che non c'entra nulla. La prima parte è sbagliata, la seconda parte, quella
dell'equivalenza pratica sui due tipi di compressione, aspetto il link.
Bye


 una rete neurale feed forward a tre strati[...]
[OT]
Sai che ti invidio...? ^_^
Nei miei studi informatici non c'è stato un esame sulle reti neurali. Mi
sai dire il titolo di un testo con il quale posso colmare questa mia
lacuna? Magari quello in cui hai studiato tu.
Grazie, Giubbe


 lacuna? Magari quello in cui hai studiato tu.
quello in cui ho studiato e':
James A. Freeman - David M. Skapura
Neural Networks. Algorithms, Applications, and Programming Techniques
Addison-Wesley Publishing Company
la tecnica di compressione lossy a cui ho accennato viene spiegata a
p. 107 di tale libro (sez. 3.4.1 "Data compression")
pero' non so se ti conviene leggere quello, forse a te interessa solo
farti un'idea generale... credo che cercando in rete si possa trovare
qualcosa di interessante (e scaricabile gratuitamente :-)), ma al momento
non saprei consigliarti...
un libro forse piu' adatto e':
Le reti neuronali - semplificare la complessita' con l'aiuto
dell'informatica (ed. Franco Angeli)
di Stefano Patarnello (un fisico, che qualche anno fa era ricercatore
presso l'IBM).
il testo classico sul connessionismo e' l'antologia in due volumi PDP
(Parallel Distributed Processing) curata dagli psicologi Rumelhart e
McClelland; in Italia fu parzialmente tradotto e pubblicato da
Il Mulino con il titolo "PDP - Microstruttura dei processi cognitivi";
questo ha una certa importanza storica, ma penso che possa risultare
piu' interessante nell'ambito di studi psicologici che informatici...
ah, ecco, ho trovato un articolo che scaricai tempo fa, il file si
chiama cosi':
tutor-hellstrom_neural-networks_1998.ps
magari se lo cerchi, riesci a trovarlo...
l'autore e' Thomas Hellstrom, un ricercatore svedese che si occupa(va)
di "predire gli andamenti dei prezzi di titoli azionari" :-)
non so se sia riuscito a costruire modelli di predizione che
funzionano, pero' di sicuro aveva scritto una serie di articoli molto
carini (e una tesi dal titolo "A Random Walk through the Stock Market",
che parafrasava un libro famoso sull'argomento, quello che sostiene
che e' impossibile predire l'andamento dei prezzi)...
quell'articolo sarebbe un tutorial sulle reti neurali, ma non so
quanto sia adatto per farsi un'idea generale (il libro di Patarnello
e' molto meglio)
grazie per avermi segnalato la pagina del SIMM, oggi scarichero'
l'articolo (ho gia' scaricato l'implementazione MatLab che dovrebbe
bastarmi per usarlo :-))