Newsgroup: it.comp.software.divx
Titolo: software per convertire divX senza ricampionare?

Ciao a tutti,
ho un problemino con un player di rete che legge 'quasi' tutti i file
xvid/divx in circolazione.
pero' capita che alcuni non riesca a leggerli del tutto.
esiste un software che mi permette di ricodificare un file divx o xvid
senza doverlo per forza ricampionare perdendo qualita'?
vi ringrazio in anticipo per eventuali suggerimenti.
tony

 senza doverlo per forza ricampionare perdendo qualita'?
Se cambi codec, devi ricodificare.
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
Il mondo è lo specchio di me morente. - Henry Miller

 Se cambi codec, devi ricodificare.
lo supponevo. lo suppo. :(.
In questo caso qual'e' l'applicazione piu' adatta per mantenere il piu'
possibile inalterata la qualita'?
ciao e grazie ancora.
tony =).

 piu' possibile inalterata la qualita'?
Io uso Virtual Dub Mod o mencoder (nel caso debba fare lavori in serie
tramite linea di comando o batch).
Con entrambi, setto il codec con quello che in Xvid si chiama "Target
Quantizer" a 2 (ottima qualità, ma meglio ancora con 1 ma non mi è mai
servito, a dire la verità). Al limite, vedi come ti viene e poi puoi
mettere a 1 e fai una comparazione.
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
Le lunghe leggi sono calamità pubbliche.
Louise Antoine Léon Saint Just

 mettere a 1 e fai una comparazione.
Ottimo. Grazie per le dritte ;).
tony

 mettere a 1 e fai una comparazione.
Mah, credo che quantizer 1 sia inutile e che il gioco non valga la candela: 
già il quantizer 2 da un' ottima qualità; se si passa a quantizer 1 la 
qualità *percepita* delle immagini non aumenta, in compenso le dimensioni 
del file ingigantiscono.
In tutti i casi io, per i miei lavoretti, uso VirtualDub ed XviD e credo che 
l' accoppiata VirtualDub - XviD sia formidabile.
Mi secca solo che ho dei problemi con i B-frames (nei cambi di scena 
compaiono dei quadrettoni, durano solo un attimo ma mi danno fastidio, e 
comunque a VirtualDub non piacciono molto; non parlo solo del messaggio 
"B-frames lag" ma ho riscontrato dei problemi anche se mi limito ad 
operazioni di "taglia e cuci") difatti, per non saper nè leggere nè 
scrivere, li ho disabilitati.
Saluti. 

 compaiono dei quadrettoni,
in quanto scrivi c'e' qualcosa di strano perche', se il codec funziona
bene, in un cambio di scena non dovrebbe mai usare B-frames
-- 
Home page di Frank: 
http://fsinapsi.altervista.org
Home page di Giubbe e FAQ: 
http://giubbe.altervista.org

 bene, in un cambio di scena non dovrebbe mai usare B-frames
Ciao Frank, sono lieto di leggerti (molti dei tuoi post, non so perchč, se 
leggo il NG con Outlook non li vedo; spesso ti leggo solo se qualcuno ti 
quota).
Non so dirti perchč e non capisco quale sia l' origine del problema, ma con 
i B-frames abilitati mi escono dei quadrettoni quando la scena cambia; 
durano un istante ma mi danno molto fastidio.
Anche un altro utente di questo NG (Michele, mi pare) lamentava questo 
problema.
Saluti. 

 durano un istante ma mi danno molto fastidio.
se escono i quadrettoni che durano solo un istante, qualcosa non e' andato
per il verso giusto. Se guardi il grafico dei quantizers noterai un picco
isolato in corrispondenza dei frame "quadrettosi".
L'unico motivo valido per cui un codec puo' produrre una cosa del genere
(escludendo il caso di codifica in singola passata a target bitrate) e'
quando viene selezionato un profilo con buffer e bitrate limitati, e la
scena risulta poco comprimibile (tipicamente: scene in cui piove o nevica
oppure un'esplosione). I cambi di scena sono rilevati dall'alta differenza
tra i blocchi di due frame consecutivi, e in tali casi i codec generano
sempre un I-frame (un delta-frame non darebbe vantaggi).
Quindi, la situazione che descrivi (quadrettoni sui cambi scena in caso
di B-frame abilitati) sembrerebbe un bug del codec...


 di B-frame abilitati) sembrerebbe un bug del codec...
Potrebbe darsi che io abbia una versione di XviD fallata
L' avevo scaricata qualche anno fa non mi sovviene neppure da dove.
In tutti i casi, ecco un estratto dalle "Release notes":
"XviD-1.0.1-05062004 _Final Release_
Based on CVS from 05.06.2004 13:00h MET"
Comunque, tolto l' inconveniente coi B-frames, l' avevo configurata seguendo 
un tutorial in rete ed ha sempre lavorato bene.
Ciao e grazie per l' interessamento. 

servito, a dire la verità).
allora, siccome se ne parla, ripropongo una domanda che avevo fatto in
un mio precedente post (intitolato "Ricodificare divx") al quale
nessuno aveva risposto: ricodificando, è meglio un target quantizer =
1, oppure impostare con Avidemux l'opzione "Stesso quantizzatore
dell'input"?
In entrambi i casi si avrebbe comunque uno scadimento della qualità?

 In entrambi i casi si avrebbe comunque uno scadimento della qualità?
Direi che ogni ricodifica comporta modifiche e, anche se minime, perdite
di qualità (in qualche maniera). Come ha detto Vyger l'1 rispetto al 2
aumenta le dimensioni senza dare apprezzabili miglioramenti di qualità,
ma se ho capito bene come funziona, se usi lo stesso quantizer
dell'input (se riesce a calcolarlo), farà una compressione con la stessa
perdita di dati della prima compressione, quindi non mi pare convenga.
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
Il pudore è una provocazione sessuale. La vera innocenza è impudica.
Francesco Orestano

 di qualità (in qualche maniera).
forse vale la pena spiegare un po' questo punto.
Una ricodifica puo' anche non comportare alcuna perdita, e in questo caso
si parla di codifica "lossless"; in caso contrario, di codifica "lossy".
Esistono codec lossless, e anche codec tipicamente usati come lossy
permettono di impostare una codifica lossless (ad esempio, x264 puo'
codificare senza perdita di informazione).
DivX e XviD sono sempre lossy, anche se usando quantizer bassi le
modifiche sono molto contenute.
Vediamo adesso, grosso modo, cos'e' che viene modificato/perduto durante
una ricodifica in DivX e XviD.
Come ben sapete, un filmato non e' altro che una sequenza di immagini,
quindi uno stream video DivX o Xvid e' la codifica di una sequenza di
immagini. Ogni immagine viene suddivisa in tanti quadratini (blocchi),
e ogni blocco viene codificato in qualche modo. Il modo piu' immediato
di codificare un blocco e' lo stesso utilizzato per le immagini statiche
JPEG, pero' un blocco puo' essere anche rappresentato in funzione di
blocchi gia' codificati in precedenza. Tralasciando i dettagli, cio'
che ci interessa e' che alla fine la codifica di un blocco comporta la
codifica di una matrice di numeri, e precisamente una matrice di
dimensioni 8x8 (64 numeri disposti in 8 righe per 8 colonne).
La codifica di una tale matrice 8x8, in DivX e XviD, viene fatta
mediante l'applicazione di una funzione matematica che si chiama
"trasformata discreta del coseno" (DCT).
Cosa vuol dire applicare la DCT?
Vuol dire passare da una rappresentazione esplicita di un blocco/matrice
a una rappresentazione implicita per mezzo di coefficienti delle
componenti in frequenza del blocco.
Vediamo di spiegare meglio questo punto.
Per chi sa come si passa dalle coordinate cartesiane a quelle polari
del piano (o dello spazio a tre dimensioni), il concetto e' analogo:
un punto nello spazio puo' essere rappresentato da una coppia di
numeri che sono le coordinate cartesiane rispetto a un sistema di
riferimento, oppure in infiniti altri modi, come ad esempio in
coordinate polari, appunto. In generale, possiamo scegliere un numero
infinito di "basi" di uno spazio vettoriale di dimensione finita n
(cioe' n vettori dello spazio linearmente indipendenti) e
rappresentare ogni altro vettore come combinazione lineare dei
vettori della base.
Ebbene, la DCT e' una "base" che ci permette di rappresentare
mediante opportuni coefficienti qualsiasi blocco 8x8.
La base DCT e' composta da 64 blocchi, che potete vedere in questa
figura:
http://www.virtualuniversity.ch/guides/webdesign/images/dct.jpg
come vedete, si tratta di 64 quadratini, avente ciascuno
dimensioni 8x8.
Quello che ci interessa e' che ogni blocco 8x8 puo' essere scritto
come combinazione lineare di questi 64 quadratini di base.
La DCT e' la funzione che, applicata a un blocco, calcola i 64
coefficienti corrispondenti a ciascun quadratino di base.
Ad esempio, se noi applichiamo la DCT a un blocco a tinta
assolutamente uniforme, che coefficienti otteniamo?
Be', in questo caso otterremo tutti coefficienti nulli eccetto il
primo perche' il blocco e' un multiplo esatto del primo quadrato
della base. Questo e' un esempio interessante, perche' ci fa capire
che, quando in una scena ci sono delle zone "compatte", applicando
la DCT sui blocchi in quelle zone, otterremo un'informazione tutta
concentrata su pochi coefficienti, e molti coefficienti nulli, e
questa potremmo codificarla in poco spazio.
In generale, pero', l'applicazione della DCT a un blocco non cambia
molto la situazione, nel senso che prima avevamo bisogno di
codificare 64 numeri, e dopo la DCT ci ritroviamo con 64
coefficienti, e quindi abbiamo ancora 64 numeri da codificare.
Fin qui non abbiamo perso informazioni (se calcoliamo la
combinazione lineare della base DCT, operazione chiamata IDCT dove
la 'I' sta per "inversa", riotteniamo pari pari il blocco originale).
Ora viene il punto cruciale.
I coefficienti DCT, in genere, non sono numeri interi, ma vengono
sempre codificati come interi, quindi questo gia' introduce
un'approssimazione, anche se in pratica e' trascurabile.
Ma quello che rende lossy le codifiche lossy e' la cosiddetta
"quantizzazione", che consiste nel "quantizzare" i coefficienti,
cioe' approssimarli al piu' vicino multiplo di un fattore di scala.
Ad esempio, se abbiamo i numeri 132, 217, 49 e il fattore di scala
e' 1, i numeri restano tali e quali.
Se il fattore di scala e' 2, i numeri diventano 132, 216, 48.
Se il fattore di scala e' 10, i numeri diventano 130, 220, 50.
E cosi' via.
In generale, l'errore commesso (la differenza tra il valore originale
e quello approssimato) tende a essere piu' alto, via via che scegliamo
fattori di scala piu' grandi.
Che effetto ha sulla compressione la quantizzazione?
Be', i coefficienti quantizzati tipicamente sono memorizzabili in uno
spazio piu' ridotto rispetto a coefficienti meno quantizzati (usando
una codifica entropica), ed e' proprio questo che ci permette di
ottenere file aventi dimensioni a piacere (al costo di una maggiore
approssimazione, ovviamente).
A questo punto uno potrebbe chiedersi: ma perche' applicare prima la
DCT e poi quantizzare i coefficienti DCT? Non si faceva prima a
quantizzare direttamente i numeri del blocco da codificare?
La risposta e' che la DCT rappresenta un modello, per quanto rozzo,
della visione umana, e i coefficienti non vengono quantizzati tutti
allo stesso modo, ma si cerca di preservare il piu' possibile
(usando quantizer bassi) le componenti in frequenza che tendiamo a
notare di piu' e a sacrificare di piu' (usando quantizer piu' alti)
quelle che tendiamo a notare meno.


 lossless (ad esempio, x264 puo' codificare senza perdita di informazione).
Com' è possibile?
Ad esempio, x264 non è basato anch' esso sulla DCT e quantizzazione (metodi 
che sacrificano l' informazione)?
Saluti. 

 forse vale la pena spiegare un po' questo punto.
Che meraviglia... Un grande come sempre. ;)
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
Con quello che non sai si farebbe un gran libro. - Sydney Smith



'stica!
chapeau per la spiegazione molto chiara e dettagliata!
tony

 che sacrificano l' informazione)?
si', anche x264 usa una versione un po' diversa della DCT, ma come dicevo
nel precedente post, la perdita si ha nella quantizzazione, non nella
conversione DCT <-> IDCT. Lo standard H.264 prevede una codifica lossless,
e in x264 e' stata implementata e puo' essere usata impostando il parametro
qp a 0. In pratica non ha molto senso perche' si ottengono file molto
grossi...
Comunque il messaggio precedente non avevo finito di scriverlo, stamattina
ho dovuto interrompere e mi sono dimenticato di aggiungere "continua..." :-) .
Ero arrivato a dire che la DCT e i quantizzatori rappresentano un modello
(rozzo) del nostro sistema visivo. Lo standard MPEG-4 Visual prevede due
metodi di quantizzazione: uno standard, che si chiama H.263 (prende il
nome dal precedente standard ITU da cui fu derivato) e che e' l'unico
previsto nel profilo SP (simple profile), e un secondo metodo previsto
per l'ASP (advanced simple profile). Con il secondo metodo e' possibile
anche scegliere a piacere i parametri di quantizzazione (uno per ogni
componente DCT, quindi 64); queste sono le famose "matrici di
quantizzazione". In realta' non ce n'e' una sola, ma due: una per la
codifica di blocchi "intra", l'altra per i blocchi "delta" (cioe',
quelli dei frame di tipo P o B). Esiste anche una coppia di matrici di
default, che corrispondono a quelle definite in un precedente standard
MPEG; e infine viene data la possibilita' di impostare una coppia di
matrici a piacere (quelle che si chiamano "matrici custom").
Gli elementi delle matrici di quantizzazione non sono esattamente quelli
che ho chiamato "parametri di scala", ma questi ultimi sono calcolati
in funzione di quelli (piu' sono grandi e maggiore sara' la
quantizzazione del relativo coefficiente).
Tipicamente, quando si imposta una matrice di quantizzazione, si usa
una matrice simmetrica, e fatta in modo da avere coefficienti piu'
bassi nella parte in alto a sinistra, e piu' alti via via che ci si
sposta lungo la diagonale principale, fino all'ultimo elemento in
basso a destra.
Per capire perche', bisogna guardare com'e' fatta la base DCT:
http://www.virtualuniversity.ch/guides/webdesign/images/dct.jpg
i coefficienti che corrispondono alla parte in basso a destra
codificano le componenti dell'immagine che consistono nei dettagli
piu' minuti. In un certo senso, questi possono essere un po'
sacrificati senza che ce ne accorgiamo troppo :-) .
Insomma, se proprio si deve sacrificare un po' di informazione, si
preferisce partire dai dettagli meno significanti.
Ci si puo' sbizzarrire a testare un po' di matrici variando i
valori dei coefficienti, ottenendo in questo modo risultati che
possono sembrare migliori o peggiori a seconda un po' dei gusti,
un po' di piccole differenze tra cosa le persone tendono a
notare di piu' mentre guardano una scena, e anche alle
caratteristiche del monitor su cui si guardano i risultati (ci
sono filmati che si vedono benissimo su certi tipi di monitor
e malissimo su altri).
Detto questo, resta da aggiungere un'ultima considerazione. Avevo
accennato al fatto che una "zona compatta" nell'immagine corrisponde
a coefficienti DCT "addensati". Questo e' un altro grande vantaggio
che offre la DCT.
Cerco di spiegare meglio.
Se generiamo un'immagine a caso (ad esempio, lanciando ripetutamente
una moneta, e scrivendo una sequenza di 0 e 1 a seconda se esce
testa o croce), quando applichiamo la DCT all'immagine casuale
otteniamo coefficienti distribuiti in modo uniforme.
Il punto importante e' che le immagini "realistiche" non sono
casuali, contengono oggetti del mondo che hanno una certa
estensione nello spazio, quindi sono caratterizzate da zone
compatte, spigoli, sfumature di colore, ecc.
Questa caratteristica si riflette nella distribuzione dei
coefficienti DCT, che tipicamente, per una immagine realistica,
tendono ad addensarsi su un numero relativamente basso di
coefficienti (dove molti altri coefficienti avranno valori bassi).
In effetti, dal punto di vista della DCT un'immagine e' tanto
piu' "complessa" quanto piu' sono uniformi i coefficienti, e
questo succede quando l'immagine e' ricca di dettagli a tutti
i livelli.
Quindi, la DCT gia' da sola fornisce dei vantaggi per quanto
riguarda la compressione, perche' la sequenza dei coefficienti,
per immagini provenienti dal mondo, e' tipicamente piu'
comprimibile di una rappresentazione esplicita. Se poi
consideriamo anche la possibilita' di fare una "quantizzazione
selettiva", i vantaggi si moltiplicano...
Ora dovrei rispondere alle domande di chi chiedeva la differenza
tra ricodificare a quantizer costante oppure a singola passata
usando lo stesso quantizer (e' una feature di avidemux).
Be', a quantizer costante con quantizer basso non si puo' certo
perdere piu' informazione dell'altro metodo...
Tuttavia non e' detto che l'altro metodo dia risultati troppo
inferiori, e in molti casi potrebbe essere preferibile.


 :-) .
[CUT]
Ecco, credo che a questo punto non ci sia più nulla da dire, pertanto mi 
limito a ringraziarti per avermi risposto, a complimentarmi con te per le 
ulteriori spiegazioni e mi faccio educatamente da parte e ti lascio da solo 
sul palcoscenico a ricevere gli applausi e le ovazioni della platea...
Ciao! 

 wrote:
I tuoi post andrebbero raccolti Frank, sono preziosi quanto gli
"Appunti di Informatica Libera". Una bella sezione sul tuo sito non
sarebbe niente male. Io potrei anche fare un search su Google Gruppi,
ma vai a sapere quali sono quelli divulgativi e quali quelli di
normale discussione..
-- 
Paradoxally,
Jan AxHell

 sarebbe niente male.
fare una sezione richiederebbe molto tempo :-) .
Scrivere due post come quelli di ieri ne richiede poco, anche se
non sono molto accurati (possono esserci imprecisioni) avendoli
scritti di getto come una chiacchierata informale.
Mi sono dilungato perche' penso sia utile tenere a mente cosa e'
che viene perso durante una codifica. Ogni tanto fa bene
avvicinarsi alle cose e vederle un po' piu' nei dettagli :-)
