Seun,
your answer is for me?

If yes, you're wrong. I know the 3:2 pulldonw process.
My frined, don't shoot in 24p, because PAL model only has 25p, and with 50i format, it doesnt need to remove pulldown. Only with ntsc model.

So, in PAL models every frame (2 field) from 50i video, that was shooted in 25p, has to be a real progressive frame without any magic.

Look at Richard's sample, it is from Hv30, and 25p, not 24.

Do you have any other examples? This one seems pretty odd. If it only happened with this shoot, then who knows why the tree look strange?

It could be lighting, it could be some setting that was overlooked, it could be your particular camera, it could be the motion of going handheld, it could be image stabilization was turned on, it could be many things particular to this shoot. Much less likely is that you've discovered that the HV-20 has an interlaced CMOS sensor.

Look at more examples. And post them if you see the same problem.

I believe Prech has a good understanding of video and knows what he is talking about.

The HV20/30 video is progressive but it's also PsF, so potentially there are interlace factors to take into account. What I mean is that the video captured through firewire is not simply 25 progressive frames per second as in the case of the Canon XH-A1, but rather it is 25 progressive frames segmented and distributed across 50 fields. If the NLE interprets this footage wrongly (may or may not be due to wrong project settings) then I can see the possibility of some deinterlace issues.

Even though I said previously that Prech's example does not look like a deinterlace issue to me, I am prepared to consider the horrific possibility that I am wrong. :) The most important thing, for me at least, is to know what's actually going on here.

Richard

I'm in NTSC land, so I deal with the 3:2 pulldown. But you're saying that the PAL version uses essentially a 2:2 pulldown to embed 25P in 50i. Makes sense, I just hadn't really considered that PAL uses a pulldown as well.

I think you may be on to something with the compression and subsequent decompression blending fields from different frames. This is a problem with DV casusing every third frame to have distortions; which is why the DVX comes with the Advanced Pulldown option. But this should not be a problem with HD.

But I sounded somewhat critical in my post, I just don't see how it can be the sensor that is not progressive. Of course I could be wrong, but it just goes against everything I've seen, read and heard. So that's why I suggested running more tests and double checking and listing the settings.


P.S. Actually, come to think of it, this problem could very well be caused by how the frame grabs are performed. A lot of players will try blending fields even with progressive images when frame grabs are done. For example, I've found VLC introducing ghosting on frame grabs when none exists in the raw footage.

So along the line of your NLE ?, how were there these frame grabs taken?

Peter,
25p PAL HDV doesnt need pulldown, just to interpret the footage to progressive.

"how were there these frame grabs taken?"

read #1 post

I wasn't sure you used Endius for the frame grab as well as viewing, but after re-reading your post, I see that's what you did.

In all seriousness, can you please explain to me how PAL doesn't use a pulldown? In NTSC, progressive frames are repeated 2, then 3, then 2 and so on into the 60i fields.

But with PAL, aren't frames repeated twice to fit into the 50i fields. How is this not a pulldown? It's not as annoying as the 3:2 pulldown, but isn't it a pulldown nonetheless? Progressive frames are being repeated to fit into a different timeline (used for televison broadcast), isn't that what a pulldown is? Or are you saying the frames have to be repeated at an uneven cadence to be officially called a pulldown?

Back to your problem. Have you seen it with any other footage? Have you tried loading the footage into a different NLE?

i ask my friend, to give me another fast moving videos from hv20.
(because i personally have hv10)

60 is not a multiplier of 24, thats because ntsc model need pulldown.
but 50 = 25x2, so we are lucky. not need to magic, just say to NLE, this 50i footage is in reality a 25P footage. That is enough.

Prech,

I realize that 60 and 24 need a common multiple, hence the 3:2 pulldown. But just to clarify things a bit, the PAL version does indeed use a pulldown. It's just an easy one to deal with, 2:2. But the process of putting the progressive frames into interlaced fields for broadcast IS the pulldown. And both PAL and NTSC versions do this.

Removing the pulldown has to be done in NTSC land to edit properly. In PAL land apparently you can leave the pulldown in there w/o any problems. But both have a pulldown.

As for the problem you presented, more footage or info on the settings your friend used would be helpful.

All,
I'd put my money on the optical image stabilizer having an occasional jitter. I'm personally not very impressed by its performance.

Less likely:
- motion blur
- the NLE trying to deinterlace of trying to combine odd&even fields from subsequent frames instead of combining fields from the same frame.

A nice test to check whether your NLE keeps the fields clean is to run some 50i interlaced video through it. It should look like this:
http://www.artech365.com/winvdr/images/invers1.jpg

See: odd&even fields perfectly untouched. From the HV20 25p progressive mode, the fields should match because they were shot at the same moment.

regs,
Pieter