license: GPL
TDecimate is a decimaton filter intended to remove duplicates from a video stream. It supports a couple types of operation which include M-in-N decimation and an arbitrary framerate decimation scheme that can support ratios not achievable with M-in-N. It also includes special handling for hybrid material such as blend decimation (for a single frame rate solution) or vfr via mkv using a timecodes file.
TDecimate (clip, int "mode", int "cycleR", int "cycle", float "rate", float "dupThresh", float "vidThresh", float "sceneThresh", int "hybrid", int "vidDetect", int "conCycle", int "conCycleTP", string "ovr", string "output", string "input", string "tfmIn", string "mkvOut", int "nt", int "blockx", int "blocky", bool "debug", bool "display", int "vfrDec", bool "batch", bool "tcfv1", bool "se", bool "chroma", bool "exPP", int "maxndl", bool "m2PA")
mode -
Sets the mode of operation. Possible settings:
Mode 0 = Straight M-in-N decimation. TDecimate will examine each set of N frames and decimate the M most similar frames. The values of M and N are controlled via the cycleR and cycle parameters. Blend decimation of video (30p) is supported in the this mode (hybrid = 1).
Mode 1 = Exactly like mode 0, except instead of decimating the M most similar frames, frames are decimated from the longest remaining strings of duplicates. The duplicate detection uses the dupThresh parameter. This mode is the correct type of decimation for anime and other sources where frames are repeated 2, 3 or 4 times in a row, and also supports blend
decimation of video (30p) with hybrid = 1.
Mode 2 = This mode uses a separate decimation algorithm that can achieve any arbitrary framerate. It is useful when you cannot achieve the desired framerate with M-in-N decimation. The output framerate for this mode is set using the "rate" parameter. The maxndl parameter can be used to tweak behavior on sources with uneven duplicate distribution. No hybrid handling can be used in this mode!
This modes output will be slightly different if you run it with a metrics input file (created on a previous pass in mode 4 for example) that lets it analyze the entire video at the very beginning than if you run it straight and let it analyze the video as it goes. Generally the differences will be small, but the 2 pass method (i.e. full analysis from an input file)
will generally produce a smoother result. The m2PA parameter can be used to force the one pass version of mode 2 to produce the same results as the two pass version by reading ahead in the stream as much as is required (the one pass version limits the read ahead to 100 frames max).
Mode 3 = This is a one-pass vfr for mkv with timecodes output mode. Hybrid must be set to 2 in this mode! It uses M-in-N decimation and cycleR must be set to 1! The type of decimation that is used on film sections (most similar or longest string) is controlled via the vfrDec setting. For this mode to work all access must be linear from start to finish... an error will be thrown if non-linear access is detected.
Since vfw needs to know the # of frames before processing starts this mode does not change the # of frames and simply pads the output as needed with black frames. The last actual frame will be recorded as a comment at the end of the mkv timecodes file, and will be reported on the padded frames as well once at least 300+ extra frames are returned. If the se option is set to true, then TDecimate will throw an error once the 306th extra frame is reached, stopping processing and alerting the user. If your gonna be around when its done and not doing batch encoding this option can save you some time.
The name and path of the mkv timecodes file to output is set using the mkvOut parameter.
Mode 4 = Metrics output. No decimation is done, but metrics are calculated allowing for the output, display, or debug options to be enabled and outputting of the metrics for later use. (first pass for two pass mkv vfr using mode 5)
Mode 5 = This is similar to mode 3 (mkv vfr, and requires hybrid=2 and cycleR=1), but as part of a two pass process. It requires a complete input file (obtained via the output parameter on a previous pass), and a complete tfmIn file (see the batch option for a way around these requirements). The advantages of this mode over Mode 3 are that it does not require linear access (seeking is supported), it uses the conCycleTP parameter instead of the conCycle parameter which allows for values greater then 2, and it will have a correct frame count with no padded frames.
Mode 6 = This is for doing 120fps->vfr w/ timecode file. It requires a complete metrics input file generated via mode 4 on a previous pass. It will decimate bit for bit identical frames only. All decimation will be into one of the following frame rates: 119.880, 59.940, 39.960, 29.970, 23.976.
Default: 0 (int)
cycleR -
Sets the "M" for the M-in-N decimation modes. In other words, setting this to 1 means 1 frame in every cycle frames will be dropped. This setting can be anything in the range 1-299. It must be less then the value of the cycle setting!
*NOTE: all hybrid handling options only support cycleR = 1. So if hybrid > 0 this value must be set to 1!
Default: 1 (int)
cycle -
Sets the "N" for the M-in-N decimation modes. In other words, setting this to 5 means cycleR frames in every 5 frames will be dropped. This setting can be anything in the range 2-300. It must also be greater then the cycleR setting.
Default: 5 (int)
rate -
This sets the output frame rate when using mode = 2. Frames will be dropped so that this frame rate is acheived while keeping audio/video sync as close as possible. This must be less then the input frame rate.
Default: 23.976 (float)
hybrid -
Controls how or if video sections (30p) should be dealt with. Possible settings:
0 - no handling
1 - blend decimation (modes 0 and 1)
2 - vfr via mkv w/ timecodes file output (modes 3 and 5)
* The hybrid option is not used when mode = 2 or mode = 4, and hybrid > 0 is only currently supported for cycleR = 1!
Default: 0 (int)
vfrDec -
Sets the type of decimation to use for film sections when using modes 3 and 5. Possible settings:
0 - drop most similar frame in cycle
1 - decimate from longest string of duplicates
Default: 1 (int)
dupThresh -
This sets the threshold for duplicate detection. This setting is used in mode 1 and also in modes 3 and 5 if vfrDec = 1. If the difference metric for a frame is less then or equal to this value then it is declared a duplicate. NOTE: metrics will be slightly different between YV12 and YUY2 processing if chroma=true... the metrics have been normalized so they should match closely, but on average the YUY2 metrics tend to be slightly higher (5-10%) then the YV12 metrics for the same frame when chroma=true. When chroma=false YV12 and YUY2 metrics will be the same, however chroma=false metrics will be higher then chroma=true metrics so if you set chroma=false be sure to account for this. This value is a % of maximum change for a block defined by the blockx and blocky values.... so 1.1 means 1.1% of maximal possible change.
Default: 1.1 (if chroma = true) (float)
1.4 (if chroma = false)
vidThresh -
This setting is used for detecting video sections (30p) based off frame metrics when hybrid > 0. If all frames in a cycle have metrics above this threshold then the cycle is declared video metrics wise. This setting is similar to dupThresh, but should be set slightly higher if your vidDetect setting is set to 1 and not 3. If you know that your source has a lot of video sequences then set this lower vs if you know your source is pure film then you can set this really high to prevent any possible misdetections. This value is a % of maximum change for a block defined by the blockx and blocky values.... so 1.1 means 1.1% of maximal possible change.
Default: 1.1 (if chroma = true) (float)
1.4 (if chroma = false)
sceneThresh -
Sets the threshold for detecting scene changes when using blend decimation for video sections (hybrid = 1). This value is a % of maximum change for the luma plane. Good values are between 10 and 25. Must be in the range 0 to 100.
Default: 15 (float)
vidDetect -
This sets what is required for single cycle video detection when hybrid > 0. Whether a single cycle alone is enough or whether two consecutive cycles or more must be detected as video is controlled via the "conCycle" and "conCycleTP" parameters.
Video detection via frame matches: (Labeled Type A)
i.) The matches that were used by TFM do not indicate that there are duplicates in the cycle
Video detection via metrics: (Labeled Type B)
i.) All frames in the cycle have metrics above vidThresh.
How these two types of information are used as a whole to determine video sections is determined by vidDetect. Each vidDetect setting has a condition that if met will result in the current cycle being detected as video. (refer above for the A and B labels). Please note that ovr (overrides) overrules vidDetect!
0 - A (if matches indicate video then consider it video)
1 - B (if metrics indicate video then consider it video)
2 - A or B (if either matches or metrics indicate video then consider it video)
3 - A and B (if both matches and metrics indicate video then consider it video)
Default: 3 (int)
conCycle -
conCycle sets the required minimum # of consecutive cycles detected as video for any section to be considered video when hybrid > 0. Meaning, if conCycle is set to 2, and a single cycle is detected as video but both the cycle before it and after it are detected as film then that cycle will be considered film as well. If conCycle had been set to 1 in the previous example then the standalone video cycle would have been consider video. This setting is used in all cases except two pass mkv vfr (mode 5) where conCycleTP is used instead! The difference is conCycle is limited to a maximum value of 2 while conCycleTP has no upper limit. Possible values are 1 or 2.
default: 1 if vidDetect = 3 (int)
2 otherwise
conCycleTP -
This is the same as conCycle, but is used in mode 5 (two pass) and allows for any value (not just 1 or 2) and has no upper limit.
Default: 1 if vidDetect = 3 (int)
2 otherwise
nt -
Sets the noise threshold used when calculating difference metrics. If the abs() difference between two pixels is less then or equal to this value, then the difference is considered 0. This can help lower the metrics of actual duplicate frames thus widening the difference between dups and non dups making it easier to set correct thresholds. Avoid setting this value to high or very similar objects moving over one another will start to not be detected etc... Good values are in the range 1-2. For clean video using a value of 0 seems to work best.
Default: 0 (int)
blockx -
Sets the x-axis size of the blocks used for metric calculations. Larger blocks give better noise suppression, but also give worse detection of small movements. Possible values are any power of 2 from 4 up to 2048 (4, 8, 16, 32, ... 2048).
Default: 32 (int)
blocky -
Sets the y-axis size of the blocks used for metric calculations. Larger blocks give better noise suppression, but also give worse detection of small movements. Possible values are any power of 2 from 4 up to 2048 (4, 8, 16, 32, ... 2048).
Default: 32 (int)
batch -
This setting is intended to be used only with mode 5. Basically, it sets some arrays to fake values and disables a few checks allowing for an avisynth script with tdecimate(mode=5, ...) to be loaded when the tfmIn and input files do not have any entries. This is useful and needed for setting up a two pass system in vdub's job control. i.e. you make the first pass and second pass scripts, and then set up both to encode in vdub's job control. NOTE: if you set batch = true and the tfmIn and input files do not have entries for all frames then you will
get borked output!
true - enables fake values and disables checks
false - doesn't
Default: false (bool)
tcfv1 -
Sets the type of timecode format to use for mkv timecode files when they are created in modes 3 and 5. The two format types are those defined and used by mkvtoolnix. verion 1 sets the framerate for frame ranges while version 2 gives the timecode for each frame in milliseconds. See the mkvtoolnix documentation for more info about the two formats.
true - use version 1
false - use version 2
Default: true (bool)
se -
Only used when in mode 3. It will cause TDecimate to throw an error once the 306th padded frame is reached, alerting the user that it has finished, so that time wont be spent processing unneeded frames. This option should not be used when doing batch encoding or something similar, because the error will usually pop-up a window which requires the user to click, thus it would stop any subsequent processing as well.
true - stop early (throw error)
false - don't
Default: false (bool)
chroma -
Sets whether or not chroma is considered when calculating frame difference metrics. Setting this to false can give a speed up... it a quality vs speed setting (though in some cases setting chroma=false can improve operation).
true - consider chroma
false - don't
Default: true (bool)
exPP -
Set this to true if you're using a tfmIn file, have tfm set to PP=1, and are using a separate filter (such as tdeint) to do post-processing based on tfm's combed frame hints. If you don't set this to true when PP=1 in tfm, then tdecimate assumes the interlaced frames marked in the tfmIn file are not being deinterlaced... if this is not the case (they are actually being deinterlaced by a separate filter) then those frames will not be handled correctly.
Default: false (bool)
maxndl -
This setting is used only with mode 2 and stands for "max non-duplicate length". It tells TDecimate the maximum consecutive number of non-duplicates. This info is used when planning the decimation strategy. In normal cases, when duplicates are evenly distributed in the video, it should not be necessary to set this. Only in cases where the length indicated
by the decimation ratio is too short should this need setting. For example, say we have the following pattern in a video:
5 5 7 7 2
where the numbers indicate how many frames there are between duplicates. In this case we want to remove 5 in every 26 frames. This decimation ratio (5/26) would indicate that
there is one duplicate in every 5.2 frames (5/26 = 1/5.2). Obviously, as the pattern above shows, this is the not the case as there are runs of up to 7 without a duplicate. So we would need to set maxndl to 7.
Another example would be decimating a 59.94fps video to 23.976. This ratio would indicate one duplicate in every 1.667 (5/3) frames. However, if the video has sections where two
non-duplicates are back to back then maxndl would need to be set to 2 to correctly handle it.
EXTRA INFORMATION:
While maxndl stands for "max non-duplicate length", it is actually more like a trade off between maintaining video sync and producing a smooth result. The larger maxndl is the more the decimation can be non-uniformly spread throughout the video, which helps the smoothness of the result in cases where duplicates are not evenly spread. Anyways, experiment with increasing maxndl and see what happens.
Possible settings for maxndl are any integer greater than 0.
Default: not set (int)
m2PA -
Will override the default read-ahead maximum of 100 for mode 2. This will allow the one pass mode (metrics not available from an input file) to produce the same results as if the metrics were available.
**NOTE: the cycle size could very well be in the 1000's or 10000's, so there is the possibility setting m2PA=true could mean the processing will stall for quite some time (5-10 minutes or more) when a new cycle starts!!! Please check the largest cycle size that will be used using debug=true before setting m2PA=true!
true = override the default maximum
false = don't
Default: false (bool)
ovr -
Sets the name and path to an overrides file. An overrides file can be used to force ranges of frames to be considered film or video and to specify drop frames or decimation patterns over ranges of frames. For more info on using an ovr file see the OVERRIDES section at the bottom of this file.
Default: "" (String)
output -
Sets the name and path to an output file. The output file will include all metrics caculated. Each line will include a frame number, plus the difference metric, and the scene change metric. This file can be used for input (via the input parameter) on another pass to avoid having to recaculate the metrics or for the mode 5 two pass vfr support.
Default: "" (String)
input -
Sets the name and path to a metrics file to use as input. This file should have been created with the "output" parameter on a previous pass.
Default: "" (String)
tfmIn -
Sets the name and path to an output file from TFM. This option is only useful in cases where hybrid > 0. It means TDecimate wont have to check the actual frames for hints and can result in a very slight speed up. The only case where it is absolutely required is in mode 5!
Default: "" (String)
mkvOut -
This sets the name and path for the mkv timecodes file that is generated in modes 3 and 5.
Default: "" (String)
debug -
Enabling this will make TDecimate output information about its internal states and decisions via OutputDebugString(). You can use a program called DebugView from System Internals:
to view this output. This can be useful in setting thresholds and seeing what is happening. To find out exactly what all it shows you'll have to use it ;)
When mode = 2 and debug=true, TDecimate will spit out the cycle sizes for the series of M-in-N decimations. That output will look something like this:
[1004] mode2_cfs 0 = 7 [1004] mode2_cfs 1 = 7 [1004] mode2_cfs 2 = 14 [1004] mode2_cfs 3 = 56 [1004] mode2_cfs 4 = 392
The last "mode2_cfs # = ##" line shows the largest cycle size being used (the number after the "="). So if you set m2PA=true, and the metrics are not available from an input file, TDecimate will be reading that ## frames (392 in the above case) ahead in the video stream, and will have to process those many frames at each cycle boundary!
default: false (bool)
display -
Outputs almost exactly the same information as debug, but draws it on the actual frames in the upper left hand corner. This is usually easier to read and use then the debug output. To find out exactly what all it shows you'll have to use it ;)
default: false (bool)
An overrides file can be used to manually set drop frames, declare video/film sections, or specify decimation patterns over ranges of frames.
specifying video cycles:
To specify a range of frames for TDecimate to consider video... first, enter the starting frame number, then put a comma (","), then enter the ending frame number, and finally put a "v" as the specifier. This range is inclusive, meaning that the starting and ending frame numbers will be counted as video! Remember that video sections are only considered when hybrid > 0!
example: 10,334 v
specifying film cycles:
Same as video but use "f" as the specifier. Doing this will only make a difference when using hybrid > 0 and detecting video sections. In all the other modes everything is considered film to begin with.
example: 10,334 f
specifying drop frames:
To specify a drop frame enter the frame number you want to drop and put a "-" specifier. If you manually specify more then cycleR drop frames for one cycle then the ones that come
first chronologically will be used. If using mode 2, and not an M-in-N decimation mode, the same restriction applies, but instead of cycleR being the limiter it is an internally computed number.
example: 226 -
specifying a decimation pattern:
Use the drop frame specifier along with keep frame specifiers (+) as place holders.
example: 10,334 +-+++
In this example every 2nd frame will be dropped starting at frame 10 and going to frame 334.
EXTRA NOTES:
1.) If you specify overlapping entries then the entry that comes last in the ovr file will be used.
2.) All frame number entries correspond to the frame numbers in the input clip (i.e. the input into TDecimate). They do not correspond to the frame numbers after decimation (this is the cause of a lot of headaches).
3.) You can only give cycleR drop frames per cycle. If you specify more then that, then the first cycleR worth specified will be used.
06/25/2005 v0.9.9.2
+ Added mode 6 (120fps -> vfr w/ timecodes file).
05/24/2005 v0.9.9.1
+ Added iSSE optimizations for default metric calculation path (32x32 blocks + nt<=0 + mod 16 width and height).
05/18/2005 v0.9.9
+ First cut at new mode 2 operation.
+ Added maxndl/m2PA parameters, goe with mode 2.
04/19/2005 v0.9.8.3
+ Added exPP parameter, fixes handling of interlaced frames marked in tfmIn files when PP=1 in tfm and an external post-processor is used to deinterlace the combed frames.
- Fixed crash caused by above circumstances.
03/13/2005 v0.9.8.2
+ Added missing logic to most similar decimation mode. It can now correctly handle panning->static and static->panning areas like longest string. It can also detect cycles that need two duplicates dropped. Assuming match info is present.
+ Tweaked decimation decisions for both longest string/most similar. These are the decisions that use the extra info such as match info and d2v rff info from tfm.
+ Added isse luma diff calculation routine for yuy2.
- Fixed a bug in the longest string decimation decision that utilized match info from tfm.
03/10/2005 v0.9.8.1
+ Scene change metrics are calculated using only luma, regardless of the chroma option.
+ There can only be one change above sceneThresh within the current cycle as well as the surrounding two cycles for it to be detected as a scene change (as long as cycle length
is 10 or less).
+ D2V rff duplicate info is taken into account when deciding what frames to drop, instead of only for hybrid detection.
+ When hybrid > 0 and concycle or concycleTP is greater then 1, single cycles that are detected as video and that have a scene change detected in them are treated as video.
02/19/2005 v0.9.8
+ Most similar decimation mode now takes duplicate via match info into account.
+ Match duplicate info and d2v duplicate info is shown with debug/display options.
+ rff info from d2v option in tfm is now taken into account when doing hybrid detection.
+ Increased the maximum possible cycle value to 300.
01/08/2005 v0.9.7.2
- Fixed SetCacheHints being called incorrectly and always defaulting to CACHE_ALL.
- Small change to protect against overflow with 1.0 weight when blending frames.
01/04/2005 v0.9.7.1
+ Improved longest string decimation algo by having it look for an obvious duplicate case based off matches/metrics.
01/03/2005 v0.9.7
- Fixed mode 4 display output saying "mode 3" instead of "mode 4".
+ Added chroma parameter.
+ mode 4 display and debug output now display the sceneChange metrics along with the block difference metrics.
01/02/2005 v0.9.6.2
- Fixed incorrect setcachehints call due to checking the value of the wrong argument.
+ Faster and more accurate mmx/sse2 blending routines, thanks to Leak.
+ Optimized the metric calculation routines. Exactly how much of a speed increase is dependent on the source being processed.
+ Some other optimizations and internal changes.
12/22/2004 v0.9.6.1
- Fixed a problem with timecode file generation that would occur in mode 5 with tcfv1 = true. If the cycle following a cycle that needed 2 dups removed was detected as video then
an erroneous line would be written to the file.
- Fixed not initializing mkvOutF file handle.
12/19/2004 v0.9.6
- Fixed not differentiating between c matches and deinterlaced frames when hybrid > 0 and checking for dups via matches.
- Fixed crash with debug=true and large cycles (> 50) due to too small of a string buffer.
- Changed default sceneThresh to 13.
- conCycle and conCycleTP now default to 1 when vidDetect = 3 and still default to 2 when vidDetect != 3.
+ Added handling for cycles around scene changes which need 2 dups removed.
+ Some other internal changes.
12/14/2004 v0.9.4
- Fixed problems with longest string decimation and static to panning and panning to static scene workarounds in longest string decimation.
+ added se parameter (causes mode 3 to stop early once the last actual frame is delivered).
+ mmx and sse2 blending routines now work with any width (not just mod 8 and mod 16).
12/07/2004 v0.9.3
- fixed outputting of extra timecode entries when using tcfv1=false (v2 format) in mode 3 or mode 5 and the last frame was not a cycle boundary.
- fixed incorrect formatting of the first 2 lines of the mkvOut file when in mode 3 and using tcfv1=false (v2 format).
+ added mmx and sse2 blending routines (used when hybrid = 1)
11/30/2004 v0.9.2
- fixed mishandling of the last cycle of a clip when in mode 3 and the last cycle was film.
- removed a mode 5 specific vidDetect = 3 action that wasn't suppose to be there.
+ write blockx and blocky sizes into tdecimate metric log files.
+ timecode v2 format support.
11/28/2004 v0.9.1
+ Added batch parameter.
+ Added crc checking of input/output files to make sure that a file loaded via the input parameter actually goes with the current video.
11/27/2004 v0.9
- Initial release.
$Date: 2005/07/10 16:11:01 $