Help with bizzarre interlacing

[eriler]

Hi,

I have a problem with the interlacing of something i'm trying to encode, and i think i need some help with the deinterlacing on this.
The source seems to be interlaced AAABBABBAAABBAAABBAAABBABBBBBABBA

Note that the above is probably wrong, it just seems too bizzarre, the souce seems like a mix of interlacing and the animator drawing a clear picture with a weaker picture on top to better animate movements, but i'm not sure.

After deinterlacing it with this script:
DGDecode_mpeg2source("C:\VTS_05_1.d2v", info=3, cpu=6)

crop( 4, 58, -4, -58)

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


ColorMatrix(interlaced=true)
ConvertToYV12()

I get results like this, where the color is shifted, and there are still seemingly interlaced frames left as well.
http://puu.sh/7F2BX.jpg
I also found this (Not included in the clip of the source under), so there is definitely something wrong: http://puu.sh/7F3Zd.png

Here is a clip of the source:
https://mega.co.nz/#!WdUjhRjS!veAKis5D8Kw_st-H-GLFWi4QAoW5oLPUuYKrjBz39ZA

Is anyone able to find out how it's interlaced and possibly a solution to it?

[feisty2]

is your clip yuy2? if it is use ConvertToYV12(interlaced=true), if not (yv12) u need to remove chroma blend

[eriler]

It seems it already is YUV 4:2:0, so i shouldn't be using ConvertToYV12 at all, though that doesn't really change anything on the encode visual-wise.

Edit:

When deinterlacing with (This was just an experiment, i know it's probably not best to deinterlace with this):
tdeint()
AssumeTFF()
Telecide(guide=1,chroma=true)

I get this:
http://puu.sh/7F7rA.jpg

Instead of what i'd get with the script in the first post:
http://puu.sh/7F7Ci.png

[lansing]

upload the sample that you are talking about.

[eriler]

upload the sample that you are talking about.


Here is a clip of the source:
https://mega.co.nz/#!WdUjhRjS!veAKis5D8Kw_st-H-GLFWi4QAoW5oLPUuYKrjBz39ZA


I posted it in the first post.

[lansing]

I posted it in the first post.

post a sample that shows the obvious problem. The one you put up is a bad sample because people can't really see what's going on with those dot pattern in the way.

[eriler]

The first sample contains the first frame i posted an image of, which does show the problem, but i've cut out another sample for you which shows the frames where the girl with the frog is (At about 30 seconds in), this doesn't have any dots, so it should be easier to analyze. The first few frames in the sample seems to have been slightly corrupted by the video cutting software i used, so disregard them, but everything else should be proper.

https://mega.co.nz/#!zAEDQDrb!ijAIuBGFUL8pBMkG7ciFeR00GIUEu7UNpTk0pULu2Ho

[lansing]

your source is anime, so 99% of the time you will need ivtc, not deinterlace. And you should not crop the video before ivtc.

I ran the common ivtc and it looks perfect to me, I didn't see any chroma blend in the sample
mpeg2source("abc.d2v")
tfm().tdecimate()

[feisty2]

Sorry, I was completely outta my tree, just ignore what I said before, u converted ur clip to yv12 after tfm and there's nothing wrong with it, so what u really need is deblend and do remove interlaced=true from color matrix cuz ur clip ain't interlaced any more after tfm

[feisty2]

replace tfm.tdecimate with the script below

luma = tfm(pp=0, slow=2)
chroma = vinverse().Srestore(omode="PP3", cache=10)

# manual sync: figure out which frame (previous,current aka p,c) of 'chroma' clip is most similar to current frame of 'luma' clip

# 46*log(|x-y|+1) uses the full [0,255]-range and scales little differences better than |x-y|*2
diffp = mt_lutxy(luma,chroma.selectevery(1,-1),"x y - abs 1 + log 46 *")
diffc = mt_lutxy(luma,chroma, "x y - abs 1 + log 46 *")

# average difference between compared frames
mp = mt_lutf(diffp,diffp,"avg",expr="x")
mc = mt_lutf(diffc,diffc,"avg",expr="x")

# build conditional masks based on the caculated comparisons
maskp = mt_lutxy(mp,mc,"x y < 255 0 ?")

# finally merge the luma of the tfm with the chroma of the srestore clip accordingly to the binary mask
MergeChroma(luma,chroma).mt_merge(chroma.selectevery(1,-1),maskp,luma=true,Y=2,U=3,V=3)


edit: sorry, can't remember where it's originally from

[eriler]

your source is anime, so 99% of the time you will need ivtc, not deinterlace. And you should not crop the video before ivtc.

I ran the common ivtc and it looks perfect to me, I didn't see any chroma blend in the sample
mpeg2source("abc.d2v")
tfm().tdecimate()

Wow, it would seem it was having the crop in the wrong place was the cause of the chroma shift(?) / blend in all 3 places i used as examples, and i don't see any more anywhere. But i still have frames like these:
http://puu.sh/7G76C.jpg
So it still seems to be telecined some places.

replace tfm.tdecimate with the script below

luma = tfm(pp=0, slow=2)
chroma = vinverse().Srestore(omode="PP3", cache=10)

# manual sync: figure out which frame (previous,current aka p,c) of 'chroma' clip is most similar to current frame of 'luma' clip

# 46*log(|x-y|+1) uses the full [0,255]-range and scales little differences better than |x-y|*2
diffp = mt_lutxy(luma,chroma.selectevery(1,-1),"x y - abs 1 + log 46 *")
diffc = mt_lutxy(luma,chroma, "x y - abs 1 + log 46 *")

# average difference between compared frames
mp = mt_lutf(diffp,diffp,"avg",expr="x")
mc = mt_lutf(diffc,diffc,"avg",expr="x")

# build conditional masks based on the caculated comparisons
maskp = mt_lutxy(mp,mc,"x y < 255 0 ?")

# finally merge the luma of the tfm with the chroma of the srestore clip accordingly to the binary mask
MergeChroma(luma,chroma).mt_merge(chroma.selectevery(1,-1),maskp,luma=true,Y=2,U=3,V=3)


edit: sorry, can't remember where it's originally from

I tried this script as well, but i couldn't get it to work well. For the script i needed srestore.avs, and all the requirements for that, but the latest version of srestore_2.7g.avsi wouldn't work, and the previous versions were giving me "Attempted to read or write protected memory, indication of corrupt memory" error messages.
LoadPlugin("C:\AviSynth\plugins\RemoveGrain.dll")
LoadPlugin("C:\AviSynth\plugins\TIVTC.dll")
import("C:\AviSynth\plugins\srestore.avs")
loadplugin("C:\AviSynth\plugins\average-codeblock\src\Release\Average.dll")
loadplugin("C:\AviSynth\plugins\GRunT.dll")

loadplugin("C:\AviSynth\plugins\masktools-v2.0a48\mt_masktools-26.dll")

loadplugin("C:\AviSynth\plugins\colormatrix.dll")
Import("C:\AviSynth\plugins\Vinverse.avsi")


LoadPlugin("C:\dgindex\DGDecode.dll")
DGDecode_mpeg2source("C:\VIDEO_TS\VTS_05_1.d2v", info=3, cpu=6)

luma = tfm(pp=0, slow=2)
chroma = vinverse().Srestore(omode="PP3", cache=10)

# manual sync: figure out which frame (previous,current aka p,c) of 'chroma' clip is most similar to current frame of 'luma' clip

# 46*log(|x-y|+1) uses the full [0,255]-range and scales little differences better than |x-y|*2
diffp = mt_lutxy(luma,chroma.selectevery(1,-1),"x y - abs 1 + log 46 *")
diffc = mt_lutxy(luma,chroma, "x y - abs 1 + log 46 *")

# average difference between compared frames
mp = mt_lutf(diffp,diffp,"avg",expr="x")
mc = mt_lutf(diffc,diffc,"avg",expr="x")

# build conditional masks based on the caculated comparisons
maskp = mt_lutxy(mp,mc,"x y < 255 0 ?")

# finally merge the luma of the tfm with the chroma of the srestore clip accordingly to the binary mask
MergeChroma(luma,chroma).mt_merge(chroma.selectevery(1,-1),maskp,luma=true,Y=2,U=3,V=3)


crop( 4, 58, -4, -58)

ColorMatrix()

[feisty2]

The latest srestore should work, the script needs strict linear access so just randomly jumping to some frame (like preview) will give u broken output, but encode the script should be okay

[eriler]

Right. It was the preview thing i was doing :rolleyes:

I'll encode it and see.

[eriler]

I finished the encode with the script i posted above in post #11 and it isn't IVTC'ed, and the chroma blend still remains. Though oddly the girl with the frog didn't show chroma blending (Probably has something to do with the decimation from 29.97 to 23.976 fps that wasn't in the script).

http://puu.sh/7GeUF.png

http://puu.sh/7GeVn.png

[feisty2]

after "xxxsource"
add "utoy ()" to your script and post the image you got then replace it with "vtoy ()" and post the image too
edit: if it isn't chroma blending, my guess would be plane y,u,v are running out of sync, you need to decimate 3 planes manually and separately to make them synchronized again

[eriler]

There is no "xxxsource" anywhere in the script. Did you mean after "DGDecode_mpeg2source("C:\VIDEO_TS\VTS_05_1.d2v", info=3, cpu=6)" ?


DGDecode_mpeg2source("C:\VIDEO_TS\VTS_05_1.d2v", info=3, cpu=6)
utoy()

??

This is how it ends up then:
http://puu.sh/7Gh6r.png

[feisty2]

can you try to post an "interlaced" frame, i cant see anything wrong with this frame

[eriler]

can you try to post an "interlaced" frame, i cant see anything wrong with this frame

Oh, it was supposed to be that small?

I checked both utoy and vtoy now, and nether look faulty or out of sync on the frame with the redhaired girl in post #14.

utoy:
http://puu.sh/7GjTF.png

vtoy:
http://puu.sh/7GjUI.png

[feisty2]

I can see the issue now, the chroma is not blended but not synced to luma, you need to do a manual decimate to make luma and chroma synced, use "ovr" function in tdecimate

[eriler]

To use an override file? But i have no idea how to make one that'll decimate chroma and luma separately and sync them. The help file for tdecimate doesn't specify it either.

Although, as lansing said, when IVTCing with just tfm().tdecimate() and where the crop part is after the IVTC part (See picture post #11), the chroma and luma were in sync, the only problem then was some telecined frames remaining because of the bizzarre telecining pattern this video has. Wouldn't the solution lie more towards tweaking a IVTC plugin to handle the unusual pattern (tdecimate, QTGMC, yadif)?

[feisty2]

I don't get it, why would cropping (spacial filter) cause a chroma out sync (temporal problem)

[Guest]

OK, what am I missing? :)

With this simple script, there is no problem in the frog scene you posted (with or without the crop):

dgsource("VTS_05_1(00h05m04s-00h05m54s) (1).dgi")
crop( 4, 58, -4, -58)
telecide()

[eriler]

OK, what am I missing? :)

With this simple script, there is no problem in the frog scene you posted:

dgsource("VTS_05_1(00h05m04s-00h05m54s) (1).dgi")
telecide()

So far the chroma being out of sync seems to have been caused by the crop being wrongly placed in my script.

If you look at the picture in post #11, and take the sample at the bottom of post #1 and try the same script you did on the second sample, you'll see (I use the part with the yellow-haired girl when stepping through the frames) that it's not completely IVTC'd.

Edit:
I litterally go from
http://puu.sh/7Gqiq.jpg
to
http://puu.sh/7Gqn6.jpg
When i have crop in the wrong place.

Edit2:
Excuse the ColorMatrix(Interlaced=true), i just removed the interlaced=true part, and check, it did no visual difference on either one.

Edit3:
I see you index the file in .dgi while i use .d2v, i don't suppose that makes any difference? I also use info=3, and cpu=6 in my dgdecode.

[Guest]

Your top crop has to be a multiple of 4 to avoid the effect. This second scene has field blending so that complicates things.

Please advise the title and region of the DVD.

[eriler]

The DVD is R1 region, and the title of the DVD box set is "VanDread: The Ultimate Collection".

Why does the top crop have to be dividable by 4? I always thought dividable by 2 was the rule. And does it in that case only apply to the top crop?

[Guest]

It's well-known that a crop of 1 on the top for luma is equivalent to a one-field shift (this is used in some field swap filters). When you crop by 2 you get a crop of 2 for luma and a crop of 1 for chroma (because chroma is subsampled). Thus you shift the chroma by one field but not the luma.

A bottom crop will not have this field shift effect.

[eriler]

This seems to do the trick on the yellow haired girl, and none of the other examples i've used in this thread show any chroma out of sync, or remaining telecine.

AnimeIVTC(mode=2, bbob=4, chrfix=true)

crop( 4, 58, -4, -58)

trim(44,33023)

ColorMatrix()


Another thing, with Telecide(), the runtime of the episode is ~18 minutes, and with this script here it's ~23 minutes (The latter is 99.9% likely the correct runtime), and the framecount is the same on both.

Should i go with top crop 54 or 60? I'll either get 2 pixels of black bars, or crop away 2 pixels of good video then..

Also, do you have any other inputs on improvements, or do you think this is a good script for the deinterlacing this video?

[Guest]

Another thing, with Telecide(), the runtime of the episode is ~18 minutes, and with this script here it's ~23 minutes (The latter is 99.9% likely the correct runtime), and the framecount is the same on both. I don't have the whole episode so I can't comment specifically. The difference between 18 and 23 is accounted for by the decimation associated with IVTC. I don't know what AnimeIVTC does.

Should i go with top crop 54 or 60? I'll either get 2 pixels of black bars, or crop away 2 pixels of good video then.. Your choice.

Also, do you have any other inputs on improvements, or do you think this is a good script for the deinterlacing this video? I don't know AnimeIVTC.

If you have field blending then you need to do something about it as simple IVTC will not suffice. If AnimeIVTC is doing that for you, then be happy.

[eriler]

But even though the chroma shift looks fine now, should i really make it dividable by 4? What would the difference be?

Also, thank you for your help so far.

And if i may, i have one more issue with the DVD (A different disc in the same series) with the audio for each episode being out of sync. Through hearing for where it starts and ends and matching lip movements, i've managed to get it approximately right, but it's still no good solution. The The cuts for the video differ completely from the cuts of the audio:
Episode 1: Video: trim(21, 34474) Audio: 2,34470
Episode 2: Video: trim(34516, 67534) Audio: 34467,67534
Episode 3: Video: trim(67563, 100589) Audio: 67494,100589
Episode 4: Video: trim(100610, 133633) Audio: 100520,133633
...
Episode 7: Video: trim(199752, 232775) Audio: 199602,232775
The trim on the video is after IVTC and the framerate on the audio is 23,976.

As you can see, they're far from identical, and they don't have the same constant offset.

Do you have any ideas as to how to fix this so the same cuts can be used on both the video and the audio?

[Guest]

But even though the chroma shift looks fine now, should i really make it dividable by 4? What would the difference be? As I said, I don't know what AnimeIVTC is doing. You have moved the crop to after the AnimeIVTC call, so if it has upsampled the chroma, then the field shift will not occur.

And if i may, i have one more issue with the DVD (A different disc in the same series) with the audio for each episode being out of sync. Through hearing for where it starts and ends and matching lip movements, i've managed to get it approximately right, but it's still no good solution. The The cuts for the video differ completely from the cuts of the audio:
Episode 1: Video: trim(21, 34474) Audio: 2,34470
Episode 2: Video: trim(34516, 67534) Audio: 34467,67534
Episode 3: Video: trim(67563, 100589) Audio: 67494,100589
Episode 4: Video: trim(100610, 133633) Audio: 100520,133633
...
Episode 7: Video: trim(199752, 232775) Audio: 199602,232775
The trim on the video is after IVTC and the framerate on the audio is 23,976.

As you can see, they're far from identical, and they don't have the same constant offset. Do you have any ideas as to how to fix this so the same cuts can be used on both the video and the audio? First, it's off topic for your own thread! You need to create a new thread or change the title.

Anyway I don't understand your statement of the problem, and I don't like to get involved in people's random AV sync issues, unless it can be attributed to a problem with my tools. Maybe someone else can help you with it.

[lansing]

don't complicate things, the main story shouldn't have any problem with correct order of ivtc.

The single issue from the samples is the opening part with the dot pattern. Doing a separatefields() can see that there is field-blending output at 29.97fps, and a 30fps interlaced credit put on top of that.
So a straightforward approach is to simply use srestore to deblend the animation part back to 23.976fps.


mpeg2source("abc.d2v")
qtgmc(preset=medium) # or some other faster bobber
srestore(23.976)


Since the frame rate of the animation and the credit is not equal anymore, some frames from the credit part will be thrown away in the process, but who cares, it's just a few frames.

[eriler]

I understand. I'm making the encode now, but presumably it's going to be a-ok. Thank you for your help.

I'm sorry for going off topic in my own thread, that's why i asked "If i may", i knew it was a long shot.

Edit, was making my post when you posted:
don't complicate things, the main story shouldn't have any problem with correct order of ivtc.

The single issue from the samples is the opening part with the dot pattern. Doing a separatefields() can see that there is field-blending output at 29.97fps, and a 30fps interlaced credit put on top of that.
So a straightforward approach is to simply use srestore to deblend the animation part back to 23.976fps.


mpeg2source("abc.d2v")
qtgmc(preset=medium) # or some other faster bobber
srestore(23.976)


Since the frame rate of the animation and the credit is not equal anymore, some frames from the credit part will be thrown away in the process, but who cares, it's just a few frames.

With AnimeIVTC it gets bobbed with TGMC, it also required srestore to be a loaded plugin, so i reckon it uses that as well.

[jpsdr]

Vandread is horible in interlacing mode. In anime, you have different kind of interlacing.
Lucky, you have a standard pulldown, and with a simple avisynth pulldown(x,y) you can do the whole thing.
A little less lucky, you have different pulldown sequence for "opening", "first part" (eyecatch), "second part", "ending", "preview".
Nevertheless, with eventualy 5 different pulldown you do the whole thing. These are still "reversible" => you can retrieve the original footage.
After, you are less lucky.
In old footages you can find two "irreversible" mode.
One, where you'll have one progressive frame, 2 "strong interlaced" and two "little interlaced". The interlaced is made with some kind of blending.
Another, you'll have one progressive frame, and 4 interlaced frames. The first two the interlaced have a "V" form, the second two have a "reverse V" form.
Time going, there is less and less of these, as new HD progressive masters are re-made for blu-ray, using the original film footage.
And, the last, appeared around the years 2000, when digital productions appeared. Reversible, but a "pain in the ass". You have standard pulldown sequence, but the position of the pulldown change almost at each scene change. It seems that when they produce the anime, instead of creating the whole thing at 23.976fps, and doing the pulldown after, they have done each scene, and apply pullwdown scene by scene. For these, there is not original "film" footage. But, it's still reversible. I've personnaly done a VDub filter which try to detect and work with this kind of footage (i think animeIVTC is doing something similar). I've personnaly use it on several animes like Hellsing, Kiddy Grade, Full Metal Panic, Hack sign.
And, one day, i've tried Vandread... and give up ! Never seen a such total mess ! ... Maybe Crest/Banner of the stars are also in the same mess.
Unfortunately, you may try to IVTC one of the few title it's propably impossible to do.

[eriler]

AnimeIVTC worked wonders on the opening, almost. It fixed all the abovementioned problems, but it drops a good frame occasionally, so i get a jerk here and there in the video.

qtgmc(preset=medium) # or some other faster bobber
srestore(23.976)
Did not work either. Chroma was out of sync with this script. I used placebo preset instead of medium preset too.

And apparantly, 58 top crop is multiplicative by 4, because i got "This top crop is not multiplicative by 4" errors when i tried changing it to 54 or 60, so that shouldn't be the cause of the chroma shift.

So back to scratch, are there any suggestions to a bobber which might take care of this field-blended opening?

[lansing]

post your entire script, I ran the srestore on the opening and I didn't see any chroma shift. And cropping has nothing to with this, so please leave it out of the discussion before further confusion.

[ChiDragon]

And apparantly, 58 top crop is multiplicative by 4

A calculator is all you need to tell you that 58/4 is not a whole number. The error message appears when your total crop for the frame isn't divisible by 4, but neuron2 already pointed out how you can field-shift the chroma by cropping the top by increments less than 4.