Recensubs HQ

La vera guida a come cavolo si encoda per davvero - Episodio 7: IVTC/DeInt/VFR/Cazzi&Mazzi (1)

« Older   Newer »
  Share  
view post Posted on 18/3/2015, 18:13     +1   +1   -1
Avatar

Bimbosp

Group:
Administrator
Posts:
9,780
Reputation:
+929
Location:
Gallarate (VA)

Status:


Sono passati circa due mesi dall'ultima volta che ci siamo visti, direi che è il momento di partire con una delle sezioni più importanti della guida: quella che tratta tutto il discorso della gestione del framerate, quindi come ripristinare un flusso progressivo fluido e corretto.

Vi avviso già da subito, però, che non so bene come approcciare questo argomento. Mi spiego meglio: ci sono sicuramente delle nozioni di cui certamente devo parlarvi, e che quindi andrò a spiegarvi, ma allo stesso tempo ci sono tantissime situazioni particolari, che mi sono capitate negli anni magari su singole sorgenti, che potrei anche dimenticare di menzionare o che comunque non sono certo valgano il tempo per cui dovrei dilungarmi. Per cui la mia intenzione attualmente è di coprire quantomeno le cose che più comunemente vi troverete di fronte (questo nel giro di due o tre episodi), magari aggiungendoci anche qualche nozione per consentirvi di districarvi da soli con altro, poi andare avanti con gli altri argomenti, e se eventualmente qualcuno avesse domande su particolari problemi, potrei riprendere l'argomento più avanti parlando di vari casi particolari.

Premesso questo, cominciamo.



Capitolo 1: L'approccio duro e puro all'IVTC - Il field match

Arrivati a questo episodio della guida, dovreste già sapere cosa sia il pulldown e cosa si intenda con IVTC, altrimenti vi invito a ripassarvi l'episodio 2 prima di proseguire con la lettura.
Come avevo preventivato, per quanto l'intenzione finale di questa guida è sfruttare prevalentemente YATTA, è bene avere una chiara idea di come si va a operare sul video, per cui paradossalmente, credo che sia più corretto farvi partire facendovi fare nel modo più inutilmente complesso che possa esistere, perché questo modo richiede che abbiate una completa comprensione dell'IVTC e vi obbliga a comprendere e distinguere i pattern per poter funzionare, quindi è sicuramente il metodo migliore da un punto di vista educativo.

Come prima cosa vi offro un piccolo file che utilizzeremo come esempio per questo primo capitolo.

http://task-force.lacumpa.biz/sample1.ts

Scompattate lo zip, indexate il ts, aprite avspmod e caricate il video, così ci mettiamo all'opera.

Si tratta di una semplice pubblicità giapponese, ma essendo un video live action è molto semplice distinguere i pattern, per cui per ora è meglio.

Anzitutto porto alla vostra attenzione il primo fatto: i primi due frame (0 e 1) sono duplicate del terzo frame (2). Questo ve lo faccio notare perché in realtà anche con gli anime che vanno in onda in TV può capitare che i primi e gli ultimi frame a ridosso delle pubblicità abbiano problemi del genere: può infatti capitare che abbiano duplicato qualcosa oppure al contrario che abbiano tagliato qualche frame. Nel primo caso potete risolvere semplicemente trimmando via i frame duplicati, nel secondo invece il problema è quando ci si trova con un field da solo spaiato del proprio match, e potete risolvere o tagliando via quel field e cominciando da dopo, oppure se proprio insistete potete tenerlo e fare postprocess per interpolare l'altro field ─ personalmente consiglio di risolvere di trim senza farsi troppi problemi, ma potete agire come preferite.

Superata questa parentesi, proseguiamo a osservare cosa abbiamo per le mani.

In questo caso specifico, come vi dicevo, si procede di trim senza problemi, per cui come prima cosa sappiamo che dobbiamo tenere il video a partire dal frame 2.
Per il punto finale, però, per il momento ci fermiamo prima: questo esempio è utile perché ha anche altre cose in serbo per noi, ma è ancora presto per metterci le mani nei capelli, per cui per ora glissiamo tranquillamente fermandoci al frame 216.
CODICE
trim(2,216)


E ora comincia la parte che ci riguarda. In questo capitolo ci occuperemo esclusivamente del field match, per cui quello che faremo ora è soltanto ripristinare un flusso progressivo appaiando i field.

Anzitutto diamo uno sguardo a quello che abbiamo adesso, dopo aver trimmato. I frame 0 e 1 sono interlacciati, i frame 3, 4 e 5 sono progressivi, i frame 5 e 6 sono interlacciati, i frame 7, 8 e 9 sono progressivi... e così via. Notate il pattern? Già.
Se questo pattern rimanesse identico fino alla fine, avremmo un singolo pattern, e quindi parleremmo di pattern costante. Ma vi invito a proseguire, andate al frame 30.
Qui, come finora, abbiamo un frame interlacciato, e anche proseguendo al frame 31 abbiano un frame interlacciato, per poi ritrovarci con un frame progressivo. Il pattern su cinque frame con i primi due interlacciati e i seguenti tre progressivi pare finora valido. Andando però sul frame 33 notiamo che c'è un cambio scena e il frame, che seguendo il pattern precedente sarebbe dovuto essere progressivo, è invece interlacciato.
C'è quindi stato un cambio di pattern, quindi l'esempio che abbiamo per mano ha un pattern variabile.
Proseguendo notiamo che i frame 34, 35 e 36 sono progressivi, mentre il 37 è di nuovo interlacciato. Anche il 38 è poi interlacciato, 39, 40 e 41 sono progressivi e il 42 è interlacciato. Questo pattern prosegue fino al frame 56, mentre al frame 57, col nuovo cambio scena, cambia nuovamente il pattern.
Se osserviamo, i frame 57, 58 e 59 sono progressivi, mentre 60 e 61 sono interlacciati. A questo punto vi sarete abituati e starete già cercando il prossimo cambio scena e...
...lo trovate al frame 77. I frame 77, 78 e 79 sono progressivi, mentre 80 e 81 sono interlacciati. Nonostante il cambio scena, il pattern è rimasto costante.
Con questo dovreste aver quindi capito che non necessariamente a ogni cambio scena corrisponde un cambio pattern. Ma soprattutto, è importante che impariate il contrario.
In questo caso abbiamo per le mani un video live action, per cui non c'è questo problema, ma con gli anime è tutta un'altra storia: può capitare che nel bel mezzo di una scena il pattern cambi all'improvviso. Questo succede in particolar modo nel caso in cui abbiano dovuto aggiustare il lip sync di un doppiaggio in fase di editing 60i, senza badare troppa attenzione al pattern.
Ora che sapete a cosa dovete stare attenti, vi lascio una breve pausa per analizzare il resto del video.

Ok, ora che sapete cosa avete per mano, è tempo di agire. Per evitare di confondersi e di combinare casini, è bene organizzarsi a dovere e seguire un metodo preciso.
Anzitutto, per poter rimettere assieme le coppie di field come si deve, è necessario separare i field top da quelli bottom. Per farlo vi basta usare:
CODICE
separatefields()

e vi ritroverete con un video 1440x540 a 59,94 fps.
Piccola parentesi: a questo punto è bene assicurarsi che il field order sia corretto. Andate al frame 0 e clickate play. Se il video è fluido è corretto, se il movimento scatta perché fa "avanti e indietro" nel tempo col movimento, significa che il field order è invertito. In questo caso il field order è TFF, e se stato usando MPEG2Source dovrebbe essere stato impostato correttamente, ma in base al filtro che usate per caricare il video, può capitare che il flag di TFF/BFF non sia corretto. A questo riguardo vi linko la pagina della wiki di avisynth con tutti i comandi inerenti ai field. In particolar modo, se il field order è errato, potete fare assumetff() o assumebff() prima del separatefields() in base alla necessità.

Ora che abbiamo i field ognuno per conto proprio, dobbiamo preparare i pattern. Per farlo ci avvarremo di selectevery().
Per la precisione, prepareremo 5 clip, ognuna che parte dal frame 0 e prosegue girandosi le varie possibilità di match.
Vi ricordo che di base vi conviene utilizzare i match current e next, e usare i match previous soltanto in caso di necessità in prossimità dei cambi scena.
La prima possibilità che andiamo ad analizzare, che ci interessa da subito, è che ci serva fare un match nnccc, che è in effetti il primo pattern che abbiamo all'inizio del video.
Visto che abbiamo in video TFF, fare match N significa tenere fisso il field bottom e appaiarlo col top del frame successivo. Viceversa se facessimo match P terremmo fermo il field top e faremmo il match col field bottom del frame precedente.
Siccome il video inizia con un frame interlacciato, ci manca un field, quindi ci è in qualsiasi caso impossibile fare un match p, e quindi dovremmo interpolare l'altro field (però a quel punto ci ritroveremmo con 5 frame unici, e dovremmo o fare una sezione a 29,97 oppure saremmo costretti a decimarlo ugualmente), ma facendo match n saltiamo il problema scartando il field privo di match.
Per usare selectevery, dobbiamo anzitutto dire ogni quanti frame si ripete il pattern, per poi dirgli quali frame prendere, nell'ordine in cui vogliamo che li prenda.
Abbiamo visto che il pattern si ripete ogni 5 frame originariamente, ovvero ogni 10 field, che ora occupano un frame ciascuno, per cui il pattern che andremo a definire è spalmato su 10 frame per selectevery. Il conto parte da 0, per cui usando numeri negativi utilizzerete frame precedenti a quelli del set, mentre usando un numero pari o superiore al numero che date di selectevery andrete a prendere frame successivi (del resto, se definite 10 frame come range e contate a partire da 0, il decimo frame è il numero 9).
Il prossimo passo è dirgli cosa andare a prendere. Quindi, ricapitolando, il frame 0 è il field top del frame 0 originario, il frame 1 è il field bottom del frame 0 originario, il frame 2 è il field top del frame 1 originario e il frame 3 è il field bottom del frame 1 originario.
Per fare un match n dobbiamo appaiare il field bottom del frame 0 originario col field top del frame 1 originario, ed essendo un video top field first dobbiamo inserire prima il field top e poi il field bottom. Ciò significa che per prima cosa dobbiamo andare a prendere il frame 2, e successivamente il frame 1.
Il frame 0 è pronto, ma dobbiamo preparare anche i frame 1, 2, 3 e 4 del pattern originario.
Per il frame 1 originario, che pure era interlacciato, serve nuovamente fare un match n.
Il frame 1 originario corrisponde ai frame 2 (top) e 3 (bottom) attuali, mentre il frame 2 originario ha dalla sua i frame 4 (top) e 5 (bottom) attuali. Come avrete già capito, dobbiamo appaiare il bottom dell'1 originale (il 3 attuale) al top del 2 originale (il 4 attuale), mettendo prima il top e poi il bottom.
Fatti questi due frame, che erano i due match n, restano i match c, che quindi rimangono in ordine.
Il frame 2 originario è formato da 4 e 5, e dovendo mettere prima il top teniamo quindi 4 e 5. Stesso discorso per frame 3 e 4, di cui quindi terremo 6 e 7 e poi 8 e 9.
Tutto questo, in codice, si traduce in:
CODICE
selectevery(10,  2,1, 4,3, 4,5, 6,7, 8,9)

Gli spazi, come già spiegato, sono assolutamente superflui a livello di codice di avisynth, ma sono utili per avere una separazione grafica che rende più comprensibile cosa stiamo mettendo assieme a cosa quando andiamo a leggere il codice.
Ora abbiamo i field nell'ordine corretto, ma dobbiato tornare ad avere il video progressivo appaiandoli. Per farlo possiamo avvalerci del comando weave().
Inoltre, come già detto, questo è solo uno dei cinque possibili pattern nel caso di pulldown 3:2, e noi dobbiamo anche pensare agli altri 4, per cui per il momento ci limiteremo a salvare il pattern come un clip da riutilizzare poi.
Siccome a partire dal frame 0 stiamo facendo un match nnccc, lo chiameremo adeguatamente:
CODICE
nnccc = selectevery(10,  2,1, 4,3, 4,5, 6,7, 8,9).weave()

E un pattern è sistemato.

Ora bisogna preparare gli altri pattern. Cercate di farlo da soli, come esercizio per vedere se avete capito come si fa.
Partite dal cnncc, poi fate ccnnc, cccnn e infine ncccn.
Quando avete finito, controllate il codice sotto spoiler per verificare se li avete indovinati.

CODICE
nnccc = selectevery(10,  2,1, 4,3, 4,5, 6,7, 8,9).weave()
cnncc = selectevery(10,  0,1, 4,3, 6,5, 6,7, 8,9).weave()
ccnnc = selectevery(10,  0,1, 2,3, 6,5, 8,7, 8,9).weave()
cccnn = selectevery(10,  0,1, 2,3, 4,5, 8,7, 10,9).weave()
ncccn = selectevery(10,  2,1, 2,3, 4,5, 6,7, 10,9).weave()


Ci siete riusciti? Bene! Non ci siete riusciti? Rileggete il paragrafo e, se ancora non vi è chiaro, chiedete qui sotto cosa non avete capito e cercherò di essere più chiaro, per quanto mi è possibile.

Ora quindi si passa alla parte realmente manuale del tutto. Buttate un return weave() in fondo al codice e sotto di quello cominceremo a selezionare i vari pattern per i pezzi di video che ci interessano: in questo modo avspmod continuerà a farci vedere il video interlacciato originale mentre lavoriamo e poi ci basterà cancellare questa riga per ritrovarci con il video progressivo a lavoro finito.

Dunque, dal frame 0 al frame 32 abbiamo due frame interlacciati e tre progressivi, per cui abbiamo bisogno di fare un match nnccc. Fin qui è semplice, perché ci basta prendere il clip nnccc e tenere i frame dallo 0 al 32, per poi aggiungerci il resto.
Dal frame 33 parte il nuovo pattern, ma attenzione: i pattern che abbiamo specificato all'inizio partono tutti dal frame 0 e durano cinque frame, per cui dobbiamo ragionare in multipli di cinque. Per semplificare, quindi, controlliamo il pattern a partire dal prossimo multiplo di cinque, ovvero il frame 35: progressivo, progressivo, interlacciato, interlacciato, progressivo. Perciò, a partire dal frame 33 e fino al frame 56, avremo bisogno di fare match ccnnc.
Per ora, la riga finale è così:
CODICE
nnccc.trim(0,32)+ccnnc.trim(33,56)

Ora, come sappiamo abbiamo un pattern che parte dal frame 57 e nonostante il cambio scena rimane uguale fino al frame 96. Usando sempre il ragionamento di prima, ci torna comodo andare al frame 60 e controllare da lì cos'abbiamo. Essì, pare che sia ritornato il pattern nnccc, per cui diventa:
CODICE
nnccc.trim(0,32)+ccnnc.trim(33,56)+nnccc.trim(57,96)


Ora arrivate fino alla fine da soli, togliete il return weave, e poi controllate se il vostro codice assomiglia a quello sotto spoiler.
CODICE
MPEG2Source("sample1.d2v")
trim(2,216)
separatefields()
nnccc = selectevery(10,  2,1, 4,3, 4,5, 6,7, 8,9).weave()
cnncc = selectevery(10,  0,1, 4,3, 6,5, 6,7, 8,9).weave()
ccnnc = selectevery(10,  0,1, 2,3, 6,5, 8,7, 8,9).weave()
cccnn = selectevery(10,  0,1, 2,3, 4,5, 8,7, 10,9).weave()
ncccn = selectevery(10,  2,1, 2,3, 4,5, 6,7, 10,9).weave()
nnccc.trim(0,32)+ccnnc.trim(33,56)+nnccc.trim(57,96)+cccnn.trim(97,109)+cnncc.trim(110,136)+ccnnc.trim(137,163)+cccnn.trim(164,180)+ccnnc.trim(181,214)


Se non coincide, riguardatevi questo pezzo e se ancora non avete capito chiedete.

Abbiamo finito qui? Men che meno!
Ora ricontrolliamo il risultato.

Avrete già notato che in alcuni cambi scena sono rimasti dei frame interlacciati. Questo è dovuto al fatto che, quando hanno effettuato l'editing, hanno tagliato in punti che hanno lasciato spaiati dei field in frame interlacciati prossimi al cambio scena, che si sono quindi ritrovati orfani di match.
Per la precisione i frame con questo problema attualmente sono i frame 76, 96, 109, 136 e 163. In particolare per il frame 76 la cosa vi fa notare che, anche se il pattern non cambia, è possibile che ci siano comunque problemi al cambio scena in base a come è stato effettuato l'editing, per cui è sempre bene effettuare controlli.

Come già avevo avvisato, se ci troviamo in prossimità di cambi scena, possiamo risolvere facendo un match p anziché n oppure possiamo interpolare.
Per il momento limitiamoci a fare dei match p.
Per farlo, ci prepariamo un altro clip da aggiungere alla sfilza di clip che avevamo sopra. Questo clip lo chiamiamo p e sarà un clip in cui ogni frame è un match p. Successivamente, andremo a utilizzare strange per selezionare i singoli frame che vogliamo sostituire con dei match p.

Come esercizio, vi lascio sotto spoiler il codice per i p match. Se avete capito quanto spiegato finora e avete letto tutto attentamente, avete tutte le informazioni per scriverlo da soli, per cui fate una prova e poi controllate.

CODICE
p = selectevery(2,  0,-1).weave()


Se avete fatto correttamente anche questo, direi che avete compreso alla perfezione l'uso di selectevery e il funzionamento di field match e parity, se invece qualcosa non torna, rileggete bene tutto finché non comprendete perché il codice è questo.

Ok, quello che rimane è solo selezionare i frame da sostituire e, prendendo a esempio il frame 76, il codice è:
CODICE
strange(76,76,p)


Gli altri ve li lascio a voi come esercizio.

Sotto spoiler, ecco il codice definitivo di questo primo capitolo.

CODICE
MPEG2Source("sample1.d2v")
trim(2,216)
separatefields()
nnccc = selectevery(10,  2,1, 4,3, 4,5, 6,7, 8,9).weave()
cnncc = selectevery(10,  0,1, 4,3, 6,5, 6,7, 8,9).weave()
ccnnc = selectevery(10,  0,1, 2,3, 6,5, 8,7, 8,9).weave()
cccnn = selectevery(10,  0,1, 2,3, 4,5, 8,7, 10,9).weave()
ncccn = selectevery(10,  2,1, 2,3, 4,5, 6,7, 10,9).weave()
p = selectevery(2,  0,-1).weave()
nnccc.trim(0,32)+ccnnc.trim(33,56)+nnccc.trim(57,96)+cccnn.trim(97,109)+cnncc.trim(110,136)+ccnnc.trim(137,163)+cccnn.trim(164,180)+ccnnc.trim(181,214)
strange(76,76,p)
strange(96,96,p)
strange(109,109,p)
strange(136,136,p)
strange(163,163,p)


Perfetto! Abbiamo effettuato correttamente il field match. Con questo si conclude il capitolo 1.
Nel capitolo 2 affronteremo la decimazione e il VFR.



Capitolo 2: L'approccio duro e puro all'IVTC - Decimazione e VFR

*TBD*

Ho intenzione di preparare il secondo capitolo entro la fine della settimana, se possibile, ma intanto vi lascio già il primo che è comunque abbastanza consistente.
Ci si risente. :v

EDIT: A casa sp una settimana è composta di 19 mesi, a quanto pare.

Ben ritrovati.

Trovandomi a voler procrastinare un po' di lavoro, la prima cosa che mi è venuta in mente è stata quella di chiudere la guida autistica per fare IVTC e VFR interamente a mano (cosa utile fondamentalmente solo a scopo educativo o come esercizio di stile).
Come per il matching trattato nel capitolo precedente, anche questa parte di decimazione all'atto pratico la sfrutterete molto di rado, mentre il VFR manuale può già tornare utile, visto che non esistono strumenti realmente affidabili di VFR automatico che possano gestire qualsiasi framerate (la cosa più vicina è il mix 24/30 con YATTA, ma ha i suoi limiti, e se bisogna fare un VFR reale per qualsivoglia ragione, essere in grado di fare VFR a mano è fondamentale).
Bene, come prima cosa cattatevi il sample per la decimazione:

http://task-force.lacumpa.biz/sample2.ts

Ora, dopo aver constatato che è il PV per la opening di Jinrui wa Suitai Shimashita, e consci che lo vedrete subbato il 31 febbraio del 2023, vediamo di capire cos'abbiamo per le mani.

Di primo acchito sembra tutto in regola. Voglio dire, è già progressivo, che altro potrebbe esserci?
C'è che in realtà non è 30p effettivo, ma tutto il pezzo del pv (originariamente 24p) è stato portato a 30p duplicando frame. In pratica è la stessa situazione in cui ci troviamo dopo aver fatto matching, semplicemente al posto di aver portato a 60i col classico 2:3 pulldown, hanno solo duplicato un frame ogni quattro.
I primi frame "di assestamento" (chiamiamoli così, intendo quei frame neri o duplicati che vengono messi a inizio e fine video per i motivi più disparati; negli anime encodati da tv possono capitare anche in mezzo all'episodio, prima e dopo gli stacchi pubblicitari) possiamo fingere che non esistano, il video vero e proprio comincia dal frame 2, per cui partiamo trimmando.
CODICE
trim(2,0)

Ora, quello che era il frame 2 adesso è il nostro frame 0, per cui controllando il gruppo di frame 0-4 noteremo questo pattern:
ABBCD
I frame 1 e 2 sono identici. Analizzando il resto del video noteremo che questo pattern rimane inalterato fino al frame 390. Dal 391 invece abbiamo il logo Lantis, che è 30p effettivo. Abbiamo quindi per le mani un VFR.
Nota estemporanea di colore: considerando come vengono fatte queste cose, la scritta che compare al frame 240 è stata probabilmente aggiunta a 30p dopo che il video al di sotto è stato duppato, ma trattandosi di una scritta completamente statica non ci crea il benché minimo problema (e compare pure in un frame unico, quindi non ci crea nemmeno fisime di decimazione su quale dei due dup sia più corretto tenere).

Ricapitolando, quindi, quello che sappiamo è che:
- dal frame 0 al frame 390 abbiamo un video 24p duppato a 30p con un pattern ABBCD
- dal frame 391 fino alla fine abbiamo un video 30p
Per gestire una situazione del genere manualmente, dobbiamo anzitutto salvarci un clip non decimato che utilizzeremo in seguito, e poi andare a decimare.

IMPORTANTE: QUANDO SI DECIMA È BUONA ABITUDINE MANTENERE IL SECONDO DUP. A meno di casi particolari (per esempio, pattern disallineati durante un fade, in cui si potrebbe ripristinare un video progressivo senza postprocess impiegando pattern atipici), il secondo dup è quello qualitativamente migliore. In un pulldown classico, il primo dup è quello matchato dall'interlace, per cui ci saranno dei minimi artefatti (magari anche sostanzialmente invisibili, eh) e disallinamenti di field dovuti all'encode lossy, mentre il secondo dup è progressivo. In tutti i casi (sia pulldown, sia dup progressivi), il secondo dup ha comunque il frame precedente come reference, per cui l'encode lossy avrà preso il frame precedente e gli avrà potuto migliorare qualche dettaglio col bitrate a disposizione.

Ne consegue che, in questo caso, avendo:
ABBCD
il nostro pattern di decimazione ideale sarà
KDKKK
che significa che, in un gruppo di cinque frame, vogliamo tenere primo, terzo, quarto e quinto.
Per dire questo ad avisynth possiamo usare nuovamente il filtro selectevery. In questo caso, per la precisione:
CODICE
selectevery(5,0,2,3,4)

Visto che non sono soddisfatto della spiegazione che avevo dato durante il field match, rispiegherò più approfonditamente l'uso di selectevery.
Al solito, avisynth parte a contare dallo 0. Il primo valore di selectevery stabilisce il gruppo di frame, ovvero ogni quanto selezionare. Dalla seconda cifra in poi si specificano quali frame selezionare.
NOTA BENE: Riguardo all'uso di selectevery, potete specificare frame all'infuori del range specificato (per esempio, mantenendo 5 come gruppo, se dite -1 o 5 state selezionando rispettivamente il frame precedente al primo e il frame successivo all'ultimo del gruppo di 5), potete ripetere più di una volta lo stesso frame (duplicandolo a tutti gli effetti) e potete specificare anche frame fuori ordine (per cui fare selectevery(5,4,3,2,1,0) vi farà un video che riproduce ogni gruppo di cinque frame al contrario). Mi sembrava il caso di avvisarvi perché selectevery può ritornare utile in occasioni atipiche, e saperlo utilizzare al massimo delle sue capacità è sicuramente comodo, visto che può evitare di fare casini di trim manuali per sistemare certe cose.

Tornando al nostro file esempio, quindi, avremo da fare:
CODICE
clip30 = last#questo clip mantiene il video non decimato originale
clip24 = selectevery(5,0,2,3,4).assumefps(last.framerate)#ci salviamo il video decimato e lo riportiamo allo stesso framerate del video originale


Se vi state chiedendo il perché dell'assumefps, è presto detto: avisynth non consente di fare splice di clip con proprietà diverse. Framerate, risoluzione, colorspace, audio... ogni proprietà dei clip deve coincidere.
Ok, ora abbiamo i due clip, quello originale e quello decimato, dobbiamo metterli assieme per il vfr.
La parte più facile qui è sapere quale parte del clip30 prendere, visto che va dal frame 391 fino alla fine. Ma il clip24? Finiva al frame 390, per cui possiamo calcolare quale sia il frame attuale. Il calcolo è semplice e dipende da come abbiamo decimato: si tratta di una semplice proporzione, ovvero 390:5=x:4. Avendo preso 4 frame ogni 5, significa fare 390/5*4=312. E se andiamo a controllare il clip24, il frame 312 è effettivamente l'ultimo che ci serve, dal 313 sbuca il logo lantis.
All'atto pratico quindi, semplicemente:
CODICE
clip24.trim(0,213)+clip30.trim(391,0)

Perfetto! Ora però dobbiamo fare il vfr. E questa non è una cosa che si fa dentro avisynth, ma a parte.
Create un file txt (per comodità e abitudine da yatta vi suggerisco di chiamarlo con lo stesso nome dell'avs aggiungendo .vfr.txt, per cui se avete sample2.avs, fate sample2.vfr.txt), apritelo con blocco note, e dentro cominciate a scrivere la prima riga:
CODICE
# timecode format v1

Fin qui tutto ok. Quando andremo a fornire questo file a x264 encodando, leggerà la prima riga e saprà che sono nel formato v1 (quello che noi poveri umani riusciamo a comprendere).
La seconda riga, invece, serve per stabilire qual è il framerate base del video. Dalla terza in poi si specificano le eccezioni, ovvero range di frame che sono a un framerate diverso dal framerate base del video.
Nel nostro caso, quindi, abbiamo due possibilità: specificare il framerate film come base e specificare poi il range di frame finale come eccezione a framerate video, oppure l'opposto, specificare il framerate video come base e specificare poi tutta la parte iniziale come film.
YATTA specifica sempre il framerate film come base, e poi specifica le sezioni video come eccezione, ma all'atto pratico, lavorando a mano, l'unica differenza è una questione di comodità: conviene dover specificare il minor numero di eccezioni possibile, quindi dipenderebbe da caso a caso. Per abituarvi a quel che vedrete con YATTA, quindi, ecco cos'avremo nel nostro caso:
CODICE
# timecode format v1
Assume 23.976023976024
214,255,29.97

Quel valore assurdo è il framerate film con l'arrotondamento più piccolo consentito dal timecode v1, ed è il valore che sputa fuori YATTA. Pure il 29.97 è il valore usato da YATTA per le parti video nei vfr.

Ad ogni modo, ora potete salvare e chiudere avspmod e blocco note, perché tutto quello che c'è da sapere per la decimazione manuale e il vfr l'ho trattato. O quasi.

Ci sono effettivamente alcune cose che non ho trattato, ma che è una sbatta spiegare nello specifico. Per cui ve le spiego in breve e se avrete effettivamente bisogno di fare 'ste cose ve le sbolognate da soli, visto che sono cose che potreste intuire da soli riflettendo un po', senza che io mi sbatta a postare esempi precisi con tanto di calcoli e tutto:
- Come si calcola il nuovo valore di un frame post-decimazione e splice in mezzo a un video vfr per trascriverli nel txt del vfr? Il video decimato è decimato per interezza, quindi mettendo tutto assieme con trim e splice non avrete problemi, ma dopo che mettete tutto assieme dovete tenere conto dei vari pezzi per avere il calcolo preciso. Sì, è pallosso, infatti io stesso il più delle volte non sto a calcolare a mano, ma mi limito a cercare i frame su avspmod (a tal proposito, può essere utile evidenziare i frame iniziali di ogni sezione con un invert o un subtitle, per ritrovarli più facilmente nel caso in cui i cambi di framerate siano in mezzo a una scena o in mezzo al nero anziché con un cambio scena netto come nell'esempio che abbiamo utilizzato).
- Come si gestisce il vfr in caso sia necessario fare bob di una sezione, mentre si tiene il resto al framerate originale o decimato? Banalmente il framerate e il framecount del pezzo col bob è raddoppiato. Ovviamente aiutarsi con avspmod per ritrovare i numeri giusti dei frame semplifica la vita anziché doversi calcolare a mano tutti i numeri esatti di frame.
- Come si calcola il framerate per le sezioni di vfr con decimazioni particolari (per esempio decimazione NinM o comunque decimazioni con pattern diversi in uno stesso video, entrambe situazioni non gestite da YATTA e che vanno quindi sapute fare manualmente)? Esattamente come il calcolo del nuovo valore di un frame, si tratta di una proporzione: framerate originale : M = nuovo framerate : (M-N). Ricordate che con NinM si intende quanti frame (N) vanno decimati in ogni gruppo di frame (M). Per cui la decimazione standard sarebbe una decimazione di 1in5, e YATTA è in grado di gestire correttamente solo pattern di 1inN. Se dovete fare altre robe, dovete arrangiarvi a mano (è l'unico caso per cui servirebbe saper usare gli override di tdecimate), ma le rare volte che l'ho dovuto fare io me la sono sbrigata usando dei deleteframe sull'avs generato da YATTA e poi aggiustando a mano il file del vfr che lo accompagnava...


La prossima lezione, di cui non voglio dare assolutamente il benché minimo preavviso né certezza, dovrebbe trattare di tfm/tdecimate (in particolar modo dell'uso degli override), ma se sarò particolarmente scazzato potrei passare direttamente a YMC e YATTA, tanto imparare a fare ivtc con tfm e tdecimate serve a poco o niente se si impara a usare YATTA.

Edited by mirkosp - 6/10/2016, 17:13
 
Web  Top
Nononn
view post Posted on 18/2/2016, 02:50     +1   -1




La guida continua?
Potresti riuppare il file su cui lavorare?

Edited by Nononn - 18/2/2016, 04:28
 
Top
view post Posted on 18/2/2016, 13:00     +1   -1
Avatar

Member

Group:
Utente abilitato
Posts:
286
Reputation:
+28

Status:


 
Top
view post Posted on 18/2/2016, 14:58     +1   -1
Avatar

Bimbosp

Group:
Administrator
Posts:
9,780
Reputation:
+929
Location:
Gallarate (VA)

Status:


Dovrebbe continuare, ma francamente mi è passata la voglia e ogni giorno che passa è sempre più inutile saper fare queste cose, visto che c'è sempre meno spazio per il fansub e sempre più sorgenti già prese bene che non richiedono minimamente di sapere tutte queste cose (vuoi perché i simulcast esteri offrono video migliori dei .ts o perché tanto usando i bd abbiamo già video progressivi puliti).
 
Web  Top
view post Posted on 18/2/2016, 15:38     +1   -1

Member

Group:
Utente abilitato
Posts:
968
Reputation:
+161
Location:
Trentino Alto Adige

Status:


CITAZIONE (mirkosp @ 18/2/2016, 14:58) 
Dovrebbe continuare, ma francamente mi è passata la voglia e ogni giorno che passa è sempre più inutile saper fare queste cose, visto che c'è sempre meno spazio per il fansub e sempre più sorgenti già prese bene che non richiedono minimamente di sapere tutte queste cose (vuoi perché i simulcast esteri offrono video migliori dei .ts o perché tanto usando i bd abbiamo già video progressivi puliti).

Rimangono sempre le serie vecchie e DVD in situazioni alquanto improbabili come uniche fonti. Certo, scrivere un manuale per poche consultazioni non vale la pena... ma perché non ridurre il resto all'osso? Invece di esporre tutto nel minimo dettaglio potresti mettere solo la struttura di quello che ci sarebbe da scrivere: una scaletta, un diagramma di flusso, dei link o delle cose da fare (e da evitare) stile "lista della spesa" e poi, quelli ai quali effettivamente la cosa interessa, almeno avranno un punto da cui iniziare.
 
Top
view post Posted on 18/2/2016, 16:52     +1   -1
Avatar

Bimbosp

Group:
Administrator
Posts:
9,780
Reputation:
+929
Location:
Gallarate (VA)

Status:


Perché non sono abbastanza e molte delle cose "pratiche" che ho imparato o le ho scoperte da solo o mi sono state insegnate su IRC e non hanno riscontri online.
 
Web  Top
Nononn
view post Posted on 19/2/2016, 00:17     +1   -1




C'é qualche lettura consigliata per chi vuole imparare di piú?
 
Top
view post Posted on 6/10/2016, 16:14     +1   -1
Avatar

Bimbosp

Group:
Administrator
Posts:
9,780
Reputation:
+929
Location:
Gallarate (VA)

Status:


Non ci credevo neanche io, ma ho realmente ultimato la guida alla decimazione manuale.

Buon Dio.
 
Web  Top
view post Posted on 6/10/2016, 16:38     +1   -1
Avatar

Distruttore di mercati

Group:
Utente abilitato
Posts:
682
Reputation:
+163
Location:
Aiur

Status:


Vogliamo sapere come si fa a far generare il timecode a yatta utilizzando il NoDecimate :PogChamp:

Lo so... ormai scrivo solo per usare il PogChamp a caso.
 
Top
view post Posted on 6/10/2016, 18:31     +1   -1
Avatar

Member

Group:
Utente abilitato
Posts:
370
Reputation:
+50
Location:
Rokkenjima

Status:


Perché piuttosto non finisci Love Lab? :Kappa:
 
Top
view post Posted on 6/10/2016, 19:02     +1   -1
Avatar

Bimbosp

Group:
Administrator
Posts:
9,780
Reputation:
+929
Location:
Gallarate (VA)

Status:


CITAZIONE (Gregory_House @ 6/10/2016, 19:31) 
Perché piuttosto non finisci Love Lab? :Kappa:

EHEH MEMES.
 
Web  Top
11 replies since 18/3/2015, 18:13   1198 views
  Share