Newsgroup: it.comp.software.divx
Titolo: inatteso problema di interlacciamento

saluti,
utilizzo un encoder HW MPEG2/DivX (precisamente il ConvertX della Plextor)
con usb2 per fare acquisizione video da TV e SAT, utilizzando una uscita
videocomposita (quindi analogica PAL). L'impiego e' equivalente a quello
di un VCR, prevalentemente per registrare film e cartoni.
Con mia grossa sorpresa ho scoperto che il file AVI od MPEG del film
acquisito puo' presentare i tipici effetti dei filtri di interlacciamento,
che in pratica sono una sorta di effetto "fantasma" sugli elementi in
movimento, causati dai filtri di deinterlacciamento utilizzati
dall'encoder nel mettere insieme i due semiquadri.
In teoria questo non si dovrebbe presentare, visto che film e cartoni
nascono come progressivi (24 trame al secondo, portati a 25 in TV) e non
interlacciati (50 semiquadri al secondo). Se questo succede e' perche'
nella conversione per la TV da qualche parte si crea un errore di fase,
per cui nella stessa trama vanno a finire due semiquadri che in realta'
dovrebbero andare in due trame diverse, e che percio' fanno riferimento ad
istanti temporali che si differenziano di 1/25 di secondo. Di qui
interviene il filtro di deinterlacciamento con il conseguente degrado di
qualita'. 
Per risolvere il problema dovrebbe esserci la possibilita' di ricuperare
questo sfasamento prima di effettuare la codifica DivX o MPEG2, rimettendo
a posto i semiquadri nella trama.
Quello che mi piacerebbe sapere e': cosa potrei utilizzare, sia come HW
che come SW di acquisizione, per poter risolvere questo problema
ricuperando l'errore di interlacciamento e quindi codificando in
progressivo?
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 a posto i semiquadri nella trama.
Per la codifica in mpeg2 non dovrebbero esserci problemi, basta farla
interlacciata. Il DivX invece va deinterlaciato. Lo puoi fare con avisynth
Esistono comunque altri software di codifica, come autoGK, che rendono la
procedura automatica.
Bye, Giubbe
-- 
HomePage e FAQ: 
http://giubbe.altervista.org
Inutile scrivere in privato, non ricevo le email


Appunto, dscaler.
Ho letto in giro che funziona meglio di prodotti hardware del costo di
migliaia di dollari. Ok... ci credo poco, ma almeno dscaler non costa nulla!
Inoltre, I prodotti hardware non sono altro che sistemi digitali a
microprocessore che di fatto fannno girare in firmware programmini del tutto
simili a dscaler.
Ciao,
Luca.

 No, non c'č perchč non c'č lo sfasamento. Sarebbe troppo facile altrimenti!
si', a meno che, pero', il suo non sia il caso che ho detto sopra...
in tal caso ha ragione lui: gli basta fare in modo che i semiquadri
vengano riaccoppiati in modo giusto

 Luca.


 pagina di manuale deli mjpegtools, che accenna a questi problemi:
utilissimo, grazie



Non c'è lo sfasamento! :-)
Ciao ragazzi.

 wrote in message
news:ct5jkn$rth$1...@news.newsland.it...


 pagina di manuale deli mjpegtools, che accenna a questi problemi:
utilissimo, grazie


 del PC si vedranno gli artefatti, mentre sul TV si vedrà perfettamente.
purtroppo la cosa non e' cosi' semplice...
un frame progressivo non puo' essere trattato allo stesso modo di un
frame interlacciato;
(con "frame progressivo" intendo un frame in cui righe pari e dispari
sono riferite allo stesso istante temporale)
se il frame fa parte di una scena poco movimentata, non c'e' molta
differenza; altrimenti, nel caso di frame interlacciato, occorre che il
codec preveda un modo speciale di trattare i frames... ad esempio:
la codifica dei I-frames (intra-frames) e' piu' o meno una codifica
simile a una compressione jpeg: nel caso di frame interlacciato, se
tu tratti l'immagine in modo normale, non riesci a comprimerla bene
(le "seghettature" aumentano notevolmente il numero di dettagli),
quindi il codec finisce per produrre I-frames di bassa qualita'...
il risultato finale e' un pastrocchio...
mpeg2 prevede appunto un modo specifico di codificare frame
interlacciati, che tiene conto del fatto che il frame va considerato
come l'intercalazione di due semiquadri...
una cosa analoga viene fatta da "libavcodec", che ha queste opzioni:
   ildct
       Use interlaced DCT.
   ilme
       Use interlaced motion estimation (mutually exclusive with qpel).
credo che anche XviD abbia opzioni analoghe...
e forse anche DivX commerciale...
comunque, quello che volevo dire, e' che se parto da un filmato
"nativamente interlacciato" (diciamo l'acquisizione di un telegiornale)
e voglio farne un DivX (quindi non un mpeg2), e non uso tali opzioni
specifiche (ildct e ilme), e non uso un filtro di deinterlacciamento
e non riscalo il filmato, allora mi esce fuori un pastrocchio...
(per il motivo che ho detto)
ciao

 come l'intercalazione di due semiquadri...
Il mio sospetto e' gli encoder HW (ConvertX od Hauppauge) in realta' fanno
SEMPRE il deinterlacciamendo da due semiquadri e poi codificano in MPEG2 o
DivX. Non sfruttano in pratica la possibilita' di conservare
l'interlacciamento nella codifica (opportunita' offerta anche dall'ultima
versione commerciale del DivX).


 versione commerciale del DivX).
boh... un mio amico ha una scheda "Pinnacle MP20" che codifica in MPEG2
(e anche MPEG1); se acquisisce alla massima risoluzione, i risultati sono
mpeg2 interlacciati e sono buoni (nel senso che sul televisore si vedono
bene); gli encoder HW che dici te non li conosco... non sapevo neanche che
le schede facessero un deinterlacciamento (mi chiedo quale algoritmo
abbiano usato: ce ne sono molti :-))


Ciao e grazie, e scusami per averti frainteso, quando parlavi di
trasmissioni in progressivo.


Ah... ecco perchè avevo trattato il DivX alla stregua dell'mpeg2 per quel
che riguarda l'interlacciamento. In effetti ho esperienza solo con l'ultima
versione di questo codec.
Ciao!

 trasmissioni in progressivo.
di niente, sono consapevole che spesso non mi esprimo benissimo (perche'
scrivo di getto senza rileggere)


A voler dirla tutta, mi ero permesso di chiarire meglio le cose a beneficio
di eventuali lettori che intendano farsi un idea leggendo le nostre righe.
Penso che sia questo il valore aggiunto dei newsgroup, rispetto allo scambio
di email in privato :-)
Ciao Frank!

 mah... qui appunto non ti capisco :-(
spero che l'esempio aiuti a capire cosa intendevo
ciao

 di email in privato :-)
Esatto, studiero' le risposte nel weekend... :-)
Stefano



Ok, ma mi sa che anche nel televisore ho lo stesso problema. Ho fatto 1 ora
e mezzo di ricerche per trovare un documento veramente utile per capire come
funziona il PAL, che metterò in cassaforte e te ne passo il link:
http://www.dsp.dist.unige.it/~aldo/ETIdisp/Cap1.pdf
nel paragrafo 1.4.2 si parla dei sincronismi verticali. Come vedi sono
identici per entrambi i semiquadri. Ma deve esserci un modo per dire al
cinescopio di tacciare i semiquadri "top" alle righe 1, 3, 5, 7... ed i
"bottom" alle righe 0, 2, 4, 6... e non viceversa, se no succede che sul TV,
1 volta su 2 vedo quello che hai appena dimostrato! Ebbene, leggendo questo
paragrafo finalmente mi pare di aver capito (forse come ti dicevo prima tu
c'eri già arrivato, o per lo meno eri sulla buona strada). Il "trucco" sta
nel fatto che la trasmissione del secondo semiquadro (o "field", se
vogliamo), iniza con un ritardo di mezza riga (osserva la figura 1.11)!
Infatti se metti in relazione questo con la figura 1.5 del paragrafo 1.3, e
consideri che le righe vengono tracciate INCLINATE dal cinescopio, il
ritardo temporale di mezza riga si traduce in una traslazione spaziale di
mezza riga!
Che sistema diabolico... trasmetto identici impulsi di sincronismo per
ciascun semiquadro, ma dopo aver aspettato il retracing verticale che segue
il primo semiquadro, trasmetto il secondo semiquadro dopo un ulteriore
ritardo di mezza riga, et voila!
Quindi, per ritornare al discorso che facevi, mi sa che ho cominciato io a
dire cazzate, e te mi sei ignaramente venuto dietro :-)
Cioè: anche il PAL distingue l'ordine dei due semiquadri, proprio per
evitare l'effettaccio che hai mostrato tu con quelle due immagini che
parlano da sole. Quindi nel comporre il segnale PAL, bisogna mettere i
semiquadri pari e dispari nel loro giusto ordine, che deve essere noto.
Insomma il problema di mantenere l'ordine dei semiquadri "top" e "bottom",
altrimenti si perde quella che tu chiami "coerenza" e che mi hai appena
dimostrato, resta tale e quale anche se intendiamo visualizzare il filmato
su un TV! Sei d'accordo?
Luca.

 Esatto, studiero' le risposte nel weekend... :-)
Okkio perņ, Stefano, cerca di discernere le cose sensate dalla marea di
cavolate che ho scritto!
Eh si, perchč magari ce la metterņ tutta, credendo di aver detto cose
giuste, ma poi scopro che erano cavolate :-)
Vedi il mio scambio con Frank, per capirci... :-) :-)
Ciao!
Luca.

 su un TV! Sei d'accordo?
direi di si'.
pero', nonostante un errore nei ragionamenti, e' stata una discussione
utile :-)
purtroppo, temo che non sara' molto utile a chi ha iniziato il thread,
in quanto mi e' parso di capire che il suo problema viene causato dalla
scheda, che effettua gia' la compressione DivX, e che non gli consente
di impostare opzioni tipo quelle che abbiamo descritto...
ciao


Ciao!

 filtri di deinterlacing!!! :-) :-) :-)
ecco, se ne hai voglia, possiamo parlarne (senza fretta), sperando che
anche altri intervengano.
tempo fa analizzai il modo di funzionare di un algoritmo di
deinterlacciamento (guardandone il codice sorgente); avevo capito cosa
faceva, poi decisi di scriverne uno anch'io... mi sembrava di avere
avuto una buona idea, ma poi vidi che faceva pena...

 prima e la seconda linea... se fai un disegno, lo vedi facilmente.
questo ragionamento e' illustrato da questa figura:
http://fsinapsi.altervista.org/extra/fields.png
la diagonale del rettangolo e' una linea del primo campo
(l'inclinazione e' esagerata, ma aiuta a capire meglio)
la linea parte dal punto p1, e dopo il ritracciamento, la linea
successiva parte dal punto p2...
per quanto riguarda il secondo campo, nelle ipotesi che avevo fatte,
la sua posizione verticale al momento di partenza doveva essere la
stessa posizione verticale della linea corisspondente del campo
precedente, cioe' la posizione che aveva a meta' strada (punto p3);
facendo la proiezione (linea tratteggiata) del punto p3, otteniamo
il punto p4, che (nelle ipotesi che avevo fatte) era quindi il punto
di partenza della linea, ed e' esattamente il punto di mezzo tra p1
e p2;
ora, come ho detto, nei dettagli le cose stanno in maniera diversa,
ma i principi sono quelli.