Getting rid of strange motion-based blends

[bkman]

Hey, I have an odd PAL DVD source here that has blended fields based on the scene motion. If there is little motion then there there are no blended fields (so that section can simply be woven), if there is medium motion then every second set of fields is blended with the next set, and if there is high motion there are two blended sets of fields after every one unblended. At least that is what I gather.

I can remove most of the blends with tdeint(mode=1, tryweave=true).selecteven() but the third case where there are two blends in a row messes this up for a while. Any idea as to how I can get rid of the whole lot of the blends?

[bkman]

Nobody has any idea?

[Boulder]

Maybe you should post a small unprocessed sample, probably nobody can help you without seeing the actual issue. (Can't promise that I can help even in that case ;))

[bkman]

Ok, I hope this page gets my problem across: http://thehandofkwll.googlepages.com/exampleofblends

[Boulder]

Can you post a short unprocessed video clip, maybe 25-50 frames will do. There are some very knowledgeable people here who might be able to get a good pattern out of there.

[bkman]

The problem is that I'm fairly sure there is no pattern. The source has no blends for most of it's duration and those sections can simply be woven to retrieve original frames. As I said, I have perceived the amount of blends to be scene-motion dependant. Has anyone heard of a mastering process which results in this?

What I really need is either some way to detect blends and remove them, or at least just detect the "two blended frames in a row" phenomenon. I'll try and illustrate what is happening even further:

(bobbed with tdeint(mode=1, tryweave=true)

@ = unblended woven frame
* = unblended line-doubled (bobbed) frame
# = bobbed blended frame
<- frame taken after selecteven()

Example stream:

@ <- (woven with next)
@
@ <-
@
* <- (can't be woven without combing)
#
* <- (blends are skipped)
#
* <-
#
# <- (extra blend breaks the pattern)
*
# <- (blend ends up in the final video)
*
# <-
*
# <- (another extra blend corrects the pattern again)
#
* <-
#
* <-

[Mug Funky]

Has anyone heard of a mastering process which results in this?

splicing 2 sources together? one with blends the other without?

or a standards converter with threshold-based aperture control? i haven't seen one of these, but that's not to say none exist. there are converters out there that reset their pattern on scenechanges to avoid (compression unfriendly) blended, interlaced scene cuts.

if you were to post a sample we could suss this source out. at the very least, info on what source it is would be good (DVD or other? region? title?).

[Guest]

As I said, I have perceived the amount of blends to be scene-motion dependent.
It seems pretty obvious to me that in a scene with no motion, blended fields would not show any ghosting (and so would seem to not be blends), just as you do not see combing in a static interlaced clip. You wouldn't need any special mastering to produce that effect.

I second Mug's call for a source clip.

[bkman]

It seems pretty obvious to me that in a scene with no motion, blended fields would not show any ghosting (and so would seem to not be blends), just as you do not see combing in a static interlaced clip.

But there is no ghosting in "low" motion as well as no motion. People walking and talking for instance doesn't exhibit any blended fields, but fighting (fast motion), fullscreen effects and scene changes often do. I really think it's some sort of interlaced motion compensation as the motion looks nice and smooth on my DVD player and CRT TV, even though it is irritating on a progressive monitor.

Info about the source: DVD, Region 4, "Mortal Kombat: Conquest".

I'll try and get a sample up later, but from which part of the video? A section with blends? Also, how can I cut the sample out without processing?

[Boulder]

You can use DGIndex for cutting, select the range and choose Save project and demux video. You get an m2v file out of that.

[bkman]

I've uploaded a sample over here: http://rapidshare.de/files/21840885/sample.demuxed.m2v.html

Sorry but it's larger than a few megabytes. I didn't want to misrepresent the source.

[MOmonster]

@bkman
The Blends mainly appear in the slowdowned Part.
It is maybe a mix of a DEFT conversion and a slowdown blendconversion, but I`m not sure. Indeed there is nothing that can repair this. There is a small part for example that shows only blends and has no clear fields. If there is any possibility to get a better version than use this, else I prefer to keep the interlacing. If this is also no option for you, you can try repairDEFT, unDEFTmatcher or Cdeblend+decimator.

[bkman]

Unfortunately there is NO better version than this, and I can't leave it interlaced. I've tried undeftmatcher, and it doesn't seem to help very much, and cdeblend seems unable to accurately detect the blends no matter which parameters I try.

So far the best results I've had have been with tdeint(mode=1, tryweave=true).selecteven(), which is mostly acceptable except for cases where there are multiple blends in a row. So I guess that will have to do unless there is some way of detecting that case and doing something about it (like like replacing it with a morph from the last unblended frame). That doesn't seem likely though. :)

[Mug Funky]

eeks. this is a warner DVD, yeah? they do some funky NTSC to PAL conversions. they range from okay to terrible (though native PAL stuff is obviously pretty good).

i'd go with whatever momonster is suggesting... i'm much better at introducing blends than removing them :)

motion-compensation could be interesting (the "morph" you mention). restore24 might be able to be hacked to do this when it can't find a good adjacent frame. it'd be a lot of work though, and if your problems are on action scenes there'll most likely be more quality issues from the compensated frames than you'll get from simple blends.

[scharfis_brain]

- this is a DEFT conversion
- there is no motion compensation/interpolation

all one can try to do is to use one of the DEFT repair scripts, or maybe:

TDeint(mode=1, type=3, full=false)
unblend() #or deblend()
selecteven()

[bkman]

unblend seems to help with the leftover blends, but it also has the odd side-effect of reversing the slomo and normal motion sections, so slomo runs full speed and normal runs slomo :scared:

Actually, I have never heard of DEFT conversion. Can you explain how and why it is done, and why it results in this mess of blends? Or point me to some information about it?

[MOmonster]

Here (http://forum.doom9.org/showthread.php?p=771933#post771933) scharfis brain gives a small explaination what a DEFT converter do. In general it´s not easy to restore such a conversion, but for your sample a good result is just impossible, because some parts are totally overblended and the created functions try just to decimate the blended fields and keep the clear.

[bkman]

Thanks for the info. Why isn't the DEFT machine sure whether the source is film or not, though? It should be in this case :confused:

Maybe someone will make the perfect unDEFT script one day, which in this case would be capable of detecting intermediate blended fields and replacing them with the previous full field, or a motion-compensated field between the last and next clear fields, or just skipping them if that isn't possible. I can dream :rolleyes: