Newsgroup: it.media.video.produzione
Titolo: Correzione ordine di campo

Ciao, acquisendo da Videocamera miniDv, da TV e da VCR alla fine ho
fatto casino. Ho acquisito una VHS, compresso in MPEG2 e fatto il DVD.
Di solito controllo sempre sia la correttezza dell'ordine di campo (B x
MiniDV, A x TV e VCR) sia il DVD finale ma stavolta ho fatto la cazzata
di restituire la VHS e cancellare l'AVI (per costante mancanza di
spazio) prima di verificare la buona riuscita delle operazioni.
Anche se da un DVD a CBR 8000Kbps posso sempre ricavare un buon DiVX
progressivo o deinterlacciato, sto facendo degli esperimenti per
cercare di recuperare qualcosa dall'MPEG2.
Ho provato due strade diverse:
-apertura dell'MPEG2 con VirtualDubMPEG2, applicazione di un filtro
"field SWAP", start del Frameserver e ricompressione MPEG2 con TMPGEnc;
-apertura dell'MPEG2 con TMPEGEnc, inversione dell'ordine di campo in
"Setting" e ricompressione MPEG2.
In entrambi i casi il problema dell'inversione viene risolto ma il
risultato e' assai peggiore del MPEG2 originale, tale da non essere
giustificabile dalla seconda ricompressione subita, sempre a CBR
8000Kbps. Vedo degli artefatti strani, in corrispondenza dei contorni
dei soggetti, che non so spiegarmi.
Sapete indicarmi una spiegazione del fenomeno?
Avete qualche suggerimento in merito?
Esiste il modo di evitare la seconda compressione su TMPGEnc (si puo'
indicare a TMPGEnc di fare una ricompressione fittizia)?
Ciao e grazie.

 (si puo' indicare a TMPGEnc di fare una ricompressione fittizia)?
LOL!
--
http://snipurl.com/dgkl

 (il secondo field del frame precedente).
In effetti, adesso che me lo fai notare, mi chiedo come non ci abbia
pensato prima. Mi torna che il risultato dell'algoritmo di ricerca dei
macroblocchi sull'I-frame successiva, durante la costruzione dei P- e
B-frame, venga compromesso dall'inversione dell'ordine di campo.
Pero' questo accade all'atto della seconda compressione pertanto, come
dicevi tu, un SW che semplicemente scambi le informazioni di campo nel
primo MPEG2 senza effettuare ricompressioni potrebbe funzionare (in tal
senso speravo di poterlo far fare a TMPGEnc mediante qualche
impostazione)
Grazie della spiegazione,
Ciao.

 primo MPEG2 senza effettuare ricompressioni potrebbe funzionare
Si, ma ti tieni la pessima compressione fatta all'inizio, pur essendo un
CBR8000.
Hai misurato il "Q"?
Prova.
--
http://snipurl.com/dgkl

 B-frame, venga compromesso dall'inversione dell'ordine di campo.
L'interlacciamento nell'MPEG-2 NON viene codificato tramite il motion
compensation, ma agendo sulla DCT in uno dei due seguenti modi:
1) ogni campo del frame viene codificato a se', un po' come succede
   nell'MJPEG che memorizza due immagini JPEG per frame;
2) ogni macroblocco 16x16 puo' essere codificato come progressivo oppure
   viene suddiviso in due macroblocchi 16x8, uno con il campo A e
   l'altro con il campo B. Sta all'encoder decidere se il macroblocco
   va memorizzato come progressivo o interlacciato (questo secondo
   metodo e' quello che piu' o meno accade anche per il DV).
In questo processo, quindi, l'ordine del campo non ha alcuna influenza
sull'efficacia dell'encoder: se infatti provi a codificare lo stesso
sorgente prima in top-field-first e poi in bottom-field-first otterrai
due identici stream ad eccezione di un bit per ogni frame che indica
appunto l'ordine del campo.
Diverso e' il discorso se codifichi come progressivo un materiale
interlacciato: li' si' che cambia l'efficacia dell'encoder, pero' non e'
questo il caso.
Mi e' capitato una volta di cambiare l'ordine di campo ed ho usato
bbvinfo dei bbtools (con una piccola patch per indicare la posizione
dove sta il byte che contiene il bit di ordine di campo) e uno scriptino
perl che cambia il bit in base all'output di bbvinfo.
Per Windows c'e' ReStream:
 
http://shh.sysh.de/restream.html
Ciao,
  Luca

 Sara' altissimo.
Ciao Salvo, a distanza di tempo abissale sono riuscito a riacquisire e
ricomprimere con gli stessi parametri, ma con ordine di campo corretto,
il medesimo filmato.
Ebbene, analizzando il "Q" dei due filmati trovo che l'MPEG2 con ordine
invertito ha Q medio di 5.81 mentre quello corretto di 5.43.
Valore quasi identico, nei due casi, per il Q di picco (> 8).
Mi sembra un valore alto in assoluto e mi chiedevo se cio' potesse
dipendere dalla scadente qualita' del sorgente (filmato Hi8 NTSC
portato in VHS PAL e acquisito via VCR).
Al di la di questo, per quanto mi avevi accennato, mi sarei atteso una
differenza maggiore tra i due Q rilevati. Potrebbe essere attribuibile
al filmato questa scarsa differenza?
Ciao e grazie.