Cos'è telecine? Se non comprendi molto quello che è scritto in questo documento, leggi la definizione di telecine su Wikipedia (pagina inglese). E' una descrizione comprensibile e ragionevolmente completa di cosa si indichi con telecine.
Una nota riguardo i numeri. Molti documenti, inclusa la guida su indicata, fanno riferimento al valore dei campi per secondo del video NTSC come 59.94 e i valori corrispondenti di fotogrammi al secondo come 29.97 (con telecine e interlacciamento) e 23.976 (per il progressivo). Per semplicità alcune documentazioni arrotondano tali cifre a 60, 30 e 24.
Strettamente parlando, tutti questi numeri sono approssimati. Il video NTSC in bianco e nero era esattamente 60 campi al secondo, ma successivamente venne scelto 60000/1001 per incastrare i dati del colore e rimanere compatibili con le televisioni bianco e nero contemporanee. Anche il video NTSC digitale (come quello sui DVD) è a 60000/1001 campi al secondo. Da ciò discende che il video interlacciato e telecine è 30000/1001 fotogrammi al secondo; il video progressivo è 24000/1001 fotogrammi al secondo.
Precedenti versioni della documentazioni di MEncoder a molti post archiviati della mailig list fanno riferimento a 59.94, 29.97 e 23.976. Tutta la documentazioni di MEncoder è stata aggiornata per usare i valori in frazione, e anche tu dovresti usare questi.
-ofps 23.976 è sbagliato. -ofps 24000/1001 dovrebbe invece essere usato.
Come viene usato telecine. Tutto il video pensato per essere riprodotto su televisione NTSC deve essere a 60000/1001 campi al secondo. I film per la TV e gli spettacoli sono spesso registrati direttamente a 60000/1001 campi al secondo, ma la stragrande maggioranzna dei film per cinema è filmata a 24 o 24000/1001 fotogrammi al secondo. Quando i film da cinema vengono masterizzati su DVD, il video viene quindi convertito per la televisione usando un processo chiamato telecine (o telecinema).
Su un DVD il video non è praticamente mai memorizzato con 60000/1001 campi al secondo. Per un video che originariamente era 60000/1001, ogni coppia di campi viene combinata in un fotogramma, risultando in 30000/1001 fotogrammi al secondo. I lettori DVD hardware leggono quindi un parametro codificato nel flusso video pe rdeterminare se le linee pari o quelle dispari debbano formare il primo campo.
Solitamente il contenuto a 24000/1001 fotogrammi per secondi resta così com'è quando viene codificato per un DVD, e il lettore DVD deve eseguire il telecine al momento. Alcune volte invece, il video subisce il telecine prima di essere scritto su DVD; anche se in origine era a 24000/1001 fotogrammi al secondi, diventa 60000/1001 campi al secondo. Quando viene memorizzato su DVD, le coppie di campi vengono assemblate per formare 30000/1001 fotogrammi al secondo.
Guardando i singoli fotogrammi generati da video a 60000/1001 campi al secondo, che sia telecine o no, l'interlacciamento è chiaramente visibile ovunque vi sia del movimento, dato che un campo (diciamo le linee pari) rappresenta un istante nel tempo 1/(60000/1001) secondi dopo l'altro. Riprodurre video interlacciato su un computer risulta brutto sia perché il monitor ha una risoluzione maggiore sia perché il video viene mostrato un fotogramma dopo l'altro invece che un campo dopo l'altro.
Note:
Questa sezione si applica solo ai DVD NTSC, e non a quelli PAL.
Le righe di esempio per MEncoder proposte nella
documentazione non sono pensate per un
utilizzo reale. Sono solo quelle minimali richieste per codificare la
relativa categoria di video. Come fare buoni rip di DVD o configurare bene
libavcodec
per la massima qualità
non è lo scopo di questa documentazione.
Ci sono alcune note a piè di pagina specifiche di questa guida, così indicate: [1]
Il video progressivo è stato originariamente filmato a 24000/1001 fps, e memorizzato sul DVD senza modifica alcuna.
Quando riproduci un DVD progressivo con MPlayer, MPlayer emette la riga seguente appena il video inizia la riproduzione:
demux_mpg: 24000/1001 fps progressive NTSC content detected, switching framerate.
Da qui in poi, demux_mpg non dovrebbe mai comunicare di aver trovato "30000/1001 fps NTSC content" (contenuto NTSC a 30000/1001 fps).
Quando guardi video progressivo, non dovresti mai vedere alcuna interlacciatura. Fai tuttavia attenzione, poiché alcune volte c'è una piccola parte in telecine infilata dove non te la aspetteresti. Ho trovato alcuni DVD di spettacoli televisivi che hanno un secondo di telecine ad ogni cambio di scena, o anche in momenti casuali. Una volta ho guardato un DVD che aveva una prima parte progressiva e la seconda in telecine. Se vuoi esserne davvero certo, devi controllare tutto il video:
mplayer dvd://1 -nosound -vo null -benchmark
Using -benchmark makes L'utilizzo di -benchmark fa sì che MPlayer riproduca il filmato il più velocemente possibile; tuttavia, in dipendenza dal tuo hardware, può metterci un po'. Ogni volta che demux_mpg segnala un cambio nella frequenza fotogrammi (framerate), la linea immediatamente sopra ti dirà il tempo ove è cambiata.
Alcune volte il video progressivo sui DVD viene indicato come "soft-telecine" perché è fatto in modo che il lettore DVD esegua il telecine.
Il video in telecine è stato filmato in origine a 24000/1001, ma ha subito il telecine prima di essere scritto sul DVD.
Quando MPlayer riproduce video in telecine non segnala (mai) alcun cambio di framerate.
Guardado un video in telecine, noterai artefatti che sembrano "lampeggiare": appaiono e scompaiono ripetutamente. Puoi notarlo meglio facendo quello che segue
mplayer dvd://1
Ricerca una parte con movimento.
Usa il tasto . per avanzare di un fotogramma per volta.
Guarda il pattern dei fotogrammi che paiono interlacciati e di quelli progressivi. Se il pattern che vedi è PPPII,PPPII,PPPII,... allora il video è in telecine. Se vedi qualche altro pattern, allora il video può aver subito il telecine attraverso qualche metodo strano; MEncoder può effettuare la conversione senza perdita da telecine non standard a progressivo. Se non vedi alcun pattern, allora molto probabilmente è interlacciato.
Alcune volte il video in telecine sui DVD viene indicato come "hard-telecine". Dato che l'hard-telecine è già a 60000/1001 campi al secondi, il lettore DVD riproduce il video senza elaborazione alcuna.
Un altro modo per scoprire se la tua sorgente è in telecine o no è riprodurla
con le opzioni -vf pullup e -v da riga
comando per vedere come pullup relaziona i fotogrammi.
Se la sorgente è in telecine, dovresti vedere sulla console un pattern 3:2 con
0+.1.+2
e 0++1
che si
alternano.
Questa tecnica ha il vantaggio di evitare di guardare la sorgente per doverla
identificare, il che può tornare utile se vuoi automatizzare la procedura di
codifica ovvero se vuoi eseguire tale procedura in remoto su una connessione
lenta.
Il video interlacciato è stato filmato in origine a 60000/1001 campi al secondo ed è memorizzato sul DVD a 30000/1001 fotogrammi al secondo. L'effetto di interlacciatura (spesso chimato "combing") è un risultato di coppie di campi che vengono combinate in fotogrammi. Ogni campo è spostato di 1/(60000/1001) secondi e quando vengono mostrati contemporaneamente la differenza si nota.
Come per il video in telecine, MPlayer non dovrebbe mai segnalare alcun cambio di framerete, riproducendo contenuto interlacciato.
Quando guardi attentamente un video interlacciato avanzando fotogramma per fotogramma col tasto ., noterai che ogni singolo fotogramma è interlacciato.
Tutto il contenuto di un video "progressivo e telecine miscelato" è stato in origine filmato a 24000/1001 fotogrammi al secondo, ma alcune parti alla fine hanno subito il telecine.
Quando MPlayer riproduce questa tipologia di video salta (spesso ripetutamente) avanti e indietro tra "30000/1001 fps NTSC" e "24000/1001 fps progressive NTSC". Controlla le ultime righe dell'emissione di MPlayer per vedere questi messaggi.
Dovresti controllare le sezioni "30000/1001 fps NTSC" per assicurarti che siano davvero in telecine e non solamente interlacciate.
Nei contenuti con video "progressivo e interlacciato miscelati", il video progressivo e interlacciato sono mescolati tra loro.
Questa categoria è decisamente simile a "progressivo e telecine miscelato", fino a quando non controlli le parti a 30000/1001 fps e scopri che non hanno il pattern del telecine.
As I mentioned in the beginning, example MEncoder lines below are not meant to actually be used; they only demonstrate the minimum parameters to properly encode each category.
Progressive video requires no special filtering to encode. The only parameter you need to be sure to use is -ofps 24000/1001. Otherwise, MEncoder will try to encode at 30000/1001 fps and will duplicate frames.
mencoder dvd://1 -oac copy -ovc lavc -ofps 24000/1001
It is often the case, however, that a video that looks progressive actually has very short parts of telecine mixed in. Unless you are sure, it is safest to treat the video as mixed progressive and telecine. The performance loss is small [3].
Telecine can be reversed to retrieve the original 24000/1001 content, using a process called inverse-telecine. MPlayer contains several filters to accomplish this; the best filter, pullup, is described in the mixed progressive and telecine section.
For most practical cases it is not possible to retrieve a complete progressive video from interlaced content. The only way to do so without losing half of the vertical resolution is to double the framerate and try to "guess" what ought to make up the corresponding lines for each field (this has drawbacks - see method 3).
Encode the video in interlaced form. Normally, interlacing wreaks
havoc with the encoder's ability to compress well, but
libavcodec
has two
parameters specifically for dealing with storing interlaced video a
bit better: ildct and ilme. Also,
using mbd=2 is strongly recommended
[2] because it
will encode macroblocks as non-interlaced in places where there is
no motion. Note that -ofps is NOT needed here.
mencoder dvd://1 -oac copy -ovc lavc -lavcopts ildct:ilme:mbd=2
Use a deinterlacing filter before encoding. There are several of these filters available to choose from, each with its own advantages and disadvantages. Consult mplayer -pphelp and mplayer -vf help to see what is available (grep for "deint"), read Michael's Niedermayer Deinterlacing filters comparison, and search the MPlayer mailing lists to find many discussions about the various filters. Again, the framerate is not changing, so no -ofps. Also, deinterlacing should be done after cropping [1] and before scaling.
mencoder dvd://1 -oac copy -vf yadif -ovc lavc
Unfortunately, this option is buggy with MEncoder; it ought to work well with MEncoder G2, but that is not here yet. You might experience crahes. Anyway, the purpose of -vf tfields is to create a full frame out of each field, which makes the framerate 60000/1001. The advantage of this approach is that no data is ever lost; however, since each frame comes from only one field, the missing lines have to be interpolated somehow. There are no very good methods of generating the missing data, and so the result will look a bit similar to when using some deinterlacing filters. Generating the missing lines creates other issues, as well, simply because the amount of data doubles. So, higher encoding bitrates are required to maintain quality, and more CPU power is used for both encoding and decoding. tfields has several different options for how to create the missing lines of each frame. If you use this method, then Reference the manual, and chose whichever option looks best for your material. Note that when using tfields you have to specify both -fps and -ofps to be twice the framerate of your original source.
mencoder dvd://1 -oac copy -vf tfields=2 -ovc lavc \ -fps 60000/1001 -ofps 60000/1001
If you plan on downscaling dramatically, you can extract and encode only one of the two fields. Of course, you will lose half the vertical resolution, but if you plan on downscaling to at most 1/2 of the original, the loss will not matter much. The result will be a progressive 30000/1001 frames per second file. The procedure is to use -vf field, then crop [1] and scale appropriately. Remember that you will have to adjust the scale to compensate for the vertical resolution being halved.
mencoder dvd://1 -oac copy -vf field=0 -ovc lavc
In order to turn mixed progressive and telecine video into entirely progressive video, the telecined parts have to be inverse-telecined. There are three ways to accomplish this, described below. Note that you should always inverse-telecine before any rescaling; unless you really know what you are doing, inverse-telecine before cropping, too [1]. -ofps 24000/1001 is needed here because the output video will be 24000/1001 frames per second.
-vf pullup is designed to inverse-telecine telecined material while leaving progressive data alone. In order to work properly, pullup must be followed by the softskip filter or else MEncoder will crash. pullup is, however, the cleanest and most accurate method available for encoding both telecine and "mixed progressive and telecine".
mencoder dvd://1 -oac copy -vf pullup,softskip -ovc lavc -ofps 24000/1001
An older method is to, rather than inverse-telecine the telecined parts, telecine the non-telecined parts and then inverse-telecine the whole video. Sound confusing? softpulldown is a filter that goes through a video and makes the entire file telecined. If we follow softpulldown with either detc or ivtc, the final result will be entirely progressive. -ofps 24000/1001 is needed.
mencoder dvd://1 -oac copy -vf softpulldown,ivtc=1 -ovc lavc -ofps 24000/1001
I have not used -vf filmdint myself, but here is what D Richard Felker III has to say:
It is OK, but IMO it tries to deinterlace rather than doing inverse telecine too often (much like settop DVD players & progressive TVs) which gives ugly flickering and other artifacts. If you are going to use it, you at least need to spend some time tuning the options and watching the output first to make sure it is not messing up.
There are two options for dealing with this category, each of which is a compromise. You should decide based on the duration/location of each type.
Treat it as progressive. The interlaced parts will look interlaced, and some of the interlaced fields will have to be dropped, resulting in a bit of uneven jumpiness. You can use a postprocessing filter if you want to, but it may slightly degrade the progressive parts.
This option should definitely not be used if you want to eventually display the video on an interlaced device (with a TV card, for example). If you have interlaced frames in a 24000/1001 frames per second video, they will be telecined along with the progressive frames. Half of the interlaced "frames" will be displayed for three fields' duration (3/(60000/1001) seconds), resulting in a flicking "jump back in time" effect that looks quite bad. If you even attempt this, you must use a deinterlacing filter like lb or l5.
It may also be a bad idea for progressive display, too. It will drop pairs of consecutive interlaced fields, resulting in a discontinuity that can be more visible than with the second method, which shows some progressive frames twice. 30000/1001 frames per second interlaced video is already a bit choppy because it really should be shown at 60000/1001 fields per second, so the duplicate frames do not stand out as much.
Either way, it is best to consider your content and how you intend to display it. If your video is 90% progressive and you never intend to show it on a TV, you should favor a progressive approach. If it is only half progressive, you probably want to encode it as if it is all interlaced.
Treat it as interlaced. Some frames of the progressive parts will need to be duplicated, resulting in uneven jumpiness. Again, deinterlacing filters may slightly degrade the progressive parts.
About cropping: Video data on DVDs are stored in a format called YUV 4:2:0. In YUV video, luma ("brightness") and chroma ("color") are stored separately. Because the human eye is somewhat less sensitive to color than it is to brightness, in a YUV 4:2:0 picture there is only one chroma pixel for every four luma pixels. In a progressive picture, each square of four luma pixels (two on each side) has one common chroma pixel. You must crop progressive YUV 4:2:0 to even resolutions, and use even offsets. For example, crop=716:380:2:26 is OK but crop=716:380:3:26 is not.
When you are dealing with interlaced YUV 4:2:0, the situation is a bit more complicated. Instead of every four luma pixels in the frame sharing a chroma pixel, every four luma pixels in each field share a chroma pixel. When fields are interlaced to form a frame, each scanline is one pixel high. Now, instead of all four luma pixels being in a square, there are two pixels side-by-side, and the other two pixels are side-by-side two scanlines down. The two luma pixels in the intermediate scanline are from the other field, and so share a different chroma pixel with two luma pixels two scanlines away. All this confusion makes it necessary to have vertical crop dimensions and offsets be multiples of four. Horizontal can stay even.
For telecined video, I recommend that cropping take place after inverse telecining. Once the video is progressive you only need to crop by even numbers. If you really want to gain the slight speedup that cropping first may offer, you must crop vertically by multiples of four or else the inverse-telecine filter will not have proper data.
For interlaced (not telecined) video, you must always crop vertically by multiples of four unless you use -vf field before cropping.
About encoding parameters and quality:
Just because I recommend mbd=2 here does not mean it
should not be used elsewhere. Along with trell,
mbd=2 is one of the two
libavcodec
options that
increases quality the most, and you should always use at least those
two unless the drop in encoding speed is prohibitive (e.g. realtime
encoding). There are many other options to
libavcodec
that increase
encoding quality (and decrease encoding speed) but that is beyond
the scope of this document.
About the performance of pullup: It is safe to use pullup (along with softskip ) on progressive video, and is usually a good idea unless the source has been definitively verified to be entirely progressive. The performace loss is small for most cases. On a bare-minimum encode, pullup causes MEncoder to be 50% slower. Adding sound processing and advanced lavcopts overshadows that difference, bringing the performance decrease of using pullup down to 2%.