[transcode-devel] YAIT - Yet Another Inverse Telecine filter

[Allan N. Snider]

A have done quite a bit of transcoding now, and as a result have become acutely aware of any interlacing artifacts that get through to the final encoding. And, I don't like it. I have also seen a lot of variable frame rate dvd's lately. It was usually only the older dvd's but it seems to be back in full force now. The --hard_fps, and -J ivtc,32detect,decimate method does a pretty good job, but some interlacing always gets through. I had an idea for a different approach and have implemented it, called YAIT. This is meant specifically to handle NTSC telecined data mixed with progressive data. (Of course pure telecined works as well). The results (IMHO) are good for almost everything I have tried so far, so I'm posting my filter. It is expensive though, as it requires a complete separate pass on the video stream. But, unlike most others, that doesn't bother me. I have not tried this with psu mode, (it probably won't work). It definitely won't work for PAL or interlaced. Here is the documentation header from the filter, and I have attached the patch (against v1.1.0). I hope people try it out. After using it, I was surprised to find small bits of interlacing in every single (what I thought was) pure progress 24 fps dvd that I have encoded.

/*
*      yait:
*              Yet Another Inverse Telecine filter.
*
*      Usage:
*              -J yait=log[=file] (-y null)
*              -J yait=ops[=file]
*
*      Description:
*

*

*      stream and an external analysis tool to be run.
*

*      result is a (noticeably) smoother video.
*

*

*
*      Using the filter:
*
*          Pass 1:
*
*              -J yait=log -y null
*

*

*              In this case use something like:
*                      -H 10 -x vob -i ...

*                      -J yait=log -J text=frame:posdef=8
*
*          Running the tcyait tool:
*

*
*              tcyait [-d] [-l log] [-o ops] [-m mode]
*                      -d              Print debug information to stdout.

*
*              I typically run it as:
*                      tcyait -d > yait.info
*

*              portion.  So, it exists as a separate tool for now.
*
*          Pass 2 (and 3):
*
*              -J yait=ops -y ...
*

*              visa versa.  Here is an example invocation:
*

*                              -J yait=ops --progress_rate 25
*

*                              -J yait=ops --progress_rate 25
*

*              need not be specified.
*
*      DISCLAIMER:
*

*      'smartyuv' for those.
*

*      the .ops file manually.
*

*      is, such as it is.
*                                              Allan
*/

This functionality may already exist in other packages (AviSynth perhaps?), but it's not in transcode, so this could be a useful addition. If there is enough interest, it would be nice to integrate it into dvd::rip. Allan * This filter is designed specifically to handle mixed progressive and NTSC * telecined data (2:3 pulldown), converting from NTSC_VIDEO (29.97 fps) to NTSC_FILM * (23.976 fps). It uses row save and copy operations to reconstruct progressive * frames. It is provided as an alternative to the -J ivtc,32detect,decimate method. * For those who don't care how much cpu is used but are interested only * in trying to achieve the best quality rendering, then read on. If not, then stop * reading right now, as this filter requires a complete separate pass on the video * The main advantage of using a separate pass is that it provides a much * larger window of frames to examine when deciding what frames need to be dropped * or de-interlaced. The video stream is read at 30 fps (--hard_fps). Duplicate * frames are inserted by the demuxer to keep the frame rate at 30 when progressive * data is encountered. These frames can appear quite early or late, far beyond the * five frame local window used by ivtc, etc. This approach allows drop frames to * be credited, and debited, (up to a point), making better drop frame choices. The * Another advantage of using a large frame window is to provide context * for determining interlace patterns. Local interlace patterns (eg. a 5 frame * window) can sometimes be impossible to determine. When able to look ahead or * behind for existing patterns, usually the correct pattern can be inherited. * The filter guarantees one drop frame per 5 frames. No more, no less. * The first pass is used only to generate row (even/odd) delta information. * This is written as a text log file (called yait.log by default). (The * file name can be specified using yait=log=file). This is the only data * required by this pass, so no video (or audio) frames need to be encoded. * You do need to specify the demuxer_sync method however. (It must be 2). * Alternatively (for debug purposes), you may want to generate a frame * labeled video file, then compare the yait analysis to the original video. * --export_fps 0,4 --demuxer_sync 2 -y xvid4,null -o label.ogm * Pass 1 created a yait.log file. The analysis tool 'tcyait' is then run * which reads the log file and determines which areas are telecined and * progressive and detects the telecine patterns. A yait frame operations * file is then written (yait.ops by default). It is a text file containing * instructions for each frame, such as nop, save even or odd rows, copy rows, * drop frames, or blend a frame. The usage of the tool is as follows: * -l log Specify input yait log file name [yait.log]. * -o ops Specify output yait frame ops file name [yait.ops]. * -m mode Specify transcode de-interlace method [3]. * One could query why pass 1 doesn't just create the .ops file directly. That * is, run the analysis at TC_FILTER_CLOSE time and save the user from having * to run the tool directly. The main reason is that the tcyait code is alpha * and still undergoing a lot of fine tuning. I would not want to have to * regenerate the row delta information every time I tweaked the analysis * The second pass (or third for -R 1 and -R 2), reads the frame operations file * generated by tcyait, (called yait.ops by default). (The file name can be * specified using yait=ops=file). This file instructs the filter to save or * copy rows, skip frames, or de-interlace frames, and causes the pre filtering * to reduce the frame rate to 24 fps. Hence, you must specify the export fps * as 24, or will get truncated audio, (ie. --export_fps 24,1). The frame * sequence seen by the filter must match exactly what pass 1 saw. That is, you * cannot specify a frame range or audio track in pass 1, but not pass 2, and * transcode -H 10 -a 0 -x vob -i ... -w 1800,50 -b 192,0,0 -Z ... * -R 1 -y xvid4,null --demuxer_sync 2 --export_fps 24,1 * transcode -H 10 -a 0 -x vob -i ... -w 1800,50 -b 192,0,0 -Z ... * -R 2 -y xvid4 --demuxer_sync 2 --export_fps 24,1 -o ... * The import frame rate and --hard_fps flags are forced by the filter and * This is a work in progress. For non-NTSC telecine patterns, PAL, or purely * interlaced material, you are going to get nonsense results. Best stick to 'ivtc' or * For some video, remarkably good results were obtained. (I was quite pleased and * hence felt obliged to distribute this). In a few cases I had video constantly switching * frame rates, with single or small grouped telecine, both even and odd patterns, and was * able to reconstruct the original 24 fps progressive film for the entire file, without * blending a single frame. For others, not so good. The analysis tool can sometimes * generate a lot of false positives for interlace detection and specify needless frame * blending. Generally, wherever a frame blend is specified, something went wrong. I * usually step frame by frame in the original (frame labeled) .ogm and edit/correct * There is much work to be done still (especially documentation), but here it

filter_yait.patch.gz
Description: application/gzip