720p24 Mode Theories
 

Here's my theory about what's going on in 720p24 mode on the HD100:

1-The file is really 720p60, with only 24 active frames. The rest are null

2-VLC plays it fine at the correct frame rate.

3-Quicktime attempts to play it at 60fps, but it can't keep up (on my machine) so it settles for about 40fps

4-There are no "pulldown" frames to remove like the DVX in 24PA. Only "null" frames to ignore in the 60fps stream

If all this is truly true, it looks like Apple will only have to update how Quicktime/FCP looks at the MPEG stream from the HD100. It also looks like this approach is pretty clever on JVC's part...before observing all this I was trying to figure out how one would remove pulldown from the 720p24 (actually 720p60) stream without a re-compress.

I suspect Apple will have this wrapped up shortly in an update.

Does anybody have any evidence to the contrary? Thoughts?

How would this work with shutter speed and motion blur? Do you think the image is being exposed at 60 times a second only giving you a shutter speed of 1/60th as the lowest possible? No 1/48th shutter?

Or is it just being written to tape at 60p?

I'm talking ONLY about the MPEG stream format, as it's imported into a computer.

All evidence so far is that the CCD/camera section of the camcorder captures and processes images just like a DVX, with the exception of having the option of Motion Smoothing. Default shutter speed is 1/50th, and you can dial in 1/48th no problem.

Nate,

You are totally correct. The MPEG transport stream is a 60p wrapper with 24 active frames. Repeat flags indicate to player and capture devices what to do.

Wow. I sounded smart then. I honestly was kinda winging it.

I know you probably wouldn't presume to speak about an Apple product, but it sounds like getting real 24p support is not a huge underlying issue?

I can try a feel superior that we do support 24p and 25p from the new JVC camera, but it wasn't that hard. I'm sure Apple is just around the corner with their update. Large companies natural take longer with their relaeses.

Naw, I'd feel superior. That's a very real advantage of staying small!

Okay, I assume then it's just a matter of figuring where the valid 24p frames are and decoding them correctly. But might not GOP issues cause problems in extracting the frames from MPEG stream?

Another Question for David
 

Kinda. All frames are valid in the stream because they're the only ones there. JVC distributed the 19mbs across 24 and ONLY 24 frames per second. The "filler" frames, to bring it up to 60fps, are empty virtual frames. They're not even repeat picture data...they're just placemarkers instructing the decoder to repeat the last frame for either 2 or 3 60fps frames.

As far as GOP issues go, it sounds like the way an MPEG stream works, it's a non-issue. I don't know that though, I'm just guessing based on David's response above.

My question for you David is if you think the JVC method is a clever, legal use of the MPEG spec, or a hack. It seems not all software reads this correctly, so at the very least it seems like new use of an obscure part of the spec. Barry Green notes that the MPEG decoder in his Sony XBR HD set correctly decodes it though! (via firewire/TS streaming)

Interesting - thanks for the info.

It is all standard MPEG. The these new ProHD streams can be captured and played on old DVHS decks, nothing but the way MPEG works. However NLEs have never been good at MPEG, so there is some work to do.

I read several versions, in this thread, of how ProHD works. As far as I know:

CAMERA
Always running at 48fps, 50fps, or 60fps with "correct" shutter-speeds of 1/48th, 1/50th, and 1/60th.


CAMERA ANALOG OUTPUT
1) 720p50 or 720p60 direct from the CCDs.

2) I haven't read what what happens in "24fps" mode. Perhaps it is not output via analog. Perhaps every other frame is dropped and 2:3 pulldown is added to yield 720p60. (I've got no idea what happens in Region 50?)


MOTION FILTER OFF
Every other frame is dropped, yielding 24p, 25p, or 30p.

1) If the HD1/HD10 MPEG-2 encoder is employed, it still may not be able to encode 24p. (The original could NOT.) So some scheme may be used to create 30fps from 24fps. This may be where the idea of REPEAT frames comes from. In fact, the NTT encoder couldn't encode 25p either. So maybe 25p is converted to 30fps by using REPEAT frames. All recording is 720p30. As far as I know there is nothing recorded that has anything to do with 720p50 or 720p60

2) 24p, 25p, and 30p are MPEG-2 encoded and recorded. As far as I know there is nothing encoded or recorded that has anything to do with 720p50 or 720p60.


MOTION FILTER ON
Pairs of frames are "conbined" into one -- so there is 24p, 25p, and 30p output from the filter. (MF possibly IN the encoder.)


PLAYBACK ANALOG OUTPUT
1) 720p25 and 720p30 are frame-doubled to yield 720p50/1080i50 or 720p60/1080i60. This is just like the HD1/HD10. 2:3 pulldown is used to yield 720p60 from 720p24. (I've got no idea what happens in Region 50?)

2) If only 720p30 is recorded, the REPEAT FLAGS are used to obtain 24 and 25fps. p25 and p30 are frame-doubled to yield 720p50/1080i50 or 720p60/1080i60. This is just like the HD1/HD10. 2:3 pulldown is used to yield 720p60 from 720p24. (I've got no idea what happens in Region 50?)


i.INK OUTPUT
There are many possibilities:

1) Do the obvious: frame-double 25p and 30p to 720p50 and 720p60. Add 2:3 pulldown to 24p to get 720p60. NLEs understand 720p50, 720p60, and 720p60 carrying 24fps. 720p60 (w/wo 24fps) is ATSC legal. I assume this is what is meant by a 720p60 "wrapper."

2) Output 24p 25p, and 30p. Modify NLE's to capture 720p24 -- ready for Timeline. HDV NLE's already accept 25p and 30p. Both 720p24 and 720p30 are ASTC legal.

3) Frame-double 25p and 30p to 720p50 and 720p60. Output 24p as 720p24. NLEs can accept 720p50 and 720p60. Modify to capture 720p24 -- ready for Timeline. Both 720p24 and 720p60 are ASTC legal.

4) 24p, 25p, and 30p are frame-doubled to yield 720p48, 720p50, or 720p60. NLE's are ready for 72050 and 720p60 -- but not 720p48 so they must be modified to capture and then drop every other frame. Only 720p60 is ASTC legal.

5) Output only 30p. Use some kind of scheme to embed 24fps and 25fps in 30fps. NLE's could drop the REPEAT frames to get back 24p and 25p. Certainly not ATSC legal. (This matches the 30fps only encoder.)

6) Output only 25p and 30p. Use some kind of scheme to embed 24fps in 30fps. NLE's could drop the REPEAT frames. Certainly not ATSC legal.


I would sure love to know what is really recorded and what come down the i.LINK!!!

Wow. That's a lot of questions and suppositions for one post. I'll add info where I can from my experience with the camera last week.

Really? I was only talking about 24p mode the whole time, and David confirmed my theory.

I'm almost positive that the camera section runs at the FPS going to tape in all modes. The available selection of shutter speeds in any given mode supports this theory

Pulldown is definitely added via the component outputs, and AFAIK, the composite output also. During our quick motion tests at Clairmont, it looked to me however that this might be a "quick/easy" method of pulldown added, and frame based, not field mixed. I saw a little stutter live, but not from the files pulled off that tape.

There is though. The m2t and m2v files pulled off tape shot in 24p mode are definitely 59.94fps. That's what David just confirmed for me.


I agree. It states in the manual that one cannot see the effect of Motion Smoothing live through the LCD, finder, or any analog output. This supports the theory that it relies on extra DSP built into the MPEG encoder.


I'm not sure why they'd go with frame doubling for some formats, and MPEG repeat flags on others, but who knows? David only confirmed how it works in one mode.

Again, I have no idea about frame doubling in the 25 and 30 modes. 24fps inside p60 is the repeat flags vs. pulldown as we know it from the DVX. I know this because the files Barry pulled live off the camera via 1394 while shooting match the files we later pulled off tape.

That's the one thing I'm sure of because JVC always claims you get true 720p50/720p60 via the analog output. In fact, they are making an HD-SDI option so you can use the camera in a studio. Also, double frame-rate is the key to the Motion Filter.


"The m2t and m2v files pulled off tape shot in 24p mode are definitely 59.94fps. That's what David just confirmed for me."

I agree -- but David hasn't said if the 24fps has 2:3 pull-down. The NLE world understands 2:3 pulldown so I assume that's what is used even with i.LINK. What's interesting is that i.LINK is the one connection where pure 24fps could be used right into a disk file -- just like film.


"I agree. It states in the manual that one cannot see the effect of Motion Smoothing live through the LCD, finder, or any analog output. This supports the theory that it relies on extra DSP built into the MPEG encoder."

If you go to : http://www.gyhduser.com/

you'll ind my short version of how I think an MPEG-2 encoder can do the MF. Like you, if it was done in DSP I can't see why we can't see it. (Wow, that's a sentence!)

"24fps inside p60 is the repeat flags vs. pulldown as we know it from the DVX. I know this because the files Barry pulled live off the camera via 1394 while shooting match the files we later pulled off tape."

Can you explain more. DVCPRO HD uses Repeat Flags but the DVX simply uses 2:3:3:2 pull-down. Which did you find?

There's some Motion Smoothing filter clips on the web. The one I examined looked like it just overlayed the previous captured 1/24th frame, not one captured "in-between". I absolutely could be wrong on that though.


and the following are related:

The statement "but David hasn't said if the 24fps has 2:3 pull-down" is not really true because the method of using repeat flags would BE the "pulldown". I've found that JVC inserts their 24 frames per second into a 59.94 stream with repeat flags. That way they get the entire 19mbs the stream allows. Why they didn't go with a 24fps stream to begin with I'll never know...existing compatibility, perhaps? It seems a good portion of MPEG decoders already decode it properly, and without worrying about pulldown methods, which is a technical coup I'd think.

720p24 is not an HD broadcast standard, whereas 720p60 is. There are no mysteries here. JVC is not doing anything either clever or odd. 24p is put into 60p just like 24 is put on a 60i DVD, only 24 frames are encoded, but 60Hz presentation is predetermined with repeat flags (i.e. there is no native 24p DVD, just as there isn't a broadcast MPEG 720p24.) 25p goes into 50p the same way. Remember MPEG is designed for broadcast, not of acquistion or editing. So it seems confusing if you try to think too hard about it. :)

David,
It seems still, that the fact that HDV was concocted as a video camcorder format for those wishing to complement their HDTV purchase is lost on those who dream of having a low cost camera that will replace film based cameras.

The further fact that MPEG2 is the broadcast format for HD signals is also somewhat of a comprehension sticking point for many. While some companies will 'massage' the paranoia of those who don't fully understand what the HDV format is all about by releasing HDV camcorders with 'user requested features'; the fact remains that HDV was never intended as a film replacement format.

Even those who fanfare H.264 and MPEG4 as MPEG2 replacements are whistling up the drainpipe. They may be better in some peoples minds, but as HD is currently being broadcast using MPEG2, the cost to broadcasters and consumers alike in purchasing hardware that is able to encode/decode an as yet unsupported broadcast format would prohibit an easy transition.

One day in the future, there'll be affordable to the Joe Bloggs of the World digital camcorders with image quality to match 35mm film... with true 24p etc, etc. It just won't be today.

Actually, 24fps IS an ATSC standard (Table 3) and folks continue to claim it is used for movies. I think it NOT used, but every HDTV is supposed to decode it. The problem is, that to be useful, all HDTVs would have to support 72Hz refresh, which they don't.

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

"24p is put into 60p just like 24 is put on a 60i DVD, only 24 frames are encoded, but 60Hz presentation is predetermined with repeat flags (i.e. there is no native 24p DVD."

So it does NOT work like the DVX100 where 24p uses 2:3 pulldown to get 60i. Right?

Nor does it work like film where only 24fps are recorded -- which would lengthen record time. (Panasonic claims they will truly record only 24fps to SD cards!)

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

Anyway, I'm still confused. Only 30 -- not 60 frames -- are RECORDED to tape otherwise the tape duration would be cut in half. So the 24 frames have to get placed within 30, not 60 frames. That requires 6 REPEAT frames per second. WHICH of each 24 frames is repeated and flagged?

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

And, what gets sent down the i.LINK cable? 30 frames/second with 6 flagged frames or 60 frames/second with 12 flagged frames?

This question relates to the 30fps mode. In the HD1/HD10 only 30 frames/second were sent via i.LINK. Does the HD100 send 60 frames/second? If so, then it feeds 720p60 into your NLE. (Of course, each frame has been doubled.)

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

Whether 30 frames with 6 flagged or 60 frames with 12 flagged frames come via the i.LINK -- which, if any, NLEs understand "Flagged Repeat frames?" They are used to working with 24fps with 2:3 pull-down because that's how film comes in.

Which leads to THE critical question. Will the repeat frames be dropped during capture so that 24fps video is stored to a file. Or, will 720p60 be stored to a file and when the video used -- the flagged frames will simply be ignored. Clearly the former is better as it saves storage space and reduces disk bandwidth.

Which will ConnectHD and AspectHD do?

Correct. It works nothing like the DVX.

No, you have it right. Picture data exists for ONLY 24 frames.

It would be easier to think of the MPEG stream in this case as being elastic, maybe. It identifies itself to the decoder as 60fps, but it really only has 24 real frames in it. ALL of the frames get repeated...some will get repeated twice, some will get three viewings. The pattern and the amount would be the same as 2:3 pulldown going to 60 fields/sec in NTSC.

What gets output to 1394? The exact same stream that goes to tape. There's no need for anything to be changed.


Does it send 60fps? Yes and no. The stream SAYS it's one thing (60fps), but only carries data for 24 frames. And the repeat flags in place of the remaining frames.

Apaprently Vegas does. VLC does. David says the repeat flag is very common (and his example is 24fps MPEG2s for NTSC DVDs, which I use every day). The NLEs that don't only have to tighten up their behavior with the MPEG spec.

I suspect if the underlying MPEG decoder engine as it relates to the editing program can hack it, then it'll keep it as it stands. I know Final Cut Pro takes the HDV stream and puts it in a Quicktime wrapper, so maybe Apple will choose to completely deconstruct the MPEG stream and recreate it to their own liking upon intake...recreate it so FCP can deal with it easier.

Apple deals with the whole HDV mess by using a HDV component for Quicktime...so all of a sudden pretty much ANY program that works with video on the Mac can now read/write HDV. It's very slick.

Correct, 720/24p is one of the ATSC HD-sanctioned broadcast standards. I don't know of any stations who are broadcasting it, but they could if they chose to.


No, but it would be more akin to how the VariCam records 24p within a 60P data stream. 2:3 pulldown, but instead of mixing within fields, it's simple frame doubling. Every two frames should be written out using 2:3 frame repetition: frame "A" written twice, frame "B" written three times, and then repeat. But again, David knows best as he's actually decoding the files.

Panasonic will output only the flagged frames to the P2 card -- if you wanted to record 720/4P, you could actually fit over two hours on a single card.

JVC didn't go that route -- they chose a fixed bitrate per second. Which is actually good for their 24P implementation, as it means that it's the least-compressed form of HDV available. By using the repeat-frame flags, they get 25% more compression bandwidth applied to each compressed frame.

No, as long as the bandwidth is 19 megabits per second, the tape duration will be identical. What would change would be the level of compression per frame -- recording 60P on tape would require each frame to be compressed with half as much available bandwidth, and would likely result in atrocious compression artifacts. But as long as the 19mbps data rate is maintained, regardless of the number of frames per second, the tape duration will stay the same.

And as Nate and Lumiere and Cineform have all confirmed, the 24P data is encoded/carried within a 60p MPEG-2 file. Tim Tokita, general manager of product engineering for JVC, confirmed this for me as well. It's a 60P data stream.

However, out of those 60 frames, only 24 are unique. 36 are handled, apparently, by a simple flag that just says "repeat the last frame" -- which takes up practically none of the available bandwidth!

Incorrect. The data stream that gets recorded is 60p. 36 repeat/duplicate frames per second. As to which particular ones they are, there should be 3 out of every five-frame sequence, following the 2-3 pattern.

The firewire cable is carrying a 60p data stream, with 36 flagged frames per second.

In 30p mode, 30 frames get sent down the firewire. The 60p "wrapper" is only used for the new 24P mode. In 30P it (apparently) acts exactly like an HD1/HD10.

DV Rack, Vegas, and Windows Media Player all see the files as 23.976 MPEG-2 files. Can't speak to any other programs.

Also, the HD1 and HD10 can transport those files via firewire. They can't play/decode the data, but you can capture 24p files from an HD1, and you can write them back out to an HD1. It knows how to process the data stream, but it doesn't know how to decode/display it.

No difference in storage space or disk bandwidth. MPEG-2 is exceptionally efficient when it comes to duplicated frames. They occupy basically one bit, AFAIK; a flag that says "just repeat the last frame". It takes up no more storage space. On disk, on tape, and via firewire, it's always 19 megabits per second no matter how many frames are encoded.

With DVCPRO-HD the # of frames per second does affect the storage space, because each frame is encoded discretely at a fixed/constant bitrate. With HDV MPEG-2, the only thing that's absolute is the data rate. The presence or absence of frames will change how many bits get allocated to encode each frame, but even if it were capable of encoding 60 separate frames (which the current hardware can't, but HDV specs do allow for), the final product will *still* be 19mbps. Just more heavily compressed.

Maybe. But I'm not seeing much else besides DVCPROHD stepping up to the plate. HDV is the defacto HD counterpart to DV.

Apple is already distributing HD movie trailers in 720p via h264. People have unearthed evidence that iPods will be sprouting video capability real soon. You don't have to be a genius to see where it's going. Yes, yes, I know Apple only has x% of the market, but it's clear they aim to make a dent in it...and I bet they will.

I think it's unfair to categorize people looking to this camera for real production work as "Joe Bloggs". When prepping the HD100 at Clairmont Camera in Los Angeles, it was interesting to note that all the techs there were fascinated. No quips about how it wasn't a "real" camera, etc.

I'll agree..I wish HDV was a little better. But I don't bemoan it. I look forward to the production value it will add to my lower-budget work.

"It is what it is". I'll deal.

I realize that when I think of Repeat Flagged frames I'm thinking of DVCPRO. Here there are always 30 frames. Is is easy to repeat a frame every 4 frames to get 6 groups of 5 frames.

But here's where I get lost.

We know the HD100 records 5 6-frame GOPs per second -- 720p30.

When we only have 24 rather than 30 frames within those 5 6-frame GOPS -- I just don't see WHERE the 24 frames "go" because 24 can't be divided into 5 GOPS.

Obviously, there could be 4 6-frame data GOPs followed by 1 "null" GOP of 6-frames, but I think that would leave gaps in the data flow.

So I feel the 24 frames must be distrbuted uniformly amoung 30 frames.

Each new 24fps frame must generate an I frame followed by 5 B/P frames yielding 1 GOP. This means every second there would only be 4 GOPs not 5 GOPs.

This makes me think, as you suggest, that something like a 2:3 pulldown pattern must be used. But at 4:30AM -- I can't think how it would work. Can you, or David, explain the cadence that gets the 24 into 30.

Lastly, although everyone talks about 720p60 -- the recording system remains 720p30. I don't see where p60 comes into play until each frame (for 30p) is doubled in the NLE and assigned an appropriate timebase.

Thus not only do we have understand HOW 24 gets into 30 -- we have to understand in the NLE how we get back our 24 frames out of the 24.

Nope. The recording system is 60p. 60p has been part of JVC's HDV spec from day one. The problem has apparently been the MPEG encoder chip they use -- it apparently can't handle a 60p data rate, so they limit it to 30p. It's not the format's fault, it's the hardware's fault.

But since the generation of a 24p file means creating a 60p file (while only having to deal with the throughput of 24 frames) the hardware can handle that. So the file that gets written to tape is a 60p file, containing 24 frames worth of data, and 36 "duplicate frame" flags. It's actually encoded as a 60p file, but more than half of those frames just basically point to a prior frame and say "what he said."


At least, that's what I gathered from JVC, and it matches with what Graeme said that Lumiere told him, and Graeme has been working with JVC 24P footage for a while. It also matches with what David and Nate are saying, so I'm pretty sure it's accurate.

David would likely be the one who knows best.

The .m2t's in the article on HDVInfo.net are direct 24p captures from tape, as processed by HDV Rack and by Pixela HD Capture, so if you want to examine a 24p HDV file, there are some available for download.

Yes I should have said 720p24 is not used as a broadcast standard, 720p60 is the common format. I don't spend my day looking at ATSC specs, yet I have (well much more my co-workers) spent a lot of time looking at many different transport streams. We have been doing this for a long time now.

The confusion seem to be with the 6 GOP structure and how that applied with repeat flags. The repeat flags do not use any of the 6 frames in the GOP. Here is how a GOP looks in the transport stream. In 30p the camera uses a 30 frame transport so the IBBPBB applies to each of the frames. In 24p in a 60p transport the repeat flags ('R' -- note: all of the is way over simplied -- for my understanding too) would look something like :
I R B RR B R P RR B R B RR
R vs RR apples the 3-2 pulldown. The 6 frame GOP covers 15 frames in transport stream "time." There are 4 GOPs for the 24 frames which adds to 60 display frames per second.

So you are saying that the HD1/HD10 recording system could write ten 6-frame GOPs per second to tape!?!

So there is no change to recording system in the HD100?!?

I agree that the encoder was/is limited, but I never had any idea the recording system was ready for 720p.

Mind blowing.

1) This means by the next NAB we could see a enhanced HD100 that is true 720p60. Only a new encoder chip needs to be dropped in!

2) That's when we'll get the PCM audio tracks.

3) This raises a lots of questions:

A) When the HD1/HD10 recorded 30p I thought it only wrote five 6-frame GOPs to tape.

But, if the tape had space for ten 6-frame GOPs, that means skipping every other GOP space on the tape. Analog output was frame doubled. And the 720p30 (every other GOP) was sent down i.LINK. Correct?


B) Does the HD100 also only write 30p to tape -- skipping every other GOP space on the tape? And, send 720p30 down i.LINK? I assume it does.


C) I've got to understand what David has posted, but I don't yet.


D) Here's where I'm stuck. If I were JVC and I could record 720p60 to tape -- I would use 2:3 pulldown because the whole NLE industry works with this cadence: AABBBCCDDD so 24 frames nicely turns into 60 frames.


E) But I get the feeling this NOT what JVC is doing. Perhaps because 2:3 pulldown doesn't work for inter-frame compression.Therefore, some other scheme is used.

F) But, what comes down i.LINK? Some bizarre pattern of IBP frames or clean 720p24?

If the former, is that what the NLEs will record to a disk file -- leaving the NLE MPEG-2 decoder to obtain only the 24p in realtime -- or will the software driver obtain the 24p and write it to a disk file as 24fp?

No. 30p uses a 30 frame transport stream. As for "tape had space for ten 6-frame GOPs", MPEG doesn't work that way -- DV and DVCPRO-HJD do, but not MPEG. The tape is just a constant bit-rate data source, it isn't divided into frame slots. This way 'I' frames can, and are, much bigger than 'B' frames, and the frame rate can be independent of bit-rate.

There are no skipping GOPs. I don't even know what you could mean by that. What goes down i.Link is the same as what is put to tape.

Forget NLE industry, the MPEG design has nothing to do with it. Pulldown was developed for broadcast, and yes the the 24p is placed into a 60p transport via pulldown. However, it is not like 24p in DV or not like 24p in DVCPRO-HD as both of those systems waste large amount of bandwidth becuase the tape is pre-allocated with frame slots (MPEG doesn't.) Your knowledge of these system I think is hurting you ability to understand MPEG -- which is better design for efficiency, not for editability.

Pulldown and inter-frame compression are not related. ProHD 24p is using pulldown and inter-frame compression without any (negative) impact for doing so (all positive.)

Clean standard MPEG in a 60p transport stream with 24p actual frames.

Again these NLE concerns don't quite apply. The data is real 24p, no matter how it is wrapped. NLE tools developers should have no problem dealing with this -- it took us on a fews day to make Aspect HD work with 24p sources -- although it certainly helps not to be a native MPEG editor (speeding our development time.)

Superb explanation overall. Let me try to just clarify this last point a bit:

It is, indeed, a 60p stream. But 36 of those 60 frames have no data assigned to them -- because they're exact duplicate frames, in the data stream they're just pointers back to prior frames. So there are 24 frames that have actual compression encoded on them, and then there are 36 "duplicate frames" there -- and because of MPEG efficiency, those duplicate frames take up practically no space.

So, the data stream looks something like what David said earlier:
Frame 1 = fully-compressed I-frame
Frame 2= pointer back to Frame 1, taking up no space at all
Frame 3 = compressed Bi-directional frame
Frame 4 = pointer back to Frame 3, taking up no space at all
Frame 5 = pointer back to Frame 3, taking up no space at all
Frame 6 = compressed Bi-directional frame
Frame 7 = pointer back to frame 6
Frame 8 = compressed Predicted frame
Frame 9 = pointer back to frame 8
Frame 10 = pointer back to frame 8

etc. etc.

You can see how if that stream was uncompressed and played back at 60p frame rate, it would have a similar frame cadence as 24p recorded on a 60p Varicam tape: you'd see 24 distinct frames displayed per second, but there would actually be 60 frames updated and displayed on the television.

And the pointer frames take up practically no space and no bandwidth, so there's really no loss in doing it this way. Had they made an actual 24p data stream they could not have made it HDV compatible. HDV has no provision for 24p in the spec -- it's 25p, 30p, 50p and 60p only. So they implemented 24p within a 60p data stream, to keep it HDV-compatible.

I think the problem is merging my understanding of MPEG-2 TS with the concept of 24fps pulldown from DV and the concept of Flagged frames from Varicam.

I think this is the first time inter-frame compression (TS) has incorporated intra-frame compression technology.

To really understand I've got to draw it. Thank you guys for the help!

According to JVC, they write MPEG-2 to tape as they do DV. That is, each DV frame requires two "tracks" (ie., 2 swipes of the head accross the tape -- each swipe is 1 field) so every frame of HDV will also be require 2 tracks. Thus one second of DV, or one second of HDV, require 60 tape tracks.

JVC writes the TS bit-stream into the DV segment of the tape -- leaving the PCM segment untouched -- for now. They write Sub-code into it's area.

However, they also claim that WITHIN these 60 tracks, the TS macro-blocks are written in a scrambled way so a small DO can only wipe out a few macro blocks. They claim the loss of an I frame is almost impossible because the DO would need hit -- over the 60 tracks -- all the macroblocks making-up the I-frame.

So you are correct that within the 60 tracks, the CBR bit-stream is written without regard for "tracks." It is a pure data stream.

Nevertheless, the 5 GOPs -- written into 60 DV tracks -- making up 30 frames DOES occupy an exact amount of space on the tape. Thus 30fps recording use a fixed space on the tape for every second of video.

What we don't know is if JVC designed the system so the 60 tracks can hold the data-stream for 30 frames or 60 frames. If only 30 frames, then JVC has to make a change to support 720p60 -- run the tape twice as fast and write 120 frames for each second, thereby cutting recording in half OR increase the the recording density by 2X.

But, if the 60 tracks will hold the data for 720p60 -- JVC is all ready for 720p60 simply by swapping in a new encoder.

I tend to think the 60 tracks can accept 720p60, but is now being used at "half capacity" however that might be be done.

Wow! It seems that your ideas can't be budged. Sorry, your conclusions are counter to our real world experience of analyzing the transport stream data.

It isn't me that needs to be budged -- you'll have to budge JVC. I have had the HDV tape data structure explained several times to me by JVC. JVC considers it very important that they use the DV track structure and Sony does not. They want the press to understand that point!

I don't see why you have so much believing JVC. Are you really saying they are lying to the press? Or, their engineers don't understand their own technology?

And, if you read the D-VHS spec. doc, they have diagrams of the track structure where the TS bit-stream is packed into groups of 6 tracks.

http://www.jvc-victor.co.jp/english/D-VHS/dvhstr-e.html

David, when you look at the TS bit-stream it is tellling you NOTHING about the tape track structure! The data you see has been already been removed from the tracks. I'm not saying ANYTHING about TS data. I made that clear in what I wrote.

The track structure has an important role in ProHD:

1) It is what will allow PCM audio to be added. JVC engineers explained at great length to me why the PCM audio would be 6-frames ahead of video. That's because all 6 frames of the GOP must be pulled off the tape, before the first video grame can be output. But the very first PCM audio was pulled from the tape on the very first frame! Is JVC Japan feeding me BS?

2) If the structure already has the capacity to hold 720p60 within the 60 tracks -- it means JVC needs to do very little to get 720p60.

3) If the 60 tracks cannot hold the data for 720p60 -- then it will need to be modified for 720p60. If they do this, the JVC way (D-9), they'll speed-up the tape recording 120 tracks/second. (And, that will give us 4-channel PCM audio.)

4) It also allows "trick frames" which is how you can see video during high-speed Forward/Rewind.

5) It holds meta-data.

Bottom-line -- tape always has a structure. Even when it it is recording pure data -- tape always has a structure that holds the data. I don't see, given that JVC is so consistent on this point, why you are having so much problem accepting that the transport streams (what you see) are carried within a structure.

"I tend to think the 60 tracks can accept 720p60, but is now being used at "half capacity" however that might be be done."

I seriously doubt this Steve. Think of pure data rates. The transport mechanism is at the heart of it a backup drive, with a maximum data transfer rate of 25Mbps. JVC are using the full 19Mbps of 720p for their encoding (or lets face it the artifacts would be pretty rude if it was only using 9.5Mbps for 720p).

So, if JVC want to encode 60p using the same tape transport, they would have to use the same data rate (or up to 25Mbps anyway), and that wouldn't be a good thing.

As you say, they would need to double the transfer rate to tape to allow for 38Mbps which would mean as you suggest running the tape 2x speed or a new tape format with double the density.

Of course, they could also do this like Panasonic are, and only allow the higher frame rates to the likes of the FS4 and limit tape recordings to 30p max.

Let's see:

1280x720x30 >> 27,648,000 pixels/second compressed into about 18Mbps

1440x540x60 >> 46,656,000 pixels/second compressed into about 23Mbps

1280x720x60 >> 55,296,000 pixels/second compressed into about 18Mbps

What do see here?

1) That 1080i is far more compressed than 720p30 -- which is why 720p30 looks so much better!

2) We can see that: 27,648,000 / 18 >> 1.5:1
verses 46,656,000 / 23 >> 2.0:1

3) How would 720p60 fare? 55,296,000 / 18 >> 3.0:1

4) So while 720p60 would be 2X more compressed than 720p30, it would only be 1.5X more compressed than 1080i is today.

Which why it is possible that JVC will release an HD100 class camcorder with 720p60. And, why I think today's camcorder tape recording structure can handle 720p60.

But I'm totally wrong about "half capacity." Clearly the 720p30 is recorded into the full 18Mbps. It simply looks much better than if 720p60 were compressed to 18Mbps!

Question: would 720p60 look worse than 720p30 at 18Mbps. Perhaps not if the encoder is far better than the one in the HD1/HD10. For this reason I wouldn't rule-out a 720p60 version of the HD100 once the encoder can handle 60fps. For one thing, under motion, it would divide motion into 60 steps rather than only 30 steps -- so the motion vectors would be far more accurate.

Which means there is another approach to 720p60 than writing 120 tracks/second I mentioned in a reply to David. Using a better encoder, 720p60 can be squeezed into the same 60 tracks/second used to today for 720p30.

Which is why I think JVC is talking about a 720p60 "wrapper" on a 30fps camcorder. The wrapper is 60Hz even though today it only carries 24p and 30p -- because it will carry 60p in an HD200.

"Question: would 720p60 look worse than 720p30 at 18Mbps"

I wouldn't doubt it at all, but that is only my guesswork at play. I know what you mean by the motion vectors being less, however I have to think that your still adding more than your compression gains or 120fps would be better than 60fps again.

If 19.2Mbps is good enough for broadcast HDTV runing at 720p60 -- why should we think it won't be OK for a next generation HD100. Which is another reason I think the HD100 currrent recording system is ready to carry 720p60. In fact, I doubt it is any different than the HD1/HD10.

I feel like this fact has been staring us in the face all along. JVC chose an ATSC data rate of 19.2Mbps exactly so everything will match an industry standard. Which is why they continue to use record TS while Sony does not.

And, they chose to record this to an industry standard DV tape data structure.

This is pure JVC thinking. It is the way they worked VHS. For decades they kept evolving upon the VHS platform. Enhancement after enhancement. Likewise, with Digital-S (D-9) which is VHS in it's nearly last form. Along with W-VHS and D-VHS.

They'll take 19.2Mbps, MPEG-2 TS, and DV transports as far as they can.

"If 19.2Mbps is good enough for broadcast HDTV runing at 720p60"
I havn't seen it but I think the question is "is it good enough?".

I have noticed since the intro of digital TV that the quality of what is broadcast is often much less than what I would have thought would be acceptable or termed "broadcast quality". Some content looks simply stunning, but other content looks horrible, full of macroblocks etc. People worry about chromatic abberations in the HD101's lens yet there are far worse villans out there. The quality of the encoder is a huge factor. After all, these things have to be real time encoders, which even our 3.6GHz top of the range CPUs can't achieve while consuming 100+ watts.

If you get your way, I think you'b be left with the choice of either great quality 30p or a unimpressive 60p without throwing more bitrate at it.

Only my opinion though, and you know what they say about opinions, like armpits, everyone has em and most of them stink... (thats the nice analogy anyway)

AGREED, with a capital "A" (and capital "G", "R", "E", "E", and a "D"). 19.2 isn't good enough for broadcast. Works okay for "American Idol", but the bitrate is woefully inadequate for sports coverage. Macroblocking and mega-mosquito noise galore.

What you both say is true -- of 1080i60.

But it is definitely not true of 720p60.

I have NEVER seen an MPEG2 artifact on FOX, ABC, or ESPN sports! Never, ever!

But, when there is a burst of fire on an animattion on sports replays -- the fire macro blocks like crazy on 1080i. Perfectly clean on 720p60.

Progressive simply compresses with vastly greater efficiency under motion.

I've also never seen an artifact from my JVC HDV camcorder.

However, I must compliment CBS. They really send out a clean signal! They also refuse to allow cable companies to drop their data rate. It's NBC that gets most of the complaints.

Hey Barry!

I'm moving to LV in October! Already bought a house and car!

How good/bad is Cox HD?

See you in October!

There is a way to answer this question. Find out what the HD7000 is going to do.

http://pro.jvc.com/prof/Attributes/f...&feature_id=01

User-selectable Recording Format
HDV: 720/24p/25p/60p/50p, 480/60p, 576/50p
MPEG2: 1080/60i/50i (HDD Only)
DV: 480/60i/24psf, 576/50i/25psf


It won't do 1080p (thats a bit of a shame). We know HDV is 4:2:0, but what about the "MPEG2: 1080/60i/50i". It would be nice to have a 4:2:2 option, especially on a camera your going to spend near on US$30K