Newsgroup: it.comp.software.divx
Titolo: test sulla conversione di framerate - lettori sa

In un post di ieri menzionavo la capacita' di molti lettori
stand-alone (d'ora in poi abbrevio "sa") di riprodurre in
modo abbastanza fluido e soddisfacente filmati con frame rate
diversi da 25 fps.
E' da un pezzo che mi chiedo quale metodo usino, e per ora
sono portato a credere che si tratti di una variante del
"metodo switch" del filtro "ConvertFPS" di AviSynth.
Purtroppo non conosco modo per saperlo direttamente,
neanche smontando l'apparecchio (il mistero sara' racchiuso
dentro un chip :-)) e neppure saprei a chi chiederlo
(qualcuno lo sa?).
Non resta che un approccio di tipo comportamentista
skinneriano :-)
Immagino non sara' proprio facile, comunque chi volesse
divertirsi a testare il proprio lettore sa, per prima cosa
si procuri un filmato 29.97 nativo. Per esempio,
potete scaricare questo:
http://video-akamai.stage6.com/634.divx
(20,909,654 bytes)
Le caratteristiche di questo divx sono le seguenti:
----------------------------------------------------------
Info generiche
durata              00:01:56 (116.053255 s)
tracce audio        1
Traccia video
codec               DX50
framerate           29.969000 fps
risoluzione         640 x 352
bitrate             1,300.699131 kbps
totale frames       3,478
key frames          16 (0; 300; 600; 900...)
zero-byte frames    0
min key int         1
max key int         300
key int medio       217.375
Qf                  0.192655
Traccia audio n. 1
audio tag           0x0055 (MP3)
bitrate             128 kbps CBR
canali              2
bit campioni        0
frequenza           44,100
chunks              3,478
dimensione          1,864,318 bytes
----------------------------------------------------------
Scorrendo i frame mi pare che si tratti proprio di un 29.97
"nativo", cioe' non ci e' stato portato da un framerate
diverso (con un procedimento 3:2 pulldown), ma i fotogrammi
sono stati "fotografati" proprio a quella frequenza.
Questo e' il frame 251 del filmato:
http://fsinapsi.altervista.org/tmp/frame251.png
Visualizzandolo sul pc lo vedo benone.
A questo punto, proviamo il lettore sa, naturalmente usando
un supporto riscrivibile
(mkisopad 634.divx | cdrecord -v -tao -)
Ecco, lo vedo molto bene anche sul televisore: riproduzione
fluida, buona qualita', neanche l'ombra di uno scatto...
Se invece faccio una conversione rozza (eliminazione regolare
di frames per portarlo da 29.97 a 25, ad esempio usando
"mencoder -ofps 25...") ottengo un filmato evidentemente
scattoso...
Quindi, fino a qui si puo' dire che il lettore sa non usa
un metodo semplice di rimozione/inserimento frames nello
stream video, ma deve per forza usare un metodo piu'
complicato.
Adesso devo sbrigare altre cose :-)
Ma piu' tardi colleghero' l'uscita SCART del lettore sa
all'ingresso della scheda di acquisizione, e riacquisiro'
la sua uscita; in questo modo otterro' un filmato 25 fps
avente la stessa durata di quello originale a 29.97.
In altre parole otterro' il risultato della conversione
operata dal lettore, naturalmente scalato e dopo essere
passato da digitale -> analogico -> digitale;
nonostante questi passaggi, spero di riuscire a capire
qualcosa sul metodo usato per la conversione.
Magari se qualche volontario volesse applicare un
metodo di conversione di quel filmato da 29.97 a 25
mediante AviSynth (seguendo le istruzioni che si trovano
nella pagina indicata ieri da Giubbe), sarebbe ottimo,
cosi' si potrebbero fare dei confronti tra i vari
metodi...

 diversi da 25 fps.
Ciao Frank, scusa se ti rispondo solo qui e solo ora,
ho provato il tuo filmato (simpatico il tipo...) e ti comunico
che sul Philips DVP 3010 va perfettamente. Voglio dire, nessuno
scatto (come invece avviene nella visione di filmati a 23,976)
ne' altra imperfezione percettibile. Perfetto. Nulla da
segnalare neanche a velocita' aumentata o ridotta, ne' frame
by frame. Per farla breve, pare a 25 fps...
Attendo eventuali ulteriori istruzioni e/o suggerimenti :)

 Attendo eventuali ulteriori istruzioni e/o suggerimenti :)
ce l'hai una scheda di acquisizione?
Mi descrivi meglio il comportamento del Philips 3010 su un
tipico film 23.976?
In particolare mi interessa sapere:
- l'audio e' riprodotto in modo fluido?
- in che modo scatta? Immagino non sia tanto facile descriverlo
  in modo dettagliato...
Se potessi avere un pezzettino di pochi secondi di un film a
23.976 scattoso _riacquisito_, sarei curioso di vederlo frame
per frame. Ma se non puoi, non importa...
Per tornare a quello 29.97, ieri ho poi riacquisito il filmato
in uscita dal mio lettore (che, a questo punto, presumo si
comporti come il tuo) ed e' venuta fuori una conferma a quanto
gia' sospettavo. Credo che sia abbastanza interessante :-)
Quando uso il termine "metodo rozzo di conversione framerate",
intendo quello usato di default da mencoder (opzione "-ofps"
senza altri filtri) e suppongo valga lo stesso per la opzione
"decimate" dei vari VirtualDub; una volta descrissi il
metodo con uno pseudo-algoritmo, ma in questo momento non
trovo il post su "google gruppi"...
Ad ogni modo, si tratta in questo caso di eliminare un frame
ogni tanto, in modo da far tornare i conti; per essere piu'
precisi, in una sequenza costituita da 29970 frames, non
facciamo altro che buttarne via 4970, in modo che ne
rimangano 25000; in pratica, ne butteremo via uno ogni 6,
anche se capitera' qualche volta di buttarne via uno dopo 7
(perche' 29.97 e' un pochino meno di 30).
Questo e' il metodo piu' semplice e immediato, ma da'
risultati mediocri/scarsi: se il filmato e' molto statico,
puo' anche darsi che si veda in modo sufficientemente
fluido, ma basta che qualcosa si muova nella scena per
percepire chiaramente una mancanza di naturalezza nel
movimento (dovuta ovviamente al fatto che abbiamo tolto
un frame ogni 6).
Adesso mi fa molta fatica mettere sul web una paginetta
per mostrare il filmato riacquisito dal lettore, quindi
dovrai fidarti della mia parola :-)
Il punto cruciale e' che i frames prodotti in uscita al
lettore (destinati al televisore) sono "semi-interlacciati",
cioe' alcuni appaiono progressivi, mentre molti presentano
le tipiche seghettature (o "denti di pettine") dei filmati
interlacciati, nonostante il filmato originale sia composto
solo da frame che appaiono progressivi...
(Puoi controllare il filmato di ingresso, scorrendolo
frame dopo frame, mediante Avidemux2 o Vdub, o quello che
preferisci).
Un'altra caratteristica notevole e' che il filmato
riacquisito, se riprodotto sul pc, appare difettoso;
naturalmente migliora un po' applicando un filtro di
deinterlacciamento, ma e' interessante notare che la
conversione operata dal lettore e' valida solo se il
filmato viene visualizzato dal televisore PAL...
Ieri avevo messo questo frame, estratto dal filmato
originale:
http://fsinapsi.altervista.org/tmp/frame251.png
Il filmato riacquisito ha la stessa lunghezza (1m56s), ma
dato che e' a 25 fps, il frame 251 dell'originale corrisponde
a un'altra posizione di quello acquisito, cioe' questa:
251*25/29.97 = 209.376042
Adesso guarda questi frames (208 e 209) di quello riacquisito:
http://fsinapsi.altervista.org/tmp/acqu_frame208.png
http://fsinapsi.altervista.org/tmp/acqu_frame209.png
Il primo appare progressivo, il secondo interlacciato...
Mi pare che scorrendone molti, la maggior parte appaiano
interlacciati, e penso che deve proprio essere cosi'.
In pratica, il lettore ha applicato uno schema regolare,
per costruire, dal filmato originale, una coppia di
semiquadri (ogni 40 ms), prendendo le linee un po' da un
frame, un po' da quello adiacente, in modo da sfruttare al
meglio il materiale disponibile; cioe', invece di buttare
via un frame completo (come nel metodo rozzo), qui ogni
frame partecipa (anche se parzialmente) alla costruzione
di qualche semiquadro. Questo metodo pero' puo' andare bene
solo se il risultato viene mandato a un televisore PAL...
(come gia' scrissi, e' una specie del "modo switch" del
filtro ConvertFPS di AviSynth)
Adesso resta il mistero del perche' il Philips visualizzi
in modo decente i 29.97 e non i 23.976, perche' in teoria
23.976, essendo piu' simile a 25, dovrebbe dare risultati
ancora migliori... e infatti, con il mio lettore i 23.976
si vedono ancora meglio dei 29.97, al punto che, se
guardo un 23.976 pensando che sia un 25, non riesco ad
accorgermi delle differenze.
E' probabile che ci sia un baco nel lettore (nel firmware?);
se potessi vedere i suoi frame riacquisiti, si potrebbe
cercare di capirci qualcosa. Magari prova a protestare con
il servizio di assistenza Philips :-)


e non era settato a "yes" l'header "X-no-archive"...
Tuttavia, se cerco tale ID sulla pagina
http://groups.google.it/advanced_search?hl=it
mi dice che non lo trova...
Sembra che "Google Gruppi" perda dei post.
Ad ogni modo, l'anno scorso pensavo che quell'algoritmo
descrivesse il comportamento del lettore. In seguito pero'
ho dovuto ricredermi, perche', con mia sorpresa, notavo che
il lettore visualizzava meglio da se' i framerate diversi da
25, rispetto agli stessi filmati ottenuti da una mia
conversione preventiva (sul pc) a 25.
Infatti, buona parte del mio interesse per la questione nasce
dalla domanda (che avevo posto su questo Ng il 3 agosto 2005):
------------------------------------------------------------
ma quello che piu' mi interessa sapere e' se conviene
preventivamente convertire il filmato a 25 fps in fase di
codifica (usando un qualche algoritmo, che magari e'
migliore della tecnica usata dal lettore) oppure conviene
lasciarlo com'e'?
------------------------------------------------------------
Dopo piu' di un anno, la risposta che ho trovato e':
conviene lasciarlo cosi' com'e' (a meno che il lettore non
abbia bachi).
La cosa buffa e' che la conversione effettuata dal lettore e'
davvero descrivibile da un algoritmo molto simile a quello
sopra, ma con alcune differenze. Innanzitutto l'algoritmo non
opera a livello di interi frame, ma a livello di singole linee
(quindi, nell'algoritmo, il termine "frame" va sostituito con
"linea"); in secondo luogo, il timestamp (la variabile che
indica il trascorrere del tempo) di visualizzazione va riferito
al fascio elettronico del cinescopio, quindi:
ts=0 corrisponde alla prima linea del primo semiquadro;
ts=1 corrisponde alla seconda linea del primo semiquadro (cioe',
     la terza del primo frame corrispondente);
e cosi' via. Quindi va cambiato anche il "passo" con cui si
incrementano i due timestamp.
Tenendo conto di queste differenze, l'algoritmo sopra e' una
buona descrizione del processo di costruzione del filmato PAL
che esce dal lettore.
In particolare, se fr1 > 25, come nel caso fr1=29.97, alcune
linee (circa il 16% del totale) di ciascun frame saranno
scartate; mentre, se fr1 < 25, come nel caso fr1=23.976,
non solo tutte le linee di ciascun frame saranno utilizzate,
ma circa il 4% di esse saranno utilizzate anche nel
semiquadro successivo (quali saranno dipende dalla posizione
che si rende via via necessaria).
Ai fini della visualizzazione su un tv PAL, a me pare che
questo metodo sia quello che sfrutta nel miglior modo possibile
l'informazione disponibile.
Per capire perche' funziona, e' utile ragionare un po' su una
specie di indovinello:
Se acquisiamo su PC una trasmissione televisiva (diciamo un
telegiornale), visualizzando il filmato vediamo le famigerate
seghettature da interlacciamento. Sappiamo che cio' e' dovuto
perche' i frame acquisiti non sono "fotografie" scattate in
un certo istante (come accade con un film girato a 24
fotogrammi al secondo), ma l'intercalamento di due
"semiquadri" che riferiscono a due istanti temporali diversi;
(in modo analogo, ogni semiquadro non e' proprio una "mezza
fotografia", perche' il tempo di riferimento varia un po',
dall'alto verso il basso...).
Per visualizzare su tv un film (girato a 24 fotogrammi al
secondo), la procedura adottata e' la seguente:
- si velocizza un po', facendo finta che sia stato girato
  a 25 fps (l'audio risultera' un po' piu' acuto, e le
  immagini leggermente piu' veloci, e il film finira'
  qualche minuto prima rispetto alla proiezione al cinema);
- i due semiquadri PAL vengono creati da un frame.
Questa procedura e' adottata sia per i film trasmessi dalle
emittenti, sia per la visualizzazione dei film in DVD.
Ora, pero', qui c'e' un problema: in un segnale PAL canonico,
i due semiquadri sono riferiti a istanti temporali diversi
(la distanza e' 20 ms), mentre, nel caso di un film, i due
semiquadri sono ottenuti dallo stesso frame (che e' una
fotografia statica) e quindi si riferiscono allo stesso
istante temporale...
Per ragioni analoghe e simmetriche a quanto avviene con i
filmati interlacciati visti in modo progressivo sul PC, non
dovremmo notare qualche tipo di artefatto quando guardiamo
un film (magari un DVD) alla TV?
E invece, in questo caso, li vediamo bene.
Perche'? :-)