SeparateFields().SelectEvery(4, 0, 3).Weave() for 576p to 576i not working

[slikvik]

I have a DMR-EZ49V VCR (HDMI Out) and a HDMI Capture device. This workflow only allows me to capture the source at 576p (Lossless).

I understand that the Panasonic is simply bobbing to 576p so I should be able to undo the deinterlace losslessly?

I've tried using SeparateFields().SelectEvery(4, 0, 3).Weave() but I'm noticing two things:

1) It appears to work in that I can see frame-by-frame that the combing is there, but then at certain points later in the test capture, the combing disappears, even on frames with motion.

2) To confirm this inconstant behaviour I recapped the same scene, ran it through the same script, and unlike on the first capture where I get the combing, on the second I don't!

Here's the 1st capture, showing two consecutive frames, at a point that shows a successful merging of fields:


[Attachment 65340 - Click to enlarge]

Here's another area of the 1st capture where no interlacing shows (even over multiple frames of movement):


[Attachment 65341 - Click to enlarge]

Here's the same frame from the 1st and 2nd capture after merging fields. One successfully interlaced, the other shows no interlacing over any of the frames:


[Attachment 65342 - Click to enlarge]


...I've tried (4,1,2) as well.

[dannyboy48888]

Try tdeint(mode=1, slow=2, tryweave=true)
This will give you double frame rate but it will construct full frames from the neighbors if it can. If you don't see any combing then you can do select every and separate fields to make it properly interlaced again afterwards.

If the source is indeed progressive start to finish but you want interlace you have to change the frame rate before separate like so
Changefps("ntsc_double")
That way there's 59.97 frames for it to pull fields from to make 29.97 interlaced frames.

[Skiller]

2) To confirm this inconstant behaviour I recapped the same scene, ran it through the same script, and unlike on the first capture where I get the combing, on the second I don't!

This might be, as I explained in the other thread, because a 576p capture may start at a former top or bottom field.

Because of this, you should look at the individual fields first and decide if the top or the bottom ones are the original ones.


Like so

#576p 50fps capture with original 576i core
SelectEven()
AssumeTFF()
Top=Separatefields().SelectEven().LanczosResize(width,height).Subtitle("Top")
Bottom=Separatefields().SelectOdd().LanczosResize(width,height).Subtitle("Bottom")
Interleave(Top,Bottom)

Then you just alter between AssumeTFF() and AssumeBFF() for the re-interlacing. For example, if you decide the top fields are the original ones, you use AssumeTFF(). No need to change SelectEvery parameters.

AssumeTFF() #or AssumeBFF()
SeparateFields().SelectEvery(4,0,3).Weave()

[jagabo]

Deinterlaced to 576p at 25 fps or 50 fps?

Note that cartoons typically have character animation at only 12 fps. So after re-interlacing you won't have combing on every frame. Check a panning shot where there are usually 24 unique frames every second.

Upload a short sample (no processing, not reencoded) of your source.

[slikvik]

Deinterlaced to 576p at 25 fps or 50 fps?

Note that cartoons typically have character animation at only 12 fps. So after re-interlacing you won't have combing on every frame. Check a panning shot where there are usually 24 unique frames every second.

Upload a short sample (no processing, not reencoded) of your source.

I probably stupidly used the cartoon as it was a retail clean tape for testing.

Here's part of my first capture unprocessed: https://files.videohelp.com/u/302778/LK%20Capture%201%20Source.avi
Here's the same capture interlaced, seemingly okay? https://files.videohelp.com/u/302778/LK%20Capture%201%20Merged%20Fields.avi
(As I mentioned, later on in this same processed file you will find that interlacing appears to have stopped.)

Here's the same unprocessed scene in a second capture: https://files.videohelp.com/u/302778/LK%20Capture%202%20Source.avi
And the same part, using the same script, but this time not working: https://files.videohelp.com/u/302778/LK%20Capture%202%20Merged%20Fields.avi

[slikvik]

2) To confirm this inconstant behaviour I recapped the same scene, ran it through the same script, and unlike on the first capture where I get the combing, on the second I don't!

This might be, as I explained in the other thread, because a 576p capture may start at a former top or bottom field.

Because of this, you should look at the individual fields first and decide if the top or the bottom ones are the original ones.


Like so

#576p capture
AssumeTFF()
Top=Separatefields().SelectEven().LanczosResize(width,height).Subtitle("Top")
Bottom=Separatefields().SelectOdd().LanczosResize(width,height).Subtitle("Bottom")
Interleave(Top,Bottom)

Then you just alter between AssumeTFF() and AssumeBFF() for the re-interlacing. For example, if you decide the top fields are the original ones, you use AssumeTFF(). No need to alter SelectEvery.

AssumeTFF() #or AssumeBFF()
SeparateFields().SelectEvery(4,0,3).Weave()

I'll give this a go but I did try a number of combinations.

This might help. I've just captured some test video (excuse the quality)...

This is the 576p source: https://files.videohelp.com/u/302778/Video%20Source%20576p.avi
Here is my combined fields version: https://files.videohelp.com/u/302778/Video%20Merged%20576i.avi

What's really interesting here is you can SEE the combing stop at the 4 second mark! It's driving me crazy

EDIT: I just ran your detection script (thanks!) on the source video above and it's TFF. I then ran with AssumeTFF and I get exactly the same results attached. Interlacing appears to stop midway through him talking and then for the rest of the capture.

[Skiller]

Note that I updated the script because I forgot to add SelectEven at the start. We are only interested in even frames for the determination (it obviously would be opposite for odd frames, so that's why).
You have to look for signs of interpolation and deinterlacing (artefacts, blurryness). If they are there in BFF marked fields but not TFF marked ones, then TFF are the original ones.

For cartoons, I would expect there to be no interlacing if it's a 25 fps speedup version (is this by any chance a The Lion King VHS? If yes, it should be 25p.).

[slikvik]

Thanks. I'm going to give this a better try tomorrow (next time NOT using a cartoon, as presumably that simply needed to be captured at 25fps in the first place?) and I will report back!

My main concern as shown in the above non-cartoon samples, is that interlacing appears to stop at some point doing the videos. Choosing the wrong starting frames wouldn't cause that would it? Could it be dropped frames in the source that suddenly throw the script out?

I'll do some better tests and see what I get.

[Skiller]

Could it be dropped frames in the source that suddenly throw the script out?

I had that suspicion as well. But I don't think it should (but we will see). The reason I think it should not is because the ADC of the Panny always returns standard def video, so 720x576 interlaced. It is the following processing that turns this into whatever the user requested via the menu settings (HDMI output format). So if there are frame drops, they would have occured before the processing and thus cannot have an effect on where the original lines are and where the filled-in ones are.
What can have an effect is if there are frame drops during the HDMI capture. That would mess with the cadence and swap things around.


With a cartoon source like this the capture is not any different. There are two fields representing the same point in time and therefore, if paired correctly, there is no apparent interlacing throughout the entire main movie.


I will have a look at your samples now and report back.

Edit: Your real-world sample is full of frame drops due to the noise bar (might be bad tracking) and that's why there are not enough unique fields to produce interlaced frames after re-interlacing. So this is to be expected. You need proper test material.

[jagabo]

The source is not as was described. Both clips have a pattern like:

A B B B C D D D E F F F

All progressive and the duplicate are exact. The second clip switches cadence at frame 203 to

A A B B C C D D E E F F

again all progressive with exact duplicates. The best way to handle this is simply TDecimate(Cycle=4, CycleR=2), leaving you with 25p.

[Skiller]

So there is something very wrong with the capture process. With the real life example, and if the noise bar isn't causing the frame drops, it should obviously be A B C D E F G .... (50 fps).

[slikvik]

Hi both,

Just want to apologise. Despite the packaging saying otherwise, this HDMI Capture device only outputs 30fps, even at lower resolutions! While you can set your capture software to encode at 60 or 50, it's not getting that number of frames. I just tested by using a PC as a source, manually setting the input resolution to 1920x1080/60p, 800x600/60p and 720x576/50p. In all instances you see A B B B C D D D E F F F or A A B B C C D D E E F F patterns.

I should have realised sooner but being my first test was with a cartoon I thought it may be to do with the lower true framerate of animation.

Saying that, you've been super helpful in the thread, and the scripts and info will be useful when I finally do get to capture 720x576/50p that I want recombine fields to remove the Panasonic's crappy de-interlace! Thank you.

[Skiller]

Glad you found the cause of this effect.

Unfortunately the market is flooded with flawed capture devices.