Newsgroup: it.comp.software.divx
Titolo: Analisi DRF di bitstream H.264

Come annunciato nei giorni scorsi, nella versione di AVInaptic che
trovate nel sito (9-02-2007) ho finalmente attivato l'analisi DRF
anche sui bitstream H.264 (MPEG-4 Part 10/AVC).
Non ho molto da spiegare, perche' si utilizza allo stesso modo di
quella dei bitstream ASP: basta cliccare su Statistiche->AnalisiDRF
(oppure sul pulsante con il grafico colorato rosso/giallo/verde).
Sicuramente ci saranno ancora delle imprecisioni (e forse qualche
errore grosso che puo' far crashare il programma), che cerchero' di
eliminare quanto prima, comunque nelle poche prove che ho fatto mi
sembra che l'analisi sia stata effettuata in modo corretto.
Se avete tempo e voglia, usatelo per analizzare i vostri filmati
codificati con x264, e magari confrontate i risultati con l'analisi
dei file stats effettuata da "x264 stats analyzer": se riscontrate
differenze nei risultati, segnalatamele, in modo che possa cercare
dove ho sbagliato.
Se avete filmati H.264 generati da codec diversi da x264, testatelo
anche su quelli...
Mi restano da spiegare alcuni dettagli.
Nel rapporto di un filmato H.264, adesso dovrebbe sempre comparire
una voce come questa:
--------------------------------
PPS id                      0
  Codifica entropica        CABAC
--------------------------------
il sotto-campo "Codifica entropica" e' rientrato di due spazi
perche' si riferisce al "PPS" indicato nella riga sopra.
Un encoder H.264 puo' definire vari PPS e SPS, dove PPS (Picture
Parameter Set) e SPS (Sequence Parameter Set) sono insiemi di
settaggi ai quali possono riferirsi le immagini del filmato.
Quindi, ogni "slice" che codifica un'immagine (o parte di essa)
ha un riferimento a un PPS; a sua volta, ogni PPS ha un riferimento
a un SPS.
Un dato abbastanza significativo relativo a un PPS e' se le
componenti dell'immagine sono codificate mediante un algoritmo
di tipo VLC (simile a quelli usati nei codec ASP) oppure una
codifica aritmetica (CABAC), che tipicamente comprime abbastanza
di piu' (richiede anche piu' tempo per la decodifica).
Ah, un'ultima cosa... ho attivato anche il "grafico DRF", che
pero' va risistemato meglio perche' cosi' non mi pare molto
utile.
Se avete suggerimenti, consigli e critiche, non fatevi problemi :-)
Essendo una versione appena scritta, la considero tutt'altro
che definitiva, quindi se mi suggerite migliorie, e' abbastanza
probabile che possa decidere di implementarle.
-- 
Home page di Frank: 
http://fsinapsi.altervista.org
Home page di Giubbe e FAQ: 
http://giubbe.altervista.org

LODE LODE LODE !!!
scaricato, stupendo, magnifico !!!!
piccola nota
DRF<16: 77 (24.444444 %)
DRF=16: 4 (1.269841 %)
perche' non mi dici il dettaglio dei quant minori di 16 ?
poi (richiestina)
DRF<16: 77 (24.444444 %)
DRF=16: 4 (1.269841 %)
DRF=17: 4 (1.269841 %)
DRF=18: 1 (0.317460 %)
DRF=19: 4 (1.269841 %)
DRF=20: 3 (0.952380 %)
DRF=21: 24 (7.619047 %)
DRF=22: 2 (0.634920 %)
DRF=23: 7 (2.222222 %)
DRF=24: 57 (18.095238 %)
DRF=25: 63 (20 %)
DRF=26: 50 (15.873015 %)
DRF=27: 18 (5.714285 %)
DRF=28: 1 (0.317460 %)
questo report potrebbe essere piu' "intuibile" se ci si mette un segno # 
per evidenziare il peso percentuale sul totale
tipo
fatto # = 25 frames (i numeri messi sotto li ho ritoccati per rendere 
piu' cabibile il tutto)
DRF<16: #####   150 (24.444444 %)
DRF=16: ##       60 (1.269841 %)
DRF=17: ##       60 (1.269841 %)
DRF=18: #         1 (0.317460 %)
DRF=19: #         4 (1.269841 %)
DRF=20: #         3 (0.952380 %)
DRF=21: ##       26 (7.619047 %)
DRF=22: ####### 320 (0.634920 %)
DRF=23: #         7 (2.222222 %)
DRF=24: ##       57 (18.095238 %)
DRF=25: ###      66 (20 %)
DRF=26: ##       50 (15.873015 %)
DRF=27: #        18 (5.714285 %)
DRF=28: #         1 (0.317460 %)
ho pero' dei problemi ad aprire un file
www.64k.it/andres/data/a/movie1.mkv
mi restituisce questo:
[ Info sul file ]
Nome: movie1.mkv
Data: 9/02/2007 20:19:19
Dimensione: 458,410 bytes
[ Info generiche ]
Tipo di file: JVT NAL sequence
[ Hex dump ]
00000000: 00 00 00 01 06 05 ff ff  30 dc 45 e9 bd e6 d9 48 
|......ÿÿ0ÜEé½æÙH|
00000010: b7 96 2c d8 20 d9 23 ee  ef 78 32 36 34 20 2d 20  |·.,Ø 
Ù#îïx264 - |
00000020: 63 6f 72 65 20 35 34 20  73 76 6e 2d 36 32 30 4d  |core 54 
svn-620M|
00000030: 20 2d 20 48 2e 32 36 34  2f 4d 50 45 47 2d 34 20  | - 
H.264/MPEG-4 |
00000040: 41 56 43 20 63 6f 64 65  63 20 2d 20 43 6f 70 79  |AVC codec - 
Copy|
00000050: 6c 65 66 74 20 32 30 30  35 20 2d 20 68 74 74 70  |left 2005 - 
http|
00000060: 3a 2f 2f 77 77 77 2e 76  69 64 65 6f 6c 61 6e 2e 
|://www.videolan.|
00000070: 6f 72 67 2f 78 32 36 34  2e 68 74 6d 6c 20 2d 20 
|org/x264.html - |
00000080: 6f 70 74 69 6f 6e 73 3a  20 63 61 62 61 63 3d 30  |options: 
cabac=0|
00000090: 20 72 65 66 3d 31 20 64  65 62 6c 6f 63 6b 3d 31  | ref=1 
deblock=1|
Rapporto generato da AVInaptic (9-02-2007) in data  9 feb 2007, h 20:19:38
(ti avverto che ho barato un po' su questo file... se hai problemi ti 
dico come l'ho fatto...)
In ogni caso : grazie per il preziosissimo contributo a tutta la 
comunita :)!!!
ciao
BHH

 dico come l'ho fatto...)
non so con cosa l'hai fatto, ma si puo' ottenere lo stesso tipo di
file con x264 (il programma a riga di comando).
L'ho rinominato come "movie1.264" e dato in pasto a mplayer che lo
riproduce bene (la sigla della 20th century fox).
Inoltre, con il comando:
---------------
$ MP4Box -add movie1.264 pippo.mp4
Adjusting AVC SizeLength to 16 bits
AVC-H264 import - frame size 640 x 272 at 25.000 FPS
Import results: 315 samples - Slices: 2 I 46 P 267 B - 1 SEI - 2 IDR
Saving to pippo.mp4: 0.500 secs Interleaving
---------------
si ottiene un MP4 che contiene quello stream (se fosse un matroska
MP4Box non lo importerebbe)
Ciao e grazie per il feedback


ho fatto un mirror del file (sono certo che andrai in saturazione di 
banda entro 8 ore!) 
www.64k.it/andres/data/a/avinaptic-
20070209-full.zip
BHH

On 09-Feb-07 Andres Zanzani wrote:

bene, ti ringrazio molto per la disponibilita'


Andres Zanzani ha scritto:

http://www.64k.it/andres/data/a/avinaptic-20070209-full.zip
-- 
Andres Zanzani
Cesena, Italy
www.64k.it/andres
 <--- Tutto e oltre per i DivX

 
ho anche aggiornato il thread su divxmania... se partecipassi anche 
tu... sarebbe molto utile !!
ciao


Altra ovvieta'... se non ci sono frames con quant < di 15 (ipotesi) 
basta segnare quant<15: 0 frames
ciao
BHH

 
ok.. continua a catena... : e' arrivata l'ora di tradurlo in inglese... 
come facciamo ? leggerai un ini di traduzione o fai un menu' a tendina 
con la scelta del linguaggio ?


 ho fatto un mirror del file
Se ti può essere utile, Frank, posso metterti in mirror un po' tutto
quanto anch'io! ;)
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
Il fanatismo consiste nel raddoppiare gli sforzi quando si è
dimenticato l'obiettivo. - George Santayana

 con la scelta del linguaggio ?
adesso inizio a pensare a una soluzione.
Quello che faro' sicuramente e' farmi estrarre tutte le stringhe costanti
che ho messo nel codice del programma, e inserirle in un elenco.
Poi togliero' dall'elenco tutte le stringhe che non dipendono dalla lingua.
A questo punto ci sara' da tradurre tutti i messaggi rimasti...
Poi trovero' il modo per permettere il selezionamento della lingua.
Accidenti... mi sono fatto dire dal mio compilatore il numero di stringhe
costanti presenti nel programma: 2101   :-(
Pero', di queste, quelle che contengono testo in italiano saranno
alcune decine...


 quanto anch'io! ;)
grazie anche a te.
Se lo metti, comunicami l'URL, cosi' metto il link, come ho fatto per
il mirror di Andres (per capire cosa intendo, dai un'occhiata alla mia
pagina, quella da cui si scarica il programma)


 tu... sarebbe molto utile !!
l'ho visto :-)
Mi devo iscrivere per poter rispondere?
Ok, ora provo


 
il tutto sta nel --pass1 quella opzione sta ad indicare che deve fare 
file funzionale all'analisi del primo passo.
(mi sa che studiare troppo il sorgente di le spec di h264 non ti ha 
fatto conoscere le opzioni di x264... ;) no prob, qui e su divxmania 
troverai pane per i tuoi denti !:)


 
anche io ho smoccolato quanto ho dovuto "tradurre" automkv in italiano 
(io sono partito facendo il programma in inglese...), in compenso le mie 
  stringhe sono circa una 70ina...
comunque anch'io penso che le stringhe nel tuo pragramma non saranno 
tante... molto (se non tutto) del risultato dell'analisi e' gia' in 
inglese... la rogna sara' solo portare fuori / dentro le stringhe, vedrai !
se ti serve una mano con la traduzione (ops.. non credo affatto...) chiedi!
ciao
BHH
-- 


 troverai pane per i tuoi denti !:)
infatti non ho mai creato veramente un x264, se non per semplici
prove :-)
Il fatto e' che per me e' fondamentale mettere film su supporti per
poterli scambiare con altri (parenti e amici) e per poterceli guardare
su un lettore da tavolo (non con un pc).
Quindi, finche' non si troveranno facilmente in vendita lettori che
riproducono anche H.264, restero' legato a XviD e Lavc (del resto,
abbondando di bitrate, si ottengono risultati molto buoni anche con
quelli, quindi e' solo un problema di dover sprecare piu' spazio).
Una delle poche cose che so sulle opzioni di x264, e' che gli
sviluppatori hanno copiato la tecnica di "rate control" dal codice
di libavcodec (progetto ffmpeg); infatti, se guardi nella lista
degli autori, compare anche Niedermayer, solo per quel motivo (non
e' stata una partecipazione attiva :-))
Se ti capita di confrontare i risultati con "x264 stats analyzer"
e di notare delle differenze nei numeri, avvertimi.
Stamattina ho ricontrollato il programma e mi sono accorto di una
dimenticanza (ora l'ho messo a posto, ma ormai lo rilascero' tra
qualche giorno), comunque forse si tratta di una situazione che in
pratica non capita mai, quindi la versione di ieri dovrebbe dare
ugualmente risultati giusti.
Ciao


Ah, dimenticavo... in una comunicazione privata mi hanno detto
che nel rapporto ci sono troppi numeri che non significano
molto per persone non esperte (il 99% di quelli che lo vedono).
Il consiglio che mi hanno dato e' quindi di riportare solo quello
che riporta "DRF Analyzer", in particolare i commenti se la
qualita' e' alta, media o bassa, ecc
Piu' precisamente, il programma dovrebbe stampare un rapporto con
queste info:
-----------------------------------------------------
Codice:
FourCC: XVID
Codec: XviD0046
Resolution: [ Width: 688 Height: 288 ]
Frame Rate: 25.000 frames per second
The Video has 164396 frames [ 01:49:35 ]
Average Frame quality is  HIGH  [Average DRF/quantizer is 2.97]
Standard Deviation: Quality is MEDIUM   [Std. Deviation is 1.00]
Image Resolution is HIGH
There are NO frame drops ( NO drops is better )
This video may have some frames with VERY POOR Quality! 
The Width is not multiple of 32. May degrade performance in some systems.
Kilobits per Second: 1039.86
Bits per Pixel: 0.21
e poi:
Audio Codec: (mp3 ac3 dts aac ogg...)
n° canali:(2, 5.1)
Bitrate:
Frequenza di campionamento
-----------------------------------------------------
A me pare che queste informazioni ci siano gia', alcune in modo
esplicito (il "Bits per Pixel" e' il Qf e "Kilobits per Second"
e' il bitrate del video), altre in modo implicito (i giudizi
sulla qualita')
Comunque, che ne pensate?
Dovrei mettere i commenti sulla qualita' e togliere alcune
informazioni che risultano incomprensibili?


 
per la qualita' sono d'accordo
ti posto questo snippet (per avere dei parametri qualitativi, e' gia' 
aggiustato in base ai quant di x264
if RESOLUTION * AR is >= (720*384*1.85) then it's considered to be VERY HIGH
if it is >= (624*336*1.85) then it's considered to be
HIGH
if it is >= (544*288*1.85) then it's considered to be
MEDIUM
if it is >= (480*256*1.85) then it's considered to be
LOW
else it's considered to be VERY LOW;
if STD.DEVIATION is < 3 then it's HIGH
if it's < 8 then it's MEDIUM
else it's LOW
if AVG. QUANTIZER is < 18 then it's VERY HIGH
if AVG. QUANTIZER is < 22 then it's HIGH
if it's < 26 then it's MEDIUM
if it's < 32 then it's LOW
else it's very LOW
riguarda alle informazioni... non me ne frega nulla se sono 
incomprensibili ai piu'... perche' privarci di una informazione se e' a 
disposizione?
Se proprio insistino crea un pulsante "advanced" che mostra i parametri 
avanzati/di troppo esempio:
1) muxing application
2) writeing application
3) info sulla codifica h.264 (i parametri di encoding del x264)
4) se i SP-slices e gli SI-slices non ci sono, non nominarli, (ma 
nell'avanzato scrivi lo stesso che non ci sono)
aggiungo la richiesta: nel grafico DRF mostrare/poter scegliere il frame 
ed indare il quant specififico del frames... altra cosa.. ma non 
andrebbe invertito ? ovvero i quant bassi in alto e quelli alti in basso 
? (tipo moltiplichi il valore dell'asse Y * -1)


 pagina, quella da cui si scarica il programma)
Metto solo Full package, zip con le dll e ultimo eseguibile. Giusto?
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
Essendo il lavoro la cosa più bella del mondo, bisogna lasciarne sempre
un po' per domani. - Anonimo

 di quelli che lo vedono).
E i poveri esperti, che fanno? ;)
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
Più di una bella impiccagione previene un pessimo matrimonio.
William Shakespeare

 A questo punto ci sara' da tradurre tutti i messaggi rimasti...
Se vuoi una mano con l'inglese, ben volentieri. ;)
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
Un gatto in casa è segno di solitudine, due di sterilità e tre di
sodomia. - Edward Dahlberg

 pagina, quella da cui si scarica il programma)
Ho creato una paginetta in cui ho copiato quello che c'era.
È raggiungibile direttamente dalla home page del mio sito, oppure
direttamente qui: 
http://www.lordkap.it/aruba/avinaptic/avinaptic.html
,
mentre il file zip full è in:
http://www.lordkap.it/aruba/avinaptic/avinaptic-20070209-full.zip
Fammi sapere se va bene così, se ti serve aiuto per la traduzione, se ho
messo troppo e preferisci che venga ricondotto di più alla tua pagina o
altro. Insomma: a tua disposizione. ;)
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
L'autorità dimentica un re morente. - Alfred Tennyson

 andrebbe invertito ? ovvero i quant bassi in alto e quelli alti in basso 
penso sia una questione di abitudini e di gusti :-)
Se non ho capito male, com'e' adesso dovrebbe essere come quello di
DRF Analyzer...
Piu' che altro andrebbero ridefinite le "zone colorate" a valori piu'
utili.
Un'altra cosa che posso fare e' ordinare in modo diverso i tipi di
frame di H.264 (metterei i frame I prima di tutti), ma forse non e'
molto importante...
Un'altra cosa ancora e' cambiare il termine "DRF" con "QP" oppure
"quant" (e in tal caso, solo per H.264 o anche per il caso ASP?).
Se avete suggerimenti e preferenze, fatemi sapere.


 se ti serve aiuto per la traduzione,
forse si', quando verra' il momento ti faro' sapere


 Se avete suggerimenti e preferenze, fatemi sapere.
[Angolo dell'ignoranza] ;)
Il quantizer di cui si parla nell'impostazione della singola passata "a
quantizer costante" (di solito si sceglie il 2 per Xvid) è lo stesso di
cui si sta parlando qui?
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
Non usate la parola straniera "ideali". Abbiamo nella nostra lingua
l'eccellente termine "bugie". - Henrik Ibsen

 cui si sta parlando qui?
si'.
Il termine "quantizer" viene usato di piu' nell'ambito di DivX/XviD;
mentre il termine DRF e' piu' generale e veniva usato in precedenza
(DRF=Detail Removal Factor).
Nell'ambito di H.264 si parla di QP (parametro di quantizzazione).


 si'.
Allora non mi spiego come mai ci sono valori così alti e non vengono
contemplati nella tua analisi quelli sotto il 16 che dovrebbero essere
comunque quelli che denotano una qualità migliore. Immagino mi stia
perdendo qualcosa. ;)
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
Le posizioni estreme non sono seguite dalle moderate, ma da opposte
posizioni estreme. - Friedrich Nietzsche

 perdendo qualcosa. ;)
presumo che ti stia riferendo a un'analisi di bitstream H.264.
In tal caso, e' normale che ci siano valori alti.
Per quanto riguarda i valori inferiori a 16, ho riscritto
quella parte di programma che stampa i valori e adesso usa un
metodo diverso (se ci sono valori inferiori a 16, vengono
riportati anche quelli). Una nuova versione con questa modifica
la trovi qui:
http://fsinapsi.altervista.org/tmp/tmp.zip
Nei codec MPEG-4 ASP (DivX, XviD, Lavc, 3ivx, ecc), il quantizer e'
un numero compreso tra 1 e 31, e generalmente, i valori che
corrispondono a un'approssimazione normale (senza troppa perdita di
qualita') sono nel range 2-5.
Nei codec MPEG-4 AVC (x264, ateme, ecc), il quantizer e' un numero
compreso tra 0 e 51, e generalmente, i valori che corrispondono a
un'approssimazione normale sono nell'intorno di 26.
Quindi, nel caso AVC (H.264), e' normale che i quantizer siano molto
piu' alti rispetto a quelli ASP.
Il motivo di questa differenza e' dovuto al fatto che in H.264 hanno
introdotto una trasformata differente, e un diverso modo di quantizzare
i coefficienti che risultano dalla trasformata.
Una trasformata e' un'operazione matematica che viene eseguita su
un "blocco" (un quadratino che fa parte di un'immagine), cioe'
un'operazione del tipo:
X -> A * X * At
dove A e' una certa matrice e At e' la sua trasposta.
(N.B. questa operazione e' reversibile)
Questa operazione serve per trasformare un'immagine nei coefficienti
di una combinazione lineare di una "base".
Una delle basi piu' usate e' la cosiddetta "base DCT" (trasformata
discreta del coseno), usata sia nelle JPEG che nei codec video MPEG.
Se vuoi vedere com'e' fatta una base DCT, basta che vai su
"Google immagini" e cerchi "dct basis"... ecco il primo risultato:
http://www.eecs.umich.edu/~amarathe/dct-basis.gif
Come vedi, si tratta di 64 quadratini 8x8.
Ebbene, tutte le immagini 8x8 a livelli di grigio possono essere
scritte come combinazione lineare di questi 64 quadratini.
Una combinazione lineare e' una "somma pesata" o "media pesata",
se hai piu' familiarita' con questi ultimi termini.
Quando si applica la trasformata DCT, si ottengono proprio i
"pesi", che in questo caso si chiamano "coefficienti DCT".
Uno puo' pensare: prima avevamo un'immagine 8x8 (64 numeri);
dopo la trasformata abbiamo 64 coefficienti (64 numeri). Quindi
che risparmio abbiamo in termini di spazio di memorizzazione?
Nessuno :-)
Pero', ci sono due punti importanti da osservare.
Il primo e' che si da' il caso che la nostra percezione visiva
non funziona allo stesso modo sulle 64 immaginette della base DCT,
quindi, se vogliamo apportare delle approssimazioni all'immagine
(per risparmiare spazio di memorizzazione), lo possiamo fare
sacrificando l'accuratezza nella precisione dei coefficienti
in modo proporzionale alla loro "importanza". Quindi,
inizieremo a sacrificare i coefficienti che rappresentano
componenti delle immagini che corrispondono a dettagli che
tipicamente tendiamo a percepire meno. Il criterio con cui
approssimiamo le componenti e' basato su un modello del "sistema
visivo umano", ed e' sintetizzato dalle cosiddette "matrici di
quantizzazione" (ad esempio, XviD permette di definire matrici
a piacere). Oltre alle matrici di quantizzazione, il grado di
approssimazione e' regolato da un parametro (un numero)... se
non lo avessi indovinato, questo numero e' proprio il "quantizer"
di cui stiamo parlando.
Il secondo punto importante e' che le immagini "realistiche"
(quelle che provengono dal mondo) non sono miscugli casuali
di colori, ma hanno caratteristiche statistiche significative.
A causa di cio', succede che i coefficienti DCT di un'immagine
realistica siano "addensati" in una zona della matrice; in
altre parole, e' raro che un'immagine del mondo reale abbia
tutte le componenti DCT, ma ne avra' solo un sottoinsieme
abbastanza compatto.
Quindi molti coefficienti saranno nulli, e quelli non nulli
saranno perlopiu' disposti vicini l'uno all'altro. Per questo,
e' stato introdotto un particolare riordinamento dei
coefficienti (chiamato "zigzag scan"), che genera una sequenza
di bit che viene compressa abbastanza bene mediante una
codifica entropica (la sequenza contiene sotto-sequenze
aggregate di zeri). Ricollegandomi al punto precedente,
quando si approssimano anche i coefficienti non nulli (il
grado di approssimazione dipende dalle matrici di
quantizzazione e dallo specifico quantizer), succede che il
numero di bit pari a 0 (aggregati) aumenta sempre piu',
rendendo la sequenza sempre piu' comprimibile.
Ora, le differenze nei valori di quantizer tra il caso dei
codec ASP e quelli AVC e' dovuto semplicemente a dettagli
matematici...
Non so se questa spiegazione sia tanto chiara... :-)
Se ho usato termini incomprensibili dimmelo e cerchero' di
spiegarli con altre parole.


 
per adesso lascia cosi'. che la gente non sa neache che roba sia il DRF 
(come sigla..)


 con altre parole.
Direi che la spiegazione va bene, dovrò solo cercare di ricordare tutte
le nozioni di matematica che dovrei sapere. ;)
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
If you can smile when things go wrong, you have someone in mind to
blame.

 TUTTE le informazioni in un unica scheda.
non ho capito cosa intendi.
Quando si salva il rapporto in un file, vengono messe tutte e sole
le informazioni che compaiono nel rapporto in quel momento


 avevo da Ingegneria. ;)
non ci ho messo molta matematica, dai :-)
E comunque non di analisi, ma di algebra lineare, che sicuramente avrai
studiato a ingegneria (forse il corso si chiamava "geometria"). Immagino
che di spazi vettoriali, matrici e determinanti, non ti ricordi
moltissimo, o sbaglio? :-)


 Forse bisognerebbe basarsi solo sul prodotto larghezza x altezza
per il momento ho basato le regole solo sul prodotto
larghezza x altezza, poi si vedra'...
Ho messo una nuova versione (solo lo zip con il solo eseguibile),
che comprende le seguenti modifiche:
- corrette alcune imprecisioni e dimenticanze;
- aggiunto il rilevamento automatico dei titoli di coda codificati
  a quantizer piu' alti, anche per i filmati AVC;
- aggiunta la sezione [ Giudizi sulla qualita' ]: i giudizi sul
  drf medio e la deviazione verranno messi nel rapporto solo dopo
  aver effettuato l'analisi DRF;
- modificata la visualizzazione delle distribuzioni (barrette
  percentuali)


 moltissimo, o sbaglio? :-)
Diciamo che non saprei reggere un'interrogazione... ;)
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
Chi vuol muovere il mondo prima muova se stesso. - Socrate

 di una 640x480, e questo mi lascia abbastanza dubbioso...
Anche a me lascia più di un dubbio, in effetti.
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
Chi desidera ma non sa agire è fonte di pestilenza. - William Blake

 Ho messo una nuova versione (solo lo zip con il solo eseguibile),
Aggiornato il mio mirror. ;)
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
Do people in France use American ticklers?

Ho messo una nuova versione (solo lo zip con il solo eseguibile),
Grande Frank, AVInaptic migliora di giorno in giorno :-) 
Io sarò via per lavoro fino a marzo, chissà quante release nel
frattempo. Ciao!
-- 
Paradoxally,
Jan AxHell