Is HVX true 4:2:2

[Barry_Green]

1. Can this camera record 4:2:2 color onto DV tape at 480P?

No, only miniDV can be recorded on the tape.

2. Can this camera record the 720P to "DV tape" with variable frame rates (slow motion, ect.)?

Yes, but the footage will be downrezzed to DV. Only miniDV can be recorded on the tape.

3. What is the most cost effective portable hard drive to record 720P variable frame footage with? Any recommendations?

You can use any firewire drive to offload the contents of a P2 card onto. If you're talking about live streaming directly to the drive, no product on the market supports that yet, although there should be at least two competitors by March.

4. What is currently the best NLE to edit 720P 24fps, HD DVCpro footage with? In other words, with a Powerful PC how can you easily edit with this 720P 24fps content as source?

You don't need a powerful PC. A two-year-old Powerbook can easily handle 720/24p in realtime. A modern powerful PC running FCP-HD, Avid Express Pro HD, or Canopus Edius Broadcast should probably be able to handle a dozen streams of 720/24p in realtime.

5. HVX-200 vs. DVX-100b for 480 24P footage, any difference?

Yes there are many differences, not the least of which is the HVX can capture 4:2:2 DVCPRO50 in 480p. Plus the HVX has native 16:9 CCDs. And a sharper lens. And a longer telephoto. And all sorts of other bonuses -- but then again, it's $2,000 more.

Does the HVX capture better 480P image quality then DVX-100b?

In a nutshell, yes. Now, if you're talking DV-to-DV, that's a question that will have to wait until we get a final released version and can do some fair comparisons, but the sheer advantage of the 16:9 chips will make a huge difference if you're talking about recording 16:9 footage. And the 4:2:2 DVCPRO50 mode will yield noticeably better results.

The DVX100B is an excellent camera, no doubt. But there are reasons why the HVX is $2,000 more.

 

[smelni]

Stephen -I am not sure if I agree with all that. The uncompressed frames rely on the compression that the original data has. So if you are compressing across frames you are losing some information across frames and therefore the uncompressed frames necessarily suffer at least a small amount. If your original frames are separate then the compression is not dependent on the other frames and so you wont lose information across frames.

Take a jpg for example - if you compressed across images you would necessarily lose information that you dont when they are compressed individually - i beleive this is a mathamatical certainty when dealing with lossy compression.

So DVCproHD (by this logic) is superior in its intraframe compression because all the "power" of the codec is in one frame instead of multiple - hence the motion artifacting that I understand happens with HDV.

Barry - is my logic sound?

 

[stephenlnoe]

Stephen -I am not sure if I agree with all that. The uncompressed frames rely on the compression that the original data has. So if you are compressing across frames you are losing some information across frames and therefore the uncompressed frames necessarily suffer at least a small amount. If your original frames are separate then the compression is not dependent on the other frames and so you wont lose information across frames.

Take a jpg for example - if you compressed across images you would necessarily lose information that you dont when they are compressed individually - i beleive this is a mathamatical certainty when dealing with lossy compression.

So DVCproHD (by this logic) is superior in its intraframe compression because all the "power" of the codec is in one frame instead of multiple - hence the motion artifacting that I understand happens with HDV.

Barry - is my logic sound?

I offered a TGA sequence above that is a zipped set of 6 frames from an HDV timeline uncompressed. You have a full GOP of HD-100 HDV to observe for yourself. When you bring the frames into Photoshop or Photo-Paint or whatever TGA photo editor you have you can observe the properties of the frame which is 1280 X 720 24bit RGB for every frame whether it's an I a B or a P frame. You see, once the frames are uncompressed then they are independent and the transport stream goes out the window. It's the power of the wired camera codec's motion estimation and DCT compression that ensures quality throughout the transport stream.

Uncompressed is uncompressed but not all HDV uncompresses the same. Sony's camera codec is known for not handling motion estimation well and therefore the possibility of macroblocks getting recorded in the B and P frames is there in a high motion situation. JVC on the other hand has extensive eperience with MPEG2 compression and has utilized that in their ProHD codec.

HDV1 (or in other words ProHD) has been a powerful addition to HDV and their motion estimation is impeccable, therefore the B and P frames are as you see them on the sequence provided above. I also off you to go over to the JVC portion of this forum and utilize any of the m2t's posted and dissect them and look for macroblocks. They just aren't there and therefore the signal is clean throughout the IBP GOP.

DVCProHD is great but it uses CBR DCT intraframe which isn't the most efficient compression method and therefor the datarate has to be very high to maintain the quality of the image. A good read as has been pointed out is HDTV Algorithms and Interfaces which will help anyone understand the codecs and how their quality is derrived.

good luck...

 

[smelni]

You still arent looking at my point - if you take a compression algorithm and use it across frames you will have worse results then taking the same algorithm within a single frame - this is a mathamatical certainty when applying a lossy algorithm to any data.

Now, i understand that this is not the case with dvcpro vs hdv BUT - dvcpro will not have motion artifacts simply because it is not compressed across frames - yes this requires a higher data rate - that is necessary to perform that kind of compression.

So if we assume that the 2 compression algorithms were equivalent but one is across frames and the other isnt - then the one that isnt is better.

So the question then becomes, id the hdv compression algorithm so much more better then the dvc algorithm to overcome the interframe compression issues to make it a better codec

of course this is really just an academic question - our eyes will tell us which is better - but from a mathamatical standpoint i beleive my logic is sound.

 

[smelni]

I offered a TGA sequence above that is a zipped set of 6 frames from an HDV timeline uncompressed. You have a full GOP of HD-100 HDV to observe for yourself. When you bring the frames into Photoshop or Photo-Paint or whatever TGA photo editor you have you can observe the properties of the frame which is 1280 X 720 24bit RGB for every frame whether it's an I a B or a P frame. You see, once the frames are uncompressed then they are independent and the transport stream goes out the window. It's the power of the wired camera codec's motion estimation and DCT compression that ensures quality throughout the transport stream.
..

the example you gave has no motion so the algorithms collapse into similar results - this wouldnt be a good example to show what i am talking about - I would think if you did this same example with a lot of motion the dvc would win out - I dont know for sure - but that is my suspicion.

 

[Barry_Green]

So DVCproHD (by this logic) is superior in its intraframe compression because all the "power" of the codec is in one frame instead of multiple - hence the motion artifacting that I understand happens with HDV.

HDV motion artifacting happens for a number of reasons, but there are two major ones: motion estimation errors, and the whole concept of there just not being enough bits to go around.

An interframe codec like MPEG compresses groups of frames all together, and allocates a certain # of bits to compress all those frames. If very little changes from frame to frame, the compression can be extraordinarily efficient. Shooting a static res chart, for example, will show HDV looking the best that it ever can. You'll notice that most HDV demo tapes show primarily tripod shots: Canon's, JVC's, and Sony's demo footage all show various scenes in mostly-locked-down circumstances, because that's where HDV performs its best.

So back to the GOP: within a group of frames, MPEG compresses one frame "normally" (i.e., all within the one frame), and this takes up a huge chunk of the bandwidth; it then allocates the rest of its bits to handle the changes between frames. If you have a static head shot (for example, interviewing a person talking) a lot of the frame will stay the same from frame to frame. MPEG encodes the differences between the frames, not the full frames. And therein lies the reason it can get away with such low bitrates by comparison; DVCPRO-HD (and all other DCT compression systems, such as HDCAM and Digital Betacam and MJPG and MPEG-IMX, etc) will all compress each and every frame from scratch. Which could be viewed as wasteful, but at least it's consistent. This is what Stephen is referring to when it says that it's not the most efficient type of algorithm; obviously recompressing all that unchanging data is not the pinnacle of efficiency.

So MPEG attempts to get great efficiency by encoding only the changes. And frequently not a lot will change between frames. So if the frame stays mostly the same, there's plenty of bits to be allocated to the small segments that do change, and that's why in most circumstances HDV looks (to quote Adam Wilt) "better than it has any right to."

But what happens if things do change? Lots of things, like let's say a strobelight goes off and so every pixel in the frame changes -- what happens then? Well, with DVCPRO-HD, nothing bad happens -- it just encodes the new frame as efficiently as it encoded the last frame. But for MPEG-2, it has a heart attack. EVERY PIXEL CHANGES. It can't handle that. So not only does the new frame suffer, but every frame in the group suffers -- it has to rob bits from the rest of the GOP to try to get enough bits to cope with the drastic-change scenario. This means you can have a substantial quality dropoff for the duration of that entire GOP. In Sony/Canon HDV, this means 1/2 second of substandard video quality. In JVC, it means 1/4 or 1/5 second (depending on whether you're shooting 24p or 30p).

Once that group of pictures is over, the quality can maybe recover -- on the new group, it's back to normal, presuming few changes.

So what happens when you pan? People think panning should cause HDV to fall apart, but for the most part HDV handles pans pretty well. You'd think that the massive changes in the frame would cause HDV to puke, but remember, MPEG-2 was designed to handle MOTION images. MPEG-2 includes motion prediction algorithms that can detect when something is moving through the frame, and take advantage of that redundancy even if it's moved to a new position. So MPEG-2 can frequently handle panning reasonably well. It won't be as solid as a static shot, but it'll be pretty solid depending on the quality of the motion prediction algorithm.

But some things cause massive change and give HDV fits -- things like pine needles blowing in the wind. It doesn't like that at all, and all the fine detail in the pine needles will turn to complete mush. Strobe lights make HDV very unhappy. And heat waves -- you know, the long telephoto shots in the desert where a guy comes walking over a hill, and the whole screen is rippling with heat waves -- those can cause HDV trouble. And water -- HDV can get upset by rippling water too. And smoke. And fire. All those things can cause HDV to puke. Not always, but it can happen. And the reason it happens is because HDV's motion-prediction algorithms can't cope with such unpredictable motion events.

You can see an exaggerated version of this bit-starved GOP effect on just about any HDTV broadcast. Watch broadcast high-def TV, especially in a football game, and when a full-screen graphic pops up on the screen, you'll see the picture turn super-blocky for a half-second. Or it'll happen in drama too, when they cut from a tight shot to a close-up or the other way around -- things will get blocky and bitty, just like congested net video. 720P broadcasts are a lot more resilient against this effect than 1080i broadcasts are, and 720p HDV is a LOT more resistant to artifacting than 1080i is. This type of thing doesn't happen much in HDV acqusition because usually the changes between frames during acquisition are more predictable and less drastic; I'm just offering it as an exaggerated example so you can see what happens.

720p HDV is about the best flavor of HDV for a number of reasons. The motion prediction is pretty solid, (although Nate posted some downtown L.A. clips that showed a weird ghosting artifact during a pan, an outline of a building came detached off the building and followed the pan about 20 pixels away, it was weird...) but anyway, its motion prediction is pretty good, but it also benefits because it's progressive-scan and progressive encodes much easier and much better than interlaced does. Then you have to factor in that there are many fewer pixels per frame (about 920k, vs. 1.5 million for 1080i) so that makes the compressor's job easier. And finally, there are far fewer frames -- 720/24P is a much lighter workload than 1080/60i. 1080/60i results in something like 46 million pixels per second, whereas 720/24p results in about 22 million pixels per second. So JVC gets the benefit of progressive encoding as well as almost twice as many bits per pixel to encode its footage.

It's not flawless though. Graeme posted a picture where he panned across some leaves and it shows horrific artifacting. (http://www.nattress.com/JVC_Artifacts.jpg) It happens. It's in the nature of HDV. It may not happen very often, but occasionally it will bite you in the butt. It's the price you pay for trying to record high-definition video on a $4 tape. This is the kind of thing that would never happen on an intraframe codec like DVCPRO-HD. DVCPRO-HD will compress each frame exactly the same under all circumstances, regardless of what came before it or comes after it.

 

[Barry_Green]

So if we assume that the 2 compression algorithms were equivalent but one is across frames and the other isnt - then the one that isnt is better.

But not at the same data rate.

Given adequate bandwidth, MPEG-2 or H.264 would be fantastic. My only problem with it is that the 19 or 25 megabits of HDV, or especially the 19 megabits of broadcast HDTV, is just not enough (well, that and the low color sampling). Give MPEG-2 or H.264 100 megabits to work with and 4:2:2 sampling and it would be fantastic.

So the question then becomes, is the hdv compression algorithm so much more better then the dvc algorithm to overcome the interframe compression issues to make it a better codec

At its current bandwidth, unquestionably not. At equal bandwidth, probably -- but only if you juiced it up to 4:2:2. I would bet that 4:2:2 MPEG-2 at 100 megabits would probably be notably superior to DVCPRO-HD in most shooting cases.

But at the bandwidth it's been given, no -- HDV just isn't in the same class as DVCPRO-HD.

 

[stephenlnoe]

the example you gave has no motion so the algorithms collapse into similar results.

You're right, not much motion. So instead I offer you 12 frames (2 full GOP) of birds and fire. Let's take a look at a real torture test.

Click here for uncompressed high motion frames

It's not flawless though. Graeme posted a picture where he panned across some leaves and it shows horrific artifacting. (http://www.nattress.com/JVC_Artifacts.jpg)

Barry, I'd like to see the sequence that still was lifted from. I've torture tested the HD-100 in almost any scenario and the frames are impeccable (I B and P), heat waves, steam, flashes, water waves, everything and it still holds true. Now if that d@mn 13x lens would come, we'd be set for the next couple of years.

 

[smelni]

thanks barry - i think we were agreeing about everything.

But as usual your complete description helps a lot

 

[smelni]

that new example has motion yes - but its not something that i would expect would overload the codec - a flock of birds flying - that is different - motion everywhere and random - that would be difficult

 

[Barry_Green]

Barry, I'd like to see the sequence that still was lifted from.

Me too -- but he's never posted it. I have put the HD100 through some challenging circumstances and usually been quite impressed with how well it's handled things. For HDV it's quite solid.

 

[stephenlnoe]

that new example has motion yes - but its not something that i would expect would overload the codec - a flock of birds flying - that is different - motion everywhere and random - that would be difficult

Have a look for yourself Click Here

best of luck to you...

 

[Emanuel]

Thanks stephenlnoe, as always.

 

[smelni]

Great examples - stephen - and the snow globe shows exactly what I was talking about - when you are in close and there are random particles moving in random directions that is where the codec breaks down. Ill bet that DVC would do better for that shot.

So for most of typical shots that codec will be fine but its the rare shot that will, as barry says, bite you in the butt

 

[Graeme_Nattress]

Stephen, I think I still have the capture on my system, but it's a FCP .mov rather than a raw MPEG stream. It looked awful in camera, too, played back on both CRT and LCD monitors. In shots where I tried to provoke the macroblocking, I often failed, but that one just caught it right - slow enough to see the artifacts, not fast enough to blur the level of detail down enough.

HDV is too compressed - you really can't do much in post with it, especially if it means brightening it up.

But...

DVCproHD is nearly as bad in this regard.

Mostly down to 8bit video and very, very high compression of the darker areas of the image removing the natural noise that would dither the image and stop the visibility of the artifacts.

Graeme

 

[Emanuel]

HDV is too compressed - you really can't do much in post with it, especially if it means brightening it up.

But...

DVCproHD is nearly as bad in this regard.

Mostly down to 8bit video and very, very high compression of the darker areas of the image removing the natural noise that would dither the image and stop the visibility of the artifacts.

And if we are going to a 10bits or even to an uncompressed workflow @post production?

 

[Graeme_Nattress]

It's still 8bit video. I know of know algorithms that can make 8bit video behave with the colour correcting capabilities of 10bit video.

Graeme

 

[Emanuel]

10 bits will it be the way?

 

[Graeme_Nattress]

I don't understand the question, Emanuel.

Graeme

 

[Emanuel]

Sorry my friend! My point is: 8 bits is not enough, right? Or will it be? Because I'm thinking to go to Cineform codec or even uncompressed HD @post production for 35mm film-out. What's your superior advice?