"Ghosting" in PAL Rips

[mirkosp]

PAL footage is most commonly blended in-source. Unblending it is almost always impossible, but if doable, requires frame by frame difference weighting between a clean and a blended frame; the results aren't perfect and it's only half decent if there are enough clean frames and there aren't many compression artefacts, which due to the amount of episodes per dvd in PAL releases is rarely the case.

So scratching that solution, the least bad approach you have to deal with a field blended source (even if it's NTSC and not PAL) that can't be unblended in semi-automatic and feasible manners is to simply bob to the field rate, possibly with a high quality bobber (look into qtgmc) and then edit with the field rate as the frame rate, which in the case of PAL it means you should edit at 50fps.
This way, with the fast playback speed, the blending will be less noticeable in most scenes, since the single frames are running by so fast.

Doing a simple deinterlace at 25fps or trying to go 24 will only get you with more visible blending and possibly motion stutter as well, unless you feel like manually unblending the frames one way or the other ─ in the worst and most common cases, this mean opening up photoshop and redrawing large chunks of the source; I don't suggest going down this route.

[l33tmeatwad]

@mirkosp Just fyi, if you didn't look at his second upload, the video was not actually blended, it was interlaced and was getting blended in his original ripping process.

[mirkosp]

Do a separatefields() and check the single fields (I suggest doing an assumetff() first) on the second upload. It's field blended.
Then again with the fades and overlays, it takes a bit to make sure, when there's the pan with the dogs.
Some clean fields are there, but not all fields are clean. Could very well be some lossy re-encode mess, though.

An actual m2v split would be an optimal sample to make 100% sure it isn't a re-encode issue.
From dgindex, use [ and ] to cut a bit and then do "Save Project and Demux Video," then you'll get a m2v file to share. A pan with no fades, like the one with the dogs I mentioned above, would be optimal to tell if it's field blended or not.

I'm quite positive it's going to be field blended, though. Euro pulldown PAL is almost always soft pulldown, when there weren't vfr things to deal with in the original sources, which means that the report would look different than what he posted. But euro pulldown PAL is rare. Speedup is more common than pulldown, and with speedup I mean 24p->25p speedup, which isn't the case. Never seen a 60i -> 50i slowdown ever done, either blending, or ivtc->pulldown, or a mix in case of vfr (I've seen mocomp done as well, but that's even less common).

[l33tmeatwad]

I'm quite positive it's going to be field blended, though.

The frame he points out in the original as being blended is an interlaced frame in the second video example he posted...but yeah, a raw example would probably be the easiest way to figure it out.

[mirkosp]

It is interlaced, but you have to look at the single fields. Here's the sequence of 3 fields in that place, taken from the avi he shared later on:







They are fields 1425, 1426, and 1427 when doing assumetff().separatefields(), and as you can see the second one is fully blended, while the third shows a blended chroma. Like I said, could be some derpiness from the lossy re-encode (quite possible and dare I say most likely for the chroma issue in the third screenshot, but I'm not too convinced about the second one), and to make 100% sure we need the m2v, but having worked with countless PAL sources, my gut feeling says it's field blended to begin with.

[l33tmeatwad]

Ah, I didn't really play around with it, but I am not surprised...I don't think I've ever seen a clean NTSC to PAL transfer (not that they don't exist...)