TDeint and TIVTC - Page 46

tritical · 24th January 2007, 16:59

Thought I had fixed that back in October

. Is your script just the basic:

mpeg2source()
tfm(input="")
tdecimate(input="",tfmIn="")

?

Isochroma · 24th January 2007, 19:38

Just noticed that b13 of DGIndex came out. One of the changes listed is:

* The Correct Field Order option is removed and the field order correction function is now available through the Tools menu: Fix D2V. I did this because this correction should not be applied to streams with frame repeats, and trying to prevent it via a code check runs into technical complications.

Will a wrong field order have any effect on TIVTC?

ChiDragon · 25th January 2007, 02:39

Oh, I didn't know I had to use tfmIn for it to work! Sorry about that. It makes sense considering it would need to grab every frame to get the hints otherwise. The only mention I see of that in the TDecimate readme is in the Changes List section. Maybe you should add it to the tfmIn description for us dummies.

(right now it says that it's only useful for hybrid > 0)

I get an invalid specifier error when trying to use tfmIn for files output with PP=0 in TFM though.

tritical · 25th January 2007, 19:00

@Isochroma
If you use the d2v="" parameter in tfm, then it checks for illegal field order changes in the d2v (wont work with frame repeats, but tfm shouldn't be needed on those streams)... so it wont matter there. If you don't use the d2v parameter, use a matching mode that can't handle field order changes (only modes 4 and 5 can), and the stream does have field order changes, then there will be a problem.

@ChiDragon
An explanation in the tdecimate readme is probably a good idea. Another way to get around the need for the tfmIn file is to set hints=false in tdecimate. However, then tdecimate wont get to use any info from tfm. The basic chain of events when tdecimate runs is:

startup:
0.) If hints isn't manually set by the user, then grab frame 0 and detect if there are hints in it. If there are, set hints=true, else, set hints=false.

during operation:
1.) If there's a tfmIn file, don't read hints for frames that the tfmIn file has info for.
2.) else if hints=true, reads hints for frames that don't have info from a tfmIn file.
3.) else if hints=false, never read hints

I'll check out the problem with the pp=0 files.

tritical · 29th January 2007, 09:46

Found and fixed the problem with tdecimate reading tfm output files created with pp=0. I'll put up a new version soon (a work around would be to just use pp=1 in tfm, though it will be slightly slower than pp=0 depending on the matching mode). I am also considering changing the sdlim default in tdecimate so that when cycleR > 1 it defaults to the largest possible value such that there would never be any cases where it couldn't mark a full cycleR worth of frames. I'm thinking that when someone uses cycleR>1 they are generally looking for the decimation to be spread throughout the cycle as sdlim allows instead of actually removing the cycleR frames with the lowest metric (which could all be next to each other).

ChiDragon · 30th January 2007, 07:28

Thanks! Yeah, I've been using PP=1 in the meantime.

I'm not sure defaulting sdlim to the largest possible value is a good idea. With the videos I'm encoding now that need sdlim=2, setting sdlim to 3 (or -3) makes TDecimate drop non-dups often. Actually, it drops wrong frames every cycle, but most of them don't matter as it's simply dropping the first of two same-frames (they're only "wrong" since you'd normally want to drop the 2nd frame, with the low metric). The trouble comes at the start and end of the cycles, where it may drop an actual dup at the end of a cycle and then drop a new frame at the start of the next cycle.

ChiDragon · 1st February 2007, 04:27

I've got a weird crash happening now... I'm using this ovr line:

Code:

80194,80303 ++-++-++++-++++-++++-++++-++-++++-++++-++++-++++-++-++++-++++-++++-++++-++-++++-++++-++++-++++-++-++++-++++-++++-++++-++-++++-++++-++++-+++-+++-++++-++++-++++-+++-+++-++++-++++-++++-++-++++-++++-++++-++

and whenever I try to seek to any of the frames in that cycle, VirtualDub crashes. It's the last cycle of the video, and it doesn't crash without that line. It also doesn't crash if the same line of specifiers is used for earlier frames.

cacepi · 1st February 2007, 04:51

Quote:

Originally Posted by ChiDragon

I've got a weird crash happening now... I'm using this ovr line and whenever I try to seek to any of the frames in that cycle, VirtualDub crashes.

Just a stab in the dark, but why is your ovr line so long? You have almost twice as many overrides as frames in the range.

ChiDragon · 1st February 2007, 11:22

Well, I took the ovr line for a full cycle and just copied and pasted it to this partial cycle (partial because the video ends before it completes). I haven't had problems with redundant overrides before, and using that full line for the range "79992,80002" doesn't cause a crash.

Terranigma · 6th February 2007, 00:46

tritical, I know this is offtopic, but I was wonderin' if you could perhaps compile speedier versions of Didée's filters such as SeeSaw, Deblock_QED, LimitedSharpenFaster, Mcbob, Soothe, Spresso like how you did for Vinverse?

Probably not gonna happen, but I thought i'd ask since it usually don't hurt to do so

btw, keep up the nice work.

Edit:
tritical, if you or someone else who's interested in porting these filters to .dlls need the scripts, (the latest versions), let me know.

tritical · 7th February 2007, 22:36

The biggest problem is that I don't know the inner workings of a number of the scripts you metion, some of which are very complex, so it would take me some time to go through them before I could even start turning them into filters. Some of the simpler ones, like Soothe and Spresso, I could do pretty easily, but I don't think there would be much of a speed up since they are mainly just lutxy calls. Though in memory intensive scripts it might help since it would cut down on the number of filters/clips being created and thus cache instances.

Could you post a link to the latest versions of Soothe/Spresso, just to make sure I'm looking at the right ones? I might take a stab at them sometime.

Terranigma · 7th February 2007, 23:55

Sure. Here's a link for both soothe & spresso

Chainmax · 17th February 2007, 01:15

I'm having a weird issue: when using the folloeing IVTC lines:

Code:

Deinted=TDeint(order=1,field=1,type=1)
TFM(d2v="C:\SimpS7\Epi1.d2v",order=1,mode=6,PP=7,slow=2,mChroma=false,Clip2=Deinted)
TDecimate(mode=1)

I receive the following error message:

If I remove the "d2v=..." part in the TFM line, the .AVS loads without an issue. What could be causing this?

Alain2 · 17th February 2007, 03:15

It's written.. apparently you set order=1 and the d2v info probably says order=0...

tritical · 17th February 2007, 03:34

Alain2 is correct... the error literally means that the field order value you gave to tfm isn't the same as the field order the d2v file indicates. Also, the latest dgindex/dgdecode (v1.4.9 beta 14) will not work with tfm's d2v option because of a new field that was added to the data lines (this may be what is causing your problem since the extra field means tfm never gets to the trf flags). I'll add support for d2v format v16 in the next release.

Chainmax · 17th February 2007, 03:56

Alain2: the video is TFF for sure and I even put an AssumeTFF() before the code snippet I posted. Alas, I upgraded to dgmpgdecv1.49b14 right before trying to load the scripts, whereas previous attempts used b13, so tritical is right on the money

.
I patiently await for news, master

.

foxyshadis · 17th February 2007, 05:57

Quote:

Originally Posted by tritical

Alain2 is correct... the error literally means that the field order value you gave to tfm isn't the same as the field order the d2v file indicates. Also, the latest dgindex/dgdecode (v1.4.9 beta 14) will not work with tfm's d2v option because of a new field that was added to the data lines (this may be what is causing your problem since the extra field means tfm never gets to the trf flags). I'll add support for d2v format v16 in the next release.

It was punishment for your hybris in removing the version check. ;p

Perhaps it's time to create a well-defined format and some smarter shareable parser code to go with it? (Not to be an xml-solves-all-things sort, but it would make the parsing easier. But then you'd have to include expat, meh.)

Terranigma · 17th February 2007, 16:57

I was gonna post about this other day, but I did'nt wanna bother tritical too much; but support for the latest beta version would be great.

tritical · 17th February 2007, 22:26

@ChiDragon
Could you post the entire script you were using that caused the crashes? I tried to reproduce with:

blankclip(pixel_type="YV12",length=80304,fps_denominator=1001,fps=30000)
tdecimate(ovr="ovr.txt")

where ovr.txt had the single line you posted, but it doesn't crash for me.

@foxyshadis
Yeah, I thought it was quite funny that the very next version after I removed the check wouldn't work. However, adding support for new d2v format versions isn't actually much of a problem atm (it took only 4 lines of code to support v16).

When you say create a well defined format and sharable parser code are you talking about creating a parser separate from tivtc and having it create a file that tfm could read instead of tfm parsing the d2v itself?

Terranigma · 18th February 2007, 16:50

How are you guys actually using an ovr file with tdecimate? I'd try everything to specify a dropped frame or pattern, and it seems to be of no effect. The frame that i've specified to drop would still be there.

I'd use tfm with tdecimate sorta like this
tfm(mode=4,pp=1,slow=2,flags=1,hint=true)
tdecimate(mode=1,expp=true,ovr="C:\Myovr.txt")

The "ovr" file would read something like this

Code:

217 -

24th January 2007, 19:38	#902 \| Link
Isochroma Registered User Join Date: Mar 2005 Posts: 468	Just noticed that b13 of DGIndex came out. One of the changes listed is: * The Correct Field Order option is removed and the field order correction function is now available through the Tools menu: Fix D2V. I did this because this correction should not be applied to streams with frame repeats, and trying to prevent it via a code check runs into technical complications. Will a wrong field order have any effect on TIVTC?

25th January 2007, 02:39	#903 \| Link
ChiDragon Registered User Join Date: Sep 2005 Location: Vancouver Posts: 600	Oh, I didn't know I had to use tfmIn for it to work! Sorry about that. It makes sense considering it would need to grab every frame to get the hints otherwise. The only mention I see of that in the TDecimate readme is in the Changes List section. Maybe you should add it to the tfmIn description for us dummies. (right now it says that it's only useful for hybrid > 0) I get an invalid specifier error when trying to use tfmIn for files output with PP=0 in TFM though. Last edited by ChiDragon; 25th January 2007 at 06:25.

30th January 2007, 07:28	#906 \| Link
ChiDragon Registered User Join Date: Sep 2005 Location: Vancouver Posts: 600	Thanks! Yeah, I've been using PP=1 in the meantime. I'm not sure defaulting sdlim to the largest possible value is a good idea. With the videos I'm encoding now that need sdlim=2, setting sdlim to 3 (or -3) makes TDecimate drop non-dups often. Actually, it drops wrong frames every cycle, but most of them don't matter as it's simply dropping the first of two same-frames (they're only "wrong" since you'd normally want to drop the 2nd frame, with the low metric). The trouble comes at the start and end of the cycles, where it may drop an actual dup at the end of a cycle and then drop a new frame at the start of the next cycle. Last edited by ChiDragon; 30th January 2007 at 07:31.

1st February 2007, 04:27	#907 \| Link
ChiDragon Registered User Join Date: Sep 2005 Location: Vancouver Posts: 600	I've got a weird crash happening now... I'm using this ovr line: Code: 80194,80303 ++-++-++++-++++-++++-++++-++-++++-++++-++++-++++-++-++++-++++-++++-++++-++-++++-++++-++++-++++-++-++++-++++-++++-++++-++-++++-++++-++++-+++-+++-++++-++++-++++-+++-+++-++++-++++-++++-++-++++-++++-++++-++ and whenever I try to seek to any of the frames in that cycle, VirtualDub crashes. It's the last cycle of the video, and it doesn't crash without that line. It also doesn't crash if the same line of specifiers is used for earlier frames.

1st February 2007, 11:22	#909 \| Link
ChiDragon Registered User Join Date: Sep 2005 Location: Vancouver Posts: 600	Well, I took the ovr line for a full cycle and just copied and pasted it to this partial cycle (partial because the video ends before it completes). I haven't had problems with redundant overrides before, and using that full line for the range "79992,80002" doesn't cause a crash. Last edited by ChiDragon; 1st February 2007 at 11:25.

24th January 2007, 16:59	#901 \| Link
tritical Registered User Join Date: Dec 2003 Location: MO, US Posts: 999	Thought I had fixed that back in October . Is your script just the basic: mpeg2source() tfm(input="") tdecimate(input="",tfmIn="") ?

25th January 2007, 19:00	#904 \| Link
tritical Registered User Join Date: Dec 2003 Location: MO, US Posts: 999	@Isochroma If you use the d2v="" parameter in tfm, then it checks for illegal field order changes in the d2v (wont work with frame repeats, but tfm shouldn't be needed on those streams)... so it wont matter there. If you don't use the d2v parameter, use a matching mode that can't handle field order changes (only modes 4 and 5 can), and the stream does have field order changes, then there will be a problem. @ChiDragon An explanation in the tdecimate readme is probably a good idea. Another way to get around the need for the tfmIn file is to set hints=false in tdecimate. However, then tdecimate wont get to use any info from tfm. The basic chain of events when tdecimate runs is: startup: 0.) If hints isn't manually set by the user, then grab frame 0 and detect if there are hints in it. If there are, set hints=true, else, set hints=false. during operation: 1.) If there's a tfmIn file, don't read hints for frames that the tfmIn file has info for. 2.) else if hints=true, reads hints for frames that don't have info from a tfmIn file. 3.) else if hints=false, never read hints I'll check out the problem with the pp=0 files.

29th January 2007, 09:46	#905 \| Link
tritical Registered User Join Date: Dec 2003 Location: MO, US Posts: 999	Found and fixed the problem with tdecimate reading tfm output files created with pp=0. I'll put up a new version soon (a work around would be to just use pp=1 in tfm, though it will be slightly slower than pp=0 depending on the matching mode). I am also considering changing the sdlim default in tdecimate so that when cycleR > 1 it defaults to the largest possible value such that there would never be any cases where it couldn't mark a full cycleR worth of frames. I'm thinking that when someone uses cycleR>1 they are generally looking for the decimation to be spread throughout the cycle as sdlim allows instead of actually removing the cycleR frames with the lowest metric (which could all be next to each other).

6th February 2007, 00:46	#910 \| Link
Terranigma Space Reserved Join Date: May 2006 Posts: 953	tritical, I know this is offtopic, but I was wonderin' if you could perhaps compile speedier versions of Didée's filters such as SeeSaw, Deblock_QED, LimitedSharpenFaster, Mcbob, Soothe, Spresso like how you did for Vinverse? Probably not gonna happen, but I thought i'd ask since it usually don't hurt to do so btw, keep up the nice work. Edit: tritical, if you or someone else who's interested in porting these filters to .dlls need the scripts, (the latest versions), let me know. Last edited by Terranigma; 6th February 2007 at 01:48.

7th February 2007, 22:36	#911 \| Link
tritical Registered User Join Date: Dec 2003 Location: MO, US Posts: 999	The biggest problem is that I don't know the inner workings of a number of the scripts you metion, some of which are very complex, so it would take me some time to go through them before I could even start turning them into filters. Some of the simpler ones, like Soothe and Spresso, I could do pretty easily, but I don't think there would be much of a speed up since they are mainly just lutxy calls. Though in memory intensive scripts it might help since it would cut down on the number of filters/clips being created and thus cache instances. Could you post a link to the latest versions of Soothe/Spresso, just to make sure I'm looking at the right ones? I might take a stab at them sometime.

7th February 2007, 23:55	#912 \| Link
Terranigma Space Reserved Join Date: May 2006 Posts: 953	Sure. Here's a link for both soothe & spresso

17th February 2007, 01:15	#913 \| Link
Chainmax Huh? Join Date: Sep 2003 Location: Uruguay Posts: 3,103	I'm having a weird issue: when using the folloeing IVTC lines: Code: Deinted=TDeint(order=1,field=1,type=1) TFM(d2v="C:\SimpS7\Epi1.d2v",order=1,mode=6,PP=7,slow=2,mChroma=false,Clip2=Deinted) TDecimate(mode=1) I receive the following error message: If I remove the "d2v=..." part in the TFM line, the .AVS loads without an issue. What could be causing this? __________________ Read Decomb's readmes and tutorials, the IVTC tutorial and the capture guide in order to learn about combing and how to deal with it.

17th February 2007, 03:15	#914 \| Link
Alain2 Registered User Join Date: May 2005 Posts: 236	It's written.. apparently you set order=1 and the d2v info probably says order=0...

17th February 2007, 03:34	#915 \| Link
tritical Registered User Join Date: Dec 2003 Location: MO, US Posts: 999	Alain2 is correct... the error literally means that the field order value you gave to tfm isn't the same as the field order the d2v file indicates. Also, the latest dgindex/dgdecode (v1.4.9 beta 14) will not work with tfm's d2v option because of a new field that was added to the data lines (this may be what is causing your problem since the extra field means tfm never gets to the trf flags). I'll add support for d2v format v16 in the next release.

17th February 2007, 03:56	#916 \| Link
Chainmax Huh? Join Date: Sep 2003 Location: Uruguay Posts: 3,103	Alain2: the video is TFF for sure and I even put an AssumeTFF() before the code snippet I posted. Alas, I upgraded to dgmpgdecv1.49b14 right before trying to load the scripts, whereas previous attempts used b13, so tritical is right on the money . I patiently await for news, master . __________________ Read Decomb's readmes and tutorials, the IVTC tutorial and the capture guide in order to learn about combing and how to deal with it.

17th February 2007, 16:57	#918 \| Link
Terranigma Space Reserved Join Date: May 2006 Posts: 953	I was gonna post about this other day, but I did'nt wanna bother tritical too much; but support for the latest beta version would be great.

17th February 2007, 22:26	#919 \| Link
tritical Registered User Join Date: Dec 2003 Location: MO, US Posts: 999	@ChiDragon Could you post the entire script you were using that caused the crashes? I tried to reproduce with: blankclip(pixel_type="YV12",length=80304,fps_denominator=1001,fps=30000) tdecimate(ovr="ovr.txt") where ovr.txt had the single line you posted, but it doesn't crash for me. @foxyshadis Yeah, I thought it was quite funny that the very next version after I removed the check wouldn't work. However, adding support for new d2v format versions isn't actually much of a problem atm (it took only 4 lines of code to support v16). When you say create a well defined format and sharable parser code are you talking about creating a parser separate from tivtc and having it create a file that tfm could read instead of tfm parsing the d2v itself?

18th February 2007, 16:50	#920 \| Link
Terranigma Space Reserved Join Date: May 2006 Posts: 953	How are you guys actually using an ovr file with tdecimate? I'd try everything to specify a dropped frame or pattern, and it seems to be of no effect. The frame that i've specified to drop would still be there. I'd use tfm with tdecimate sorta like this tfm(mode=4,pp=1,slow=2,flags=1,hint=true) tdecimate(mode=1,expp=true,ovr="C:\Myovr.txt") The "ovr" file would read something like this Code: 217 -