Deinterlacing/TIVTC causing jittery video?

[poisondeathray]

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?

Yes, and both sections (since you only have two in that example) need to be be adjusted to reflect the new numbering

[killerteengohan]

# timestamp format v1
assume 29.970
0,36432,23.976
36433,40071,29.970


Would starting with frame #1 be better than 0?


# timestamp format v1
assume 29.970
1,36432,23.976
36433,40071,29.970

[killerteengohan]

Well loading and using the timecodes file in MKVMerge worked fine. Its having a slight playback issue though. For some reason its playing back as if its lagging the media player for 2-8 seconds or so.

During playback, once it gets to the credits part of the episode, it looks as if it just pauses for a brief second then instantly jumps ahead maybe 10 frames or so and quickly does this multiple times for a total of 2-8 seconds. The amount of time seems to vary depending on where I seeked to. It seems to do this, especially when seeking through the video in media player. This is more annoying than jitter because its more of a gap between jumps and just looks odd. It will do this even if I did not seek through the video at all.

If I rewind or seek backwards after this has happened, it seems to play perfectly fine the second time around. The moment I close the file and re-open it again, that playback issue comes right back again and behaves exactly the same way.

I do not have this happening when its all the same framerate or the full decimated version. I tried multiple versions of MKVMerge and multiple media players and I am still getting this issue.


Whats up with this?

[jagabo]

Try using 23.976 fps CFR and converting the credits with:

FrameRateConverter(NewNum=24000, NewDen=1001)

That converter errors on the side of blended frames rather than distorted frames. It will look at lot better with the scrolling credits over a moving picture. It won't be perfect but it will look better at normal playback speed. SmoothFPS2() on the top, FrameRateConverter() on the bottom:

[killerteengohan]

I tried playing it on another computer and it plays perfectly fine so it must be something on my computer. I looked into player and codec settings.

After playing around in In MPC-HC I found a setting called Render Settings - Presentation - Enable Frame Time Correction. As soon as I disabled this, the problem stopped happening.
Do I need to have that setting on? Is it even important to have on? It's apparently on by default because I never turned it on myself.


I also noticed my other computer was using a different playback output in MPC-HC. My laptop was using madvr and that setting I just mentioned was not even allowed to be checked or unchecked like it was on my other computer that had the issue. Every setting in that Render Settings - Presentation section was grayed out. I don't know if madvr uses this or not, but as soon as I changed it to EVR (Custom Pres) like my computer, it also had that playback issue until I unchecked that setting again.

[poisondeathray]

Would starting with frame #1 be better than 0?

If you read the instructions, or what I copy/pasted earlier, it says "the start frame (0 is the first frame)" (which matches avisynth frame numbering too)

(But that wouldn't cause the playback issues you're describing - frame ranges that are omitted playback at the assumed frame rate. So you have 29.97 in your timecodes, so that 1st frame, frame zero, will have 33.3667ms duration instead of 41.7084ms duration)

I don't know what causes that problem exactly, but it's definitely a playback configuration issue if you muxed the timecodes correctly (How did you use the timecodes exactly? If using the GUI, did you load it in the timestamps box, or what was your commandline in mkvmerge?) . This is a very common method for anime

[killerteengohan]

Would starting with frame #1 be better than 0?

If you read the instructions, or what I copy/pasted earlier, it says "the start frame (0 is the first frame)" (which matches avisynth frame numbering too)

(But that wouldn't cause the playback issues you're describing - frame ranges that are omitted playback at the assumed frame rate. So you have 29.97 in your timecodes, so that 1st frame, frame zero, will have 33.3667ms duration instead of 41.7084ms duration)

I don't know what causes that problem exactly, but it's definitely a playback configuration issue if you muxed the timecodes correctly (How did you use the timecodes exactly? If using the GUI, did you load it in the timestamps box, or what was your commandline in mkvmerge?) . This is a very common method for anime

I have never used the command line, I have always used the GUI program MKVMerge and have no experience with the command line. I loaded the timecodes file in the General Track Options part of the GUI for the video. I only had to browse for the file in the GUI and it was done. I did not see it as necessary to load the timestamp file for the audio and subtitles tracks since they are not being altered in any way.

[poisondeathray]

I have never used the command line, I have always used the GUI program MKVMerge and have no experience with the command line. I loaded the timecodes file in the General Track Options part of the GUI for the video. I only had to browse for the file in the GUI and it was done. I did not see it as necessary to load the timestamp file for the audio and subtitles tracks since they are not being altered in any way.

In the mkvtoolnix GUI , there is a special box "timestamps and default duration". Select the video track (left click it), then - load the timestamps file into that box where it says "timestamps file" . If you're using an older version, it's basically the same thing, but it's called "timecodes" instead

[killerteengohan]

I am already doing it that way. I just mentioned that.

https://forum.videohelp.com/images/imgfiles/CyVKdJh.png


I also tried it using the newest version of MKVMerge and it was still giving the same playback issue.

It appears to work fine in old WMP or VLC media player. I had to disable that one setting I mentioned in post #35 in order for it to work in my MPC-HC properly. Otherwise it had that playback problem. I see in lots of places on google that you will want the setting enabled for smooth playback, but its screwing up this VFR file on playback.

[killerteengohan]

This is clearly just media player and or media player settings being picky with VFR because it works in other media players and on other computers just fine. Overall it looked like everything worked just fine and I want to thank you for taking the time to help me with learning and using timecodes files.

[killerteengohan]

I just noticed the entire .m2ts file is playing back at 60fps the entire time according to MPC-HC. This is leading me to believe that the entire thing should in fact be 60fps and that I deinterlaced it in a way that would not give the best results.

Is this supposed to be 60fps? or is what I was using, just fine?
tfm(order=1).tdecimate(mode=1,hybrid=0)


Here is a sample from the actual episode footage.

https://mega.nz/#!4kgEQS7L!Sa9g2fCchXlb7k7C1jc36VZBaaNupz13XDByd_eOMBg

If it is indeed supposed to be 60fps, how would I encode it at 60fps? tfm removes the combing/interlace lines but it outputs at 29.970fps, not 60fps.

[jagabo]

It's encoded 29.97p. It was once telecined film but it was blend deinterlaced. FixblendIVTC() might work.

[poisondeathray]

where is the original m2ts sample ? You'd have a better chance of deblending that if it had intact fields.

This type of animation should be "24p", regardless of how something "plays" it . mpchc is probably just bob deinterlacing it if it's playing back at 60fps, don't assume that's what the actual content is or should be.

There might have been many mistakes along the way too, before it even got to BD .

You'd have to check with separatefields or some bob deinterlacer for 59.94p sections to see if you're missing any. Earlier you said this was known to have some CG elements

[killerteengohan]

where is the original m2ts sample ? You'd have a better chance of deblending that if it had intact fields.

I know how to get a direct unfiltered sample from DVD VOB with DGIndex, but I do not know how to get you one from .m2ts without giving you the entire 6GB episode file so I just gave a downscaled encode with no deinterlacing done to it from a selection of random frames.

[poisondeathray]

You can cut a piece with tsmuxer (split and cut tab) or mkvtoolnix using the splitting options

(not really "cut" , it's really stream copying a segment)

[killerteengohan]

The output is making it .mkv and not keeping it at .m2ts. Is that what you want?

[poisondeathray]

mkv is ok if you loaded the m2ts directly into mkvtoolnix , you don't need the audio (uncheckmark audio and other streams).

[killerteengohan]

https://mega.nz/#!I5pz1CiJ!yNjryT4ianQKUob1jICWI9cTgE7Erw6dwYtvTJ7_32k

[poisondeathray]

This is just plain 23.976p . A simple IVTC .

There are some repeat frames, but that's intended and part of the animation style. Most people would leave it at 23.976p with the repeats . Typically this style/type of animation does not have 59.94 CG elements . But credits can be 29.97p or sometimes 59.94p . I didn't look at your credits sample - was that "original" or processed ?


That mp4 you uploaded is blended and messed up. Not sure how you made that ? Maybe you resized it while it was still in fields ?

[killerteengohan]

I am uploading original credits now, it will be done soon. My last submission was also a downscaled encode.

[killerteengohan]

That mp4 you uploaded is blended and messed up. Not sure how you made that ? Maybe you resized it while it was still in fields ?

All I did was run this script through the encoder to make that downscaled sample.


LoadPlugin("C:\Program Files (x86)\MeGui\tools\dgavcindex\DGAVCDecode.dll")
AVCSource("C:\Users\User\Desktop\Encoding\IN5\Blu-Ray\Episode 2\00001.dga")
Colormatrix(mode="rec.709->rec.601", clamp=0, threads=0)
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)
__film = last
__t0 = __film.trim(6646, 8845)
__t0


That should not have blended it to my knowledge.

[poisondeathray]

You can't do a progressive resize while it's still in fields (interlaced) . That's the reason for the blending. You have to IVTC to recover the original film frames first, then resize . Either that or do an interlace-aware resize, to keep the interlace (nobody does it the 2nd way, because the actual content is progressive)

Also, AVCSource might be causing other sorts of problems . It's depreciated and has known problems decoding certain streams. I recommend using something else like ffms2 or lsmash

Was your residual "combing" sample from the car shot in the other thread from this BD too ? I would go back and take a closer look at it

[killerteengohan]

Here are the credits

https://mega.nz/#!R1RBla7Z!kj9p5Vz3jNzDlX9KXtIbBoOgFScmJ4nCa4PVv7cGiUA

[killerteengohan]

Was your residual "combing" sample from the car shot in the other thread from this BD too ? I would go back and take a closer look at it

Yes it was, actually. I think it was just episode 1 instead of episode 2 like this one.

[poisondeathray]

The credits overlay (the actual scrolling credits) are actually 29.97i (they are 59.94p speed when bob deinterlaced) , but the background is mostly 29.97p where the live action/band is playing . (There is some cartoon insert of cars near the middle, that's really messed up)

Some people would leave this section at 29.97p , others at 59.94p. Me personally, I would use 29.97p because the credits aren't really that important - it's not vital that they are super smooth. Just smooth.

There are dedicated scripts that deal with "interlaced credits", but anything you do will involve some sort of trade off for this credits section (if the main section sample was representative, that part is quite clean and easy)

[killerteengohan]

The credits overlay (the actual scrolling credits) are actually 29.97i (they are 59.94p speed when bob deinterlaced) , but the background is mostly 29.97p where the live action/band is playing . (There is some cartoon insert of cars near the middle, that's really messed up)

Some people would leave this section at 29.97p , others at 59.94p. Me personally, I would use 29.97p because the credits aren't really that important - it's not vital that they are super smooth. Just smooth.

There are dedicated scripts that deal with "interlaced credits", but anything you do will involve some sort of trade off for this credits section (if the main section sample was representative, that part is quite clean and easy)

Yeah, 29.970 looks fine to me. Much better than the 23.976 decimated one did. I will be going with the 29.976fps. I usually dont like how 60fps looks when the entire screen pans anyways. It usually looks too smooth, too fast, or unnatural to me.

For good measure though, lets say I was wanting to go with 60fps. How would I even encode it at 60fps? If I use tfm or do not deinterlace it, the output ends up 29.970fps anyways.

Adjusting the timecode file or using QTGMC is all I can think of.

[jagabo]

I usually dont like how 60fps looks when the entire screen pans anyways. It usually looks too smooth, too fast, or unnatural to me.

Yeah, in the real world everything moves in jerky steps.

For good measure though, lets say I was wanting to go with 60fps. How would I even encode it at 60fps?

QTGMC or Yadif(mode=1). The former is much better.

And you wasted everybody's time uploading badly processed reencoded crap before.