View Full Version : Is HVX true 4:2:2
smelni
12-27-2005, 07:43 PM
I heard a rumor and first i must say very clearly that it is just a rumor that i wanted to check out.
I heard that the HVX is not true 4:2:2 - I am not sure why or how. I have actually heard this a couple of times and recently from someone "in the industry".
I just wanted to see if anyone has heard this and if it is true then what does that mean and especially what does it mean for quality and keying?
I do not mean to start a rumor so if this is completely untrue then I apologize in advance.
thanks
Barry_Green
12-27-2005, 09:18 PM
There are people trying to claim that the HVX is 3:1.5:1.5, which just shows that they clearly do not know what they're talking about (nor do they know how to do the math, because the ratio of 3 to 1.5 is exactly the same as the ratio of 4 to 2, so 3:1.5:1.5 is the same as 4:2:2)!
The HVX is true and genuine 4:2:2. Two color samples for every four pixels, on each and every line.
The discrepancy comes about in them trying to equate horizontal luma subsampling with the number 4. And you can't. You don't. That's not what the "4" means.
For example, HDCAM is 3:1:1. These people who are spreading the fibs are trying to say that the "3" in this case represents a subsampling of 1920 down to 1440. But it doesn't. It has nothing to do with that. The 3 shows the ratio of luma to chroma samples IN THE SUBSAMPLED LINE. So HDCAM is 3:1:1, meaning there's one chroma sample for every three pixels, on every line. The way it works is HDCAM is 1440x1080 in luma, and 480x1080 in chroma. 1440 / 3 = 480. 1/3 as much chroma as luma. 3x as much luma as chroma. So it's 3:1:1. Has nothing to do with the number of luma samples per line; it could be 1920x1080 and still be 3:1:1 if the chroma sampling was done at 640x1080.
They then try to claim that HDV 720p is 4:2:0, because it doesn't subsample luminance at all, it retains a full 1280x720 luminance grid, so they try to claim that that's what entitles that format to use a "4". Which is nonsense. HDV 720p is 4:2:0 because there are two chroma samples for every four luminance samples, on every other line. See, where they fall down in their tilting-at-windmills quest is that they conveniently forget to point out that 1080i HDV is also 4:2:0, and 1080i HDV also subsamples from 1920 down to 1440. So shouldn't HDV 1080i be limited to a maximum first value of 3, if they're going to claim that that's why HDCAM is measured as 3:1:1? And wouldn't that make HDV 1080i 3:1.5:0? Preposterous. 1080i HDV is 4:2:0.
It just shows a complete misunderstanding of 4:x:x terminology. Charles Poynton explains it rather well, and so does Graeme Nattress. The sampling notation of 4:x:x is applied to the final ratio of chrominance to luminance, AFTER subsampling.
DVCPRO-HD is 4:2:2 in all modes. Yes there's subsampling. Yes there's subsampling in 1080i HDV and in HDCAM too. That doesn't change what 4:2:2 and 3:1:1 and 4:2:0 mean.
Emanuel
12-27-2005, 09:46 PM
Right! As you well explained, Barry, it was a obvious misunderstanding of the ratio meaning, BTW, concerning 720p and not 1080i/p, wasn't it?
And about HDCAM, if it is the same ratio method but 3:1:1 (480x1080 in chroma), does it mean an inferior ratio, that is, a DVCPRO-HD chroma advantage? 640x1080 in 24p/60i and 720x1080 in 25p/50i?
stephenlnoe
12-27-2005, 10:43 PM
Hi,
HDV 720p:__________Frame res 1280x720, 4:2:0, Y sample: 1280x720, Cr,Cb Sample 640x360
DVCProHD 720p:_____Frame res 1280x720, 4:2:2, Y sample: 960x720, Cr,Cb Sample 480x720
JVC gives the full scan 1280x720 without subsampling/shifting so the final frame follows the spec listed above.
Barry_Green
12-27-2005, 11:43 PM
Right! As you well explained, Barry, it was a obvious misunderstanding of the ratio meaning, BTW, concerning 720p and not 1080i/p, wasn't it?
Yes, this argument is always applied against 720; for some reason the detractors always seem to forget that DVCPRO-HD also offers 1080i and 1080p (wonder why they leave that out? Hmmm...) I mean, do they really expect that 1280x720 with 640x360 chroma can stand against 1280x1080 with 640x1080 chroma? 50% more luma and 3 TIMES as much chroma res?
And about HDCAM, if it is the same ratio method but 3:1:1 (480x1080 in chroma), does it mean an inferior ratio, that is, a DVCPRO-HD chroma advantage? 640x1080 in 24p/60i and 720x1080 in 25p/50i?
Yes, in 1080 DVCPRO-HD records substantially more chroma than HDCAM does.
Barry_Green
12-27-2005, 11:45 PM
Hi,
HDV 720p:__________Frame res 1280x720, 4:2:0, Y sample: 1280x720, Cr,Cb Sample 640x360
DVCProHD 720p:_____Frame res 1280x720, 4:2:2, Y sample: 960x720, Cr,Cb Sample 480x720
JVC gives the full scan 1280x720 without subsampling/shifting so the final frame follows the spec listed above.
Those numbers are correct, yes, but it leaves out that DVCPRO-HD supports twice as much temporal resolution as HDV 720p does. HDV 720p in its current configuration is limited to a maximum of 30p, DVCPRO-HD delivers 720/60p.
toke lahti
12-28-2005, 04:59 AM
The HVX is true and genuine 4:2:2. Two color samples for every four pixels, on each and every line.
This really puzzles me, how an earth the horizontal chroma resolution is visibly so acceptable?
If we compare full hd 4:4:4 horizontal resolution and dvcprohd1080p, we notice that there are only one chroma sample in dvcprohd per 3 samples in full hd.
At the same time vertical resolution in dvcpro has the same chroma resolution than full hd.
Clearly this is because of legacy reasons of interlaced television, but that's something we should get away from.
In progressive picture, I see no logical reason for 3x1 chroma pixels (or even 4x1 in hdcam), so instead of getting 640x1080, I'd prefer 960x540.
So I'll hope that next dvcpro codec we'll get is 1920x1080@4:2:0.
It should give better quality than 1280x1080@4:2:2 at least with natural content.
JerseyMike
12-28-2005, 05:52 AM
Here's a link to a PDF written by Charles Poynton about chroma subsampling notation:
http://www.poynton.com/PDFs/Chroma_subsampling_notation.pdf
smelni
12-28-2005, 06:02 AM
Barry - thank you so much for clearing this up - a great explanantion as always - now i understand what i was being told and I can give the explanation back.
thanks for your time
stephenlnoe
12-28-2005, 07:27 AM
Those numbers are correct, yes, but it leaves out that DVCPRO-HD supports twice as much temporal resolution as HDV 720p does. HDV 720p in its current configuration is limited to a maximum of 30p, DVCPRO-HD delivers 720/60p.
Barry,
Just keeping the apples with the apples. 720p24 to 720p24. Frame for frame.
Of course there is a cornucopia of datarate and resolution math, however with the JVC offereing you know you're getting full1280x720p24@3.51MB per uncopressed TGA frame and Y sample: 1280x720, Cr,Cb Sample 640x360. That's nice to know.
A Hi8 beat us all out of a 48hour film project win because the story was excellent, not because of their technology. I mention the 48hour specifically because there is such a mixed bag of cameras all in one place.
It's all good isn't it?
smelni
12-28-2005, 08:09 AM
wait - now i am a little confused. So is the HDV format better at the luma sampling when recorded at the same frame rate as DVCProHD?
stephenlnoe
12-28-2005, 11:20 AM
wait - now i am a little confused. So is the HDV format better at the luma sampling when recorded at the same frame rate as DVCProHD?
The short answer is yes.
When you compare apples to apples (ie 720p24 HDV1 to 720p24 DVCProHD)
HDV 720p:__________Frame res 1280x720, 4:2:0, Y sample: 1280x720, Cr,Cb Sample 640x360
DVCProHD 720p:_____Frame res 1280x720, 4:2:2, Y sample: 960x720, Cr,Cb Sample 480x720
The formats are much closer than people think.
Barry's right when you get into different resolutions though (1080i and 1080p). We'll see what NAB brings to the table for HDV and 1080p.
smelni
12-28-2005, 11:26 AM
So then, considering this - it seems that DVCproHD's biggest winning attribute is the intraframe compression - while HDV is highly interframe compressed. Cause the YCrCb numbers work out to be very close - about 10 percent different if you multiple all the numbers
Barry_Green
12-28-2005, 01:41 PM
wait - now i am a little confused. So is the HDV format better at the luma sampling when recorded at the same frame rate as DVCProHD?
At the same frame rate? No, because at 24P you could record in 1080 and get 1280x1080, vs. 1280x720 in HDV. You'd get 50% more luma, and three times as much chroma, in DVCPRO-HD.
The HDV1-to-DVCPRO-HD comparisons always try to limit DVCPRO-HD to its very most limited mode. DVCPRO-HD can do far more than HDV can even think about.
It's like if you were going to play basketball against Shaquille O'Neal, but you decided that because you're 5'6", the artificial constraint is that both players can be no taller than 5'6". So Shaq has to play on his knees. Would you stand a pretty good chance against him in that case? Sure. Maybe. Heck, Shaq'd probably still beat most of us, but yes you'd have the best chance you'd ever have. But why would Shaq ever agree to that? Unleash the man, let him play, and you'd never stand a chance.
If you want to stick to 24P, shoot 1080/24P on the HVX, and get 50% more luma res and 3 TIMES as much chroma resolution as HDV1. If you want to stick to 720P, let the HVX's full 60P frame rate come into play, where you get a comparable resolution picture (25% less luma than HDV1 but 50% more chroma than HDV1), but you also get variable frame rates and up to twice as many frames per second.
No contest.
Barry_Green
12-28-2005, 01:57 PM
So then, considering this - it seems that DVCproHD's biggest winning attribute is the intraframe compression - while HDV is highly interframe compressed. Cause the YCrCb numbers work out to be very close - about 10 percent different if you multiple all the numbers
Hardly. DVCPRO-HD's biggest attributes are:
intraframe compression for a complete avoidance of all motion artifacts;
substantially superior chroma resolution (in 720p mode it has 50% more chroma than HDV, in 1080 mode it has about 90% more than HDV);
true progressive scan in 1080 mode, which no HDV2 product offers;
constant, predictable compression performance on a frame-for-frame basis, vs. HDV's bit-starved nature which can cause significant image degradation if the codec gets overloaded;
imperviousness to dropouts, where HDV can punt an entire 15-frame GOP (1080 mode) or 6-frame GOP (720 mode); or, in the JVC version, you can get massive scrags that stay on the screen for 1/4 to 1/5 second (depending on whether you're recording 24p or 30p mode);
variable frame rates;
the ability to record 60p in 720 mode;
MUCH milder compression than HDV in all circumstances;
bitstream compatibility with existing DVCPRO-HD products that are already established in the marketplace, such as the AJ-HD1200A deck and the VariCam, as opposed to the nearly universal incompatibility of the three various flavors of HDV;
much better editing integration (FCP5 has been working in native DVCPRO-HD for 18 months now, since April 2004) and depending on your Mac you can edit nearly a dozen streams of DVCPRO-HD in real time (something that just isn't gonna happen when editing an MPEG-2 transport stream!);
the ability to do a firewire preview of DVCPRO-HD data, something HDV cannot now nor ever do. Not sure if the HVX supports realtime firewire scrubbing/preview in HD or not, but it works on the 1200A deck.
There are probably more reasons, these are just the ones that I can think of off the top of my head.
The 720/24p variant of HDV is probably the most robust, best implementation of HDV. I have said many times that if I had to shoot HDV, that would be the flavor that I would strongly prefer (although Canon's new 1080/24F is not bad at all). That doesn't put it in the same ballpark, class, or league as DVCPRO-HD though. It's a whole class up from HDV. Maybe two, if you follow Sony's logic:
DVCPRO-HD is a direct toe-to-toe competitor to HDCAM. Sony produces four HD formats, HDCAM-SR at the top, then HDCAM, then XDCAM-HD, and then HDV at the bottom. Sony classifies XDCAM-HD as "between HDV and HDCAM." That puts HDCAM two levels above HDV. And by extension, DVCPRO-HD two levels above HDV. And that sounds about right to me.
smelni
12-28-2005, 01:59 PM
Barry - i understand all that and see that the hvx is superior in that way. Clearly superior especially in the addition functions available.
but in an apple to apple test - 720 24p on both - theoretically the hdv should look nearly the same - or will the interframe compression lose all the gains in the luma?
EDIT - thanks barry - beat me to it
Barry_Green
12-28-2005, 02:34 PM
If you want to make Shaq play on his knees, then yes, the HDV1 720/24p will be quite competitive with 720/24p DVCPRO-HD. The chroma res vs. luma res will probably come close to cancelling each other out. It will definitely be the most competitive that HDV will look against DVCPRO-HD, yes.
Of course, we're talking strictly about codecs here too. There's far more going on that will affect your image than just the codec! The lens, the chips, the latitude, the sensitivity, the noise, the DSP processing, the gamma curves, all those things will play a big role in how the overall image looks.
stephenlnoe
12-28-2005, 04:35 PM
So then, considering this - it seems that DVCproHD's biggest winning attribute is the intraframe compression - while HDV is highly interframe compressed. Cause the YCrCb numbers work out to be very close - about 10 percent different if you multiple all the numbers
Not exactly, If the codec carries a clean signal then once it's in the NLE it can be uncompressed from the transport stream (whether HDV or DVCProHD) and worked with in it's uncompressed state. The hangup is not on HDV or DVCProHD as a transport but on what gets uncompressed.
I wrote this on some other threads somewhere around here but I'll write it again. With HDV you can work in 1 of 4 modes. Those being: Native MP@HL, RGB(AVI), Uncompressed (2VUY), or intermediate codec (Cineform and the like). If working in uncompressed you get the full rez 1280x720, 4:2:0, Y sample: 1280x720, Cr,Cb Sample 640x360 @ 3.51MB per TGA frame (uncompresssed). Once the data is uncompressed then the transport stream (whether HDV or DVCProHD) have nothing to do with working the frames and frame sequences.
Then it comes down to how well the original codec handled the motion estimation and the DCT compression. With HDV1 you know exactly what you're getting 1280x720 without interpolated pixels. I offer These uncompressed frames (Click here) (http://www.planetliquid.us/video/Users/stephenlnoe/horse.zip) for you to bring into photoshop and check out. With any DCT compression you can push the image to seeing the 8x8 blocks (DVCProHD or HDV). Try working with the TGA's to see how much HDV uncompressed can take.
I tell you, splitting hairs over 8 bit formats get's old and I should have left it alone. Let me write this, both HDV and DVCProHD are much better than what we had and certainly both are worthy of film transfer if the story is good enough.
take care amigos...
Barry_Green
12-28-2005, 04:54 PM
Let me write this, both HDV and DVCProHD are much better than what we had and certainly both are worthy of film transfer if the story is good enough.
Completely agreed (as far as HDV1/720/24p goes!)
richkuhr
12-28-2005, 05:32 PM
Hello:
Does anyone have answers to the following HVX questions:
1. Can this camera record 4:2:2 color onto DV tape at 480P?
2. Can this camera record the 720P to "DV tape" with variable frame rates (slow motion, ect.)?
3. What is the most cost effective portable hard drive to record 720P variable frame footage with? Any recommendations?
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?
5. HVX-200 vs. DVX-100b for 480 24P footage, any difference?
Does the HVX capture better 480P image quality then DVX-100b?
Thanks Friends
Barry_Green
12-28-2005, 05:57 PM
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
12-28-2005, 06:42 PM
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
12-28-2005, 07:57 PM
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 (http://www.amazon.com/gp/product/1558607927/qid=1135824992/sr=8-1/ref=pd_bbs_1/102-5027997-3540924?n=507846&s=books&v=glance) which will help anyone understand the codecs and how their quality is derrived.
good luck...
smelni
12-28-2005, 08:33 PM
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
12-28-2005, 08:36 PM
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
12-28-2005, 08:52 PM
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
12-28-2005, 08:56 PM
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
12-28-2005, 09:06 PM
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 (http://www.planetliquid.us/video/Users/stephenlnoe/birds.zip)
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
12-28-2005, 09:06 PM
thanks barry - i think we were agreeing about everything.
But as usual your complete description helps a lot
smelni
12-28-2005, 09:10 PM
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
12-28-2005, 09:30 PM
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
12-28-2005, 09:43 PM
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 (http://www.dvxuser.com/V3/showpost.php?p=377067&postcount=1)
best of luck to you...
Emanuel
12-28-2005, 09:58 PM
Thanks stephenlnoe, as always.
smelni
12-29-2005, 08:46 AM
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
12-29-2005, 09:05 AM
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
12-29-2005, 12:51 PM
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
12-29-2005, 01:12 PM
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
12-29-2005, 01:33 PM
10 bits will it be the way?
Graeme_Nattress
12-29-2005, 01:51 PM
I don't understand the question, Emanuel.
Graeme
Emanuel
12-29-2005, 02:01 PM
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?
Derrick_SA
12-29-2005, 02:53 PM
Hi there,
So this means with 4:2:2, that this camera should be great for Greenscreen work right?
Thanks,
Derrick
Barry_Green
12-29-2005, 03:32 PM
There are many factors that go into getting great greenscreen work, of course. With all other things being equal, yes 4:2:2 should deliver twice as much color resolution (and therefore much more accurate keying) than 4:1:1 or 4:2:0.
Another aspect of successful greenscreening is compression noise. All other things being equal, the less-compressed (and therefore less noisy) image will deliver superior keying results. In DVCPRO-HD mode, the footage is actually more compressed than in DV, but still way less compressed than HDV. But in DVCPRO50 mode, the compression is exceptionally mild.
So yes, DVCPRO50 mode should deliver keying that's comparable to Digital Betacam. In DVCPRO-HD mode, the compression noise will be more noticeable, but it'll still have substantially more color resolution, plus there will never be any motion artifacting.
So, to say in one word what it just took me several paragraphs to blather on about, "YES" -- the HVX should be the finest green-screen camera anywhere near its price range.
stephenlnoe
12-29-2005, 06:13 PM
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
I'd like to see the sequence if you come across it and have the notion to put up a link.
Anyway, you may remember reading my thoughts on the matter (HDV edit's, FX and color correction) over on Cow a couple of months back. All editing/FX/ColorCorrection is done uncompressed and the limitation I've run into has not been the transport stream but instead has been gradient banding caused by an 8 bit color pallette. Even when working with 16bit subpixel routines it's not the same as a 10 bit source to start with (as you state) and anyone would have to be careful with gradients and HDV or DVCProHD, particularly using a secondary color corrector. Selectively isolating any primary or secondary colors to boost saturation will cause DCT to show itself. Brightening the overall image gain, gamma and black level luminance has not been a problem at all nor has gain, gamma and black level RGB adjustments caused many problems.
Barry_Green
12-31-2005, 10:12 PM
Stephen, you've asked for examples of when the JVC codec chokes... I was cleaning up my hard disk and came across the Charles Papert/Nate Weaver mini35 footage we shot in L.A. and found a wild doozy of an HD100 motion artifact. The full .m2t that it's in is 115 megabytes or so, so I just extracted the little bit that shows massive double-image shadowing into a .WMV at maximum bitrate to preserve the effect as best as possible. Looks like Nate was swinging the camera around for some reason, and the buildings show some major artifacting and macroblocking and banding. as well as a bit of split-screen at the end.
This clip had the mini35 attached, and I would suspect that the grain of the mini35 probably pushed the codec over the edge; I doubt that this would have happened with the stock lens attached, at least not to this degree.
http://www.icexpo.com/HD100/HD100-weirdness.wmv
If you want the full 115mb .m2t I can send it to you, but I wouldn't want to post it publicly as 115mb files would choke my bandwidth allocation in no time... ;)
Barry_Green
12-31-2005, 10:31 PM
Okay, rooting around some more in the files, it looks like they all have this same weirdness going on. Here's a still extraction of the girl as she walks by:
http://www.icexpo.com/HD100/HD100-Night.JPG
Check out the massive double-image shadow behind her arm (and speaking of which, where *is* her arm?) and the shadowy purse, the banding and macroblocking and posterization... No matter how you slice it, I think everyone would agree that a frame-based codec like DVCPRO-HD would have done extremely better with that shot.
Nate had said that the mini35 caused a lot of artifacting in his music video, and MacGregor just posted saying that FX1+mini35 is way too artifacty, so I think we can safely say that mini35 + HDV = too much for the codec to handle.
The full .m2t on this one isn't too big, it's about 32mb.
http://www.icexpo.com/HD100/HD100-Night-Take-01_6.m2t
Barry_Green
12-31-2005, 10:55 PM
All right, one last one, but in motion I think this is the worst one:
http://www.icexpo.com/HD100/HD100-Night2.jpg
The double-image shadow that follows her hair and her right hand are just extraordinary. Watch it in motion, it's hard to believe:
http://www.icexpo.com/HD100/HD100-Night2.wmv
Full of split-screen too.
Without the mini35, the HD100 has always seemed to be to be quite robust. But now, having seen the footage played back, I'd say that it is absolutely useless with the mini35 (or any of the cheap variants as well). No way could someone trust this. Frame-based codec is the only way to go.
Of course, we didn't see any of this when shooting the footage; shooting it live it all looked gorgeous. This is a prime example of why the HDV aspect of "what you see ain't what you get" drives me batty -- you can't see this stuff happening in the viewfinder or on the monitor; it's only after you record it and play it back that you get to see what HDV has done to your footage.
It's weird -- this shadow seems to primarily affect the red channel; you can see a lot of red shadowing all over the place on anything that moves, her hair gives off a red glow as it bounces and her hands have a weird red tracking shadow.
stephenlnoe
01-01-2006, 12:28 AM
It's weird -- this shadow seems to primarily affect the red channel; you can see a lot of red shadowing all over the place on anything that moves, her hair gives off a red glow as it bounces and her hands have a weird red tracking shadow.
There is a setting in the camera that forces the red channel called WhitePaint <R> which will enhance the warm effect after white balance. Maybe your group changed that setting? or the setting was changed initially?
As I recall, your shoot was just before or just after the camera's release. Since then the split screen has been addressed pretty well and I'm almost sure the SSE was under the radar when your group was shooting. Now, SSE can be adjusted by a qualified tech if needed.
The camera move, hmnnn.... I'll try and simulate that (again) with one of ours. I've tried a lot of camera moves and the encoder holds true on everything I've tried. Your shot of the halo is only the second time I've seen that effect in a frame. Was that halo in successive frames or on that single frame? I don't know but it's rare and I have not come across it in my own footage.
I'm just not seeing these types of things in my footage. As I wrote above, the biggest problem I have is banding caused by gradients that are beyond the 8 bit pallette. DVCProHD will not be immune to that either. I'll be putting more m2t's up on that other thread.
take care amigo...
Barry_Green
01-01-2006, 12:54 AM
We definitely didn't go painting the image much at all. Mainly we adjusted the gamma and boosed the color gain, but we didn't go in the whitepaint settings at all.
As far as SSE, this was prior to the formal launch of the HD100 in the US, although it had been out in other countries for a while before we got to use it for this shoot.
As for what's going on in the footage, I think it's just total codec breakdown, and I think it was the mini35 that did this to the footage. The spinning sea of grain particles seems to have pushed the codec over the edge. I don't think you'll likely encounter these same effects without the mini35.
I posted frame-for-frame .WMV extracts of the pertinent sections of the M2T's, and I posted one of the M2T's. The halos are tracking everything and last for a long time.
Again, I don't think the regular HD100 would exhibit as much of this, although I did see a bit of the shadowing effect in Nate's downtown m2t's. But I do think that this makes the HD100 (and probably all HDV cameras) useless for mini35 / micro35 work.