Press Release: HMC150, "the new DVX"

This is my very first post, but I've been reading everyday since NAB2008 to stay on top of the HPX170 and HVX200A news. Basically, I'm planning to switch my studio over to HD on Jan 1, 2009. I've been diligently researching the Panasonic cameras vs the EX1. And my biggest concern is light sensitivity. I read Adam Wilt's article on the EX1 and he states that it has the following ISO's:

- ISO 400 in 1080p modes
- ISO 800 in 1080i modes (just as you’d expect: with dual-row summation, you get twice the sensitivity), and
- ISO 500 in 720p modes.

I know Barry Green stated the new CCD block has an ISO of 500. But does the ISO also change based on the 1080p, 1080i, and 720p modes? And if so, what are the ISO's? Thank you.
 
I just don't see the point of talking about Scarlet now, because so much is up in the air and so much is unknown. Once the camera comes out and all the information is known, yes we can make a reasonable comparison.

According to the Red WEB pages:
SPECIFICATIONS, DELIVERY DATES AND DESIGN ARE SUBJECT TO CHANGE... COUNT ON IT.

However if drdimento feels the need to talk about it now, just go to:

www.ScarletUser.com

like Barry asked...

Bob Diaz
 
This is my very first post, but I've been reading everyday since NAB2008 to stay on top of the HPX170 and HVX200A news. Basically, I'm planning to switch my studio over to HD on Jan 1, 2009. I've been diligently researching the Panasonic cameras vs the EX1. And my biggest concern is light sensitivity. I read Adam Wilt's article on the EX1 and he states that it has the following ISO's:

- ISO 400 in 1080p modes
- ISO 800 in 1080i modes (just as you’d expect: with dual-row summation, you get twice the sensitivity), and
- ISO 500 in 720p modes.

I know Barry Green stated the new CCD block has an ISO of 500. But does the ISO also change based on the 1080p, 1080i, and 720p modes? And if so, what are the ISO's? Thank you.

It's my understanding that the ISO of the 150, 170, and 200a is fixed at 500 for all modes. However, Barry did the test and can correct me if I'm wrong.

The ISO readings can be misleading, because we don't test the noise level for a given ISO. If 2 cameras had identical noise levels at different ISO ratings, that would be an apple to apple comparison. HOWEVER, what can I say if camera A has an ISO of 600, but the noise level was really bad, but the other camera had an ISO of 300, but the noise was too small to see. Which is the better low light camera?

A more reasonable test would be to pick a low light setting and crank the gain up or down to match the image noise between the cameras and see what the F-Stop readings are...


There's aways give and take between the different cameras, so yes the EX-1 has a sharper image than the 150, 170, and 200a, BUT the cost is higher and you will face the potential problem of a rolling shutter.


The HMC-150 is exciting, because it opens the door to solid state HD recording at a lower price point than the HVX-200.

The HPX-170 is the smaller, lighter version of the HVX-200 and HVX-200a. While it lacks a tape drive, it has other interesting features that users will like. No one is sure yet, but we think the price will be close to the HVX-200a, maybe a bit less, but we'll see.


If you haven't gone to my Podcasts, check out the link at the bottom of this message and look for Jan's comments and Barry's comments from NAB.

Bob Diaz
 
The HVX200A is 500 across the board except in 1080i mode, it seems to lose a little, maybe to ISO 400.

Is that because unlike the the EX1 the HVX200A chips are always running at full resolution 960x540? I'm guessing that when the EX1 is doing 720p or 1080i it's actually activating fewer photosites and hence is generating less noise. But the HVX200a's chips are always using all their photosites and the image is being pixel-shifted to 1080p and then downrezzed to whatever resolution the user wants right?

davide
 
Yes, the HVX at all times is scanning its chips as a progressive matrix, operating at 1080P at all times.

The EX1 actually scans its chips in interlaced fashion when in 1080i mode, so it gains a stop.

I don't really know what it's doing that gains it a quarter stop when in 720p mode.
 
Since the HMC150 has 72mm filter threads, does this mean the bayonet mount for it would be the same as the DVX, so I could use Century/Schneider Optics lenses I already have? Or are the DVX attachment lenses not rated for HD?
 
Well, I'd hope they're the same, but I wouldn't guarantee it.

As to whether you'd even want to use the Century DVX attachments on an HD camera, that's a question we'd have to ask Schneider, at least until we can try it and see how they hold up.
 
Apologies if this has already been answered, but... Will this camera be able to output a live standard-def video feed for I-MAG? (Possibly a silly question, but with it not able to stream Firewire to a Firestore, I had to wonder.) And, if so, what the connector will be? (Being Panasonic, I'm guessing an RCA.) I probably won't be able to talk the boss into one anyway :), but after fighting that stupid 3.5mm A/V out on our GL2 again this morning, I'm ready to at least start exploring options for the future...
 
Apologies if this has already been answered, but... Will this camera be able to output a live standard-def video feed for I-MAG? (Possibly a silly question, but with it not able to stream Firewire to a Firestore, I had to wonder.) And, if so, what the connector will be? (Being Panasonic, I'm guessing an RCA.) I probably won't be able to talk the boss into one anyway :), but after fighting that stupid 3.5mm A/V out on our GL2 again this morning, I'm ready to at least start exploring options for the future...

BTW, Captain . . do you broadcast the video wireless to the panel? Would love to see what unit you use. The two we use do a great job on similiar levels (horizontally) but when the trasmitter gets up up and a way (like when mounted in a balcony on a jib and sweeps up high) the signal is lost for a brief micro sec on occassion and wondered if you experience the same?
 
Apologies if this has already been answered, but... Will this camera be able to output a live standard-def video feed for I-MAG? (Possibly a silly question, but with it not able to stream Firewire to a Firestore, I had to wonder.) And, if so, what the connector will be? (Being Panasonic, I'm guessing an RCA.) I probably won't be able to talk the boss into one anyway :), but after fighting that stupid 3.5mm A/V out on our GL2 again this morning, I'm ready to at least start exploring options for the future...

If you go to my WEB page on the HMC-150, look down to the fifth photo, you can see the RCA video and audio output connectors on the side of the camera.

http://web.mac.com/bobdiaz/Site/HMC150.html

So, yes there is an RCA SD video output.


Bob Diaz
 
You should be able to get RCA composite video and downconverted component video (not 100% sure about that one, but I think it's likely). I don't recall seeing an s-video port on there.
 
Red's Scarlet is going to have an 8X. My Red One zoom was 5x. 13X seems downright luxurious. Not as long as 20x, but still pretty darn sweet.
 
The 20X on the GL2 is certainly nice...

Anybody know if the HMC (or any of the other new models) are going to be at InfoComm? I actually get to go this year, so I'll have to stop by and check them out if they're around... :)
 
I don't know what the block size for files on an HMC-150, but let's assume the largest size of 32,768 bytes to a block. A single write-verification error, which would result in 6 additional write/write-verify steps (assuming the same as P2), would result in 32768 bytes x 6 tries = 196,608 bytes that must be buffered (worst case for 1 block failure). Not impossible to buffer with today's large RAM sizes.

I hope you are right, but with your buffer argument, you could also make class 4 work. Without a buffer, writing twice and reading once already puts you over the limit. You would never get to fix an error even at the best-fragmented state (although it could notify you of an error). I'm thinking you got the idea from P2 which has enough bandwidth to check for errors several times (and fix them) all within the card itslef (not camera) before moving on. If we find out otherwise, I'm sure Panny will brag about it :D

Finding the read/write timing specification for any Class 6 SDHC card was a bit of a search, but here's one I found:

http://www.ecost.com/detail.aspx?EDP=36985016

I knew that the read speed should always be faster, but I never bothered to look it up before.


A class 6 card supports a minimum of 6MB/second write speed, but it could be much higher.
Keep in mind that a manufactuer transfer speed doesn't mean anything. The class is the only specification that garuntees a minimum speed. However, I do agree that more than likely, it is sustaining well above the lower limit. The problem is that typically, companies want to be very conservative with the 3rd party specs to avoid an onslought of customer service calls. That could be why they specify class 6, just to be safe. I guess we'll know once we can pop a class 4 in and test ourselves. I'm not trying to argue, just jumping in on the speculation until we get more facts down the road :)

Most of the SD problems I see are from FAT corruption, not from bad writes. I have a panasonic pocket camera that has taken its share of beatings over the years and I haven't had a problem even using only the cheapest media. What I would perfer is use the extra bandwidth to write 720p120 to a 720p60 file at twice the speed. :thumbsup: With digital cameras offering crazy features like this, its only a matter of time before the mainstream video cameras start offering this. Write speed is the only limitation, they could implement the reverse of this for time lapse right now...

...But I suspect most 150 users are going to use the 21/24mbps mode exclusively, and in that mode it's 1920x1080.
Earlier I was questioning if you meant that HQ mode was not available for 720p, but now I'm thinking you were just pointing out that it does 1920 as opposed to 1440. The press release clearly mentions, "The camera can also be set to capture 1280x720 images at PH mode." I didn't catch that before, nice to know! I'm thinking that bitrate wont even be needed for casual 720p24 shooting, but would be great for quality 720p60 slow-mo or fast action.


With all the waiting we have ahead of us, I'm curious to see how well the HMC70 results come in for 13Mbs. If it comes up close to HDV at all (despite the camera's lesser specs), I think we are all in for a treat with the 150! Wasn't the 70 supposed to be released last month?
 
mcsmooth,

I think we are going to go in circles about if a Write Verification IS _OR_ IS NOT supported in the HMC-150. If it is supported, I would hope that Panasonic would understand that this is an important feature that users should know about and promote this feature.


As a side note, the FAT (File Allocation Table) is so critical to drives, that 2 copies are kept on any drive. Every block has a CRC (Cyclic Redundancy Check) to catch block errors, its' easy for the system to see which FAT has the correct data and which is trashed.

On hard drives and everything else using FAT32, the files can be fragmented with blocks all over the place. Every hard drive must wait for the sector to appear under the head to read the data. In addition, there is a delay time to move the head(s) from one track to another. This delay is called "Access Time" and the number is the AVERAGE time for the head to move from one track to another.

The higher RPM drives move the data past the head faster and there's less waiting for the requested sector to appear. Still, there is the delay for "Access Time" plus the time for the disk to rotate. Today's drives use RAM Buffers to read (as well as hold write) data. As the disk turns, sectors we didn't request are read into the RAM Buffer for that track. Should we ever need that sector, the data is now in a RAM buffer, ready for us and we don't have to wait for the disk to turn any more. We still need a full 360 degrees of rotation to get all the sectors for that track.


In the case of RAM, ROM, and Flash Memory, the "Access Time" for random fragmented data is ZERO, because there is no head in the memory chips to move. So, I can read from 0x000000000001 to 0x000000000002 as the next byte, just as fast as I can read from 0x000000000001 to 0xFFFFFFFFFFFFFF as the next byte (or any other address). Fragmented Data does cause a delay in a hard drive where we have mechanical delays, but has NO impact in for RAM, ROM, or Flash.


SPECIAL CASE: On some memory chips, the addresses are split into the upper bits and the lower bits. The upper bits for the address are loaded into the chip, then the lower bits to the address are loaded into the chip. Once the upper bits are set correctly, one can skip the step of loading the upper bits when reading/writing data where the upper bits do NOT change.

In that case, going from 0x000000000001 to 0x000000000002 requires only loading the lower bits for the address, but going from 0x000000000001 to 0xFFFFFFFFFFFFFF requires the extra step of loading the upper bits. However given that all the bytes for any block are NOT fragmented, this extra step would only be required on reading the first byte in the block. All other bytes that follow would not need the extra step of loading the upper bits. The typical FAT32 block sizes are around 2048, 4096, 8192, 16384, and 32768 bytes, so the extra step is too small to worry about when you count all the bytes.

If we had a 1 byte file, all the other bytes in the block may not be used by any other file. With very small files, using small block sizes are best to reduce the wasted space. HOWEVER, there is an increased amount of overhead to keep track of the extra blocks.

With both video and audio, the file sizes are massive, even with compression. Large block sizes work best, because this reduces the extra overhead of keep track of extra blocks. For example, assume we have a 128kB file: With 32786 byte blocks, we need to keep track of only 4 blocks (4 x 32768 = 128k), with 2048 byte blocks, we need to keep track of 64 blocks (64 x 2048 = 128k).


It would not surprise me to see on both P2 and the cards formated for the HMC-150 to see 32768 byte blocks.


Best Wishes,

Bob Diaz
 
I'm still doing research on editing software for the HMC-150 and I ran across this little tidbit that may be of interest to Apple Users...

Data_Rates_AIC.png


The highest typical data rate for AIC (Apple Intermediate Codec) is 14MB/second (49GB/hour). I recall that someone had said that it could be 10x the original data rate, a statement found in the Final Cut Express 4.0 User Guide, BUT I get the feeling form the context of that statement that the 10x increase more likely with the lower data rate recordings.

With a recording data rate of 21 Mbps (average) / 24 Mbps maximum, it's more of about a 5x increase in file size. The good news to all of this is that 500 GB of hard drive space should hold about 10 hours of AIC material.


Bob Diaz
 
Back
Top