Any recommendations for fixing/unblending this?

[hello_hello]

I have an old PAL DVD which is nothing like I've seen before. I assume it was shot in PAL (well it's an old Australian mini-series shot in Australia) and it's interlaced, but seems to still have blended frames of sorts. It's kind of like the colours from one frame bleed into the next. And the interlacing is nothing like I've seen before. Instead of the fields containing every second scan line, it's almost like it's progressive video, but for every second field, the whole image has simply been squished down a bit. There's often no actual motion from field to field, just field blending of some sort where the colours almost seem to be a frame ahead of the actual video.

QTGMC seems to clean it up fairly well (the video is very noisy) and eliminates most of the bobbing up and down, but the "bleeding" between frames remains. And given the way it's "interlaced", if it's actually interlaced, de-interlacing to 50 fps just seems to result in every frame being repeated. It's not something which is terribly noticeable when watching the video at normal speed, but is there any way to "unblend" the frames, or am I dreaming and just need to live with it?

Here's a screenshot of three successive frames to show what I'm trying to fix, and attached is a little sample of the video. Stepping through it frame by frame should make the problem fairly obvious.
Actually if anyone has an explanation as to why the video is like it is, I'd be keen to hear it. I also don't understand why at every scene change, the last frame and then the first have a distinct lack of colour.
Cheers.

[jagabo]

Interlaced YV12 chroma was incorrectly treated as progressive chroma at some point. That has caused the colors of the two fields to blend together. I don't know any way to fix the problem. Did someone use VirtualDub in the preparation of this video? That's a very common source of this problem -- VirtualDub doesn't handle interlaced YV12 properly.

[2Bdecided]

Ideally you shouldn't bob this - it's not interlaced, just phase shifted. A simple...

separatefields()
trim(1,0)
weave()

would normally fix it.

However, after blending the chroma wasn't field shifted (or it was blended after everything was field shifted), and so what you have doesn't need that treatment on the chroma. So you need...

mpeg2source("1 blended chroma.d2v")

a=last

separatefields()
trim(1,0)
weave()

mergechroma(a)

Worst still, it's a lousy telecine and the fields are misaligned. running qtgmc after the above (using a suitable mode) will probably help.

None of this solves the chroma bleed, but it looks better in other respects.

There are no unique chroma frames or fields - everything is blended (always current with next after the above processing). Ask on the doom9 forums (though I'm not hopeful).

Cheers,
David.

[hello_hello]

jagabo, the video is directly from a pressed DVD. It's not a "home video" of any sort.

2Bdecided, thanks. I'll try your suggestion later today when I have a chance to play around again.

[Selur]

have you tried running HDRAGC?

[manono]

TFM(Chroma=True)

seems to clean it up.

[jagabo]

TFM(Chroma=True)

seems to clean it up.

That's not what I saw. It made it better on some frames, worse on others.

[manono]

Oh yeah, you're right. It's just around the scene changes, isn't it? Then here's a workaround that repeats the previous and next good frames at the scene changes:

TFM(PP=0)
A=Last
prev = A.selectevery(1,-1)
next = A.selectevery(1,1)
SCclean = A.SCSelect(next,prev,A,dfactor=2.0) # 2.0 ~ 5.0
SCClean

It requires RemoveDirt and came from Didée.

[jagabo]

It's just around the scene changes, isn't it?

The scenes in the clip didn't have much motion so it wasn't often visible. But any time anything colorful moves fast he'll see the same problem.

[hello_hello]

Yeah, about halfway in (I think so, I deleted the clip I uploaded) the soldier on the horse raises his arm and you can see the colour of his shirt sleeve seems to be a frame ahead of the movement of his arm. The whole video is like that. Either there's colour which appears to be ahead or it's a frame behind. It looks a lot like motion blur when watching the video in real time so isn't all that offensive, and you'd most likely only see it on scene changes (my brain seems to interpret it like there's a quick "flash" of something), but I just wondered if there was a way to fix it. I figured probably not, but it couldn't hurt to ask.

I haven't had a chance to experiment again yet, but I'll try your idea too manono. Thanks.

[manono]

The scenes in the clip didn't have much motion so it wasn't often visible. But any time anything colorful moves fast he'll see the same problem.

Right again. Darn it.

I concentrated on the officer raising his arm beginning about 7.5 seconds into the sample and there are no good fields to use. Either the orange is above or it's below the arm as it goes up. And Chroma=True, while it removes the interlaced-looking orange stuff, only makes it solidly orange above or below the arm, depending on which field is being matched. I think I now agree this thing is hopeless and it can only be cleaned up marginally.

I think I'd go with my last script (since the scene changes are so nasty), but use Chroma=True inside of TFM. it's still not a very good solution. Thanks for pointing out the messy parts.

Edit: Hello_hello posted while I was still working on this. Yes, it's the officer on horseback raising his arm that helped me decide this thing was hopeless.

[hello_hello]

have you tried running HDRAGC?

Thanks for that Selur. I missed your post originally. I'd never heard of HDRAGC. I don't think it's going to help with the problem I originally asked about, but some of the episodes are a fair distaster in terms of varying luminance levels, so I've been playing with HDRAGC for the last hour or so. It might save me all the manual work I'd been having to do. Once I've driven myself a little mad experimenting with it, I'll get back to the original problem. Cheers.

[2Bdecided]

Can I repost this bit - you all ignored it...

There are no unique chroma frames or fields - everything is blended (always current with next after the above processing). Ask on the doom9 forums (though I'm not hopeful).

Cheers,
David.

[hello_hello]

Can I repost this bit - you all ignored it...

Not me!

Thanks for the suggestions guys. After being distracted by the frame-rate/de-interlacing thread playing with HDRAGC and having to work for a change, I finally got back to this, and after more playing around I decided just to leave it at letting QTGMC do it's thing. I was going to combine that with manono's suggestion for duplicating the frames around each scene change, and it works well, but I found the little "pause" at scene changes a bit more distracting than simply letting them fade/bleed into each other, so I've just stuck with QTGMC.
The end result is watchable, and the chroma bleed really just looks like a bit of extra motion blur at normal speed (at least to me), so it's not worth stressing over any further.

Thanks again.

[jagabo]

Can I repost this bit - you all ignored it...

There are no unique chroma frames or fields - everything is blended (always current with next after the above processing). Ask on the doom9 forums (though I'm not hopeful).

I said the same thing in the post before yours.

[hello_hello]

Well QTGMC came to the rescue a bit. Again.

I just used this:

QTGMC(sharpness=0.7)
SelectEven()

And it did a good job on the scene changes. I guess when I ran a little test encode before starting this thread I didn't notice. My earlier screenshots were taken with standard de-interlacing applied. Once QTGMC did it's thing it pretty much eliminated a bad frame one side of every scene change. So my screenshots went from the three I posted above compromising the scene change, to just two frames, so to speak. One crappy intermediate frame is no longer there. The color difference compared to my earlier screenshots is something I applied manually and the picture was resized to the correct aspect ratio this time.



It also stabilised the colours nicely in places. In the case of the soldier lifting his arm as discussed in the sample I posted.... well it couldn't do much about that, but where there was less movement and the chroma seemed to still move a frame ahead or behind the action, it now looks a lot more stable. Like it's part of the correct frame. A bit hard to explain really, but QTGMC did a pretty good job.

Thanks for the interest guys.

[hello_hello]

While I was at it, I though I'd pan and scan it and encode a 16:9 version too. I'm not sure I'll do that again in too much of a hurry. It took adding a fair few "trims" to the script to do it.