Ehilà!
Come state?
Oggi avevo altra roba da procrastinare, per cui eccoci qua.
In realtà questo passaggio potrebbe essere sintetizzato in:
RTFM:
https://avisynth.org.ru/docs/english/exter...lters/tivtc.htmVisto che ormai la teoria dietro l'IVTC la sapete tutta e quindi siete in grado di comprendere i passaggi, ma vedrò di riportare qui i punti chiave di TIVTC, visto che alcuni concetti si ripresenteranno poi per YATTA (e dovrete stabilire voi quanto essere autistici).
Capitolo 1: L'approccio per persone sane di mente all'IVTC - Il field match con TFM
TFM(d2v="percorso\al\file.d2v")
Capitolo 2: L'approccio per persone sane di mente all'IVTC - La decimazione con TDecimate
TDecimate(mode=1)
Fine!
Capitolo 3: ESSEPI NON PRENDERCI PER IL CULO, NON HAI POSTATO UN CAZZO PER TUTTO IL 2017
Ok, è giunto il momento di dire la verità: non penso che si arrivi ad una ventina di persone in tutto il mondo a cui importa (ancora) veramente così tanto della qualità video per stare a fare queste cose a mano nel 2018.
Ma alla fine questa verità è ciò che ho volutamente ignorato quando ho scritto tutte le parti precedenti della guida, per cui non ha senso smettere di ignorare questo fatto ora, no?
Se siete già arrivati a leggere tutta la guida fino a qui, quindi, o siete malati di mente quanto me, oppure avete davvero del gran tempo da perdere.
Se siete della seconda categoria allora mettersi a encodare i cartoni cinesi non è uno dei modi più utili all'umanità per occupare il tempo. Suggerirei il volontariato, ma non giudico.
Se siete della prima e davvero c'è bisogno di usare gli ovr, probabilmente avete a che fare con un qualcosa che è meglio fare con YATTA.
Pertanto, prendete quando segue come essenzialmente a scopo illustrativo: sono cose di cui ho fatto utilizzo prima di imparare a usare YATTA, che comunque fu creato proprio perché fare queste cose a mano manda in pappa il cervello.
Sostanzialmente, se non dovete sistemare cambi scena scazzati dall'MPEG-2, ma avete un video pulito con un pattern essenzialmente costante (a parte eventuali cambi pattern nei punti delle sigle e dell'eyecatch), vi conviene usare TIVTC ed evitare YATTA.
Ne consegue che in realtà per il fansub, visto che quando si sta gestendo materiale interlacciato si ha tipicamente a che fare con .ts televisivi con i soliti difetti da gestire (più comodi da sistemare con YATTA) o con DVD vecchiotti pieni di casini (in cui TIVTC farebbe errori se lasciato andare in modalità automatica), il più delle volte potrebbe convenire usare YATTA, e TIVTC è sostanzalmente "inutile", ma non è necessariamente vero.
La decisione dipende essenzialmente da quante sistemazioni ci sarebbero da fare rispetto all'IVTC automatico, quanto filtraggio per scena/per frame dovrete fare, e sostanzialmente quanta sbatta avete.
Anche nei casi in cui TIVTC commette errori, il risultato finale è tendenzialmente accettabile e per l'utente medio non esisterà differenza percettibile in playback.
Ma noi siamo qui per essere malati, per cui OVVIAMENTE non ci accontentiamo mica di una cosa logica e sensata come "raggiungere un risultato sufficientemente buono", ma vogliamo necessariamente "raggiungere un risultato inutilmente ottimo".
Nevvero?
Capitolo 4: Approfondiamo TFM
TFM si occupa del field match, ovviamente.
Per farlo, ha bisogno di calcolare tutte le metriche del caso, su cui stabilire come intervenire.
Con i computer d'oggi è un processo che si fa molto più rapidamente che il realtime di riproduzione, ma un tempo tagliare su questa roba serviva, per cui, per evitare di calcolare due volte certa roba, potete pure sputare fuori queste metriche tramite il parametro output, così da capire come sta intervenendo TFM, e poi ridargliele di nuovo in pasto a sé stesso con input, in modo tale che ai successivi usi dello script non ci sia bisogno di ricalcolarle.
Sputar fuori le metriche è utile perché essenzialmente avrete già segnalati i punti in cui TFM non è sicuro di aver fatto bene l'IVTC, dicendovi dove potrebbero esserci comb residui da dover sistemare a mano.
Un'altra cosa che possiamo valutare sono i cambi scena. TFM matcha c/p di default, utilizzando gli n in caso di cambi scena problematici in cui non trova un match. Questo significa che, se trovate dei match n nello script, probabilmente quello è un cambio scena problematico. In alternativa potreste avere una scena molto movimentata con tanta merda, e il match n usciva pulito, ma usandolo sminchiate tutto il movimento e vi beccate pure un dup in mezzo alla scena. Belle cose!
Chiarito come funziona il sistema di metriche, passiamo a qualche parametro di TFM.
Oltre ai classici parametri di order/field (sinceramente trovo un po' inutile averli separati, ma vabbè), il grosso lo fanno mode e PP.
Gli unici mode con un reale senso di esistere sono 0 e 1. Lasciare altre opzioni come automatici sono follia, eventuali altri match sono da stabilire a mano, fine del discorso.
Per PP le cose si fanno "interessanti".
PP 0 lo usate se siete assolutamente certi che non ci siano comb nel video, e volete evitare che per qualche motivo venga fatto del PP, 1 è utile per lasciare degli hint dei frame da postprocessare ma volete lasciare che il postprocess venga fatto poi da TDecimate.
Se vi state chiedendo cosa siano gli hint... in sostanza, nei primi 64 pixel in alto a sinistra del video, il bit meno importante viene sfruttato per veicolare tutte le informazioni utili.
È un sistema mutuato da decomb e che anche fieldhint/telecidehints sfruttano.
In pratica ci si mettono informazioni come le metriche, e si può flaggare il frame come progressivo o interlacciato per sapere se post-processarlo o meno.
La differenza è totalmente trascurabile, ma se volete essere completamente autistici, allora sì, prima di fare IVTC aggiungete un paio di righe nere in alto, da croppare a IVTC ultimato. Questo non lo faccio neanche io, per cui complimenti, mi avete superato.
I valori 2-7 sono "relativamente inutili". Se state leggendo questa guida vorrete sicuramente usare opzioni migliori di quelle interne di TFM per post-processare i field, per cui al più vi ritrovereste a usare il parametro clip2, e quindi usereste o un valore tra 2 e 4 per usare il clip2 così com'è, o un valore tra 5 e 7 per sfruttare la maschera di movimento di tfm. Per quel che ho potuto testare io, la maggior parte delle volte questa maschera di movimento non si è rivelata particolarmente affidabile, e se fate qualche esperimento si noterà benissimo quali pezzi sono presi dal clip2 e quali sono il match.
Per gli altri parametri di TFM...
d2v l'ho già messo sopra. Se avete un d2v, specificarlo fa solo bene, tutto qui.
slow: true (che è ovviamente default), perché nel 2018 non ha senso usare false.
mChroma: come dice bene il manuale, salvo abbiate particolari artefatti sul chroma da impedire un matching affidabile, è meglio lasciarlo su true.
y0/y1: servono per impostare una fetta (in verticale) di video da ignorare per le decisioni. Se avete un .ts con gli avvisi a 60i che passano in basso, impostare i valori di y0 e y1 consente a TFM di azzeccare i match in automatico, e in teoria dovrebbero arrivare metriche accurate a TDecimate che a quel punto non dovrebbe scazzare la decimazione, ma non ci metterei la mano sul fuoco (tanto poi ne riparliamo con gli ovr).
chtresh/chroma/blockx/blocky/MI/mthresh: tutti parametri legati al post-process automatico per decidere se un frame va post-processato o no. In generale, se c'è da fare post-process e non volete essere pesoculo, è bene assicurarsi a mano di quali frame vengono post-processati e quali no, per cui segnalereste a mano negli ovr i frame da post-processare senza che ci pensino questi parametri a doverlo decidere per voi.
E ora, finalmente, veniamo alla roba interessante...
ovr: per passare i file ovr che vi scriverete a manina; della struttura degli ovr ne parlo più sotto.
ovrDefault: per stabilire come comportarsi per il post-process nei frame non indicati a mano. Idealmente, come dicevo sopra, non dovreste lasciare decisione automatiche a tfm, ma fare a mano. Di norma vi ritrovereste a specificare nell'ovr i frame da post-processare e poi impostare ovrDefault a 1 per impedire che vengano post-processati altri frame.
Di input/output ne ho già parlato a inizio capitolo.
OutputC vi crea un file in cui vi indica quali sequenze sono state rilevate come potenziali sequenze progressive e cNum stabilisce quanti frame match c di fila devono esserci per considerare una sequenza da indicare nel file di cui sopra. Sono opzioni potenzialmente utili per sapere già dove andare a controllare per vedere se ci sono sequenze da fare in VFR.
E ora, finalmente...
Con gli OVR potete dire a TFM di TUTTO. Proprio TUTTO.
Ma ovviamente le cose utili sono essenzialmente solo 2:
1) dire a TFM che pattern/match usare
2) dire a TFM che frame post-processare
Il resto si può quasi definire superfluo, per come la penso io, per cui qui starò a spiegare solo le due cose di cui sopra, e se volete guardarvi anche il resto l'RTFM di inizio guida è sempre valido.
Anzitutto, il file di ovr è un semplice txt, in cui dentro indicate un frame (o un range di frame indicato tramite virgola) e poi cosa ci si deve fare.
Per i match, invece, avete a disposizione p, c, n, u, b. I valori u e b sono essenzialmente trascurabili, quel che conta sono ovviamente i classici match p, c, n.
TFM di default matcha p (che è l'opposto di quello che fanno decomb e yatta), per cui avete due opzioni:
- forzare tutti i pattern del video a mano così è tutto in match n
- usare il match automatico di tfm dove è affidabile e specificare il pattern con match p dove in automatico ha problemi
Se volete andare con la prima opzione, tanto vale usare YATTA, per la seconda invece potete aiutarvi con il file di output che è stato sputato fuori per capire dove serve agire.
Per il postprocess invece, + indica che il frame è combed (e quindi da post-processare) e - che il frame è pulito così com'è. Se avete indicato ovrDefault 1, dovrete solo indicare + nei frame/pezzi/pattern che vi interessano.
Dunque, quello che potete fare quindi è:
Indicare un singolo frame e dire cosa va fatto.
Ad esempio, per dire che il frame 10 va post-processato basta scrivere:
10 +
O se il cambio scena al frame 9001 va matchato n al contrario del resto, potete fare:
9001 n
Indicare cosa fare in un gruppo di frame.
Ad esempio, per dire che tutti i frame dal 20 al 30 vanno post-processati basta scrivere:
20,30 +
Indicare cosa fare in un determinato pattern.
E quindi, se avete un pezzo che tfm scaga in automatico, potete forzarlo. Ad esempio, dal frame 50 al 100 potete forzare ccppc facendo:
50,100 ccppc
Potete usare i pattern anche per il post-process. Quindi, per dire che ogni quinto frame dal 200 al 300 va post-processato, potete fare:
200,300 ----+
E... direi che per TFM è tutto.
La parte che riguarda TDecimate la rimando a data da destinarsi, che per oggi ho già scritto abbastanza.Capitolo 5: Approfondiamo TDecimate
Su TDecimate, per la verità, c'è molto meno da dire che su TFM.
I parametri che analizzerò qui sono mode, cycleR, cycle e ovr.
Ci sono tanti altri parametri, anche utili, per migliorare la decimazione automatica di TDecimate, ma siccome lo scopo ultimo è usare tivtc automatico solo quando la sorgente non ha cose complicate e andare manualmente quando invece lo fossero, analizzare tutto è superfluo, e per il resto quindi vi rimando al RTFM di inizio guida, se foste così interessati.
Di mode, sostanzialmente, ce ne interessa una: 1.
Con mode 1, tdecimate cercherà la stringa più lunga di dup che mantengano lo stesso pattern di decimazione.
CycleR e cycle servono a stabilire il pattern.
CycleR determina quanti frame vadano decimati in un gruppo, mentre cycle quanto è grande il gruppo.
Per il materiale che gestiamo solitamente questo significa CycleR è 1, e cycle è 5, e questo corrisponde al default.
In ultimo ovr.
Creando un file ovr, come per tfm, possiamo dire di preciso a tfm quali frame vadano decimati indicandoli con il meno.
Per cui, per decimare il frame 9001, all'interno dell'ovr scriveremo:
Possiamo anche specificare un pattern di decimazione, utilizzando il + per dire quali frame tenere.
Se dobbiamo decimare il terzo frame in ogni gruppo di 5 dal frame 20 al frame 209, faremo:
Molto semplice.
Con questo ci siamo levati TDecimate dai coglioni.
In realtà se ne potrebbe parlare anche di più, ma volevo semplicemente chiudere questa parte relativamente superflua della guida (e fare un nuovo post dopo anni per memare duro), per cui tant'è.
Se mai vorrò togliermi *davvero* la paglia dal culo, dalla prossima parte dovrei coprire YMC e YATTA...
Edited by mirkosp - 18/4/2020, 13:35
