Deinterlacing/TIVTC causing jittery video?

[killerteengohan]

I am using this to deinterlace an anime like I usually do.

tfm(order=1).tdecimate(mode=1,hybrid=0)

For some reason, the video becomes a bit jittery. Possibly from the decimation to 23.976fps done by it. For instance the end credits scroll upwards from the bottom and it looks like its bouncing/jerking upwards instead of being a smooth motion like in the original source video.

Can I remove the interlacing/combing lines with tfm and tdecimate like above, while keeping the video at 29.970fps instead of decimating it to 23.976fps like it is currently doing?

[davexnet]

tfm() by itself ?

[killerteengohan]

Would tdecimate(mode=4,hybrid=0) work? Not sure what it does exactly, but readme says it does not decimate.

"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."

I honestly have no clue what metrics means or is.

[poisondeathray]

Sometimes animations can have different content running at different frame rates. Credits , overlays are very common - sometimes they can be 29.97i (59.94 fields/s), while the content underneath is "24p" or lower . If you want different sections running at different speeds , you can make it VFR

[jagabo]

You probably have the wrong field order.

[killerteengohan]

You probably have the wrong field order.

I'm pretty much 100% sure that's not the problem. Nothing I changed it to got rid of them unfortunately.

[killerteengohan]

Sometimes animations can have different content running at different frame rates. Credits , overlays are very common - sometimes they can be 29.97i (59.94 fields/s), while the content underneath is "24p" or lower . If you want different sections running at different speeds , you can make it VFR

Well using tfm by itself did fix the ending credits, but it messed up the anime by making the screen bounce instead of move slowly when the entire screen is moving/panning in a direction. I guess the anime is 23.976fps and the opening/ending is 29.970fps. That show was known for using 60fps on 3D CGI scenes and 30fps on regular animation scenes from what I read.

So how would I use tfm(order=1).tdecimate(mode=1,hybrid=0) on the anime episode and keep the end credits at 29.970fps?

[poisondeathray]

Well using tfm by itself did fix the ending credits, but it messed up the anime by making the screen bounce instead of move slowly when the entire screen is moving/panning in a direction. I guess the anime is 23.976fps and the opening/ending is 29.970fps. That show was known for using 60fps on 3D CGI scenes and 30fps on regular animation scenes from what I read.

So how would I use tfm(order=1).tdecimate(mode=1,hybrid=0) on the anime episode and keep the end credits at 29.970fps?

I would double check, because the background elements in the credits might be 23.976 (or lower), but the actual overlays could be 29.97p or 59.94p or something else

You'd have to make it VFR . Ideally you'd want those 59.94 CG sections to run at 59.94, instead of dropping frames. You'd want the "regular" sections to run at 23.976. There are instructions for 2pass vfr with timecodes in the TIVTC (TFM/TDecimate) package, but there are other methods as well . This topic should be covered in various posts, especially anime forums - it's very common

[killerteengohan]

Background video underneath the moving credits looks way better and moves smoother with tfm by itself. When its decimated, that motions in the background are also screwed up pretty badly and very jittery.


I tried doing this to get the 2 scenes vfr, but it says "Splice: Video framerate doesn't match" and will not let me change framerate that way.

__film = last
__t0 = __film.trim(0, 36432)
Insert=Import("C:\Users\User\Desktop\Encoding\ID5\ Blu-Ray\Episode 2\00001 - Copy (Credits).avs")
__t0 ++ Insert


Its the episode doing it the way I was, and then I wrote a second script that is only the ending credit frames, but with tfm by itself to keep the framerate 29.970fps. But I get the error I mentioned when I try this.

[poisondeathray]

I tried doing this to get the 2 scenes vfr, but it says "Splice: Video framerate doesn't match" and will not let me change framerate that way.

avisynth is cfr only

You need to use timecodes to make it vfr . There are instructions in the TIVTC package (or at least that's one way of doing it) . You can mux in timecodes with mkvtoolnix or encode with x264 using --tcfile-in

[killerteengohan]

I will give a sample of end credits asap.

[killerteengohan]

I tried doing this to get the 2 scenes vfr, but it says "Splice: Video framerate doesn't match" and will not let me change framerate that way.

avisynth is cfr only

You need to use timecodes to make it vfr . There are instructions in the TIVTC package (or at least that's one way of doing it) . You can mux in timecodes with mkvtoolnix or encode with x264 using --tcfile-in

I will also look into and read about this because I certainly want to learn it. Thanks!!

[killerteengohan]

Here is end credits sample. No deinterlacing done to it so its still original. I just downscaled it a bit to reduce file size since 1080p is pretty big.

https://mega.nz/#!04xXjCpQ!tRyfV2PG7ameNY40RPIwAj10puSUjZUfXZT4PmLE4hM

It almost looks like the credits don't even need deinterlaced or TIVTC used on it.

[jagabo]

That video is encoded progresssive and contains progressive frames. 29.97 fps is the right frame rate for the material (it may have originally been interlaced, but if it was, it has been deinterlaced to 29.97p already).

[killerteengohan]

That video is encoded progresssive and contains progressive frames. 29.97 fps is the right frame rate for the material (it may have originally been interlaced, but if it was, it has been deinterlaced to 29.97p already).

Yeah, I guess that's what makes the credits different from the episode. The episode is indeed still interlaced.


I am a bit lost with this timecode file though. I believe I get how to use it, but the creating it I am still a little confused on. Sorry but I have never done this before and visual help always helps me catch on quicker.

Am I supposed to add something like timecode=timecode.txt in the script and it just makes it? Do I create my own from scratch like writing an avisynth script, save it as .txt and then use the text file in MKVMerge when muxing?


For just this one episode, if possible tell me this. How would I make the timecodes file for it if this is the times I want to adjust. If it's a text file for loading, what would it look like in it?

00:00:00.000 - 00:25:19.518 # Episode (23.976fps)

00:25:19.518 - 00:27:20.939 # Ending Credits (29.970fps)

Once I see a completed timecodes file or get how to make it, I am sure I can pick up on the rest of it fairly quickly by toying with it like I usually can.

[poisondeathray]

I am a bit lost with this timecode file though. I believe I get how to use it, but the creating it I am still a little confused on. Sorry but I have never done this before and visual help always helps me catch on quicker.

Am I supposed to add something like timecode=timecode.txt in the script and it just makes it? Do I create my own from scratch like writing an avisynth script, save it as .txt and then use the text file in MKVMerge when muxing?


For just this one episode, if possible tell me this. How would I make the timecodes file for it if this is the times I want to adjust. If it's a text file for loading, what would it look like in it?

00:00:00.000 - 00:25:19.518 # Episode (23.976fps)

00:25:19.518 - 00:27:20.939 # Ending Credits (29.970fps)

Once I see a completed timecodes file or get how to make it, I am sure I can pick up on the rest of it fairly quickly by toying with it like I usually can.

If you're using mkvmerge, look at the instructions under "timestamp" (it used to be called "timecodes" in older versions) . The easiest to use is v1 timecodes format, where you specify frame ranges, and their fps. You just mux that in with mkvmerge

17.1. Timestamp file format v1

This format starts with the version line. The second line declares the default number of frames per second. All following lines contain three numbers separated by commas: the start frame (0 is the first frame), the end frame and the number of frames in this range. The FPS is a floating point number with the dot '.' as the decimal point. The ranges can contain gaps for which the default FPS is used. An example:

# timestamp format v1
assume 27.930
800,1000,25
1500,1700,30

You could use avisynth, but assume a set frame rate (temporarily) just to append your segments . The timecodes will override everything later

[killerteengohan]

So let me make sure I have this right.

1. I make an avisynth script without deinterlacing, but only the filters I want to use and encode the video still interlaced.

2. I make a timecodes/timestamp file similar to this and save it as .txt file. (Tell me if I am writing this timecodes wrong please)

# timestamp format v1
assume 29.970
0,45540,23.976
45541,49179,29.970

3. I load the encoded video and use the timecode/timestamp file in MKVMerge.


Is that correct?

[poisondeathray]

So let me make sure I have this right.

1. I make an avisynth script without deinterlacing, but only the filters I want to use and encode the video still interlaced.
?

Nope - if you do this with mkvmerge, specifying sections in timecodes manually

You do whatever you normally do in avisynth. But you divide it up into sections in the script with different processing.
e.g
Part A would be 23.976 after IVTC (TFM+TDecimate), but Part B the credits section would be 29.97 (or whatever - TFM only, not TDecimate) - you don't use the same processing for part B or other sections (you can't decimate it to 23.976). You'd need to use AssumeFPS(24000,1001) for the 29.97 section (same framecount, but different assumed framerate) in order to join them (or AssumeFPS(30000,1001) for part A ) . Basically each section needs to temporarily have the same framerate to make avisynth cooperate

To append it would be
part A ++ Part B

And you still encode progressive

[killerteengohan]

So would this be the proper script for doing a Part A and Part B?

LoadPlugin("C:\Program Files (x86)\MeGui\tools\dgavcindex\DGAVCDecode.dll")
AVCSource("C:\Users\User\Desktop\Encoding\IND5\Blu-Ray\Episode 2\00001.dga")
Colormatrix(mode="rec.709->rec.601", clamp=0, threads=0)
LoadPlugin("C:\Program Files (x86)\MeGui\tools\avisynth_plugin\TIVTC.dll")


__film = last

__t0 = __film.trim(0, 45539).tfm(order=1).tdecimate(mode=1,hybrid=0) # Part A

__t1 = trim(45540, 49179).AssumeFPS(24000,1001) # Part B

__t0 ++ __t1


crop( 4, 2, -4, -2)
Spline36Resize(1024,576).dehalo_alpha(rx=1.2, ry=1.2, darkstr=0, lowsens=0, highsens=100, ss=1.0)
hqdering(smoother=deen("c3d",1,3,2,2))
blur(0.02)

The script loads properly, but the video has 31 more seconds in length than it should. I assume this is from the assumefps slowing the video playback speed but keeping all the frames?? All of the video is at its proper time up until the credits start, then the credits add more time than it was before. It should be 27:20.930 but that script makes it 27:51.294. That will throw the audio and subtitles out of sync with it. Will it be fixed when the timecode file is used on it?

[poisondeathray]

Do your framenumbers refer to the original framenumbers ?

Because after you process , tdecimate will decimate the 1st section and change the numbers - so your timecodes file is no longer correct

The timecodes file refers to the actual new encoded frame numbers, which is going to be different than the original

[poisondeathray]

Also, didn't you say "That show was known for using 60fps on 3D CGI scenes " ? Were there other sections that were 60fps? or maybe not in this version ?

Anyways , the idea is the same. You just temporarily assign a FPS (just to satisfy avisynth), but the timecodes specify the actual framenumbers and fps . (There are other methods that output a timecodes file based parameters, but manually doing it will always be more accurate, just more tedious)

[killerteengohan]

Do your framenumbers refer to the original framenumbers ?

Because after you process , tdecimate will decimate the 1st section and change the numbers - so your timecodes file is no longer correct

The timecodes file refers to the actual new encoded frame numbers, which is going to be different than the original

Yeah that's the original frame numbers before decimation was done to it. I wouldn't have been able to use the decimated frame numbers because it didn't work when I tried it.

Also, didn't you say "That show was known for using 60fps on 3D CGI scenes " ? Were there other sections that were 60fps? or maybe not in this version ?

Anyways , the idea is the same. You just temporarily assign a FPS (just to satisfy avisynth), but the timecodes specify the actual framenumbers and fps . (There are other methods that output a timecodes file based parameters, but manually doing it will always be more accurate, just more tedious)

I almost always prefer the manual, more accurate way even if it is a bit more work.

[poisondeathray]

Do your framenumbers refer to the original framenumbers ?

Because after you process , tdecimate will decimate the 1st section and change the numbers - so your timecodes file is no longer correct

The timecodes file refers to the actual new encoded frame numbers, which is going to be different than the original

Yeah that's the original frame numbers before decimation was done to it. I wouldn't have been able to use the decimated frame numbers because it didn't work when I tried it.

Then you did something wrong. That's the way it's supposed to work

You can't refer to a framenumber or range in the timecodes file that isn't there. The timecodes have to reflect the new numbering

I almost always prefer the manual, more accurate way even if it is a bit more work.

Me too; that's why I personally would look for the 60fps sections that are supposed to be there

[killerteengohan]

I am encoding it with that script now. I will try the timecode lines where I asked if they were correct or not, when it is finished encoding. If I have any problems with the timecode file working, I will be sure to let you know and ask about them.


Is this the correct usage that I will put in the .txt file? I don't need to specify directories or output formats or anything?

# timestamp format v1
assume 29.970
0,45540,23.976
45541,49179,29.970


Will this adjust the credits framerate in MKVMerge with a method like assumfps or changefps? I hope it will not alter frame counts.

[poisondeathray]

I am encoding it with that script now. I will try the timecode lines where I asked if they were correct or not, when it is finished encoding. If I have any problems with the timecode file working, I will be sure to let you know and ask about them.


Is this the correct usage that I will put in the .txt file? I don't need to specify directories or output formats or anything?

# timestamp format v1
assume 29.970
0,45540,23.976
45541,49179,29.970


Will this adjust the credits framerate in MKVMerge with a method like assumfps or changefps? I hope it will not alter frame counts.

Those are the wrong numbers. Because the 1st section used tdecimate. tdecimate alters the frame counts. Therefore your new numbers have to be used in the timecodes

You used trim() before tfm.tdecimate. So the trim() numbers use the original numbering. Afterwards it will change

[killerteengohan]

Then you did something wrong. That's the way it's supposed to work

You can't refer to a framenumber or range in the timecodes file that isn't there

I did something wrong?

Those frame numbers are there before its decimated. That's the frame numbers that are in the source.

I tried using the decimated frame numbers like this and it did not work. The episode was only 22min and the end credits did not even show in the preview.

__film = last

__t0 = __film.trim(0, 36432).tfm(order=1).tdecimate(mode=1,hybrid=0).cro p( 4, 2, -4, -2).Spline36Resize(1024,576).dehalo_alpha(rx=1.2, ry=1.2, darkstr=0, lowsens=0, highsens=100, ss=1.0).hqdering(smoother=deen("c3d",1,3,2,2)).blu r(0.02)

__t1 = __film.trim(36433, 0).AssumeFPS(24000,1001).crop( 4, 2, -4, -2).Spline36Resize(1024,576).dehalo_alpha(rx=1.2, ry=1.2, darkstr=0, lowsens=0, highsens=100, ss=1.0).hqdering(smoother=deen("c3d",1,3,2,2)).blu r(0.02)

__t0 ++ __t1


The source frame numbers were what I needed to use for it to be correct. The numbers do not change until after the decimation is done.

[killerteengohan]

I am encoding it with that script now. I will try the timecode lines where I asked if they were correct or not, when it is finished encoding. If I have any problems with the timecode file working, I will be sure to let you know and ask about them.


Is this the correct usage that I will put in the .txt file? I don't need to specify directories or output formats or anything?

# timestamp format v1
assume 29.970
0,45540,23.976
45541,49179,29.970


Will this adjust the credits framerate in MKVMerge with a method like assumfps or changefps? I hope it will not alter frame counts.

Those are the wrong numbers. Because the 1st section used tdecimate. tdecimate alters the frame counts. Therefore your new numbers have to be used in the timecodes

You used trim() before tfm.tdecimate. So the trim() numbers use the original numbering. Afterwards it will change

I tried that and it made the video over 30 mins long and put half the episode twice.


__film = last

__t0 = __film.trim(0, 45539).tfm(order=1).tdecimate(mode=1,hybrid=0) # Makes it 36431 frames in length after decimation

__t1 = __film.trim(36432, 0).AssumeFPS(24000,1001)

__t0 ++ __t1

[killerteengohan]

Oh wait I get what your saying. Your talking about the timecodes numbers, not the scripts numbers. Sorry about that!

[poisondeathray]

No - the original script numbers are probably ok
But the timecodes are not - you need to reference the new framenumbers produced by your script

Oh wait I get what your saying. Your talking about the timecodes numbers, not the scripts numbers. Sorry about that!

Don't worry ... it can be confusing at first

[killerteengohan]

No - the original script numbers are probably ok
But the timecodes are not

It's ok... it can be confusing at first

Yeah I get it now, I was thinking you were talking about the script frames. I will correct the numbers. I pretty much knew I would have to do that.
Other than those numbers needing adjusted, is it written right?