So I've been contemplating for some time why the HDV encoding looks much better than we ever expected when in 24P mode. It wasn't until I started closely analyzing flagged frames and pulldown patterns that I realized how much better the JVC HDV implementation is over Sony's.

I used to tell people that if you had a dropout on an I-frame with Sony HDV, then you potentially would lose the use of 15 frames of footage. I then would say that JVC implementation was roughly twice as good because the GOP size was only 6 frames. However, I wasn't considering the fact that the JVC records at 60fps and Sony at 30fps.
When in 30P mode, there are 10 GOPs per second (3 frames plus one repeat "clone" each per GOP) instead of only 2 GOPs (of 15 frames each) with Sony. And even better, in 24P mode, there are either only 2 or 3 frames per GOP.
So in relation to MPEG performance, JVC is 5 times better than Sony (2 GOPs per second with Sony, 10 GOPs per second with JVC.)

I made a chart: http://homepage.mac.com/timdashwood/.Pictures/JVC-GOP.jpg

Now this is where is gets a little confusing:
It seems that, when in 24P mode, JVC have either flagged the first or last frame in each repeat sequence, but I'm not sure which. My natural assumption was the first (for simplicity's sake) but now that Steve Mullen suggested marking your in point on the last frame of each repeated sequence, it could be the other way around. Steve must have access to some white paper information I would like to read.

Either way, the point is that once I graphed the pulldown pattern within the 6-frame GOP pattern I was surprised that JVC chose to flag the frames they do.
It would appear that by keeping consistent flagged frames only 3 of the 10 I-frames in every 60 are actually flagged. The other 21 frames (of a 24P sequence) are all P or B frames. I've slid the GOPs around in my chart to try to make more sense of it, but the results are the same.

It probably isn't so bad having so many P-frames since the repeat frames use virtually no bandwidth. Therefore there is more leftover when a new P frame is created for the next 24P frame.

So my conclusion is that if a clever software developer was so inclined, they could create a pulldown removal application to obtain superior images by ignoring the flagged frames and selectively using as many of the I frames as possible. This way 10 of the 24 frames would actually be I frames.

Have I totally confused everyone now?

Thoughts?


ADDENDUM: Please don't quote me on any of the above - it is speculation and not fact. Read the rest of the posts to learn more.

My natural assumption was the first (for simplicity's sake) but now that Steve Mullen suggested marking your in point on the last frame of each repeated sequence, it could be the other way around. Steve must have access to some white paper information I would like to read.

I made the suggestion so that when one cuts to a new shot, one would not see a kind of freeze frame effect by seeing 2 or 3 of the same frames. By cutting to the last frame, one sees only a single frame before we move on to the next frames.

But, you could equally argue that by cutting to the first frame, the eye uses the repeat frames to help establish the new shot.

With interlace, the rule was never cut to a judder (mixed) frame.

-----------------------

I think you are way ahead of me in thinking about how the RF might be placed. But, if anyone could write such software it would be CineForm.

------------------------

Remember how I warned against AIC. Well it turns out the failure of AIC is only with interlace video!

Imagine my finding this in my own Sony HDV Handbook.

Some consider AIC to not be a high-quality intermediate codec. They claim "when brightly colored objects are moving, AIC video shows a coarse pattern of interlacing in the chroma because AIC does not filter 4:2:0 chroma when it converts the MPEG-2 stream into I-frames frames."

Looking further, it turns out this warning is equally valid for capture to HDV. Another reason to work with progressive!

And even better, in 24P mode, there are either only 2 or 3 frames per GOP.

I'm pretty sure I saw a post from David Newman at some point that layed out the 24P GOP structure, and it wasn't anything like 2 or 3 frames per GOP, there were still six compressed frames per GOP, and the repeat flags didn't count against that.

So it was something like a single GOP =

IrBrrBrPrrBrBrr

The I, B, and P frames are encoded frames, the "r" is a repeat flag.

That gives you four GOPs per 60-frame second. Which happens to also work out if you figure that with a six-frame GOP, you also get four GOPs per second for 24fps.

Again, hopefully David Newman will write in and clarify.

As far as dropouts, Sony does indeed punt an entire GOP, but JVC doesn't necessarily -- it can happen where an entire GOP gets dropped, but usually it just scrags a portion of the frame. A dropout in JVC HDV causes a block of corruption usually a full macroblock or two high, and stays on the screen for the full six frames (so about 1/4 or 1/5 of a second) while the rest of the frame continues to update. Vs. Sony, which just seizes for 1/2 second.

Yes Barry, you have it. The repeat frames are not counted as part of the 6 frame GOP, otherwise MPEG efficient would be terrible.

So there aren't 10 GOPs per second, it is dependent on frame rate?

For a GOP of 6 over the 24 active frames, means there is a new GOP every 1/4 second.

So just to be absolutely clear:
Assuming a 24P pattern of IrBrrBrPrrBrBrr for each 6-frame GOP, it actually results in a full 15 frames - but the repeats aren't actually frames, just flags, so they don't count - hence 4 GOPs per 60 frames.

I will assume that means that 30P would look something like IrBrBrPrBrBr and there would be 5 GOPs per 60 frames. Would 25P work the same way within 50 frames?

That throws my theory out the window! However, it does explain why NLEs are having such a hard time adapting to this.

Now here's a question from left field: How similar are the flags used in ProHD to the flags used in DVCPROHD? It is encoded into VITC, EXIF data, TC data, ???? I ask because I wonder if the DVCPROHD Frame Rate Converter Plugin for FCP would be of any assistance in removing the pulldown from 720P60 captured material. I crossed my fingers and tried last night by converting 720P60 m2t to DVCPROHD 720P60 and using the FRC plugin, but it wouldn't work.

I made the suggestion so that when one cuts to a new shot, one would not see a kind of freeze frame effect by seeing 2 or 3 of the same frames. By cutting to the last frame, one sees only a single frame before we move on to the next frames.

But, you could equally argue that by cutting to the first frame, the eye uses the repeat frames to help establish the new shot.

With interlace, the rule was never cut to a judder (mixed) frame.

Yeah. The nice thing is that (in FCP) if you edit 24P footage from the source 720P60 clip into a 23.98 fps sequence, the repeat pulldown frames are automatically thrown away - no matter what frame you start on.
As a general rule, I always started on on the first of each repeat sequence, but now that David has explained how the 6frame GOP actually works, I wouldn't even worry about it.

Yeah. The nice thing is that (in FCP) if you edit 24P footage from the source 720P60 clip into a 23.98 fps sequence, the repeat pulldown frames are automatically thrown away -- no matter what frame you start on.

I'm going to try HDVDVX which I gather still tags the video as 24 and not 23.98. (Can't figure out how he made such an error?) One can conform the clips which simply changes the tag from 24 to 23.98.

But, I'm wondering what would happen if one dropped the 24fps clips into a 23.98fps timeline? It would seem--unless FCP refuses to play without rendering--that there would be little difference between playing at 23.98 or 24. In fact, I'm not sure FCP will play the timeline at the clip's speed or the Sequence rate.

Clearly, program time will be wrong, but that no big problem. Wonder what happens if one tries to export as 23.98?

It is encoded into VITC, EXIF data, TC data, ????

Barry likely knows for sure, but I think since an indication is presented in the TC, that it is a TC flag. Very different from a couple of bytes used for a RF in MPEG-2.

Not 100% sure but I thought it was encoded in the user bits in the TC data...