View Single Post
Old 2nd November 2005, 19:07   #405  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
Quote:
I could actually encode with the previous version, but it didn't honor the Trim, as I found out much to my chagrin. However, using the new version, this doesn't open in VDubMod:

Trim(450,0)
TFM(d2v="K:\Samurai Rebellion\4-1 Movie\Movie.d2v",PP=0)
TDecimate(mode=0)

The message is, "D2V frame count doesn't match filter frame count!"
Previous to this version tfm didn't require that the number of frames it had info for from the d2v file actually matched the input frame count. Instead, it simply used the first frame count number of entries (if the d2v had more) or it used nothing for the extras (if the d2v had less). That wasn't a very good solution, but it did stop tfm from crashing when filling the d2v info array if the d2v had more info. With the addition of the trimIn parameter I decided to require that the frame info from the d2v file match the input frame count (that is where the new error msg comes from). The whole reason that the trim before requires special support is that tfm has no way to determine if a trim statement actually came before it or not.

Quote:
This does open and encodes properly:

TFM(d2v="K:\Samurai Rebellion\4-1 Movie\Movie.d2v",PP=0)
Trim(450,0)
TDecimate(mode=0)
Trimming after tfm is a viable option, the only thing it messes up is that when TDecimate gathers the hint information from tfm it assumes that the incoming frames are in the same order as when they came out of tfm. For example, to determine duplicates via matches tdecimate looks at the frame matches delievered by tfm. It uses that info to see if the same field has been used in two frames in a row... i.e. if the current frame match is 'p' and the previous match was 'c' (and neither match was marked as combed and deinterlaced) then there was a repeated field. If you use trim() before tdecimate then those assumptions are no longer correct for the first frame after the cut position. TDecimate also considers rff duplicate info that is passed by tfm, and that information would also be incorrect for the first frame following a cut. Currently there is no way to disable tfm's hinting or to force tdecimate not to use the information if it sees that it is present.

Changing your script to use trimIn would work like this:

TFM(d2v="K:\Samurai Rebellion\4-1 Movie\Movie.d2v",PP=0,trimIn="trim.txt")
TDecimate(mode=0)

with trim.txt containing the following line:

0,449

Here 0,449 is marking the frames that were cut out (inclusive).

Last edited by tritical; 2nd November 2005 at 19:10.
tritical is offline   Reply With Quote