720p24 Mode Theories

[David Newman]

Originally Posted by Nate Weaver

Why they didn't go with a 24fps stream to begin with I'll never know...existing compatibility, perhaps?

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. :)

[Steve Crisdale]

Originally Posted by David Newman

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.

[Steve Mullen]

Originally Posted by David Newman

720p24 is not an HD broadcast standard, whereas 720p60 is.)

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?

[Nate Weaver]

Originally Posted by Steve Mullen

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

Correct. It works nothing like the DVX.

Originally Posted by Steve Mullen

Nor does it work like film where only 24fps are recorded -- which would lengthen record time.

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

Originally Posted by Steve Mullen

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?

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.

Originally Posted by Steve Mullen

And, what gets sent down the i.LINK cable?

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

Originally Posted by Steve Mullen

Does the HD100 send 60 frames/second? If so, then it feeds 720p60 into your NLE. (Of course, each frame has been doubled.)

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.

Originally Posted by Steve Mullen

which, if any, NLEs understand "Flagged Repeat 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.

Originally Posted by Steve Mullen

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.

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.

[Barry Green]

Originally Posted by Steve Mullen

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.

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.

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

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.

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!)

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.

Anyway, I'm still confused. Only 30 -- not 60 frames -- are RECORDED to tape otherwise the tape duration would be cut in half.

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!

So the 24 frames have to get placed within 30, not 60 frames.

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.

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

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

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.)

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.

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.

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.

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.

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.

[Nate Weaver]

Originally Posted by Steve Crisdale

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.

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

Originally Posted by Steve Crisdale

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.

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.

Originally Posted by Steve Crisdale

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.

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.

[Steve Mullen]

Originally Posted by Nate Weaver

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 i.

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.

[Barry Green]

Originally Posted by Steve Mullen

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.

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.

[David Newman]

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.

[Steve Mullen]

Originally Posted by Barry Green

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.

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?

[David Newman]

Originally Posted by Steve Mullen

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?

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.

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.

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.

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.

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.

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.

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.)

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

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

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?

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.)

[Barry Green]

Originally Posted by David Newman

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

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.

[Steve Mullen]

"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."

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!

[Steve Mullen]

Originally Posted by David Newman

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.

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.

[David Newman]

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.