Newsgroup: it.comp.software.divx
Titolo: Domanda tecnica sul DRF

Questa domanda è praticamente per Frank, in quanto autore di
AVInaptic. 
Ho rippato 2 volte lo stesso film con impostazioni un po' diverse (*),
e il risultato finale è molto simile. Ho analizzato i due AVI con
AVInaptic senza notare niente di particolare, poi li ho analizzati con
DRFAnalyzer e ho visto che quello con DRF medio leggermente migliore
ha però molti più "KeyDRF > 4" e ci ho fatto caso solo perchè rispetto
a quello peggiore afferma che "This video may have some frames with
VERY POOR Quality! ".
Cos'è il KeyDRF? Perchè risulta peggiore nel rip venuto meglio?
Intanto posto i log di DRFAnalyzer, poi se serve posto quelli di
AVInaptic.
(Hehe, il titolo del film è molto fuorviante, in realtà si tratta solo
di questa commedia: 
http://akas.imdb.com/title/tt0054298/
 )
(*) 
1°) resize bicubic (sharp) + uncomb
2°) resize lanczos + field deinterlace (no blend) + greyscale 
(il film è preso da VHS PAL in bianco e nero)
------------------------------------------------------------------------------------------------------------------
DivX DRF Analyzer v0.9.5 Report!
File Name: W:\Sex Kittens go to College PAL 43 INT.avi
FourCC: XVID
Codec: XviD0046
Resolution: [ Width: 640 Height: 480 ]
Frame Rate: 25.000 frames per second
The Video has 154776 frames [ 01:43:11 ]
Average Frame quality is  MEDIUM	[Average DRF/quantizer is
3.27]
Standard Deviation: Quality is MEDIUM	[Std. Deviation is 0.91]
Image Resolution is HIGH
There are NO frame drops ( NO drops is better )
Recomended Resolution: [592x432] 	(Target DRF/quantizer=2.8)
Performance Caracteristics: 
Macroblocks per frame: 1200 ( Poor Playback in Slow Computers, PIII450
or better required ) 
The Width is multiple of 32
Kilobits per Second: 1717.28
Kilobits per Frame: 68.69
Kilobits per Macroblock: 0.057
Bits per Pixel: 0.23
Frame Type Statistics :
I Frames: 0.71%
P Frames: 50.34%
B Frames: 48.95%
S Frames: 0.00%
N Frames: 0.00%
(More Advanced Codecs use B and S frames)
Frame Quality Statistics :
DRF=1&2:	43461	28.3%
DRF=3:		29206	19.0%
DRF=4:		76595	49.8%
DRF=5:		4345	2.8%
DRF=6:		55	0.0%
DRF=7:		19	0.0%
DRF=8:		0	0.0%
DRF=9:		0	0.0%
DRF>9:		0	0.0%
KeyF/DeltaF:		0.71%
KeyDRF<4:	1085
KeyDRF=4:	9
KeyDRF>4:	1
AverageKeyDRF:	2.30
MAXDRF:	7
AverageDRF:	3.27
Deviation:	0.91
------------------------------------------------------------------------------------------------------------------
DivX DRF Analyzer v0.9.5 Report!
File Name: W:\Sex Kittens go to College PAL 43 INT lanczos.avi
FourCC: XVID
Codec: XviD0046
Resolution: [ Width: 640 Height: 480 ]
Frame Rate: 25.000 frames per second
The Video has 154776 frames [ 01:43:11 ]
Average Frame quality is  HIGH	[Average DRF/quantizer is 3.16]
Standard Deviation: Quality is MEDIUM	[Std. Deviation is 0.94]
Image Resolution is HIGH
There are NO frame drops ( NO drops is better )
This video may have some frames with VERY POOR Quality! 
Recomended Resolution: [592x448] 	(Target DRF/quantizer=2.8)
Performance Caracteristics: 
Macroblocks per frame: 1200 ( Poor Playback in Slow Computers, PIII450
or better required ) 
The Width is multiple of 32
Kilobits per Second: 1717.30
Kilobits per Frame: 68.69
Kilobits per Macroblock: 0.057
Bits per Pixel: 0.23
Frame Type Statistics :
I Frames: 0.72%
P Frames: 50.47%
B Frames: 48.81%
S Frames: 0.00%
N Frames: 0.00%
(More Advanced Codecs use B and S frames)
Frame Quality Statistics :
DRF=1&2:	52059	33.9%
DRF=3:		26513	17.3%
DRF=4:		72616	47.3%
DRF=5:		2381	1.5%
DRF=6:		12	0.0%
DRF=7:		51	0.0%
DRF=8:		34	0.0%
DRF=9:		2	0.0%
DRF>9:		0	0.0%
KeyF/DeltaF:		0.72%
KeyDRF<4:	934
KeyDRF=4:	1
KeyDRF>4:	173
AverageKeyDRF:	2.05
MAXDRF:	9
AverageDRF:	3.16
Deviation:	0.94
------------------------------------------------------------------------------------------------------------------
-- 
Paradoxally,
TT3HxV uvL

 Cos'è il KeyDRF? Perchè risulta peggiore nel rip venuto meglio?
il KeyDRF di DRFAnalyzer e' il quantizer usato nella codifica di
un I-frame.
Queste informazioni le trovi anche nei report di avinaptic: in
fondo, dopo l'analisi DRF, ci sono le statistiche dei quantizer
per tipo di frame
-- 
Home page di Frank: 
http://fsinapsi.altervista.org
Home page di Giubbe e FAQ: 
http://giubbe.altervista.org

per tipo di frame
Sarebbe il gruppo degli I-VOPs? Però non capisco la relazione, mi pare
che tu metta il totale dei frame e le percentuali per i valori, mentre
DRFAnalyzer direttamente il numero di frame anzichè le percentuali,
dico bene? 
Ma alla fine, il fatto che il rip con DRF medio migliore abbia molti
KeyDRF > 4  mentre l'altro solo 1 è irrilevante o è negativo?
----------------------------------------------------------------------------------------------
[ Info sul file ]
Nome: Sex Kittens go to College PAL 43 INT.avi
Data: 23/01/2009 05:43:56
Dimensione: 1,464,145,920 bytes (1396.318 MB)
[ Info generiche ]
Durata: 01:43:11 (6191.04 s)
Tipo di contenitore: AVI OpenDML
Streams totali: 2
Tipo stream n. 0: video
Tipo stream n. 1: audio
Audio streams: 1
ISFT: VirtualDubMod 1.5.10.1 (build 2439/release)
JUNK: VirtualDubMod build 2439/release
[ Dati rilevanti ]
Risoluzione: 640 x 480
Larghezza: multipla di 32
Altezza: multipla di 32
DRF medio: 3.266804
Deviazione standard: 0.909422
Media pesata dev. std.: 0.434436
[ Traccia video ]
FourCC: xvid/XVID
Risoluzione: 640 x 480
Frame aspect ratio: 4:3 = 1.333333
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 4:3 = 1.333333
Framerate: 25 fps
Frames totali: 154776
Stream size: 1,360,856,641 bytes
Bitrate: 1758.485347 kbps
Qf: 0.228969
Key frames: 1095 (0; 244; 251; 551; 623; ... 154494)
Null frames: 0
Min key int: 1
Max key int: 300
Key int medio: 141.347945
Ritardo: 0 ms
[ Traccia audio ]
Audio tag: 0x55 (MP3)
Bitrate (contenitore): 120.56 kbps VBR
Canali (contenitore): 2
Frequenza (contenitore): 48000 Hz
Chunks: 257960
Stream size: 93,296,040 bytes
Preload: 504 ms
Max A/V diff: 520 ms
Tipo: MPEG-1 Layer III
MPEG frames: 257960
Durata: 01:43:11 (6191.04 s)
Bitrate (bitstream): 120.556210 kbps VBR
Chunk-aligned: Sì
Emphasis: none
Mode: dual channel
Ritardo: 0 ms
[ Info sulla codifica MPEG4 ]
User data: XviD0046
Packed bitstream: No
QPel: No
GMC: No
Interlaced: No
Aspect ratio: Square pixels
Quant type: MPEG
Frames totali: 154776
Drop/delay frames: 0
Frames corrotti: 0
I-VOPs:  1095 (  0.707 %)                          
P-VOPs: 77915 ( 50.340 %) #############            
B-VOPs: 75766 ( 48.952 %) ############             
S-VOPs:     0 (  0.000 %)                          
N-VOPs:     0 (  0.000 %)                          
Max consecutive B-VOPs: 1
[ Analisi DRF ]
DRF medio: 3.266804
Deviazione standard: 0.909422
DRF max: 7
DRF=1:     1 (  0.001 %)                          
DRF=2: 44238 ( 28.582 %) #######                  
DRF=3: 29514 ( 19.069 %) #####                    
DRF=4: 76604 ( 49.493 %) ############             
DRF=5:  4345 (  2.807 %) #                        
DRF=6:    55 (  0.036 %)                          
DRF=7:    19 (  0.012 %)                          
DRF>7:     0 (  0.000 %)                          
I-VOPs DRF medio: 2.296803
I-VOPs deviazione std.: 0.476420
I-VOPs DRF max: 4
P-VOPs DRF medio: 2.509555
P-VOPs deviazione std.: 0.620177
P-VOPs DRF max: 4
B-VOPs DRF medio: 4.059551
B-VOPs deviazione std.: 0.242820
B-VOPs DRF max: 7
[ Profile compliancy ]
Profilo da testare: MTK PAL 6000
Risoluzione: Ok
Framerate: Ok
Min buffer fill: 60%
----------------------------------------------------------------------------------------------
[ Info sul file ]
Nome: Sex Kittens go to College PAL 43 INT lanczos.avi
Data: 24/01/2009 03:17:54
Dimensione: 1,464,162,304 bytes (1396.334 MB)
[ Info generiche ]
Durata: 01:43:11 (6191.04 s)
Tipo di contenitore: AVI OpenDML
Streams totali: 2
Tipo stream n. 0: video
Tipo stream n. 1: audio
Audio streams: 1
ISFT: VirtualDubMod 1.5.10.1 (build 2439/release)
JUNK: VirtualDubMod build 2439/release
[ Dati rilevanti ]
Risoluzione: 640 x 480
Larghezza: multipla di 32
Altezza: multipla di 32
DRF medio: 3.151728
Deviazione standard: 0.942494
Media pesata dev. std.: 0.433603
[ Traccia video ]
FourCC: xvid/XVID
Risoluzione: 640 x 480
Frame aspect ratio: 4:3 = 1.333333
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 4:3 = 1.333333
Framerate: 25 fps
Frames totali: 154776
Stream size: 1,360,871,230 bytes
Bitrate: 1758.504199 kbps
Qf: 0.228971
Key frames: 1108 (0; 251; 551; 623; 712; ... 154494)
Null frames: 0
Min key int: 1
Max key int: 300
Key int medio: 139.689530
Ritardo: 0 ms
[ Traccia audio ]
Audio tag: 0x55 (MP3)
Bitrate (contenitore): 120.56 kbps VBR
Canali (contenitore): 2
Frequenza (contenitore): 48000 Hz
Chunks: 257960
Stream size: 93,296,040 bytes
Preload: 504 ms
Max A/V diff: 520 ms
Tipo: MPEG-1 Layer III
MPEG frames: 257960
Durata: 01:43:11 (6191.04 s)
Bitrate (bitstream): 120.556210 kbps VBR
Chunk-aligned: Sì
Emphasis: none
Mode: dual channel
Ritardo: 0 ms
[ Info sulla codifica MPEG4 ]
User data: XviD0046
Packed bitstream: No
QPel: No
GMC: No
Interlaced: No
Aspect ratio: Square pixels
Quant type: MPEG
Frames totali: 154776
Drop/delay frames: 0
Frames corrotti: 0
I-VOPs:  1108 (  0.716 %)                          
P-VOPs: 78118 ( 50.472 %) #############            
B-VOPs: 75550 ( 48.812 %) ############             
S-VOPs:     0 (  0.000 %)                          
N-VOPs:     0 (  0.000 %)                          
Max consecutive B-VOPs: 1
[ Analisi DRF ]
DRF medio: 3.151728
Deviazione standard: 0.942494
DRF max: 9
DRF=1:  1373 (  0.887 %)                          
DRF=2: 51571 ( 33.320 %) ########                 
DRF=3: 26735 ( 17.273 %) ####                     
DRF=4: 72617 ( 46.917 %) ############             
DRF=5:  2381 (  1.538 %)                          
DRF=6:    12 (  0.008 %)                          
DRF=7:    51 (  0.033 %)                          
DRF=8:    34 (  0.022 %)                          
DRF=9:     2 (  0.001 %)                          
DRF>9:     0 (  0.000 %)                          
I-VOPs DRF medio: 2.046028
I-VOPs deviazione std.: 0.598322
I-VOPs DRF max: 4
P-VOPs DRF medio: 2.350252
P-VOPs deviazione std.: 0.567176
P-VOPs DRF max: 7
B-VOPs DRF medio: 3.996664
B-VOPs deviazione std.: 0.293073
B-VOPs DRF max: 9
[ Profile compliancy ]
Profilo da testare: MTK PAL 6000
Risoluzione: Ok
Framerate: Ok
Min buffer fill: 56%
-- 
Paradoxally,
TT3HxV uvL

 KeyDRF > 4  mentre l'altro solo 1 è irrilevante o è negativo?
il confronto che stai facendo non ha senso perche' i due filmati
sono diversi: all'encoder arrivano due filmati diversi.
L'analisi dei DRF non ti dice niente sulla qualita' dei filmati
che entrano nell'encoder. Uno potrebbe essere visivamente migliore
dell'altro, e non c'e' modo di saperlo mediante un'analisi di
questo tipo.
Questa analisi puo' essere utile per vedere quanto e' stata "pesante"
l'approssimazione operata in fase di codifica (non prima della
codifica).


codifica).
Ok, perfetto, grazie come sempre Frank! Per la cronaca, come si può
immaginare, i due filmati appaiono uguali, è difficilissimo valutare
differenze a occhio. Ero curioso di capire quella differenza numerica.
-- 
Paradoxally,
TT3HxV uvL

 quella differenza numerica.
di norma, un encoder dovrebbe codificare i frame di tipo I usando
bassi quantizer (fatte salve le impostazioni dell'utente), perche'
questi sono pochi sul totale (quindi non incidono molto sul
bitrate) e perche' servono da riferimento per gli altri (la
differenza tra i blocchi viene fatta con blocchi codificati, non
con quelli reali del filmato, quindi, tanto meno i codificati
sono approssimati, quanto piu' la differenza tende ad annullarsi).
Comunque, avere bassi quantizer sui frame I e significativamente
piu' alti sugli altri, non ha molto senso perche' il vantaggio
di avere buona fedelta' dei frame I viene vanificato...
Nelle tue due codifiche non c'e' una differenza significativa
nei numeri: uno aveva quantizer medi minori sui frame I ma
quantizer medio totale poco piu' alto; come "qualita' globale di
codifica" i due casi sono abbastanza simili.
Se la tua priorita' e' quella di ottenere codifiche con poca
perdita, allora non ti conviene codificare a "target bitrate"
in doppia passata, ma a "target quality" in singola passata;
in questo modo risparmi tempo e sai gia' a priori quanto la
codifica sara' fedele a cio' che entra nell'encoder (non hai
neanche bisogno di analizzare il filmato ottenuto).
Ricordati sempre che l'analisi DRF non dice nulla sulla
qualita' del filmato (dice, casomai, sulla qualita' della
codifica, cioe' quanto sembra essere perduto nella sola
fase di codifica finale).
Per ricordartelo meglio, ti faccio un semplice esempio che spero
chiarira' come stanno le cose.
Supponiamo di avere un filmato di partenza, che chiamiamo FO
(FO=filmato originale), che si vede abbastanza bene, e che
quindi non necessita di alcun filtraggio preliminare.
Supponiamo di applicare un filtraggio a FO, ottenendo il
filmato FF (FF=filmato filtrato); il filtro che applichiamo
ha l'effetto di "sfocare" un po' le immagini, facendo
perdere un po' di definizione nei dettagli
(per realizzare un tale filtro ci vuole un attimo: basta
rimpiazzare ogni pixel con una media pesata di un intorno
del pixel, dando peso massimo al centro, che coincide con il
pixel stesso, e un peso che decresce in funzione della
distanza dal centro).
Il filmato che otteniamo (FF) appare visivamente peggiore di
FO, perche' abbiamo appunto "segato" la nitidezza dei dettagli.
Eppure, se proviamo a codificare FO e FF con lo stesso codec
e con le stesse impostazioni di codifica (diciamo a target
bitrate in doppia passata), FF risulta probabilmente piu'
comprimibile di FO e, se andiamo a controllare i risultati delle
analisi DRF, vediamo che FF ha dei valori numeri "migliori"
di FO.
Pero', se andiamo a riprodurre il filmato, puo' essere
benissimo che FO ci sembri migliore di FF (piu' definito).
In poche parole: FF ha dei valori DRF migliori di FO, ma e'
visivamente peggiore di FO.
Perche'?
Perche' il filtraggio preventivo ha reso il filmato piu'
comprimibile (ma lo ha anche peggiorato).
Quello che tengo a precisare che non ha senso paragonare
i risultati delle analisi DRF di FO e FF, perche' per
l'encoder essi sono filmati diversi. L'encoder scopre che
FF e' piu' comprimibile e per esso puo' usare quantizer
piu' bassi, quindi la codifica di FF comportera' poca
perdita di informazione. Del resto, FF aveva gia' subito
una consistente perdita di informazione *prima* di
entrare nell'encoder, ma questo l'encoder non lo sa (ne'
e' tenuto a saperlo), e nemmeno noi lo possiamo sapere
mediante una qualsiasi analisi a posteriori.


l'encoder essi sono filmati diversi. 
Quindi basta che il deinterlace e il resize siano diversi per
considerarlo un flusso completamente diverso.
-- 
Paradoxally,
TT3HxV uvL

 considerarlo un flusso completamente diverso.
per l'encoder sono diversi. Basta che usi due metodi di resize
diversi (lanczos e bicubic, come hai fatto) per avere due filmati
diversi (rispetto a bicubic il lanczos ha l'effetto di aumentare
leggermente il contrasto, quindi tende ad appiattire meno; e cio'
ovviamente ha degli effetti sulla comprimibilita', sia in senso
spaziale che temporale).
In pratica, prima della codifica, dovresti decidere la catena di
filtraggi da applicare al filmato, in modo da fissare una volta
per tutte cio' che poi andra' codificato.


stanno giusti dentro un dvd :-) .
Ehhh, ma io sono fiscale coi generi: ogni DVD contiene (nel massimo
del possibile) solo film di genere analogo, non metto mai un horror
con una commedia, un fantasy con un drammatico, etc. E' un'abitudine
che mi è rimasta dai tempi delle VHS quando dovevo usare un qualche
criterio per stoccarle e non impazzire (troppo) a cercare un film. Coi
DVD è meno importante, uso il WhereIsIt (programma di catalogazione)
per trovare i film, ma mi piace mantenere la stessa logica, e mi basta
aspettare che una cartella di un certo genere raggiunga i 4 Gb e
rotti, ovvero dai 3 ai 6 film, cosa che con la dimensione variabile
sarebbe è molto più random.. :-)
-- 
Paradoxally,
TT3HxV uvL

stanno giusti dentro un dvd :-) .
potresti per favore dirmi come si chiama questo programmino?
Grazie :-)




l'ho scritto da me. Fa parte di un programma costituito da decine
di utilities che uso spesso (a riga di comando).
Comunque so che esistono altri programmi che svolgono la stessa
funzione, quindi qualcuno sapra' segnalarteli (se non ricordo
male, nel Ng ne fu nominato almeno uno).
Il mio programma e' a riga di comando, e si usa cosi': mi
sposto su una directory in cui ho messo molte directory ciascuna
contenente un film. Se chiedo al programma di trovarmi un
sottoinsieme delle directory che occupano uno spazio compreso
tra due dimensioni da me scelte (diciamo che deve essere
compreso tra 4,600,000,000 e 4,700,000,000) mi tira fuori una
soluzione tipo questa:
the-family-man -> 1467836416
juha -> 1065541798
quel-pomeriggio-di-un-giorno-da-cani -> 734503921
l-inquilino-del-terzo-piano -> 733510416
la-piscina -> 698560744
tot = 
4699953295
vedi com'e' preciso? :-)
Lo ha potuto fare perche' ci sono film con dimensioni "bastarde".
Se fossero stati tutti della stessa dimensione (diciamo 700 MiB)
non avrebbe trovato nessuna soluzione (la soluzione migliore che
avrebbe trovato sarebbe stata intorno a 4,400,000,000).
Il programma funziona in un modo estremamente semplice: per prima
cosa scandisce tutte le sottodirectories della directory corrente,
memorizzando per ciascuna directory la sua dimensione totale (in
bytes).
A questo punto ha i seguenti dati:
- un insieme finito di numeri interi (le dimensioni delle dir);
- un numero intero che e' il massimo che non va superato;
- un numero intero che e' il nostro "target" (e' la dimensione
  di cui possiamo accontentarci).
Il suo compito e' quello di trovare un sottoinsieme di numeri
la cui somma sia non superiore al massimo consentito e non
inferiore al target desiderato.
Questo e' un classico problema dell'informatica, che si chiama
"knapsack problem" (se cerchi con google, trovi un'infinita'
di materiale).
La mia implementazione e' veramente stupida, esistono algoritmi
piu' furbi, che in molte situazioni si comportano meglio del mio
(cioe', sono piu' efficienti, trovano una soluzione in minor
tempo).
Comunque, tutti gli algoritmi conosciuti impiegano un tempo che
cresce in modo esponenziale al crescere dell'insieme dei numeri
(in informatica si dice che il problema e' NP-completo; un
problema e' NP se la verifica di una soluzione si puo' fare in
tempi "brevi", cioe' che hanno un tasso di crescita polinomiale
con la dimensione dell'input, indipendentemente da quanto tempo
occorra per individuare quella soluzione...).
Se non trovi un programma analogo, fammi sapere (alle brutte
cerchero' di compilarti il mio)
