fix wrongly deinterlaced source

[RieGo]

Hi guys,

i got a quick question. so i recorded a broadcast and foound that it really destroyed the movie.
so basically they are broadcasting 720P 50fps
what i think they did with this footage: they bobbed a 25P source, so i got 2 almost similar frames in a row.
i came up with this script to fix it:
Trim(1,0) #(to keep an even amount of frames)
BilinearResize(last.width,last.height/2) #halving horizontal frame size to weave them back
AssumeFieldBased().AssumeTFF()
Weave()
vinverse2()


as i'm not really an expert i'd like to know is there any better way to fix this in the future? how is it usually done?
unfortunately i already removed the untouched source, but i could provide a new sample next week.

[StainlessS]

I think that it might be something like this

#AssumeBFF()
AssumeTFF()
SeparateFields()
SelectEvery(4, 0, 3) # EDIT: Get the even field from the 1st botched frame, and the odd field of the 2nd botched frame.
Weave()


I'm sure that someone will pipe up if I'm wrong.

[Ghitulescu]

What you think may not be the reality.

Without a sample, people will only guess.

[RieGo]

I think that it might be something like this

#AssumeBFF()
AssumeTFF()
SeparateFields()
SelectEvery(4, 0, 3) # EDIT: Get the even field from the 1st botched frame, and the odd field of the 2nd botched frame.
Weave()


I'm sure that someone will pipe up if I'm wrong.

Thanks! seems to work just fine. can't see much of a difference to my code (i know, it's almost the same). need to test some more.

What you think may not be the reality.

Without a sample, people will only guess.

i know. i'm sorry for letting you wait.
so in case someone has any hints on how to get the best out of this source, please let me know :)
it's reeaaally bad...
https://mega.nz/#!R44E0Z5A!QRb6bTxfW0w3P_Nz1C3SisFUHQIAZg-OfOR54ZO1UwI

btw: just noticed there's a field swap in the end of this clip, because of frame dropping, i think.

[real.finder]

BlendBob() will help too, but I think that the original of this source was SD then the channel upscale it by something like IResize

[johnmeyer]

I looked at the video. It is 50 fps progressive, with each frame duplicated. The duplicate frame is offset vertically by a couple of scan lines. This duplicate looks just fine, but it is offset. Unless I am being really dumb, it looks to me like the simplest thing is to throw out every other frame. I don't think it matters whether you choose to remove the odd or the even frames.

Since the motion is based on duplicate frames, you will visually get the identical thing with the resulting 25 fps progressive stream as you do with the original 50 fps with each frame duplicated. Here is the script, the simplest one I have ever devised (I always put the video into Vegas and then frame serve from that, which is why the video is "fs.avi"):

AVISource("E:\fs.avi")
selectodd()

Note:

I just ran the script and when I used selecteven() instead of selectodd(), and when I then zoomed way in on the roll bar on the truck, near the beginning of the clip, I noticed that the grain pattern was quite different between the frames that remained: one frame had lots of grain and the next frame had much less grain. This pattern repeated, without change. I didn't see that with selectodd. So, with this clip, maybe it does matter which frames you choose to decimate.

Someone with a keener eye might look at this and see if, to recover absolutely the best image, whether it might make sense to look at combining one field from one frame with the complementary field from the duplicate frame, with a proper horizontal offset applied. This might create problems at the upper or lower margin, however, and you'd have to fill in with the fields from the existing frame.

[RieGo]

I looked at the video. It is 50 fps progressive, with each frame duplicated. The duplicate frame is offset vertically by a couple of scan lines. This duplicate looks just fine, but it is offset. Unless I am being really dumb, it looks to me like the simplest thing is to throw out every other frame. I don't think it matters whether you choose to remove the odd or the even frames.

Since the motion is based on duplicate frames, you will visually get the identical thing with the resulting 25 fps progressive stream as you do with the original 50 fps with each frame duplicated. Here is the script, the simplest one I have ever devised (I always put the video into Vegas and then frame serve from that, which is why the video is "fs.avi"):

AVISource("E:\fs.avi")
selectodd()

Note:

I just ran the script and when I used selecteven() instead of selectodd(), and when I then zoomed way in on the roll bar on the truck, near the beginning of the clip, I noticed that the grain pattern was quite different between the frames that remained: one frame had lots of grain and the next frame had much less grain. This pattern repeated, without change. I didn't see that with selectodd. So, with this clip, maybe it does matter which frames you choose to decimate.

Someone with a keener eye might look at this and see if, to recover absolutely the best image, whether it might make sense to look at combining one field from one frame with the complementary field from the duplicate frame, with a proper horizontal offset applied. This might create problems at the upper or lower margin, however, and you'd have to fill in with the fields from the existing frame.

thanks to all of you!
i will try to get good results by dropping one frame, denoising and interpolating to 50 fps. maybe that's the right way to handle this crappy source...

update: just tried to check what you said about duplicate frames, using a simple script: (don't know how i could do this for the whole video)
clip_complete=last
Trim(clip_complete,1,1).crop(0,2,0,0) ++ Trim(clip_complete,2,2).crop(0,0,0,-2)

Frames are definitely not the "same". really looks like just odd and even frames.

trying BlendBob() next. never used that.

[LemMotlow]

They're duplicate frames with seriously bad aliasing, common with PAL transfers from film.