Newsgroup: it.comp.software.divx
Titolo: GordianKnot - Aspect Ratio

Il secondo tentativo che sto facendo per vedere se GK si dimentica di
settare XviD secondo i parametri che gli dň, č con un film PAL 16:9
anamorfico interlacciato.
Volendo rimanere entro gli standard dei lettori stand-alone, mi sono
imbattuto nel problema dell'AR.
La copertina del film indica 1.85:1. Per potermi avvicinare a questo
valore il piů possibile, devo ridurre eccessivamente la risoluzione
(384x208=0.1%), mentre io preferirei stare al di sopra di 512xXXX.
Tuttavia in questo caso oltrepasso il 2% di errore (restando nei
limiti di 0.22 bits/(pixel*frame). E' troppo? C'č qualche escamotage
che mi consenta di fare meglio senza passare dall'ITU (che cmq mi pare
non sia riconosciuto dai lettori e che abbia a sua volta un errore di
2.5%)?
-- 
Paradoxally,
Jan AxHell

2.5%)?
Aggiornamento: ho visto che se imposto l'orizzontale a multipli di 16
anzichè 32, ottengo uno 0.3% di errore AR (560x304) con 0.199
bits/(pixel*frame). Il film dura 99 min, quindi il bitrate per un CD
da 702 Mb sarà al limite. Che ne dite, è accettabile?
Ma soprattutto: come se la cavano i lettori stand-alone con
orizzontali non multipli di 32?
-- 
Paradoxally,
Jan AxHell

 orizzontali non multipli di 32?
benissimo.
ho un divx 524x394 (4:3) che il lettore stand-alone riproduce
benissimo e 524 non e' multiplo nemmeno di 8 (394 non lo e' nemmeno
di 4)...
ma da dove esce fuori 32? per analizzare i movimenti gli algoritmi
suddividono i frame in "macroblocchi" di dimensioni 16x16, e, se
la risoluzione non e' esattamente multipla di 16, sono comunque
(o dovrebbero) in grado di estenderli e trattarli in modo trasparente
all'utente... per quanto riguarda la decodifica, la cosa e' ancora
piu' semplice, persino un lettore primitivo come il nortek riesce
a trattare bene risoluzioni strambe (come 524x394)...

a trattare bene risoluzioni strambe (come 524x394)...
Appunto: chi mi dice che tutti i lettori accettano quiesti valori?
Esistono delle specifiche trasversali ai lettori? Quel che ho letto è
che sì, si possono vedere filmati "non standard", ma con qualità
inferiore, poichè l'aggiustamento viene fatto al volo degradando
l'immagine. Ho una XBOX che si mangia tutto, quindi non posso fare
prove con lettori stand alone. Ho ordinato un Pioneer DV470 con
chipset mediatek, con quello potrò fare esperimenti.
Inoltre il GordianKnot stesso è impostato di default su 32 e 16, e un
motivo ci sarà...
-- 
Paradoxally,
Jan AxHell

 motivo ci sarà...
sul 32 non saprei dire (eccetto quanto detto sopra in riferimento
alle schede grafiche); per quanto riguarda il 16, in effetti lo standard
mpeg4 richiede obbligatoriamente che le dimensioni del filmato siano
multiple di 16; come ho gia' detto, credo che tale vincolo sia dovuto solo
al fatto che gli algoritmi lavorano su blocchi 16x16...
in effetti, una volta mi sono scontrato con questo problema:
stavo codificando una serie di divx, avendo scelto una risoluzione non
standard 576x342 (attenzione: 342, non 432; il resto della divisione
per 16 di 342 e' 6)
a un certo punto ho aggiornato l'encoder (mencoder, dalla versione
1.0pre4 alla 1.0pre5) e improvvisamente e' comparso un problema:
le ultime 6 righe del filmato ottenuto si vedevano malissimo (con lo
stesso mplayer, e anche con tutti gli altri lettori); eppure con la
versione precedente non avevo mai riscontrato niente del genere...
il motivo e' che avevano "ripulito" il codice del codec, e non si
erano accorti del problema che ne era derivato perche' lo avevano
testato solo su multipli di 16; quando gli e' stato segnalato hanno
subito risolto, e cosi' con l'attuale release ufficiale (1.0pre6) e'
di nuovo possibile fare filmati con risoluzioni non multiple di 16;
ma lo sai cosa hanno fatto? e' molto semplice! se una risoluzione non
e' multipla di 16 viene "estesa" in modo che lo sia (considerando il
piu' piccolo multiplo di 16 che sia maggiore o uguale), ottenendo in
tal modo una risoluzione conforme allo standard; poi pero', nello
stream, viene memorizzata la risoluzione scelta dall'utente e in
effetti questa cosa non sarebbe molto corretta... tuttavia i lettori
che ho visto non sembrano avere problemi con questa tecnica, per
quanto sia scorretta...

 molto sensato
oops, scusa, mi era sfuggita questa considerazione.
ho capito il pincipio che hai esposto, ma non sono molto d'accordo,
e in parte ne ho spiegato il motivo nel post precedente.
penso che dovrei spiegarlo meglio (magari in post futuri), per il
momento mi limito a un accenno.
fermo restando che, a un certo livello di astrazione esistono dei
vincoli da rispettare (multipli di 16 o 32), mi pare assurdo che tali
vincoli debbano propagarsi a livelli piu' astratti dell'utente che
deve crearsi un divx; tra i compiti dei programmi c'e' quello di
svincolare i livelli superiori, mascherando le caratteristiche
tecniche inessenziali a tali livelli. come ho accennato nel post
precedente, i vincoli sulla risoluzione possono essere rispettati
dove effettivamente hanno senso, liberando pero' l'utente a
scegliere la risoluzione che piu' gli fa comodo (entro certi
limiti)

quanto sia scorretta...
Ok, in pratica la conclusione è che se sto dentro i multipli tanto
meglio, se no mi adeguo di conseguenza.
-- 
Paradoxally,
Jan AxHell

limiti)
Io preferisco ottenere risultati il più possibile fedeli
all'originale. Tuttavia il film che ho compresso a seguito di questa
discussione ha un AR error del 2.2% ed è veramente dura rendersene
conto ad occhio. Ho rispettato i multipli di 32 e 16 passando dall'
1.85:1 a 1.89:1, ma me ne rendo conto solo perchè lo leggo nei dati,
non certo da quel che vedo a schermo. Direi che entro certi limiti ci
si può anche stare. Sì, mi hai detto che bene o male funzionano anche
filmati non standard, ma dato che sono cmq la minoranza (fino ad ora
non avevo avuto questo problema) mi regolerò di volta in volta :)
-- 
Paradoxally,
Jan AxHell

 meglio, se no mi adeguo di conseguenza.
in conclusione ti consiglio di fare delle prove e valutare da te.
per quel che riguarda le prove che ho fatto io, non trovo motivi
validi per rispettare la regola dei multipli a discapito dell'AR,
ma non posso essere certo che un divx con risoluzioni non standard
non da' problemi a nessun lettore...
se in futuro compri un lettore stand-alone e scopri che i tuoi
divx non standard si vedono male, non prendertela con me :-)

divx non standard si vedono male, non prendertela con me :-)
No no, anzi, grazie di tutte le risposte! :)
-- 
Paradoxally,
Jan AxHell

passate?
Come sopra, chiedo a chi lo sa: ho fatto una prova sempre con il film
che ho già compresso e in GK mi è saltato fuori questo :
160.5% of 0.152 Compressibility Test
Che vuol dire??
-- 
Paradoxally,
Jan AxHell

 Questo *credo* sia il "Begin with keyframe" che c'è nelle opzioni del
credo di no. sto guardando la documentazione di "Enc": nella sezione
"XviD - Compressibility test" c'e' un'immagine "XviD Configuration -
Global"... in quella finestra c'e' un parametro che si chiama
"Maximum I-frame interval" (li' e' settato a 300); quello e' lo stesso
parametro che io ho chiamato "max keyint"
se tu lo setti a 50, allora otterrai *almeno* un keyframe ogni 2
secondi di filmato (ma avrai bisogno di un bitrate superiore);
se lo setti a 1, allora otterrai un filmato contenente soltanto
keyframes (qualcosa di molto simile a un MJPEG)...
comunque, conviene usare valori del tipo 250 o 300;
io ti ho solo detto un modo per costringere il codec a generare piu'
keyframes, visto che DRFanalyzer ti segnala che i tuoi xvid ne hanno
troppo pochi...

troppo pochi...
Ok, ho capito, me ne occuperò solo in caso di gravi problemi, per ora
mi basta capire come gestire il compressibility test.
-- 
Paradoxally,
Jan AxHell

 Ho lasciato come era, proprio come dici tu e come indicato dal doc.
e' certo che si e' verificato un problema, ma non so spiegarlo :-(
pare che Enc abbia generato un filmato breve (dal tuo film) e che
il totale delle dimensioni dei frame ottenuti sia eccessivamente
alto... una causa potrebbe essere che quelli di XviD hanno modificato
il formato del logfile ed Enc non legge piu' le informazioni esatte;
ma non e' detto...
ecco, queste sono le prime righe di un logfile di XviD (1.1.0-beta1):
--------------------------------------------------
# XviD 2pass stat file (core version 1.1.-126)
# Please do not modify this file
i 2 972 0 0 34225 4113
p 2 637 335 0 44057 4243
b 4 0 972 0 9195 1764
b 4 0 972 0 8428 1697
p 2 4 938 30 32740 1823
b 4 0 972 0 8871 1875
b 4 0 972 0 8643 1869
p 2 16 952 4 37103 1935
b 4 0 972 0 8097 1763
b 4 0 972 0 8507 1806
p 2 16 952 4 32450 1840
[...]
--------------------------------------------------
la prima colonna indica il tipo di frame, la seconda sara' il quantizer...
la dimensione (in bytes) del frame dovrebbe proprio essere la sesta...
ci pensero' meglio stasera... se scopriro' qualcosa te lo faro' sapere

ci pensero' meglio stasera... se scopriro' qualcosa te lo faro' sapere
Grazie. Non avrò modo nè di rispondere nè di occuparmene fino a
domenica, o al massimo sabato sera (se nevica forte ;-) 
-- 
Paradoxally,
Jan AxHell

 risulta che possano esserci problemi con il logfile,
mi ero deciso a scrivere all'autore, e ho quindi recuperato il tuo
post in cui riportavi il risultato del test...
e mi sono accorto dell'errore!!! :-)
questo e' quanto scrivevi:
-----------------------------------------
Mah, ho provato adesso Enc usando l'AVS del film che ho già compresso,
ed ho ottenuto un log poco chiaro (ho settato la dimensione finale a
702 Mb e ho lasciato XviD così com'era dall'ultimo lavoro):
00:06:05   [Ok]   0.09%   718,848 / 806,882,028 Bytes
(6384 / 148950 frames used, 512x272, 25.000 fps, 148950 frames,
5958.00 seconds)
Ct 5% (Normal, Del)   702 KBytes   XviD (xvid)   F:\Temp 5\Perfume.avs
C:\Video\GordianKnot\VirtualDubMod\VirtualDubMod.exe
(FR)3479#4#Fast1#13#Avi21#F:\Temp 5\Perfume.avi2
-----------------------------------------
ecco la spiegazione... mi era sfuggito!
la "target video size" che hai impostato non e' 702 Mb, ma 702 Kb:
se guardi la prima riga, puoi notare il valore 718,848, che invece
avrebbe dovuto essere 736,100,352;
quindi, il vero risultato del test non e' 0.09%, ma 91.23%
in altre parole, il test dice che il risultato della codifica sara'
molto buono (si avvicina abbastanza alla saturazione del codec)
se vai a vedere la finestrella di Enc dove hai impostato la "target
video size", tra parentesi e' specificato (KBytes), quindi avresti
dovuto metterci 702*1024=718848 e non 702...
in realta', credo che tu intendessi un valore ancora diverso...
perche, immagino, nei 700MB (capacita' di un CD) hai conteggiato
tutto l'AVI, completo di stream audio;
quindi, avresti dovuto togliere la dimensione dello stream audio
e un po' di overhead...
comunque, nella documentazione viene dato questo suggerimento:
----------
Now put the bitrate you are going to use for the real encode or, if you
prefer, your target video size (you can obtain both informations with Gordian
Knot).
----------
in pratica, forse ti conveniva usare un "bitrate calculator" e
impostare in Enc il valore di bitrate calcolato per il solo stream
video...
alla fine sembra che il problema sia chiarito. :-)
ciao

>ci pensero' meglio stasera... se scopriro' qualcosa te lo faro' sapere
scusa per il ritardo immane, sono stato preso da altro...
ho appena riguardato il codice di "Enc" e mi sembra corretto, anche se
ci sono alcuni particolari che purtroppo non posso verificare...
da quello che ho capito, "Enc" puo' effettuare un test di
"comprimibilita'" (CT) oppure una "size prediction" (SP)
(oppure puo' effettuare una normale codifica, ma adesso non mi
interessa);
i due test sono effettuati in modo praticamente identico, l'unica
differenza e' che nel CT vengono stampate piu' informazioni, in
particolare viene stampato il valore di percentuale che piu' o
meno ci dice se la codifica che vorremmo fare dara' un buon
risultato oppure conterra' artefatti...
vediamo adesso quali sono i punti salienti del metodo impiegato da
Enc. (e' molto facile)
per effettuare un test (SP o CT), l'utente specifica un valore della
percentuale di filmato che verra' analizzata (nella documentazione
si nota il valore 5%, ma mi pare che giubbe consigliava un valore
piu' alto, cioe' 15%); indichiamo tale percentuale con p;
indichiamo inoltre con f il numero totale di frames di cui e' composto
il filmato;
se definiamo tot=int(1400/p)
allora il rapporto 1400/tot e' una approssimazione di p; in altre
parole, se noi consideriamo il filmato come una sequenza di blocchi
consecutivi lunghi tot frames, e per ciascun blocco prendiamo solo i
primi 14 frames, alla fine avremo preso una percentuale di frames che
si avvicina abbastanza a p (la percentuale scelta);
questo e' esattamente cio' che fa il filtro "SelectRangeEvery(tot,14)"
di AviSynth, che "Enc" appende allo script usato per generare il
filmato...
a questo punto viene effettuata la codifica vera e propria ("Enc"
mette in esecuzione un programma eseguibile esterno, che provvede
a interpretare lo script ".avs"...); alla fine della codifica, da
qualche parte viene lasciato un file che si chiama "vdenc.log"...
qui purtroppo non ho modo di provare...
se mi facessi avere il contenuto di tale file "vdenc.log", potrei
controllare se il resto del programma e' corretto...
a questo punto, "Enc" analizza il file "vdenc.log", ricavandone
questi dati:
- frames: il numero di frames presi in considerazione (si tratta
  di un numero inferiore a f*14/tot, perche' un certo numero di
  frames vengono scartati);
- frsize: il numero di bytes occupati da tali frames;
dopodiche' effettua una proiezione lineare, calcolando il valore:
size = f*size/frames;
il valore size cosi' calcolato e' proprio il risultato del test SP,
cioe' il valore in bytes che occupera' lo stream video del filmato
nel caso in cui venga codificato a "quantizer fissato".
nel test CT viene calcolato un ulteriore valore: in questo test,
l'utente specifica anche il bitrate che vorrebbe usare (oppure,
se preferisce, puo' specificare direttamente la dimensione in bytes
che vorrebbe ottenere); in ogni caso, il programma riesce a
calcolare la dimensione in bytes desiderata, che chiama tsize
(presumo che stia per "target size"); cio' gli permette di calcolare
questo valore:
ctval = 100*tsize/size
che e' il risultato del test CT, cioe' la famosa percentuale che
ci dice se il risultato della codifica sara' buono, o se dovremmo
invece apportare qualche modifica nei parametri di codifica...
se ricordo bene, tu avevi ottenuto un risultato del tutto sballato
(mi pare 0.09%), il che vuol dire che in tutto questo processo
qualcosa non e' andato per il verso giusto...
visto che l'algoritmo e' molto semplice e sostanzialmente corretto,
secondo me il problema si e' verificato nell'analisi del file
"vdenc.log"... forse tale file ha un formato diverso da quello che
si aspetta il programma...
secondo me, un modo per ovviare a problemi di questo tipo sarebbe
quello di sostituire l'analisi del logfile con un'analisi diretta
del file AVI generato, in modo da rendere il programma indipendente
da possibili cambiamenti di formato dei logfile...
(forse l'unico vantaggio nell'uso del Perl in questo programma sta
proprio nella semplicita' di analisi di un tale file di testo);
tuttavia, esistono librerie C molto buone e semplici per analizzare
file AVI (esempio: "avilib" che si trova nei pacchetti "transcode"
e "ogmtools") ed e' molto facile fare la stessa analisi che Enc
effettua sui logfile, analizzando direttamente l'AVI (ad esempio,
avilib ha una funzione che si chiama "AVI_frame_size", e restituisce
la dimensione in bytes di qualsiasi frame dello stream video
contenuto nell'AVI).
piu' tardi scrivero' all'autore di Enc per chiedergli se gli
risulta che possano esserci problemi con il logfile, o se possa
dipendere da qualcos'altro...
ciao

e un po' di overhead...
A questo non avevo pensato, grazie delle dritte! :-)
-- 
Paradoxally,
Jan AxHell

scusa per il ritardo immane, sono stato preso da altro...
Don't worry, abbiamo tutti da fare!
-- 
Paradoxally,
Jan AxHell