Newsgroup: it.comp.software.divx
Titolo: saturazione in XviD

ho preparato un breve filmato (non compresso, in rgb24) di
500 frames (20 secondi), senza audio, chiamato 00-originale.avi
a partire da quello, ho codificato un XviD in due passate, senza
b-frames, con un target bitrate pari a 1800 kbps, con questi due
comandi:
mencoder 00-originale.avi -o xvid-1800-2pass.avi -ovc xvid
-xvidencopts pass=1:bitrate=1800:me_quality=6:max_bframes=0
mencoder 00-originale.avi -o xvid-1800-2pass.avi -ovc xvid
-xvidencopts pass=2:bitrate=1800:me_quality=6:max_bframes=0
durante la codifica, la libreria (xvidcore) stampa questo
messaggio:
xvid: 2Pass Rate Control -- 2nd pass -- bitrate=1800kbit/s
quindi il codec ha capito bene (ho chiesto 1800)...
pero', il file ottenuto (xvid-1800-2pass.avi) e' lungo 3,742,108
e ha un bitrate pari a 1490.298 kbps
perche'?
quando succede questo con libavcodec vuol dire che il codec ha
raggiunto la saturazione...
allora ho codificato un XviD analogo, sempre senza b-frames,
a qualita' costante, con questo comando:
mencoder 00-originale.avi -o xvid-q-2.avi -ovc xvid
-xvidencopts fixed_quant=2:me_quality=6:max_bframes=0
anche in questo caso, la libreria ha capito bene:
xvid: Fixed Quant Rate Control -- quantizer=2/1=2.00
il file risultante (xvid-q-2.avi) e' lungo 9,967,298 e ha un
bitrate pari a 3980.3732 kbps
mandando in riproduzione i due filmati ottenuti, a occhio non si
notano grandi differenze, solo un leggero peggioramento in alcuni
dettagli nel primo...
dal calcolo dell'indice SSIM, per confronto con l'originale,
risulta una piccola differenza;
questi sono i primi 10 frames del primo:
$ ./ssim-index 00-originale.avi xvid-1800-2pass.avi 
matrice usata: uniforme 8x8
frame 0 - indice ssim = 0.961286
frame 1 - indice ssim = 0.955464
frame 2 - indice ssim = 0.945166
frame 3 - indice ssim = 0.950103
frame 4 - indice ssim = 0.954213
frame 5 - indice ssim = 0.946049
frame 6 - indice ssim = 0.954905
frame 7 - indice ssim = 0.947432
frame 8 - indice ssim = 0.950807
frame 9 - indice ssim = 0.951648
[...]
mentre questi sono i prmi 10 del secondo:
$ ./ssim-index 00-originale.avi xvid-q-2.avi 
matrice usata: uniforme 8x8
frame 0 - indice ssim = 0.980554
frame 1 - indice ssim = 0.976268
frame 2 - indice ssim = 0.974043
frame 3 - indice ssim = 0.976313
frame 4 - indice ssim = 0.975671
frame 5 - indice ssim = 0.974514
frame 6 - indice ssim = 0.975984
frame 7 - indice ssim = 0.975624
frame 8 - indice ssim = 0.974071
frame 9 - indice ssim = 0.976068
[...]
a questo punto mi domando: se nel primo caso avevo specificato un
target bitrate di 1800, perche' non ha sfruttato meglio lo spazio
che aveva a disposizione, visto che avrebbe potuto fare di meglio?

 
Non ho capito, sorry. Il filamto era lo stesso o uno analogo?
Presumenndo che fosse lo stesso sinceramente non ti so dire perchè ha fatto
quanto da te descritto, sicuramente non è andato in saturazione.
Bye, Giubbe
P.S.
Con cosa hai calcolato il ssim?
-- 
HomePage e FAQ: 
http://giubbe.altervista.org
Inutile scrivere in privato, non ricevo le email

 Con cosa hai calcolato il ssim?
con un programmino che sto scrivendo, quando lo avro' sistemato meglio
lo rendero' scaricabile...
(voglio aggiungere qualche statistica, tipo la varianza degli indici
calcolati su ogni coppia di frame, in modo da poter valutare non solo
la qualita' media del filmato ottenuto, ma anche quanto tale qualita'
e' mantenuta costante su tutto il filmato, altrimenti c'e' il rischio
che un filmato abbia un indice elevato perche' molti frame sono
codificati benissimo, ma allo stesso tempo abbia frame codificati
male...)
i tempi richiesti per i calcoli sono molto elevati... dovro'
inventarmi qualcosa per ottimizzare...
per ora il programma e' a riga di comando e si usa cosi':
$ ssim-index 
uso: ssim-index <file1> <file2> [g]
in pratica vanno specificati due file da confrontare (possono essere
due immagini o due AVI); specificando un terzo parametro "g", l'indice
viene calcolato usando una matrice gaussiana 11x11 (con deviazione
standard 1.5), altrimenti, di default viene usata la matrice uniforme
8x8.
i filmati devono essere AVI, e sono supportati i seguenti codec:
- MJPEG
- DV
- DivX (3, 4, 5, il clone di libavcodec)
- XviD
- mpeg-1, mpeg-2 (purche' infilati in contenitori AVI)
- RGB24, YV12 e qualche altro formato non compresso
forse lo estendero' in modo che legga anche i file mpeg
direttamente (se ho voglia)
comunque a infilare un mpeg-2 dentro un AVI ci vuole un attimo

 calcolati su ogni coppia di frame,
il programma adesso genera una tabella SQL (sqlite) nella quale
inserisce i dati per ogni confronto; ecco le prime 10 righe di una
tabella:
sqlite> select * from frames order by cnt limit 10;
0|0.974643|559872|15426|1|1
1|0.969511|559872|6547|1|0
2|0.964645|559872|7257|1|0
3|0.96748|559872|7241|1|0
4|0.96578|559872|7579|1|0
5|0.963586|559872|7752|1|0
6|0.965728|559872|8173|1|0
7|0.964638|559872|9299|1|0
8|0.964531|559872|10226|1|0
9|0.966279|559872|10133|1|0
- la prima colonna indica il numero di frame (a partire da 0)
- la seconda e' il risultato del confronto ssim tra i due frame
  in quella posizione
- la terza e' la lunghezza (in bytes) del frame in quella
  posizione nel primo filmato specificato (in questo esempio,
  il primo filmato e' rgb24 non compresso con risoluzione 576x324,
  quindi tutti i frame sono lunghi 576*324*3=559872 bytes)
- la quarta e' la lunghezza (in bytes) del frame in quella
  posizione nel secondo filmato specificato (in questo esempio,
  e' un divx ottenuto in due passate con libavcodec)
- la quinta indica se il frame in questione, nel primo filmato
  e' un keyframe (nell'esempio, lo e' sempre)
- la sesta indica se il frame in questione, nel secondo filmato
  e' un keyframe (nell'esempio, lo e' il primo ma non gli altri)
interrogando la tabella e' facile ottenere molte informazioni
interessanti; attualmente, il programma stampa un risultato
tipo questo:
indice ssim medio   = 0.967832
minimo              = 0.961252
massimo             = 0.975488
deviazione standard = 0.003930
questo esempio indica un ottimo risultato, perche' non solo l'indice
medio e' alto, ma la deviazione standard e' bassa (vuol dire che
il filmato mantiene un'alta qualita' per tutta la durata); se fosse
alta, potrebbe voler dire che in alcuni punti la qualita' potrebbe
essere bassa, cioe' potrebbero esserci artefatti o altri
degradamenti...
quali altri parametri potrei calcolare?
stasera preparero' un pacchetto da scaricare, ma il programma e'
ancora troppo grezzo e inoltre richiede un bel po' di librerie:
$ ldd ssim-index
        libtreeplav.so => /usr/local/treep/lib/libtreeplav.so (0x40013000)
        libdv.so.4 => /usr/local/lib/libdv.so.4 (0x400e0000)
        libtreepavi.so => /usr/local/treep/lib/libtreepavi.so (0x40107000)
        libtreeppix.so => /usr/local/treep/lib/libtreeppix.so (0x40118000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x40148000)
        libz.so.1 => /usr/lib/libz.so.1 (0x4016b000)
        libtreepsqlite3.so => /usr/local/treep/lib/libtreepsqlite3.so
(0x40179000)
        libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0 (0x4017e000)
        libtreepmpeg2.so => /usr/local/treep/lib/libtreepmpeg2.so (0x401c7000)
        libmpeg2.so.0 => /usr/local/lib/libmpeg2.so.0 (0x401c9000)
        libmpeg2convert.so.0 => /usr/local/lib/libmpeg2convert.so.0
(0x401e7000)
        libtreepavcodec.so => /usr/local/treep/lib/libtreepavcodec.so
(0x401ee000)
        libavcodec.so => /usr/local/lib/libavcodec.so (0x401f0000)
        libtreep.so => /usr/local/treep/lib/libtreep.so (0x4047d000)
        libgmp.so.3 => /usr/lib/libgmp.so.3 (0x404a2000)
        libm.so.6 => /lib/i686/libm.so.6 (0x404ce000)
        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
        libdl.so.2 => /lib/libdl.so.2 (0x404f0000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
la libreria piu' grossa (come dimensioni) e' libavcodec (il programma
la usa per estrarre i frame dai filmati tipo divx/xvid), quindi chi
vorra' testare il programma dovra' scaricare le varie librerie a parte
(a meno di non averle gia')

 ancora troppo grezzo e inoltre richiede un bel po' di librerie:
ormai stasera non ce la faccio... anche perche' ho trovato nuove
ottimizzazioni da apportare, quindi conviene aspettare...