Press Release: HMC150, "the new DVX"

These are two grabs (in sequence), that show some blockiness, when the camera was moving pretty quickly and autofocus was also trying to make a radical adjustment (and was way out of focus at the moment):

http://www.elink123.net/SD9avcHD/SD9-Blockiness-1of2.png

http://www.elink123.net/SD9avcHD/SD9-Blockiness-2of2.png

I didn't notice blockiness in any portions of the clips that were shot anything somewhat similar to a manner that might be akin to a manner that would produce usable footage. Any noticeable blockiness I saw (which wasn't really that much, nor very severe even then), occurred in portions of the clips that were shot in a manner that would almost assuredly result in unusable footage anyway.

It's also worth noting that I basically shot at default settings, aside from switching the camera from the default of 60i to 24p. I later realized that I had forgotten to set the bitrate on the camera, to the maximum setting (which I meant to do, in addition to shooting 24p). I was just in to much of a rush at the time, I guess. The bitrate for the clips turned out to average something in the neighborhood of 10-12mbps.

Thanks to drdimento for hosting the frame grab images. http://www.elink123.net/SD9avcHD/
 
It's also important to note that you're using a $689 consumer camcorder in this testing, and you're using a bitrate that's about half of what the HMC150 is likely to support. I doubt there's any relevance at all that's going to be discovered here. The 150 will use higher bitrates, and may use better encoding. I don't think any valid conclusions can be drawn from this at all; let's let the 150 show what a 150 can do.
 
How well the codec in the HMC150 will hold up to a lot of motion seems to be a concern to many people here. From what I saw with those little SD9 clips I shot at Circuit City, it seems (to me) safe to conclude that the HMC150 isn't likely to produce much along the lines of blocky artifacts. It's difficult to image the codec will perform worse in the HMC150.
 
What I'm saying is that I think it would be jaw-droppingly startling if the HMC150 didn't substantially outperform the SD9. If it doesn't, there's something seriously wrong here.

If you're saying "hey, folks, if you think this SD9 footage looks great, just imagine how much better the 150 will look" then that's reasonable. But if you're saying "this SD9 footage isn't that great, so now I'm concerned about the 150" then that seems completely unfounded and not reasonable. See what I'm saying?
 
Robert M Wright's photo does look bad, but we are looking at a lot of worst case things here; 1/6" CCDs, a very fast pan, not exactly the best lighting, a Mbps lower than what we expect the maximum of the HMC150 to be, AND we're not even sure if they are going to use the same CODEC processor chip.

Another problem is that compared to how we would watch any video from the HMC150, we would be seeing a MOVING image and not a still frame. Also, most of us are sitting about 18" to 24" from our monitors, while few of us sit that close to an HDTV. Depending on the size of your monitor, the size of your HDTV, and where you sit, you would need to move back to around 3 to 4 feet to get the same viewing angle.

At the other end of our "Apples and Bananas" comparison, here's a frame grab from Philip Bloom's work. The source was 1280x720/25p and I cropped a 773 x 490 section from the image. The file I grabbed the image from is an MPEG-4 video.

Philip_Bloom_image.png


The source was the Sony EX-1 with the Letus 35mm lens adapter, shooting MPEG-2, 35Mbps VBR, edited (system unknown), and transfered to MPEG-4 (AAC H.264). Granted that Mr. Bloom's work is not stressful to H.264, my point is that it is possible to produce VERY good looking images using H.264 compression.

The real test is going to be around 6 to 9 months form now, once the first users can post videos they made and we can see how good (or bad) it is under the different conditions. Still, there may be a slim change that the prototype at NAB is working and we can grab a clip....

Maybe the CODEC for the HMC150 will produce some odd edging artifact with really fact pans, but then again, maybe not. This is all guess work until the camera comes out.


Pre-NAB Comments:

I will be going to NAB on Tuesday (Afternoon only), Wednesday, and Thursday. I can't recall if the Circus Circus, where I'm staying, has internet access from the room or not. I hope yes, because I'd like to post a daily update and it would be nice to read what others have to say. After all, someone is VERY likely to spot something I'm going o miss....

So, who else is going to NAB????


Bob Diaz
 
I'm not looking at it from a perspective of thinking the SD9, overall, is comparable to the HMC150 (let's sure hope not). I'm looking basically at the SD9 codec as being a fairly reasonable stand-in for the HMC150, to judge minimum performance of the AVC codec (they are likely to be fairly similar in that regard - possibly even identical, with a max bitrate of 17mbps). I don't have any expectation that SD9 footage, overall, will be comparable to the HMC150. There's going to be just way to much difference in the imaging heads.
 
I'm not worried at all about the AVC codec in the HMC150 performing poorly in low motion scenes. Even if it's only a 17mbps max bitrate, the images should be pretty pristine in low motion scenes, unless they really botch the implementation. AVC at those kinds of bitrates is very capable of that. I've used H.264 to compress low motion (1920x1080) at much lower bitrates, that still looks very clean.
 
But the consumer and the broadcast division are separate companies. There's very little cross-pollination between those two (the HSC1U is about the only product I can think of that appears in both lines). So to say that the codec chips would be "identical" seems way presumptive. That's all I'm saying.
 
. . . At the other end of our "Apples and Bananas" comparison, here's a frame grab from Philip Bloom's work. The source was 1280x720/25p and I cropped a 773 x 490 section from the image. The file I grabbed the image from is an MPEG-4 video . . . Bob Diaz

Wow, I have some DVX100B shots that look nearly or equal. Again, I don't know about others but I'm not really that impressed with the MPEG HD derivitives. My HVX material then looks one "way" better as long as I have that much light.
 
I suppose they could develop an entirely different codec implementation for the HMC150, but that would be awfully wasteful. When developing that type of software, it is far and away more efficient (time and quality wise) to develop code that is reusable (modular in design and well commented) and refine it, than simply start over from scratch.
 
Wow, I have some DVX100B shots that look nearly or equal. Again, I don't know about others but I'm not really that impressed with the MPEG HD derivitives. My HVX material then looks one "way" better as long as I have that much light.

There's no reason to expect a cropped image from an HD camera (of any variety - in the sub $10k range) to look a whale of a lot better than an image out of a DVX100B.
 
I suppose they could develop an entirely different codec implementation for the HMC150, but that would be awfully wasteful. When developing that type of software, it is far and away more efficient (time and quality wise) to develop code that is reusable (modular in design and well commented) and refine it, than simply start over from scratch.
Only if it's adequate to the purpose. If the broadcast division looked at the consumer codec and said "yuck", then I can easily see them starting over from scratch.

Look at the difference in MPEG-2 performance between the EX1 and the consumer-originated HDV camcorders, it's night and day different. Way, way better than can be accounted for through the bitrate increase.

I wouldn't be surprised in the least if the reason it's taken so long to get a professional AVC-HD camcorder out is because the broadcast division decided to implement a much better, professional version of the codec.
 
I suppose they could develop an entirely different codec implementation for the HMC150, but that would be awfully wasteful. When developing that type of software, it is far and away more efficient (time and quality wise) to develop code that is reusable (modular in design and well commented) and refine it, than simply start over from scratch.

While it is possible to have a set of DSP (Digital Signal Processing) chips to do the H.264 encoding, it would be far better to use an off the shelf encoding chip. A quick search shows there are a number of single chip solutions to chose from. Like video cameras, the selection covers a wide range from cheap to high quality, but higher cost.

It would be logical to select a "cheap" chip for the low cost consumer cameras and a higher quality (higher cost) chip for the professional cameras. The more processing power you can throw at H.264, the better the compression will be.

This is not unlike the lower cost computers using the slower, but lower cost CPU (Central Processing Unit) chips with slower memory AND the higher cost computers using the fastest CPUs with the fastest memory.


Bob Diaz
 
Developing modern object oriented software that is not modular in nature (and well commented), to implement something like the fundamental core algorithms involved in AVC or MPEG2 compression, is just utterly inefficient. From an R&D cost (and quality) perspective, it's pretty much insane (explodes man hour costs by orders of magnitude over the long haul).

Considering that HDV is a CBR implementation of MPEG2 and the implementation of MPEG2 in the EX1 is VBR (most likely with a significantly higher peak bitrate than the average bitrate), it's really not surprising (at all) to see a considerable difference in performance under stress (with what amounts to a relatively minor change, at the code level). If Sony completely tossed out the code they developed for implementing HDV, to develop the code for the MPEG2 implementation in the EX1, they pitched a lot of R&D money straight down the toilet. Compare the CBR mode in the EX1, to HDV, and I doubt you will see a lot of improvement (a little bit maybe).

One thing that struck me, when I first laid eyes on the SD9, is how incredibly tiny the camera is (amazingly small).

It occurred to me, that they might have done something like use CAVLC for entropy coding, rather than CABAC, to conserve CPU cycles, in order to produce a chip that wouldn't get as hot in that tiny housing (yet still be AVC compliant). If something like that is true in the SD9 (pure guess on my part), the extra space in the HMC150 would likely afford the "luxury" of rewriting that particular section of code for much better performance. That wouldn't require anything like an overhaul (just like rewriting a section of code to change from CBR to VBR MPEG2 encoding would not require an overhaul).
 
It would be logical to select a "cheap" chip for the low cost consumer cameras and a higher quality (higher cost) chip for the professional cameras. The more processing power you can throw at H.264, the better the compression will be.

The cost difference is primarily in R&D costs (essentially writing specific application level software), not manufacturing costs. These are simply "hard coded" processors. It isn't the same as developing a new class of general purpose processor either, like the difference between a P4 and a Core Two (for example).
 
Maybe I should mention that my background is far more in computer science than using cameras, even though I haven't written any software in years. I grew up being taught computer programming in the 60s. My dad had me writing assembly language software (on a LGP30) at the ripe age of 7. He also spent a few decades developing and writing specs for making software development processes efficient, so I got exposed to a healthy dose of that too (a lot more in-depth than I was interested in really!).
 
I have a fairly decent understanding of programming as well -- used to work in the videogame industry doing intensive graphics and compression work as well as higher-level game functions, was lead programmer on dozens of commerciall-released videogames on probably a dozen different platforms in probably six different languages including C++, C, 680x0, 6280, 65816, 80x86, 6502, and even some transportable languages we developed ourselves for cross-platform development when doing the Lion King for SNES and Genesis simultaneously. And I can tell you that the bigger a company gets, the more there's a "not invented here" syndrome, meaning: if we didn't invent it, it must be garbage. We had lots of problems with that when our company started buying others, and getting bought out by others. Like it or not, it's the way things work.

What I'm saying is: this is a big company. Whether you would find it inefficient or not, big companies frequently don't have the slightest idea what other divisions of the company are doing (for example, in Sony, they're still bundling Premiere with their VAIO computers -- even though Sony owns their own NLE!)

I stand by what I said -- it's entirely possible, if not probable, that the broadcast division not only could and would demand higher specifications than the consumer side, but that may very well account for the lengthy delay in getting a professional AVC-HD camcorder on the market. Whether that accounts for a somewhat inefficient development process or not, this is something that they're stamping their name on, that they're going to be living with for the next decade or so.

Of course, all we're doing is speculating here, as none of us knows what they've done. But I feel quite confident in saying that the performance of a $689 SD9 is going to have little to no bearing on the performance of a ~$4,000 HMC150.
 
What I'm saying is: this is a big company. Whether you would find it inefficient or not, big companies frequently don't have the slightest idea what other divisions of the company are doing (for example, in Sony, they're still bundling Premiere with their VAIO computers -- even though Sony owns their own NLE!)

No doubt, big companies do some pretty amazingly stupid things at times. I coordinated PC tech support for a division of one of the big companies downtown (in Minneapolis) a few years back. The division I worked for had an arrangement to have trouble calls go through another division's level one phone support, and then to us. Ridiculously, when I got there, we were taking the incident reports from the other division and then calling back to provide essentially the same level one troubleshooting over the phone (rarely resolving any issues that way), instead of simply dispatching a floor tech (which we almost always wound up doing anyway, but with a delay for the call back). Simply eliminating that redundancy vastly improved our response times and satisfaction feedback ratings from the users (also made the floor techs a lot happier, because they didn't wind up dealing with users that had been pissed off, by a needless delay, nearly as often).

Edit: Actually, when I look back at it, I still have to laugh a little. Our division wasn't just inducing needless delays. Our techs that did the call backs weren't quite as well trained as the other division's level one phone support techs (our floor techs were better trained though). The users didn't just get slow resolutions. They got some extra, pretty dismally irritating responses, thrown in for free too! It was basically a mess when I got there.
 
Last edited:
Let's hope Panasonic's software development for codecs is better managed than completely isolated between the two divisions. If not, the results are very predictable: buggier codecs that take a whale of a lot longer to bring to market (especially with a relatively newer codec).
 
Maybe this is too big an assumption, but when I worked at Epson America, the low end computer equipment had to take all sorts of "short cuts" to keep the price down. The "short cuts" would impact performance. However at the other end, the top of the line stuff, used the more costly solutions to improve performance.

My thinking is that the more expensive HMC150 would use better processing power than the SD9 to get a better quality image. ... or at least it seems reasonable to me. We know for a fact that the HMC150 does use better CCDs. (1/6" vs. 1/3")


It is interesting that Barry, Robert, and myself have a computer programming background. Maybe just a fluke or maybe there's something about programmers that causes us to become interested in video.


On A Side Note:

It's funny to see how many messages have been generated, but we know so little about what exactly the camera will be... Just think how many messages will be generated once we know exactly about the camera.



Bob Diaz
 
Back
Top