IVTC issue

[Acetyl]

While reversing the telecining of a stream manually (with yatta) I ran into two duplicate combed frames in a row. The issue being that they're both the same field, it contains necessary frame data, and nothing else to blend it against. Any filter I tried has either not worked, or yielded worse results. Not sure if something like this can be interpolated properly, any pattern changes don't fix it either.

Maybe someone knows of a filter or method to try.

Source frame -


Attempts to fix -

[manono]

Sample.

[Acetyl]

The whole thing doesn't conform anywhere near ccnnc.

I'll have to go and run through whole scene again, I suppose. Disregard thread.

[Acetyl]

Sample.

I didn't see your post.

This is the segment. Though there are a few others down the line.
I think I just garbled up the ccnnc order. Though that was in an attempt to fix the issue that was already there.

http://www.mediafire.com/?tonssrds7vw64f6

[Acetyl]

This is strange. The source is a DVD, I can't see any reason why the telecining pattern wouldn't be uniform, at least for the most part. Using the forced film option in DGIndex then doing a test encode still produces the same telecining artifacts, just with a video that is now 23.976 fps.

It is animated. But the distribution still seems largely random. Maybe the pronounced combing is caused by improperly done telecining, which is why I'm running into duplicate fields.

[Acetyl]

I think something just isn't clicking in mind.
In theory, the pulldown process is perfect and can be reversed with a relative lack of any loss. But our implementations don't always adhere to that concept of perfection...
I think I understand why the CCNNC pattern is best preserved. C is indicative of already aligned and intact fields forming a progressive frame. N is a partial field that needs to be merged into the next field, creating a progressive frame, the next C is the resulting progressive frame. But the pattern seems to change in an arbitrary way, which was expected as well. Compensating for why that needs to occur is why I'm doing it by eye to begin with. But the pattern the automated algorithm has laid out near the beginning, while accurate, seems much different.

NNNCC NNNCC NNNCC[...] and all my tests by eye show it is the best pattern.

I don't like eating up someone's time asking something I feel like I should be able to figure for myself. But why would this be? The fact that it works tells me I don't understand N, nor C, nor P. At least not in a full sense.

Logic says CC = 2 fields comprising the first frame. NN is the next two fields pushed forward and merged into the first field in the next frame, to recover a progressive frame. Then it repeats, thus the 2:3 pattern.

Edit - One last question in case anyone does respond somewhere along the line. The decimation pattern for this project type anyway, only allow a decimation once per 5 fields. This tells me I should be more keen on decimating an N when possible, as it's a full "frame" that's fields are now duplicated (rendering it redundant). Am I correct in thinking this?

[jagabo]

The source is a DVD, I can't see any reason why the telecining pattern wouldn't be uniform

It's quite common for breaks in the telecine pattern, even on DVD.

at least for the most part. Using the forced film option in DGIndex then doing a test encode still produces the same telecining artifacts, just with a video that is now 23.976 fps.

It's not "film" enough. Using Honor Pulldown Flags and TFM().TDecimate() is your best bet. Unless you want to find all the pattern breaks and handle the segments separately.

[Acetyl]

The source is a DVD, I can't see any reason why the telecining pattern wouldn't be uniform

It's quite common for breaks in the telecine pattern, even on DVD.

I see, I didn't know that.

at least for the most part. Using the forced film option in DGIndex then doing a test encode still produces the same telecining artifacts, just with a video that is now 23.976 fps.

It's not "film" enough. Using Honor Pulldown Flags and TFM().TDecimate() is your best bet. Unless you want to find all the pattern breaks and handle the segments separately.

The intent was a final product that was as close to "archival" quality as I could come. It's just a personal project to learn things I don't typically do a bit more in depth, for the most part.

I'm guessing using TFM().TDecimate() would have an occasional margin of error because of those not always detected pattern changes?

[jagabo]

Yes, TFM().TDecimate() does occasionally make mistakes. Sometimes when there is too little motion between frames it will mismatch the fields. Also, the default in TFM() is to post process to eliminate any remaining comb artifacts -- the post processing can sometimes mistake real detail for comb artifacts and screw them up. You can turn that off with pp=0 (see the docs). You will sometimes get a source with orphaned fields -- fields where there is no complimentary field to complete the frame. TFM() may leave a combed frame in that case.

[Acetyl]

Interesting. I hadn't known what the "pp" parameter meant. That explains quite a bit.

Texhnolyze has a lot of slow scenes, with heavy grain, followed by abrupt switches to slow panning scenes, or bright ones. Abrupt fast motion as well. It's a good enough show I'll go through it manually to ensure the threshold for error is as close to 0 as it can be. Thanks for the information.

[jagabo]

An example of TFM's post processor screwing up. TFM(pp=0) on the left (correct), TFM() on the right:



Be sure to view the image full size.

[Acetyl]

I seem to have run into something odd. I'd come to the conclusion these files were soft telecined, with sporadic interlaced fields after sudden scene changes, or in places with high motion, strings of interlaced fields in some portions. But something seems awry, because there seems to be traces of hard pulldown scattered throughout as well. Removing all pulldown flags doesn't address them, or the fields that appear interlaced.

Mainly the chroma issues on fades from light to dark in frames DGIndex reports as progressive. Some scenes still show clear telecine patterns after removing pulldown flags, etc. Originally I thought I could just use the force film or DGPulldown methods to return it to a 23.976 state and run through selectively with either QTGMC or TDeint to attempt to fix any combing or interlacing. Maybe the fades are blended fields...

I thought soft pulldown flags didn't directly alter stream data? So now that I'm finding the above, it seems like I should just IVTC whether it's reported as soft pulldown or not, without altering the file first. But I feel like something isn't quite clicking. If the stream hasn't been altered, removing the flags and dealing with any issues afterwards should be a better solution.

I'll have to keep thinking... Apologies for the post length, maybe someone knows what I'm missing? I'm not exactly an expert to begin with. Samples below if anyone has the time or curiosity to check themselves. (Second sample is the interlaced fields every third frame. It's a bit morbid, to state in advance. Nothing too graphic though.)

Thinking in retrospect. If something was reading the pulldown flags, then (manual) inverse telecine would yield the same results anyway. But I feel like at that point it'd just be wading through interlaced frames and stray fields buried under "soft" telecine. I don't know.

http://www.mediafire.com/?hxhn0xay773uz4k
http://www.mediafire.com/?0yd59dwwxyadv0t

[jagabo]

Your files are mixed soft/hard telecine. You can't use "forced film" because of the hard telecined parts. TFM and TDecimate seemed to work fine:

Mpeg2Source("VTS_04_007.demuxed.m2v.demuxed.d2v", CPU=2, Info=3) 
TFM(d2v="VTS_04_007.demuxed.m2v.demuxed.d2v") 
TDecimate()

Ah, in the second clip, the shot of feet walking up the steps is a different frame rate -- 15 fps. There are two possible solutions, use variable frame rates in your encode or smart bob the entire video to 59.94 fps (essentially what you see when you watch the DVD).

Oh, there's one other solution, encode at 120 fps with 24 fps frames repeated 5 times, 15 fps frames repeated 8 times. If there are any 30 fps frames they'll be repeated 4 times.

[Selur]

something along the lines of:

Telecide(guide=0,gthresh=10,post=2,vthresh=50,dthresh=7,blend=false,chroma=true,back=0,bthresh=50,nt=10,hints=true) SetPlanarLegacyAlignment(True)
 Decimate(cycle=5,mode=0,threshold=0,threshold2=3,quality=2)

should be able to handle both clips,...

-> forget it

[Acetyl]

It appears that a VFR encode is the most viable approach. Looking through most episodes it seems they used interlaced fields to preserve smooth motion in many places, especially during pans. (Then just put a soft pulldown over it all.) What I'd like to do is selectively bob those sections to 59.94 fps and leave everything else as is, after telecide. I know x264 can encode that, given the proper timecode file... But AVISynth doesn't seem keen on changing fps output mid stream as this script stands. AVISynth can output a variable frame rate with the right scripting though as far as I'm aware, but I haven't the slightest how to approach that. Or define the fps change in each section.

This is the yatta generated script I'm working off. I plan to use QTGMC to interpolate the new fields.

SetMTMode(5, 6)
SetMTMode(2)
LoadPlugin("C:\Editing\Yatta\Plugins\tivtc.dll")
LoadPlugin("C:\Editing\Yatta\Plugins\dgdecode.dll")
LoadPlugin("C:\Editing\Yatta\Plugins\telecidehints.dll")
LoadPlugin("C:\Editing\Yatta\Plugins\fieldhint.dll")
LoadPlugin("C:\Editing\Yatta\Plugins\nnedi3.dll")


function Preset0(clip c) {
#Name: Default
c
return last
}

function Preset2(clip c) {
#Name: QTGMC
c
QTGMC(Preset="Placebo",EdiThreads=4,EdiMode="NNEDI3",NNeurons=4,EdiQual=2,SourceMatch=3,Lossless=2)
return last
}

DGDecode_Mpeg2Source("C:\Editing\Sources\Texhnolyze\Vol2\Ep5\E5.d2v")



FieldHint(ovr="C:\Editing\Sources\Texhnolyze\Vol2\Ep5\E5.d2v.fh.txt")
TelecideHints(NNEDI3())


PresetClip0=Preset0()
PresetClip2=Preset2()

PresetClip0.Trim(0,10512)+PresetClip2.Trim(10513,10682)+PresetClip0.Trim(10683,15148)+PresetClip2.Trim(15149,15251)+PresetClip0.Trim

(15252,15461)+PresetClip2.Trim(15462,15507)+PresetClip0.Trim(15508,15531)+PresetClip2.Trim(15532,15570)+PresetClip0.Trim(15571,16654)+PresetClip2.Trim

(16655,16655)+PresetClip0.Trim(16656,23120)+PresetClip2.Trim(23121,23178)+PresetClip0.Trim(23179,27864)+PresetClip2.Trim(27865,27912)+PresetClip0.Trim

(27913,29827)+PresetClip2.Trim(29828,29859)+PresetClip0.Trim(29860,35843)



TDecimate(mode=1,cycle=5,ovr="C:\Editing\Sources\Texhnolyze\Vol2\Ep5\E5.d2v.dec.txt")

Suggestions or feedback is appreciated. I've looked through a number of the AVISynth docs, but didn't find anything conclusive (yet). The end segment that defines how to process separately then combine the frame range that QTGMC is applied to seem like they'd be where the expected fps output could be defined. The overall syntax of how avisynth interprets script seems more like guesswork on my own part at the moment.

Edit - Or...couldn't the change in fps be indicated in the "function Preset2(clip c)" portion and interpreted across all the frame ranges it applies to?

[manono]

Looking through most episodes it seems they used interlaced fields to preserve smooth motion in many places, especially during pans. (Then just put a soft pulldown over it all.)

That makes no sense. If sections are pure interlace (each field from a different point in time), then there's no pulldown for them at all, soft or otherwise.

A sample might be helpful - one showing both types, interlaced and telecined.

...interlaced fields...

You mean interlaced frames, right? And you're doing this for DVD? Or for some other format? If you're thinking of doing a VFR encode, then I guess you're doing it for some other format.

[Acetyl]

Looking through most episodes it seems they used interlaced fields to preserve smooth motion in many places, especially during pans. (Then just put a soft pulldown over it all.)

That makes no sense. If sections are pure interlace (each field from a different point in time), then there's no pulldown for them at all, soft or otherwise.

The source seems (mainly) just soft pulldown. In the portions that do this, after matching up the fields (and finding the duplicate to decimate), there's still a pronounced combing. Any field interpolation comes out with choppy motion, so I came to the conclusion it must be discarding the bottom field and only interpolating to match the top one. Mainly because the fields that needed to be recreated were visible but no post processing would come up with them.

Maybe I'm misreading it. But if it was pure interlace, wouldn't it not conform to the ccnnc pattern?

A sample might be helpful - one showing both types, interlaced and telecined.

http://www.mediafire.com/?xvt0pj7r5zd470p
There are a few other places, but this is the one I'm focussing on as a main test.

...interlaced fields...

You mean interlaced frames, right? And you're doing this for DVD? Or for some other format? If you're thinking of doing a VFR encode, then I guess you're doing it for some other format.

I meant to say fields from what were originally separate frames before interlacing. Sorry, badly phrased.
The source is a DVD, but I'm not planning on playing it back via DVD. Mkv is the intended container.

[manono]

That's an interesting one, all right. But I don't see how making a VFR encode is going to help. Whatever field order you choose, you get some backwards motion when bobbed. And as you said, almost all of it is soft telecined. The first place where there's a problem is when the guy in the back seat of the car rolls down his window. Unfortunately, it's still too light where I am to view that dark sample properly and I'll have a look after it gets dark. Maybe someone else will chime in before then.

In the mean time, here's one result (MP4, less than 1MB):

[manono]

Later, now I can see. I can't get anything good out of TIVTC during the window-rolling-down scene or the two scenes later scrolling up a man's face. I see a few problems with the one I uploaded, but nothing too serious I don't think. And most can be fixed by adding something like 'TDeint(Full=False)' afterwards. The script I used, if you're interested was:

SmartDecimate(24,60,Bob=Yadif(Mode=1))#Can use a better bobber, if you prefer
LanczosResize(640,360)

I'd be curious is someone else can solve it but, as I said before, I don't think a VFR encode is the way to go.

[jagabo]

It looks like the motion was slowed in some shots by repeating interlaced frames. That causes back and forth motion when the fields are viewed individually. I don't see an easy way to fix that.

[Acetyl]

I've found a solution. As you mentioned jagabo, instead of a clean interlace...I can't actually tell what was done exactly. But it's fixed via interpolating the top field for two frames, then the bottom for two (followed by the decimated duplicate frame). At first I just used QTGMC's function to repair shimmering on progressive sources, but wasn't keen on the blurring (even though it reconstructed the frames almost perfectly). Using NNEDI3 I ended up looking and stumbling on the pattern, and specified which field to keep manually, instead of it reading from avisynth. Then just inserted post-telecide. Motion is smooth, NNEDI3 seems to be quite a good interpolator. No real...deficit that I can notice, whether knowing to look or otherwise.

Thought I'd report back on it, in case anyone was curious. Appreciate the assistance jagabo and manono.

I have another question though. I've read through the various x264 docs, and I can't seem to find an answer. Is it possible to specify two (or multiple) avs sources of different frame rates, have it encode both of them in sequence, and splice together the results / output a timecodes file? If it is possible, would I need to make a timecodes file manually first? The credits are full interlace and seem best bobbed, it'd be good to keep it all in one stream.

[Acetyl]

I also have another question, that isn't really enough to warrant its own thread. I have a 1080p file (originally on a blu-ray). Mediainfo reports it as 1080i though, and 29.970, but I'm certain this is not the case. When actually looking at the video frame by frame it's definitely 23.976 with a pulldown applied (to my knowledge blu-ray doesn't even support 29.970 progressive standardly?) Which is good, because if it's soft pulldown I can avoid re-encoding...

Usually I just use eac3to to remove the pulldown flags, but it doesn't seem keen on doing so with this file. I've tried both with the GUI I typically use, and commandline, each output a 29.970 file that's tagged as "interlaced". It's an odd problem...are there any switches to force AVC/h.264 pulldown removal if it isn't detected, or any other software / approach I'm not aware of that anyone knows of? Searching around has yielded no real information.

[manono]

I also have another question, that isn't really enough to warrant its own thread. I have a 1080p file (originally on a blu-ray). Mediainfo reports it as 1080i though, and 29.970, but I'm certain this is not the case.

What makes you so certain? If, while advancing a frame at a time, you see the telltale 3 progressive frames and 2 interlaced frames in every 5-frame sequence, it's hard telecined and interlaced 29.97fps.

to my knowledge blu-ray doesn't even support 29.970 progressive standardly?

Not progressive, you're correct. It does support interlaced 29.97fps, which yours is (apparently).

...because if it's soft pulldown I can avoid re-encoding...

If it's been encoded as interlaced, I doubt it's soft pulldown.

Usually I just use eac3to to remove the pulldown flags, but it doesn't seem keen on doing so with this file.

Maybe because there are no pulldown flags?

...or any other software / approach I'm not aware of that anyone knows of?

An IVTC back to progressive 23.976fps?

A sample might help, 10 seconds of steady movement.

[Acetyl]

What makes you so certain? If, while advancing a frame at a time, you see the telltale 3 progressive frames and 2 interlaced frames in every 5-frame sequence, it's hard telecined and interlaced 29.97fps.

This is what I'm seeing. However I saw the same pattern on other files of the disc, but they were demuxed cleanly (at 23.976). Maybe I jumped to conclusions thinking that applied to all the files though.

An IVTC back to progressive 23.976fps?

I suppose I could do that, but I'd hoped to avoid it (not that there's much choice if it is hard telecine). crf 0 encodes start getting ridiculous, but maybe I could do a lossy encode. Doesn't help that most free avisynth plugins for h264 don't work properly if at all. Is there any tool you're aware of similar to yatta, that supports h264 (for the actual field matching portion)? I just don't trust software to perform matching reliably, would rather chance human error if the option is there.

Though I could do manual overrides without yatta as well.

A sample might help, 10 seconds of steady movement.

I didn't know how to split the m2ts or h264 file cleanly, so I just muxed it into an mkv then split. Curiously though, when I set the fps to its supposed 30000/1001, it just displayed multiple duplicate frames in between the motion, and no interlaced frames. But when setting the fps to 24000/1001 it plays as it did when it was in an m2ts. If it was hard telecine, shouldn't the issues show up regardless of what is set by the container (Even if it's tracking rate as fields/s)? (Sorry if I'm missing something obvious, I'm a bit short on sleep and things don't seem to be clicking.)

Sample (I just let it set its own frame rate) -
http://www.mediafire.com/?6ak14m11hbb0xkk

[poisondeathray]

It looks like 23.976p content with hard 3:2 pulldown (ie. encoded interlaced), but the titles and overlays are 29.97p . Either way there are no flags to "remove" or ignore

Likely this was SD content upscaled (hence the pulldown) . It's rare for original HD blu-ray content to have pulldown since it supports 23.976p and 24p natively

[Acetyl]

I see. I must have misjudged entirely, because the other files were only soft pulldown. (Though now that I look at it closer, there's a lot of passive, and very minute aliasing / blurring throughout, so you're likely right about the SD upscale. Only stands to reason the extras wouldn't need the same treatment.)

Alright, I appreciate the feedback. I'll have to keep looking for decent solutions. Don't really mind if the title's motion becomes a bit jittery...have to see what I can do with it.

[manono]

Don't really mind if the title's motion becomes a bit jittery...have to see what I can do with it.

Yeah, since there's so little of it, then I might just IVTC it and be done with it. Or, if for DVD, keep the titles part interlaced 29.97fps and encode the rest as progressive 23.976fps with pulldown and rejoin them during authoring. Or, if for something else, do a VFR encode with the titles section at 29.97fps (even progressive, if necessary) and the rest at progressive 23.976fps.

[Acetyl]

It seems another disc has the opening segment at 23.976, albeit a clean version without titles at all. This remains an option I suppose, if I can't find a better solution.

I'm not sure what this forum's policy on OPs cluttering up their threads with multiple topics is. But I figure everything evolves, and it's better than littering other sections with unnecessary threads. On the note of the first show, does anyone know of any application for working with timecode files...more specifically merging them? I figure if I could encode the episode, them bob the credits separately, and splice them together. I could take x264's 2 outputted timecode files, tack the timings onto the end of the first. Issue being, that's a lot of values to change...seems like it's a simple enough operation but I'm not a programmer, can't really make that happen. In either case, I'd imagine the frame rate would be properly read between the two merged clips at that point (intended container being MKV).

That's in theory. Unless there's something I'm missing?

[Acetyl]

So...yeah, it's this thread and I again. I seem to have more or less solved all the other issues, I guess I was just missing some things I should have been seeing but wasn't seeing nor thinking...or thinking to think. But I do have what seems like the last issue I'm not really certain how to approach.

As I said before I fixed the repeated interlaced fields, and recovered the "original" frames. But I'm guessing since I had to do so by specifying NNEDI3 keep the opposite field it otherwise wanted to, it's wrongly interpreting some black portions at the top of the frames and interpolating the fields accordingly. This causes a jittering at the top, that tends to be fairly visible in some brighter scenes. I'm not sure how to approach this, as all other field interpolators / deinterlacers produce (roughly) the same. Though a few of them I have yet to dig deeper into their settings. Can't really explain properly and made a quick GIF. Resized 2x.



Could probably stand to leave it as is, but it'd be more satisfying to figure a real solution. Trying to avoid cropping in any case. Maybe I should learn some actual scripting.

[jagabo]

Field interpolators always produce that "bob" -- hence the name of the Bob() filter. If the bounce at the top/bottom of the frame bothers you crop it away. But it usually appears on all sharp horizontal edges.