TDeint and TIVTC

[Chainmax]

You were right, it's a DGIndex problem :).

[Guest]

You were right, it's a DGIndex problem :). Is there really a problem with DGIndex, or are you just trying to combine incompatible tool versions?

[Chainmax]

I was agreeing with him, and he didn't mention that DGIndex itself has an issue. I just phrased myself wrongly, sorry about that.

[tritical]

Here is [link removed], it supports dgindex v10 d2v files.

[Chainmax]

Works like a charm :).

[tritical]

Unfortunately, development on TIVTC/TDeint has slowed a lot due to my being busy and working on other projects, but I did have some free time earlier today so here is [link removed].

This version adds a new field matching mode to tfm (mode 6, so it doesn't change any previous mode numbers), and the ability for tfm to field match off the d2v flags (can be only in 0123, a.k.a film to dvd2avi/dgindex, sections or completely). With the addition of the d2v matching to tfm, tfm/tdecimate can now do ivtc completely off the flags in properly flagged sections. The decimation is not 100% strict to allow for hopefully better handling. How it works is tfm passes on the duplicate info, which is figured by taking into account the rff flags and the actual matches used, to tdecimate. TDecimate then checks that that frame's metric is indeed <= to the lowest metric in the cycle (which it should be) and that there is only 1 d2v duplicate in the cycle. If those conditions aren't met then it uses it regular handling. Field matching off the flags gives a very large speedup since no calculations have to be done.

Also, I finally went through and changed all the setcachehints calls for all filters in tivtc.dll to use a diameter instead of radius... so depending on script complexity it could give a pretty good speed up for most people.

Any feedback on the d2v flag based matching would be helpful, especially if it doesn't work correctly. I tested it a good bit, but the only material I have atm is either 100% film or 0.0% film, nothing that is split. I also have been doing some work on improving the field matching algorithm, and would be very grateful for sample clips that have matching problems (ideally where a good match exists between the normal matches - p/c or n/c).

Full change list:
TFM: Added new match mode (mode 6)
TFM: Added field matching from d2v file
TFM: Added "flags" parameter to control how d2v info is used or not used
FieldDiff: can use sse instead of sad
ALL: setcachehints diameter instead of radius

[BangoO]

tritical, what's the advantage of matching off d2v flags, only speed ?
How much faster is it ?

Thx ;)

[tritical]

The advantage is speed and also not risking incorrect matches due to mistakes by tfm's matching algorithm. The same reasons why it is recommended to use force film vs using an auto ivtc method when dvd2avi/dgindex report 100% film or a very high percentage film. In my tests on the movie castaway tfm ran about 6 to 7 times faster than when it had to actually calculate matches. In terms of raw numbers it jumped from about 130-150 fps to 1000-1100 fps. In cases where dvd2avi/dgindex report 100% film there is still no advantage to using tivtc, but in cases where it is <100 you get the benefit of flagged ivtc in most of it (assuming it all works correctly of course :D) and intelligent handling in the rest. TIVTC will still be slower than force film since tdecimate still does metric calculations, but tdecimate is extremely fast now for material that is mod 16 width/height since the isse optimized code for that path was added.

[BangoO]

Ok tritical, I'll give it a try then.
I'm just a bit "scared" to change my encoding method as the tfm I use is just so perfect right now... (TIVTC v0.9.7.2).

My concern is on sources that are supposed to be 99% "0 1 2 3" but which contain some drops in this sequence most of time caused by bad recording (something like "0 1 2 3 0 1 3 1 2 3", that's only an example).
In these cases, TIVTC v0.9.7.2 is just perfect... what about the new one ?

[tritical]

@All
Another new version: [link removed]. It adds a second slower matching fuction. The "slow" parameter is now an int instead of bool. The default is 1 so it uses the same matching function as previous versions with slow=true. Slow=2 may perform better in some cases where slow=1 fails.

@BangoO
It should behave exactly the same just going off what you gave as info. In the sequence "0 1 2 3 0 1 3 1 2 3" tfm would do field matching off the flags for the 0 1 2 3 0 1 then use its own comparisons for two frames where the fields from the 3 are and then go back to using the flags. TDecimate would get that info, but like I described before it will fall back into its own processing when it encounters more than one d2v marked duplicate in a cycle or on other strange scenarios.

Back in v0.9.7.2 of TIVTC (January 8, 2005) nothing was implemented as far as using d2v info, all it did was check for illegal transitions and the field order. You can get that same behavior with the current version by settings "flags=3" in tfm(). "flags=0" sets the behavior to what it has been doing since v0.9.7 of tfm (february 19th, 2005) up to now. That is check for illegal transitions/field order as well as pass rff info on to tdecimate to help duplicate/hybrid detection.

The current behavior with "flags=1" (which is the default)... is that it does all that flags="0" does plus in 0123 trf flag sections it does the field matching based off the flags. One thing I didn't mention before was that when it does matching off the flags it also disables the post-processing check and just assumes the match is not combed to prevent bad post-processing decisions. Atm this is not completely finalized as it needs more testing to see how well it works on a larger number of sources.

[Chainmax]

Good to see that TIVTC is still being worked on :). If you need a trouble clip for testing, you could download my Simpsons clip (http://www.31012.com/~azulftp/TestClip.vob). DGIndex reports it as NTSC, mostly interlaced with a few progressive spots. I have a couple of questions: first of all I'd like to know the difference between mode6 and mode3 (or match on combed and match (same order) on combed, for that matter). Also, I am going to try the following line on an encode:

TFM(d2v="X:\wherever\myd2v.d2v",mode=3,PP=7,slow=2,mChroma=true,chroma=true,mi=50)
TDecimate(mode=1)

That uses the default flags=1, but I'm using DeDot (dotcrawl remover) before TIVTC, that shouldn't screw up the flag switch operation, right? Also, if I understood correctly, the flags switch assumes that the source was correctly flagged, what could happen if it isn't and the flags switch is used?


P.S: if you download the Simpsons clip, could you confirm if the windows frames on the scene where Homer parks the car move up and down?

[Mug Funky]

@ tritical:

One thing I didn't mention before was that when it does matching off the flags it also disables the post-processing check and just assumes the match is not combed to prevent bad post-processing decisions.

this would be a reasonable assumption... any encoder that wrongly flags the stream with RFF etc would be giving glitchy output anyway (occasional jitters), and i wouldn't consider it TFM's job to fix this, as i've never heard of it happening (though theoretically it could happen on a 2-pass hardware encode when the playback deck glitches on the 1st pass but not the second, or other weird things like that. to be honest i don't know at what point the 3:2 detection happens in hardware encoders, but i imagine it happens on both passes).

[BangoO]

@BangoO
It should behave exactly the same just going off what you gave as info. In the sequence "0 1 2 3 0 1 3 1 2 3" tfm would do field matching off the flags for the 0 1 2 3 0 1 then use its own comparisons for two frames where the fields from the 3 are and then go back to using the flags. TDecimate would get that info, but like I described before it will fall back into its own processing when it encounters more than one d2v marked duplicate in a cycle or on other strange scenarios.

Back in v0.9.7.2 of TIVTC (January 8, 2005) nothing was implemented as far as using d2v info, all it did was check for illegal transitions and the field order. You can get that same behavior with the current version by settings "flags=3" in tfm(). "flags=0" sets the behavior to what it has been doing since v0.9.7 of tfm (february 19th, 2005) up to now. That is check for illegal transitions/field order as well as pass rff info on to tdecimate to help duplicate/hybrid detection.

The current behavior with "flags=1" (which is the default)... is that it does all that flags="0" does plus in 0123 trf flag sections it does the field matching based off the flags. One thing I didn't mention before was that when it does matching off the flags it also disables the post-processing check and just assumes the match is not combed to prevent bad post-processing decisions. Atm this is not completely finalized as it needs more testing to see how well it works on a larger number of sources.
Ok thx for the explanations, I'll give it a try...
I'll try TDecimate as well, I never used it as it was a lot slower than Decimate from the Decomb filters...
Is it a problem if I keep on using Decimate instead of TDecimate (if it is still faster) ?

[BangoO]

I'm having surprising speed results...
I encoded 1000 frames with the following configurations:
Option 1: TFM 0.9.9.5 + Decimate
Option 2: TFM 0.9.7.2 + Decimate
Option 3: TFM 0.9.9.5 + TDecimate

The script was the following:
Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\mpeg2dec3.dll")
Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\TIVTC\TIVTC.dll")
mpeg2source("G:\pouet.d2v")
cropbottom(8)
TFM()
Decimate() # or TDecimate() for option 3
LanczosResize(1280,720)

Here are the results...
Option 1: TFM 0.9.9.5 + Decimate -> 226s
Option 2: TFM 0.9.7.2 + Decimate -> 220s
Option 3: TFM 0.9.9.5 + TDecimate -> 273s

The source is a 100% FILM source, so TFM 0.9.9.5 should have been faster than TFM 0.9.7.2, but maybe I used wrong parameters (all defaults)...
Moreover, TDecimate is still a lot slower than Decimate.

PS: I didn't compare the results, but the size of the 3 result files are exactly the same (19 869 696 bytes) so one can assume the result is the same...

[tritical]

@BangoO
For tfm to do matching off the flags and get a speed benefit you have to specify the d2v parameter... tfm(d2v=""). If you don't then there will be no difference speed wise between tfm from v0.9.7.2 and v0.9.9.5.

The reason TDecimate is slower than decimate is because of the cropbottom() you have there. It prevents the isse code from being used due to the height not being mod 16 anymore so the c code is used. The c code for tdecimate will be slower than decimate due to the extra processing it does. The isse code is definitely faster than decimate by a good bit (2x or more).

[BangoO]

@BangoO
For tfm to do matching off the flags and get a speed benefit you have to specify the d2v parameter... tfm(d2v=""). If you don't then there will be no difference speed wise between tfm from v0.9.7.2 and v0.9.9.5.
Ok i'll try again then ;)

The reason TDecimate is slower than decimate is because of the cropbottom() you have there. It prevents the isse code from being used due to the height not being mod 16 anymore so the c code is used. The c code for tdecimate will be slower than decimate due to the extra processing it does. The isse code is definitely faster than decimate by a good bit (2x or more).
Ah nice, I'll definitely try again :D

[BangoO]

And here are the results :D

Option 1: TFM 0.9.9.5 + Decimate -> 146s
Option 2: TFM 0.9.7.2 + Decimate -> 220s
Option 3: TFM 0.9.9.5 + TDecimate -> 110s :cool:

PS: the following script has been used:
Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\mpeg2dec3.dll")
Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\TIVTC\TIVTC.dll")
mpeg2source("G:\pouet.d2v")
TFM(d2v="G:\pouet.d2v")
Decimate() # or TDecimate() for option 3
cropbottom(8)
LanczosResize(1280,720)

[tritical]

@Mug Funky
this would be a reasonable assumption... any encoder that wrongly flags the stream with RFF etc would be giving glitchy output anyway (occasional jitters), and i wouldn't consider it TFM's job to fix this, as i've never heard of it happening (though theoretically it could happen on a 2-pass hardware encode when the playback deck glitches on the 1st pass but not the second, or other weird things like that. to be honest i don't know at what point the 3:2 detection happens in hardware encoders, but i imagine it happens on both passes). That is good to know. The whole matching off the flags rests on the assumption that the encoded frames in the mpeg stream are progressive. That seems highly likely when there is a 0123 pattern, but if there have been long breaks in the pattern somewhere earlier there is the possibility for strangeness. For example, I once saw a stream that had some sections with 0123 and other long sections of just 2222... in the middle of the stream there was a short section looked like this (where it transitioned from a run of 2's into 0123):

x a b c d <= mpeg frame
a b c d e

0 1 2 3 0 <= trf flags

So it was flagged with 0123, but the actual frames were offset by a field... in such a case the matching off flags would fail. I think that was from an hdtv capture that had bitstream errors from transmission or something cause it also had many illegal field order transitions so it is probably not a normal occurence.

[tritical]

@BangoO
That is better :). The results were still the same hopefully?

[BangoO]

Seems so... the file sizes are still exactly the same, and I also checked some frames, it seems identical.
I will have to test it on a bad flagged material now...

Thx for your great work tritical ;)

[tritical]

@Chainmax
I have a couple of questions: first of all I'd like to know the difference between mode6 and mode3 (or match on combed and match (same order) on combed, for that matter). The difference between mode 3 and mode 6 is only the order in which the extra matches are tried if the original two candidates are combed. First, a little explanation about the same order thing...

Assume you have a tff clip. Based on the field order the only matches that should work are p/c if you match off the top field or c/n if you match off the bottom field. So if field=1 in tfm (matching off top field) then p/c should be the best choices... if both result in combed frames, the next choice that has the best chance of making a good frame is u (u off top field == n off bottom field). So match same order simply means that it will try the match that makes since field order wise first when the main two matches are combed. Mode 3 doesn't go for the field order wise match first, but goes for the only remaining match that would still match off the same field (either p or n, whichever wasn't tried before). Both strategies have advantages and disadvantages. The u match has a more likely chance of being a good match, but it will create a duplicate because if u works it means the next frame is a p match. The n or p match is less likely to be a clean match (actually, it will only work if there is no motion), but it wont create a duplicate in a scene with motion. For example, in a lot of anime there are pulldown pattern changes at almost every scenechange due to edits and that also means that at quite a few scenechanges there is an orphaned field. In most circumstances, using the same order on combed mode will find a good match but it will create a duplicate... while the n or p match won't do any good at all. That difference is kind of moot in modes 3 and 6 since both end up trying all 5 matches if no good frame is found.

I think the best explanation for the modes if from the readme:

0 = (p/c)
1 = (p/c + n)
2 = (p/c + u)
3 = (p/c + n + u/b)
4 = (p/c/n)
5 = (p/c/n + u/b)
6 = (p/c + u + n + b)

a "/" means it will compare the matches to see which one is best, a "+" means if the previous matches are detected as combed then it will try the following match(es) and if the follwing match(es) are good then it will take it else it will drop back and use the best of the original two matches. One thing that has to be known is that tfm is only capable of comparing two matches if they are both being matched off the same field... i.e. it can compare p to c to n and u to b, but it can't compare u to p/c/n or b to p/c/n and vice versa. So to walk through modes 3 and 6:

mode 6 compares p to c and checks the best match to see if it is combed. If it isn't then it takes it else it creates the u match and checks it. If u isn't combed then it takes it, else it creates the n match and checks it. If n isn't combed then it takes it else it creates the b match and checks it... takes b if it is good else it drops back uses the best between p/c and runs post-processing on it.

mode 3 compares p to c and checks the best match to see if it is combed. If it isn't then it takes it else it creates the n match and checks it. If n isn't comed then it takes it, else it compares u to b and then checks the best match to see if it is combed... if it isn't then it uses it else it drops back and uses the best between the original two matches (p and c) and runs post-processing on it.
That uses the default flags=1, but I'm using DeDot (dotcrawl remover) before TIVTC, that shouldn't screw up the flag switch operation, right? Also, if I understood correctly, the flags switch assumes that the source was correctly flagged, what could happen if it isn't and the flags switch is used? Using dedot before is fine. The only problem that could happen with flags=1 is if you have a very strange stream that has 0123 flagging on non progressive frames. That situation should be rather rare as the whole point of using rff flags in that way is so that only the original progressive frames have to be stored.

[DarkNite]

After that explanation I'm just itching to see how mode 6 handles some of the more interesting scenechanges in older anime captures that have been sitting in my "waiting for manual edit" bin.

[Chainmax]

I don't know if this will be useful, but here are two screenshots from a specific frame (both use TIVTC v0.9.9.5):

Script 1:
MPEG2Source("X:\wherever\SimpTest.d2v",cpu2="ooooxx")
DeDot()
TFM(d2v="X:\wherever\SimpTest.d2v",mode=3,PP=7,mChroma=true,chroma=true,mi=50)
TDecimate(mode=1)
FixChromaBleeding()
LumaYV12(lumoff=-2,lumgain=1.0)
ColorYUV(levels="pc->tv")
FunkyDeblock()
VagueDenoiser(nsteps=6,chromaT=0)
HQDering()
aWarpSharp(depth=16,cm=1)
Crop(12,0,700,476,align=true)
BicubicResize(640,480,0,0.5)
BlindPP(quant=0,cpu=0,cpu2="ooooxx")
LimitedSharpen()
Result:
Link Removed



Script 2:
MPEG2Source("X:\wherever\SimpTest.d2v")
DeDot()
TFM(d2v="X:\wherever\SimpTest.d2v",mode=6,PP=7,slow=2,mChroma=true,chroma=true)
TDecimate(mode=1)
FixChromaBleeding()
FunkyDeblock()
HQDering()
Crop(12,0,700,476,align=true)
BicubicResize(640,480,0,0.5)
Unfilter(-20,-20)
LimitedSharpen()
Result:
Link Removed

[tritical]

Hm, it is hard to gather anything from that without the debug or display output or preferably both. One thing that matters when trying the extra matches is the combed frame detection is not very sensitive to really small areas of combing... so if it tries n and it has only a tiny bit of combing it might use it while match u could be completely clean. That is the real tradeoff to trying matches in different orders... the first ones tested have a higher chance of being used.

One option that should be added soon is to only allow u/b matches at scenechanges, which should work well with the orphaned field situation I described above.

[Chainmax]

I'll upload these screenshots again, this time with the debug and display output info, but would those explain the missing star in the second screen?
Also, could you please confirm wether TIVTC causes the issue I mentioned a couple of posts ago?

[Chainmax]

The star now appears with the second script :confused:. I must have screwed up somewhere.

[tritical]

Hm, if using mode=1 in tdecimate you'll have to run straight through the clip to get to that point cause mode 1 results can be different when seeking. Since it is only tfm that differs would it be possible to eliminate the rest of the script for the moment? Determining what exactly happened to cause the difference in the full script would probably require the tdecimate debug output as well.

I suspect the reason the star is gone is just because tfm used a different match in the two different modes, but the debug output will tell for sure.

I downloaded the clip, but didn't notice any window moving when he parks the car. You are talking about the part right around frame 450 correct?

[Chainmax]

I was using the "Go to" option, so it must have been the seeking issue then, because the window now appears. Thanks for the reply.

The problem in the indows should be somewhere between frames 320 and 400 after IVTC. The source doesn't display such problems. The problem was mainly caused by aWarpSharp, but I think in this case TIVTC might have contributed a bit which is why I'm asking you to double-check for me since I'm not 100% sure after several tests.

[tritical]

If it did I am either too blind to see it or am not looking for the right thing cause I don't see anything.

[Chainmax]

Do you know those times when you have a computer related issue and when you try to show it to someone else it goes away? That's what happened to (yet another time) here. First the "missing star", now this :o. I feel really stupid, sorry for wasting your time like this :(.


P.S: I didn't notice any difference at first glance when using the flags switch, but then again I'm not too perceptive at that sort of things. What were your impressions on how d2v flag based matching handled the clip?

[Moitah]

Does anyone else see a bunch of green stuff when using TDeint(type=1) with TDeintv1b3? Source frame (http://www.moitah.net/misc/nat-src.jpg), After TDeint(type=1) (http://www.moitah.net/misc/nat-tdeinttype1.jpg) (Sorry they are a bit blurred from the JPG compression)

[tritical]

Yep, it is a bug in YUY2 type=1 chroma interpolation... forgot to change three lines when ap was added in beta 3. All the YV12 routines and all the other YUY2 routines are ok. I'll try and fix that soon. Thanks for reporting.

[acrespo]

Can I trim video before use TFM with flags= 0 to 2 like this:

mpeg2source("smx.d2v")
Trim(449,32701)++Trim(35087,47956)
TFM(d2v="smx.d2v",mode=3,pp=7,slow=2,chroma=true,flags=3)
TDecimate(mode=1,hybrid=1)

[tritical]

You can, but it wont work correctly :D. For flags=0 to 2 there can't be any modification of the # of fields or the order of those fields between mpeg2source() and tfm()/tdecimate(). flags=3 as you have now will work ok though. If you want to use flags=0,1, or 2 you would need to move the trim to after tdecimate.

[tritical]

Here is [link removed].

This version adds a hybrid=3 option to tdecimate which is similar to hybrid=1 except that instead of leaving 24p sections untouched and blend converting 30p sections to 24p, hybrid=3 leaves 30p sections untouched and blend converts 24p sections to 30p. This version also adds isse optimizations for more blocksizes for tdecimate's metrics calculations. The last addition is a new parameter called "sco" to TFM which can be used to allow u/b matches only at scenechanges (good for dealing with the case of orphaned fields that only appear at scenechanges due to edits). The only thing left on the todo list for tivtc at this point is optional blending in mode 2 of tdecimate.

[tritical]

Here is [link removed].

Changes:
- SetCacheHints call to diameter instead of radius
- Fixed type=1 YUY2 interpolation routine giving messed up chroma output
(bug was introduced in v1.0 beta 3)

[Leak]

The last addition is a new parameter called "sco"[...]

Sure beats writing "Litigious Bastards" (http://www.sco.com/)... ;)

Anyhow, I'd have one request for TIVTC - while blending 30FPS sections down to 24 works fine, I've found that some of the CGI car scenes in GITS:SAC were oddly enough rendered in 15FPS, i.e. every frame is shown twice.

The problem here is that TIVTC decimates these scenes since it thinks it's material that had pulldown applied to it, and thus introduces jerkiness. Would it be possible to check if every other frame (or probably 2 out of 3 and 3 out of 4 frames) is a duplicate and in that case treat this scene as video instead of film?

Yeah, I know it's a rather odd case, but it exists nonetheless... :(

np: Richard Devine - Arc-Acid (Cautella)

[scharfis_brain]

Well, as I asked before:is it possible to code a mode switcher?
(modes: Film, 30p, 60i)

like this pseudo-code for standards conversion:


mpeg2source("NTSC-Hybrid.d2v")

a=bob().convertfps(50) # 60 to 50
b=telecide().changefps(50) # 30 to 50
c=telecide().decimate().changefps(50) #24 to 50
T-Switch(last,a,b,c)
resize(width,576)
assumetff().separatefields().selectevery(4,0,3).weave()

[Leak]

Well, as I asked before:is it possible to code a mode switcher?
(modes: Film, 30p, 60i)

like this pseudo-code for standards conversion:
Wouldn't that have the problem that there could be discontinuities at the points where the mode is switched? I.e. a frame might be repeated since both the film and 30P stream considered it essential at that spot, or a frame might be skipped for similar reasons; which could be prevented by a single filter that handles everything.

np: Jah Wobble - Fly 2 (I Could Have Been A Contender (Disc 1))

[scharfis_brain]

this could maybe be avoided by checking, which of the new rendered frames is closer to the before chosen one...

[tritical]

@Leak
Could you send me a sample from gits:sac to test on? Such cases are indeed not handled correctly with vidDetect=3. You would probably be better off using vidDetect=0 or possibly vidDetect=2, but I doubt it will fix everything.

@scharfis_brain
It is possible of course, but I've already got a lot to do on my existing filters and I have no material to test on that is a mix of 24p/30p/60i. Would you be able to send some samples?

[Leak]

@Leak
Could you send me a sample from gits:sac to test on?
Sure... give me a minute or five... :)

Here it is. (http://leak.no-ip.org/AviSynth/Stuff/GITS_SAC_02_Funny%20Framerate.m2v)

Actually, after taking a closer look at this sequence it's not simply 15 FPS animation, but something quite strange... :confused:
Such cases are indeed not handled correctly with vidDetect=3. You would probably be better off using vidDetect=0 or possibly vidDetect=2, but I doubt it will fix everything.
I doubt doing that for maybe 15 seconds of footage (if even) for a 24 minute episode is worth it...

np: Jah Wobble - Fly 2 (I Could Have Been A Contender (Disc 1))

[tritical]

I looked at the clip and to me it looks like plain 12fps animation. After field matching there is a 3 frames (1 new + 2 dups) followed by 2 frames (1 new + 1 dup) pattern and mode = 1 with tdecimate handles it fine. It did have some irregular rff flagging so using d2v="" in tfm with flags = 0, 1 or 2 lead to incorrect decimation in a couple cycles where mode=1 w/o the rff info picked the correct frames to decimate. I went ahead and added in some extra logic to prevent mode=1 using d2v dup info in such cases.

Here is the result (xvid const quant 2) after using the following script:

mpeg2source("C:\gits.d2v")
tfm(d2v="C:\gits.d2v")
tdecimate(mode=1)

gits clip (http://bengal.missouri.edu/~kes25c/gitstest.zip)

[Mug Funky]

yeah. GITS SAC sticks to 24fps all through except in the last couple of episodes, and the japanese intro sequence (which comes out slightly jerky in the PAL version due to decimation). i think towards the end of the show some shortcuts were taken in editing, so there's a mix of pure 24p and some 30p. but i can only say this based on the PAL conformed version (which has some full-frame blending in it on the last tape that wasn't on any of the others!).

kinda makes me wish there were a way to get the best of all worlds in standards-conversion. speed up the film bits, blend the 30p and 60i bits to 50i, and encode interlaced.

It is possible of course, but I've already got a lot to do on my existing filters and I have no material to test on that is a mix of 24p/30p/60i. Would you be able to send some samples?

the intro to Gantz has all three types of content. anywhere you want it uploaded? i'll grab it tomorrow (at home now...).

[tritical]

@Mug Funky

68.119.245.113
port 17252
upload/upload

If that wont work just pm me.

I've seen the intro sequence for the first gits:sac r1 dvd and it has 30p, but I think most of the actual ep is 24, if not all, though I couldn't guarentee it.

[scharfis_brain]

@MugFunky: DEFT converters can do this. (I don't know what their price is)
but they are still inperfect, because they are deinterlacing and blending the 30p to PAL
.
I prefer fieldmatched 30p, which has became telecined (changefps) to PAL.

[tritical]

[link removed]

Changes:
TDecimate:

+ mode=1 w/ d2v info and hybrid=3 decimation improvements

[B.F.]

New DGMPGDec is out.
d2v opinion don't work now.

[tritical]

Support will be added in the next release, but I am working on adding some other features so it won't be out immediately. For now, to use the d2v option with v11 d2v files just make a copy of the d2v file and in the copy change the very first line from:

DGIndexProjectFile11

to

DGIndexProjectFile10

and use that copy as the file for the d2v argument in tfm(). The only change in v10 to v11 was removing a number before the path entries and that wont make any difference to tfm's d2v parsing/reading.

[Mug Funky]

I've seen the intro sequence for the first gits:sac r1 dvd and it has 30p, but I think most of the actual ep is 24, if not all, though I couldn't guarentee it.

all of it except the last 2 episodes. don't know why it went that way (deadlines in production?).