Page 1 of 7 12345 ... LastLast
Results 1 to 10 of 63
  1. Collapse Details
    XDCAM-EX vs. AVCCAM
     

  2. Collapse Details
    #2
    Default
    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.


     

  3. Collapse Details
    #3
    Deals in Lead PerroneFord's Avatar
    Join Date
    Nov 2006
    Location
    North Florida
    Posts
    4,596
    Default
    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).
    Don't be a BillyBob...


     

  4. Collapse Details
    #4
    Senior Member
    Join Date
    Feb 2008
    Location
    Philippines
    Posts
    2,788
    Default
    barry, i read in the hmr10 specs that it only captures 1080-60i/72060p on hd-sdi? so 24p would need to have pulldown removed?

    how about other codecs as well :P dvcprohd?
    Last edited by dcloud; 11-13-2009 at 07:47 AM.


     

  5. Collapse Details
    #5
    Senior Member Jaime Valles's Avatar
    Join Date
    Jul 2004
    Location
    New York City
    Posts
    2,004
    Default
    Excellent article, Barry! Thanks for the codec stress-test. Very, very informative.
    Jaime VallÚs
    AJV Media
    Video, Photography & Graphic Design: www.ajvmedia.com


     

  6. Collapse Details
    #6
    Senior Member
    Join Date
    Sep 2009
    Posts
    1,105
    Default
    Thanks for tests and sharing another article

    One of the major differences between how AVC works, versus MPEG-2, is in the block sizes that they use. MPEG-2 uses 8x8-pixel blocks, breaking the entire picture up into 8x8-pixel areas. When things are going smooth, you'll never know they're there, but when things get really hairy in the compression, you'll see that blocky texture appear; you may have noticed this effect on HDTV programming or youtube/vimeo when net congestion hits; the image can start turning blocky. Where MPEG-2 uses a fixed 8x8 block size, AVC can vary its block size, using as small as 2x2 pixel blocks. Because of this, AVC can have a lot smoother degradation of the image; it won't turn to discrete digital blocks, and the result is usually a more organic/natural looking image, rather than a blocky digital-looking image. This is a key factor in what I was looking for: if I could get the EX1 to go blocky, what would happen to the AVCCAM?
    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 by PDR; 11-13-2009 at 12:47 PM. Reason: edited comments related to cranky's deleted post


     

  7. Collapse Details
    #7
    Bronze Member
    Join Date
    Mar 2009
    Location
    Chicago, always and forever
    Posts
    1,271
    Default
    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!


     

  8. Collapse Details
    #8
    Default
    Quote Originally Posted by Chamber005 View Post
    How is a codec "stressed" exactly? Are you doing whip-pans or something? Extreme close-ups?
    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).

    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?
    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 by Barry_Green; 11-13-2009 at 01:00 PM.


     

  9. Collapse Details
    #9
    Senior Member Jan_Crittenden's Avatar
    Join Date
    Feb 2004
    Location
    New_Jersey, USA
    Posts
    3,621
    Default
    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
    Jan Crittenden Livingston
    Panasonic System Communications Corporation
    Partner Sales Manager, NY and NJ


     

  10. Collapse Details
    #10
    Deals in Lead PerroneFord's Avatar
    Join Date
    Nov 2006
    Location
    North Florida
    Posts
    4,596
    Default
    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.
    Don't be a BillyBob...


     

Page 1 of 7 12345 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •