Barry_Green
Moderator
Last edited:
XDCAM-EX vs. AVCCAM
- Thread starter Barry_Green
- Start date
Alex.Mitchell
Well-known member
I always wondered which would come out on top in the AVC-HD (21 Mbps) vs. XDCAM EX grudge match. Now I know!
Maybe this is a pipe dream, but I wonder if you could do a similar stress test with the HPX-170. I bet that DVCPro HD would clean up, but I'm still a little curious about how a 1280x1080 4:2:2 codec compares with a 1920x1080 4:2:0 codec in a variety of situations.
Maybe this is a pipe dream, but I wonder if you could do a similar stress test with the HPX-170. I bet that DVCPro HD would clean up, but I'm still a little curious about how a 1280x1080 4:2:2 codec compares with a 1920x1080 4:2:0 codec in a variety of situations.
PerroneFord
Deals in Lead
What's MSRP?
Is it more or less than the Firestore FS-5? More or less than the Nanoflash. To me, the Nanoflash is such a bargain since for it's price you do do everything from 50Mbps to 280Mbps (which is DARN close to uncompressed quality).
Is it more or less than the Firestore FS-5? More or less than the Nanoflash. To me, the Nanoflash is such a bargain since for it's price you do do everything from 50Mbps to 280Mbps (which is DARN close to uncompressed quality).
Jaime Valles
Veteran
Excellent article, Barry! Thanks for the codec stress-test. Very, very informative.
Thanks for tests and sharing another article
The difference in macroblocking is more due to inloop deblocking than block size partition. It is difficult to "simulate" on a hardware recorder, but with software you can disable the inloop deblock with encodings (or use negative alpha & beta deblock values to lower the "strength") and you will see a macrblocked image much like those with MPEG2.
A "side-effect" of inloop deblocking is oversmoothed images. Great examples of this are seen with the GH1 and "mud". Poor AVC implementation have low efficiency, relative overcompression (proportional to scene complexity) which results in oversmoothing and "mud." Better AVC implementations have more features that help with compression efficiency. For example b-frames and CABAC are found in AVCCAM, but not in the GH1's h.264 implementation. Even on low complexity (non challenging, low motion) content, if you were able to disable deblocking, the image would be sharper with more detail.
EDITED
The difference in macroblocking is more due to inloop deblocking than block size partition. It is difficult to "simulate" on a hardware recorder, but with software you can disable the inloop deblock with encodings (or use negative alpha & beta deblock values to lower the "strength") and you will see a macrblocked image much like those with MPEG2.
A "side-effect" of inloop deblocking is oversmoothed images. Great examples of this are seen with the GH1 and "mud". Poor AVC implementation have low efficiency, relative overcompression (proportional to scene complexity) which results in oversmoothing and "mud." Better AVC implementations have more features that help with compression efficiency. For example b-frames and CABAC are found in AVCCAM, but not in the GH1's h.264 implementation. Even on low complexity (non challenging, low motion) content, if you were able to disable deblocking, the image would be sharper with more detail.
EDITED
Last edited:
Chamber005
Bronze Member
How is a codec "stressed" exactly? Are you doing whip-pans or something? Extreme close-ups?
Also, this may be unrelated, but how does this pertain to rendering videos (or does it not pertain to it at all?). There's at least 50 different formats it seems to render a video. Should what codec you start with (AVCHD, XD-CAM, H.264, etc) dictate into what you should render it into?
There's a lot of technical stuff I'm just beginning to learn now that I'm using CS4 to edit and CC my stuff (before I used 100 buck editing/rendering programs like Corel and Vegas Movie Studio). The word compression comes up a lot when people talk about rendering.
Again, not sure if these questions pertain to this article but it seemed like a good a place as any to start!
Also, this may be unrelated, but how does this pertain to rendering videos (or does it not pertain to it at all?). There's at least 50 different formats it seems to render a video. Should what codec you start with (AVCHD, XD-CAM, H.264, etc) dictate into what you should render it into?
There's a lot of technical stuff I'm just beginning to learn now that I'm using CS4 to edit and CC my stuff (before I used 100 buck editing/rendering programs like Corel and Vegas Movie Studio). The word compression comes up a lot when people talk about rendering.
Again, not sure if these questions pertain to this article but it seemed like a good a place as any to start!
Barry_Green
Moderator
I gave examples in there. Basically, a long-GoP codec gets stressed when the amount of changes between frames exceeds the amount of change it can comfortably handle. This can happen in many ways. A simple pan is not enough to do it; motion codecs such as MPEG and AVC are designed to handle pans, they have motion prediction built into them. But there are things a codec cannot predict and cannot comfortably handle. Such things include a whip-pan, a snap-zoom, or flashes going off. When a flash happens, every single pixel in the frame changes simultaneously, and that's a massive stress on a codec that is designed to only account for the changes between frames.
Long-GoP codecs are designed around the concept that with frames coming so quickly (think about it, 24 to 60 times per second), not all that much will change from frame to frame. So the long-GoP codec bases each new frame off the prior one. It uses up a large percentage of its bit budget to encode one key frame (the first frame in the Group of Pictures), and then it allocates the remaining amount of bandwidth for all the changed frames. So, while I don't remember the numbers exactly, something like 40% of the available bandwidth goes to the keyframe in each group, and the remaining 14 frames in the group have to share the remaining 60% of the bandwidth. So each frame gets about 4% of the bandwidth, except for the keyframe. 4% isn't much, but it's usually enough to handle the small changes that will occur (especially when motion prediction helps everything along by predicting and minimizing the actual amount of change).
So -- you've got a normal circumstance where 40% is used up on the first frame, and 4% to the next frame, and 4% to the next, etc. That's normally enough, because very little changes between frames. But what happens when a flash goes off? Now EVERY PIXEL has just changed! Can the codec handle it? Maybe not, probably not within that 4%! So now the flash frame has to encode all the changes, and (depending on the efficiency of the codec) it's possible that it'll have to encode all the changes back from the flash, too. So those two frames (the one with the flash, and the first one after the flash) may need a LOT of bandwidth. Maybe they need 40% of the total bandwidth by themselves (speculation for illustrative purposes). So now we've got 80% of the bandwidth being used up on the key frame, the flash frame, and the after-flash frame. That leaves the other 12 frames (in a 15-frame group) to divide up the remaining 20%, giving about 1.6% of the bandwidth per frame.
So what happens to all those frames? They have such low bandwidth, they can't be compressed very well. So they go blocky. Try saving a photoshop document as a JPEG at maximum quality, and at minimal quality, and see what the difference is -- that's what happens to long-GoP codecs. And because they compress an entire 15-frame block as a group, together, all the frames within that group are affected. So it's not a case of one frame going "glitchy", but an entire group of 15 frames will go "glitchy" simultaneously. Your video might look fine, and then when the flash goes off everything goes blocky for a half a second (assuming 30 frames per second), and then it all goes sharp again. (and, for the record, most codecs can handle a single flash without getting too bad, I'm just using the flash as an example). Keep in mind that I said that I had to push these codecs HARD to get them to break up. HDV was much easier to break, XDCAM-EX is quite robust, and AVCCAM is very robust.
What kind of scenarios can bring this about? Anything which causes a lot of change per frame, in an unpredictable way. A snap zoom (where you go from minimum to maximum in about 1/10 of a second) would cause a huge amount of change on each and every frame. Rotating and spinning the camera will cause a huge amount of change in an unpredictable way -- MPEG can predict pans and tilts, but it doesn't know how to deal with rotation. Smoke and fog can cause a lot of complications for the codec, because it's translucent and it moves in unpredictable ways. Confetti is a good one, because it's gobs and gobs of tiny detail that changes in every frame and moves in unpredictable patterns. Splashing water, for the same reason -- lots of fine detail, especially backlit water, moving in lots of directions. Strobe lights, or colored strobes -- with a colored strobe, not only does the brightness of every pixel change, but the color does too -- that's really tough on a codec to handle. Fire -- long-GoP codecs can really be troubled by fire, because it flickers, changes intensity, it can be translucent, and it moves unpredictably. Changing brightness through rapidly opening or closing the iris would probably cause no end of complications for a codec -- if you executed a quick fade-to-black by spinning the iris ring, you'd probably find that fade-out going blocky.
Intraframe codecs will never have any of those complications. Every frame is encoded discretely, uniquely, and what happens in one frame will not have any influence on what happens in any other frame.
So is long-GoP evil? No, not in and of itself. Long-GoP is a technique, nothing more. If used to increase quality, it's a valid and good technique. If used to try to make a tiny bitrate perform above and beyond its means, I think it can backfire and cause shooters problems. So the net determinant for me, as to whether it's a good thing or not, is how robust the images are. If you're using a way-too-low bitrate, and trying to use long-GoP to increase the efficiency to bring that low bitrate up to an acceptable quality level, then I think that's asking for trouble (and why I was absolutely not a fan of HDV). But, what if you had a 100mbps intraframe codec, which is enough to deliver DVCPRO-HD quality, and you added long-GoP to that? Well, in a case like that, it would be an enhancement to an already adequate system, and therefore it would increase overall quality, and would be viewed as a good thing (excepting the additional demands on the CPU in editing).
Totally unrelated, and in general it would seem to not matter much, except that certain codecs withstand multiple generations of recompressing better than others do. But you raise an interesting point -- would MPEG-2, re-compressed as AVC, look better than MPEG-2 recompressed as MPEG-2? And the reason I think there might be a case for staying in MPEG-2 is because the nature of compression artifacts from the first generation might be easier-recompressed by the same style of codec... but probably not. I don't know. Interesting question.
Last edited:
Jan_Crittenden
Veteran
Nice job Barry. Well done.
To add to the discussion, one of the key differences in the AVCCAM/AVCHD implementation is that the "I " frame of the Long GOP is addressed in the same way that AVC-Intra is. First there is the predictive pass where the Content Adaptive Codec looks at the complexity of the picture and does a "first pass" Then that is subtracted from the original and the rest of the engine is assigned to the details. The block sizes can vary within the frame and this is one of the very reasons that the Macroblocking is more noticeable on the the always 8X8 blocks in MPEG-2 vs MPEG-4 AVC/H.264. The Block sizes can vary from 16 X 16 and down to 4 X 4. The codec assigns the power where necessary. The Entropy Encoding is also significatly different in that the Variable Length Coding , available in MPEG-2 is strictly a 2D encoder, and does not have the tap dance ability of the Content Adaptive Variable Length Coding which when paired with the Content Adaptive Binary Arithmetic Coding produces the best P and B "frames."
Keep in mind that a good number of the folks that have brought you MPEG-4, were part of the MPEG-2 development and as a result, knew what needed to change to bring about a better result.
That is not to say that all implementations of AVCHD are equal, as we can see in the product that is out there currently; I would imagine over the course of time we will see it gravitate to something more uniform. That said, the AVCCAM implementation is the same across the board.
Best,
Jan
To add to the discussion, one of the key differences in the AVCCAM/AVCHD implementation is that the "I " frame of the Long GOP is addressed in the same way that AVC-Intra is. First there is the predictive pass where the Content Adaptive Codec looks at the complexity of the picture and does a "first pass" Then that is subtracted from the original and the rest of the engine is assigned to the details. The block sizes can vary within the frame and this is one of the very reasons that the Macroblocking is more noticeable on the the always 8X8 blocks in MPEG-2 vs MPEG-4 AVC/H.264. The Block sizes can vary from 16 X 16 and down to 4 X 4. The codec assigns the power where necessary. The Entropy Encoding is also significatly different in that the Variable Length Coding , available in MPEG-2 is strictly a 2D encoder, and does not have the tap dance ability of the Content Adaptive Variable Length Coding which when paired with the Content Adaptive Binary Arithmetic Coding produces the best P and B "frames."
Keep in mind that a good number of the folks that have brought you MPEG-4, were part of the MPEG-2 development and as a result, knew what needed to change to bring about a better result.
That is not to say that all implementations of AVCHD are equal, as we can see in the product that is out there currently; I would imagine over the course of time we will see it gravitate to something more uniform. That said, the AVCCAM implementation is the same across the board.
Best,
Jan
PerroneFord
Deals in Lead
So again, is this unit available? And what is the MSRP? I am shooting XDCamEX today, and spoke with my boss about purchasing the Nano in June. If this is a contender, I'd like to know.
Whilst agreeing with Barrys post as far as it goes, it has to be said that a codec can get stressed either in the way Barry says (lots of changes between frames) or due to a lot of fine detail in a static frame. Hence I'd be interested to see the same tests on static subjects with a lot of fine detail, but no movement. (Something like pages of fine newsprint.)
The ratio of bitrate assigned to I-frames to bitrate assigned to difference frames is not fixed in any long-GOP codec. Hence, you could assign 100% of the bitrate to the I-frames, 0% to the difference frames (effectively getting an I-frame only codec), or 5% to the I-frames, 95% to the difference frames. The latter would give excellent motion performance - but very poor still picture performance. Most long-GOP codecs are obviously likely to be somewhere between these figures.
It's also worth mentioning that specifying a codec does not uniquely specify it's performance at any given bitrate - the performance is a feature of the individual coder as well as the bitrate. That's been very obvious with broadcast digital TV in the UK over the last ten years - bitrates have dropped dramatically in that period, but overall quality is arguably better (though still far from perfect
) than at the start. That's the effect of coder improvements.In practical terms, my experience of AVC-HD has been limited to the coder of the HMC151, and in that case I've noticed obvious first generation STATIC artifacting around edges in 1080 mode, whilst the motion performance seems to have been pretty good. What I don't know is whether that is a function of that particular camera, or current high bitrate AVC-HD encoders in general. (In the case of the 151, it doesn't really matter, since there's a lot to be said for using it in 720p mode anyway.)
As far as the HMR10 v nanoFlash goes, for high quality work the nanoFlash is likely to be used in better than 35Mbs mode - 50Mbs at least, ideally 100Mbs long-GOP, which yields true 4:2:2 as well. So here the nanoFlash is likely to remain the better choice. But the lower bitrate modes of the HMR10 shouldn't be overlooked, and may be exactly what's needed for long, unattended runtimes - security or wildlife applications, for two examples.
What a shame you can't get the high bitrate/high quality modes of the nanoFlash in the same package as the low bitrate/long runtimes of the HMR10.
PerroneFord
Deals in Lead
My work alternates between several types of video.
1. Interviews and PSAs. These are mostly static, with the occasional slow walk and talk. Some will now be greenscreen
2. Conference recording. Camera on a tripod for 3 8 hour days.
3. Building tours, where we follow a group on tour of our historic building
4. Training videos. Mostly podium based with powerpoint shows.
I don't NEED a Nano for my work, but often the fine detail of some of the books, sculpture and other things when we are on historical tours is lost in XDCamEX. I'd love to improve that. For $3k the Nano seems a reasonable solution. We had purchased a Firestore years ago for our DVX to handle the long-form conference recordings, but honestly, with two 32GB SDHC cards, I can now get 4 hours of recording at a time without it. More than enough.
If this unit is available for $1500 then it may be a viable choice for our needs. If it's over $2k then it becomes hard to justify for me over the $3k nanoflash which gives me everything from 35 Mbps Long GOP to 200+Mbps I-Frame.
1. Interviews and PSAs. These are mostly static, with the occasional slow walk and talk. Some will now be greenscreen
2. Conference recording. Camera on a tripod for 3 8 hour days.
3. Building tours, where we follow a group on tour of our historic building
4. Training videos. Mostly podium based with powerpoint shows.
I don't NEED a Nano for my work, but often the fine detail of some of the books, sculpture and other things when we are on historical tours is lost in XDCamEX. I'd love to improve that. For $3k the Nano seems a reasonable solution. We had purchased a Firestore years ago for our DVX to handle the long-form conference recordings, but honestly, with two 32GB SDHC cards, I can now get 4 hours of recording at a time without it. More than enough.
If this unit is available for $1500 then it may be a viable choice for our needs. If it's over $2k then it becomes hard to justify for me over the $3k nanoflash which gives me everything from 35 Mbps Long GOP to 200+Mbps I-Frame.
Barry_Green
Moderator
Yes. In stock at B&H.
MSRP $2600. B&H sells it for $2280.
The Nano does things this doesn't, such as being able to record pN mode. This unit records "over 60". If you're recording 60i/60p, or 30p, I'd consider it a possible alternative, primarily for same/better quality at smaller file sizes, but if you're looking for maximum quality regardless of file sizes, I'd expect the nano can provide that. Nano can do pN modes (right?) and it has the capability to go 4:2:2.
Barry_Green
Moderator
That is correct.
Yes, I believe for ultimate quality regardless of storage space, the Nano can do better. This unit isn't necessarily offered or marketed as a recorder for ultimate quality, it's a very space-efficient high-quality recorder. It can deliver the same or better than XDCAM-EX at substantially smaller file sizes, onto commodity media, at a price point lower than the Nano. But the Nano has high-end quality (100, 160, even 220mbps IIRC) at 4:2:2, which this unit can't do.
Barry_Green
Moderator
Harddrive brings up a point I forgot, which is that the variable bitrate of the AVCCAM codecs lets you go down to as low as 6mbps. While I am a fan of pedal-to-the-metal with long-GoP codecs (pushing them to the highest bitrate they can stand to prevent codec stress) there would certainly be times when folks may want or need mega-long recording times, and the lower bitrates can get you there. Especially if you're talking about a static camera like a security camera; in cases like that, the HMR10 could record for 12 hours on a single 32GB card.
PerroneFord
Deals in Lead
Thanks Barry, While this may be a viable solution for others, it seems it won't get it done for my needs. If it was quite a bit cheaper maybe. But the price point brings it too close to the Nanoflash in my case.
[Edit]
Just had a look on B&H,
This thing has some features I wish the Nano-Flash did. Like a WFM and Vectorscope! That's fabulous! The fact that it shows the image on a screen is comforting also, though I would bet it eats some power. Seems like a nice unit for the right person.
[Edit]
Just had a look on B&H,
This thing has some features I wish the Nano-Flash did. Like a WFM and Vectorscope! That's fabulous! The fact that it shows the image on a screen is comforting also, though I would bet it eats some power. Seems like a nice unit for the right person.
Last edited:
Very very interesting. Thanks a lot for this test, Barry! Finally real-world test comparing these codecs. Turns out that the differences are quite significant. Sony has been trying to convince people that is only visible at very low bitrate, which is clearly untrue:
http://pro.sony.com/bbsccms/assets/...ns/MPEG-2_Long_GoP_vs_AVC_Comp-Strategies.pdf
http://pro.sony.com/bbsccms/assets/...ns/MPEG-2_Long_GoP_vs_AVC_Comp-Strategies.pdf
Thanks for doing the comparison, Barry. I am surprised that the AVCHD did so well at a low bit rate.
But I think most people who use an external recorder do so to get better quality video, not lower bit rate. So it would have been nice if this unit recorded to AVC Intra. I know Panasonic has the HPG20, but that's twice the price and records to expensive P2 cards.
But I think most people who use an external recorder do so to get better quality video, not lower bit rate. So it would have been nice if this unit recorded to AVC Intra. I know Panasonic has the HPG20, but that's twice the price and records to expensive P2 cards.
Elton
Veteran
Good article, very informative. I appreciate the work that went into this article.
As an avid nanoFlash user I have to say that the pricepoint of the AVCCAM device is a bit mystifying, IMO. It just seems hugely overpriced for what it delivers...and we do talk about pricepoint being so key around here.
If you reaaallly need uber-long recording times with that subtle level of image improvement at extremely low bit rates, I'm sure this unit would fit the bill.
I guess I just don't get it. Here it is, nearly 2010, with very low priced/high capacity/high speed Solid State media available to us, and we're talking about $2300 external recorders that still overcompress the image and still only do 4:2:0. And what is this about no 1080i recording unless purchasing an add-on option? Wow.
Unless super-long recording time capability is paramount, I have to admit my bias and say the nanoFlash is a much bigger bang-for-the-buck.
--Drag and drop editing with native QT/MXF (no need to log and transfer)
--Huge bitrate selectability
--4:2:2 colorspace
--High bit rate I-frame modes
--TC input
--3:2 Pulldown removal over 1080i for true 24p recording via SDI, (HDMI coming too)
--Timelapse recording
--HDMI I/O (recording HDMI, not just for viewing)
--Overcrank capability coming
If the AG-HMR10 were, say, sub-$1K I could see the obvious value, but definitely not at it's current pricepoint. It has some nice professional features, but the codec is still iffy.
As an avid nanoFlash user I have to say that the pricepoint of the AVCCAM device is a bit mystifying, IMO. It just seems hugely overpriced for what it delivers...and we do talk about pricepoint being so key around here.
If you reaaallly need uber-long recording times with that subtle level of image improvement at extremely low bit rates, I'm sure this unit would fit the bill.
I guess I just don't get it. Here it is, nearly 2010, with very low priced/high capacity/high speed Solid State media available to us, and we're talking about $2300 external recorders that still overcompress the image and still only do 4:2:0. And what is this about no 1080i recording unless purchasing an add-on option? Wow.
Unless super-long recording time capability is paramount, I have to admit my bias and say the nanoFlash is a much bigger bang-for-the-buck.
--Drag and drop editing with native QT/MXF (no need to log and transfer)
--Huge bitrate selectability
--4:2:2 colorspace
--High bit rate I-frame modes
--TC input
--3:2 Pulldown removal over 1080i for true 24p recording via SDI, (HDMI coming too)
--Timelapse recording
--HDMI I/O (recording HDMI, not just for viewing)
--Overcrank capability coming
If the AG-HMR10 were, say, sub-$1K I could see the obvious value, but definitely not at it's current pricepoint. It has some nice professional features, but the codec is still iffy.