Press Release: HMC150, "the new DVX"

I thought it would be fun to go back to my list of predictions for the HMC-150 and see how it turned out:


(1) List Price under $4,000. Well, Panasonic is saying UNDER $4,500, but we don't know if "Under $4,500" is going to be $4,499.99 or $3,999. STATUS: UNKNOWN

(2) Maximum recording data rate 20 Mbps (or higher). The maximum turned out to be 21 Mbps average and 24 Mbps maximum. STATUS: Correct

(3) Single Slot for Memory card. Only one slot. STATUS: Correct

(4) Improved CCD (also slightly larger than the HVX-200's CCD). Yes, and I like it. :thumbsup: STATUS: Correct

(5) Time Lapse Offered. Jan said, "Not likely.", sorry... STATUS: Not Likely

(6) Uncompressed Audio as well as a choice for compressed audio. Jan said, "Not likely", another sorry ... STATUS: Not Likely

(7) Support for Standard Definition. In a word, NO. STATUS: NO

(8) 12x or 13x zoom. 13x Zoom offered. STATUS: Correct

(9) Images will look a lot like the HVX-200's images. Given that the 200a uses the exact same CCDs, yes. STATUS: Correct

(10) Operation & Menus like the HVX-200; however, this last prediction is more of a "Duh!" prediction! It's still up in the air, so we'll see... STATUS: UNKNOWN


So, it seems likely that I've gotten 3 wrong and have the potential for 2 more wrong. However, I don't think those 2 are that likely to be wrong. So, my best case quessing is 70% correct, but my worst case guessing could be as low as 50% correct!!!


Bob Diaz
 
Last edited:
I can't comprehend of how you could be wrong on #10. The cameras looked identical, the menus between the 500 and 200 are largely identical, there's almost no way that the menu structure will be terribly different on the 150 vs. the HVX200...
 
Still wondering if anyone has ever used Panasonic's windows app to convert AVCHD to P2/MXF format. Does this app come with the consumer version of Pannisonic AVCHD cams? If one converted a 21 mbps file(1080p) to say 720p, how much of a file size increase would one see?
 
Saw this post earlier and had a question. I own FCE as well, and you say it automatically transcodes the AVCHD file?

What would you adjust your import settings to? The HD options only seem to support the HDV Apple Intermediate Codec in 1080i60, 1080i50, and 720p.

Well I have good news and bad news... Assuming you have FCE (Final Cut Express) 4.0, you can work with AVCHD.

Good News
: On the Apple WEB Pages, they show the importing as a simple menu system that allows you to select a clip or a group of clips. The first link talks about it and the second link shows how it's done (Click on Transfer from AVCHD).

http://www.apple.com/finalcutexpress/index.html#importing

http://www.apple.com/finalcutexpress/tutorials/


Bad News: Apple has limited FCE support to 1080/60i, 1080/50i, and 720/30p. Would it have killed them to include 1080/24p, 720/60p, and for Europe 1080/25p plus 720/50p...

Clearly they want people to spend more for the higher level editing program, but the jump from $200 to $1,200 is going to be way too much for those with limited funds. I'm not sure how this is going to work out once the HMC-150 comes out. Will Apple offer support for the additional modes in FCE 5?


Bob Diaz
 
And how long before they released FCE 5? This may seriously impact the sales of the 150.
In buying a camera it is smart to look at the whole workflow; practicality and cost to output your final product.
The next 2 years are going to challenging for the manufacturers and a reminder to all of us of the real question: what do I need a camera for? Defining your needs as clearley as possible is paramount in any investment decision.:2vrolijk_08:
 
Still wondering if anyone has ever used Panasonic's windows app to convert AVCHD to P2/MXF format. Does this app come with the consumer version of Pannisonic AVCHD cams? If one converted a 21 mbps file(1080p) to say 720p, how much of a file size increase would one see?


That converter is available on panasonic's website. I've used it to convert some avchd files from one of their consumer cameras (also flash cards) and it seems to work well with AE and premiere cs3.

No idea on the 21mbps file size increase, but I don't see why you wouldn't just convert/downres with your normal NLE.
 
Still have this odd feeling that the footage will be "Cleaner" than 170 and 200A footage @ max Quality.. Sharper? I don't think so... but cleaner? Dunno where I get that from.
 
but I don't see why you wouldn't just convert/downres with your normal NLE.

I use Sony Vegas and it appears that, for at least a while, Vegas isn't supporting Panasonic AVCHD. :cry:

Hopefully Sony Vegas will eventually support Panasonic's AVCHD, but for now I'm just trying to see how much additional expense will be involved in jumping from SD to HD.

Even if Vegas adds support, I believe they rely more heavily on the CPU than other editors. For decent speed editing native AVCHD, it seems that dumping some of the workload on the GPU will be a necessity.
 
. . . For decent speed editing native AVCHD, it seems that dumping some of the workload on the GPU will be a necessity.

If AVC-HD is GPU intense instead of CPU, I can assure you that for one I won't be going that route because it just doesn't make sense to place the pressure and load on a device that has but about 512MB memory and slow relative processor clock speed while there is 4GB setting on the motherboard, 1667FSB, dual xeon, dual cores each at 3.0GHz, with hyperthreading. That is like having a Corvette in the garage and leaving there and take the Pinto to the races instead with hopes of winning :o)
 
I'm far from an expert, but it seems that render speed depends on lots of variables. I know my after effects (which offloads many tasks to the GPU) renders snappier than my NLE (which I'm pretty sure relies mostly on CPU).

Even if you look at it simplistically, you should get more render cycles from your CPU + your GPU than you would get with your GPU alone? And the reality is that your CPU does some very specialized graphics functions (like shading) that would take loads of CPU cycles. Anything that requires specific algorithms (decode/encode) that can be built into HW and relieve CPU cycles is gonna speed the whole process up.
 
Anyone who has the words Can't, Won't, Doesn't, Couldn't should join skateboard video forums to *****. Everyone who is interested if finding possibilities and solutions should countinue as before.

Thanks.
 
If AVC-HD is GPU intense instead of CPU, I can assure you that for one I won't be going that route because it just doesn't make sense to place the pressure and load on a device that has but about 512MB memory and slow relative processor clock speed while there is 4GB setting on the motherboard, 1667FSB, dual xeon, dual cores each at 3.0GHz, with hyperthreading. That is like having a Corvette in the garage and leaving there and take the Pinto to the races instead with hopes of winning :o)

That makes absolutely no sense. The correct analogy would be taking your Corvette to the boat race. With that logic, you could tell gamers they are wasting their money on expensive graphic cards and to throw the cheapest one on a quad-core. :smile:

H264 is already excelerated on ATI's and Nvidia's latest boards, so they should take a decent load off the CPU while editing. Encoding will be another story, but you aren't forced to encode to that format.

Once AVCHD editing shows up properly in the NLEs (and if they implement it properly), re-encoding quick edits should go fairly quick. Correct me if I'm wrong, but as long as you aren't altering the picture, the only thing that should need to be re-encoded in MPEG formats are the frames that are outside of their GOP (which would be near most cut points). Once you start altering the picture (color corection, etc), then you obviously need to re-encode, but that is the case in any codec. So it should eventualy edit fairly similar to DV and exactly like HDV (without the tape). I'm sure many of us remember a time when our systems had trouble simply capturing DV without dropping frames, not to mention how painfull editing was afterwards.
 
. . . . Once AVCHD editing shows up properly in the NLEs (and if they implement it properly), re-encoding quick edits should go fairly quick. Correct me if I'm wrong, but as long as you aren't altering the picture, the only thing that should need to be re-encoded in MPEG formats are the frames that are outside of their GOP (which would be near most cut points). Once you start altering the picture (color corection, etc), then you obviously need to re-encode, but that is the case in any codec. So it should eventualy edit fairly similar to DV and exactly like HDV (without the tape). I'm sure many of us remember a time when our systems had trouble simply capturing DV without dropping frames, not to mention how painfull editing was afterwards.

So then is it safe to assume that just barrelling in video and editing cuts and transitions, drop in a few titles, and maybe an effect or two for look/feel on maybe one or two short clips, then for the most part AVC-HD will be processed via CPU but then IF we do a lot of color correction and get jazzy on the Hollywood FX then we can expect a major slow down because this will be GPU . . yes?

Lastly, the reason I bring this up as a won't, can't, etc. after having qualified it with an "IF" statement earlier . . we recently have produced our first two 1920x1080 projects inside Avid and discovered that we simply could not (not would not but couldn't) edit because the source and master screens simply could not keep up with the audio for editing purposes. The output was fine but the edit was a nightmare. Moreover, after turning down the res on those two monitors the performance improved but only marginally PLUS the view looked horendously poor (although again the output was unaffected) . . AND . . the render folder for a 10 minute project was none other than a whopping 168GB's . . . WOW . . again nothing to do with wouldn't it was couldn't and if AVC-HD is the same we'd have to have all TB drives in RAID "0" just to hope to store it all let alone if all GPU intense we'd be burried in being able to see it on our ATIX1950PRO Crossfire cards . . however . . we learned on the project we shot Friday that changing the render option from native . . it definately UP'D the performance BIG TIME !! - - AND - - reduced the render folder to 11GB's . . livable :o) do-able, could-able, would-able, etc. :o)
 
If AVC-HD is GPU intense instead of CPU, I can assure you that for one I won't be going that route because it just doesn't make sense to place the pressure and load on a device that has but about 512MB memory and slow relative processor clock speed while there is 4GB setting on the motherboard, 1667FSB, dual xeon, dual cores each at 3.0GHz, with hyperthreading. That is like having a Corvette in the garage and leaving there and take the Pinto to the races instead with hopes of winning :o)

A dedicated part, like a GPU, can handle video acceleration at a much faster rate than most processors. It's not a clock rate or a RAM thing; the architecture of modern GPUs just handles this kind of math much better than a lot of modern processors do. Not to mention the fact that when you accelerate video processing in hardware you're not completely ditching software rendering methods either. In a best case scenario, the two work in tandem to produce speedy calculations at high-precision levels.

Go read up on Anandtech or Arstechnica about hardware acceleration in video if you want a more in depth explanation of this stuff.
 
So then is it safe to assume that just barrelling in video and editing cuts and transitions, drop in a few titles, and maybe an effect or two for look/feel on maybe one or two short clips, then for the most part AVC-HD will be processed via CPU but then IF we do a lot of color correction and get jazzy on the Hollywood FX then we can expect a major slow down because this will be GPU . . yes?
The part you quoted had nothing to do with GPU/CPU, it was about editing simple cuts in MPEG formats. When you color correct an entire movie and do FX, there are going to be long render times in any format, I was talking specifically about the AVCHD encoding (last step AFTER editing is complete). Editors that support GPU processing simply use them on fucntions when it will significantly speed up the process and/or take load off the CPU while it does other things. Often this helps with real-time FX rendering/viewing. The two work together, a program can't simpy send all of its instructions to the GPU. Some programs have the ability to turn this feature off, so if you really think the programmers were dumb enough to take the slower route, you can turn it off. This silly argument went way off topic and is implemented differently by each program.

Lastly, the reason I bring this up as a won't, can't, etc. after having qualified it with an "IF" statement earlier . . we recently have produced our first two 1920x1080 projects inside Avid and discovered that we simply could not (not would not but couldn't) edit because the source and master screens simply could not keep up with the audio for editing purposes. The output was fine but the edit was a nightmare. Moreover, after turning down the res on those two monitors the performance improved but only marginally PLUS the view looked horendously poor (although again the output was unaffected) . . AND . . the render folder for a 10 minute project was none other than a whopping 168GB's . . . WOW . . again nothing to do with wouldn't it was couldn't and if AVC-HD is the same we'd have to have all TB drives in RAID "0" just to hope to store it all let alone if all GPU intense we'd be burried in being able to see it on our ATIX1950PRO Crossfire cards . . however . . we learned on the project we shot Friday that changing the render option from native . . it definately UP'D the performance BIG TIME !! - - AND - - reduced the render folder to 11GB's . . livable :o) do-able, could-able, would-able, etc. :o)
The X1950 does not have H264 accelleration... a newer board, would help you if/when the NLEs use them properly. I don't know how many times people have to say it, but the format is still going through growing pains. Just like DV and HDV, it will all be sorted out in time. If this camera is a fraction as popular as the DVX was, the NLEs will be rushing to offer support.

If you want a proven workflow that works well TODAY, you should get the 170 :thumbup:
 
. . . The two work together, a program can't simpy send all of its instructions to the GPU. Some programs have the ability to turn this feature off, so if you really think the programmers were dumb enough to take the slower route, you can turn it off. . . .

I just contacted Avid and both our Avid NLE's take advantage of the CPU/GPU workload sharing on graphics as you mentioned. YES!

Actually if the camera uses AVC-HD which is a relatively new format for the cameras/NLE's I would say this IS on topic. After all, it's about the camera and the camera uses that workflow. However, the exciting part is that we will be able to take advantage of it is what they are saying wherein they are going to have AVC-HD codecs :o) So, looks like I'll be good to go no matter what.
 
So...a Class 4 sdhc should be fine???

So...a Class 4 sdhc should be fine???

Just wondering as the class4 can handle 15 MB/s while the 150 recording stream should max out at around 3 MB/s if you're peaking at 24mbps.

Do I have that correct?

sincerely,



ian
 
The class number is in MB (Mega-Bytes) per second. You can multiply by 8 to convert it to Mb (Mega-bits) per second. (Notice the upper case for Bytes and lower case for bits.)

So, 4 MBps x 8 = 32 Mbps

BUT.... the Panasonic MHC-150 does not just write to the card and move on. The camera appears to do a write verification (read and verify the data). So, take the 32 Mbps and divide it by 2...

32 Mbps / 2 = 16 Mbps maximum with class 4 cards.


As for class 6 cards:

6 MBps x 8 = 48 Mbps

48 Mbps / 2 = 24 Mbps


I hope this helps.


Bob Diaz
 
The class number is in MB (Mega-Bytes) per second. You can multiply by 8 to convert it to Mb (Mega-bits) per second. (Notice the upper case for Bytes and lower case for bits.)

So, 4 MBps x 8 = 32 Mbps

BUT.... the Panasonic MHC-150 does not just write to the card and move on. The camera appears to do a write verification (read and verify the data). So, take the 32 Mbps and divide it by 2...

32 Mbps / 2 = 16 Mbps maximum with class 4 cards.

As for class 6 cards:

6 MBps x 8 = 48 Mbps
48 Mbps / 2 = 24 Mbps

I hope this helps. Bob Diaz

Wow Bob, great explanation. Thanks! Especially the back/forth downsizing of the spec due to the write/verify. Very helpful in understanding. :o)
 
BUT.... the Panasonic MHC-150 does not just write to the card and move on. The camera appears to do a write verification (read and verify the data). So, take the 32 Mbps and divide it by 2...
Where was this information from? Wasn't sure if I missed this somewhere or if you are thinking about the same information that was recently verified about P2 cards (which is done within card, not the camera).
http://www.dvxuser.com/V6/showthread.php?p=1255973

48 Mbps / 2 = 24 Mbps
The reason I ask is that this seems a little risky considering your 24/48Mbps number would be at the exact minimum of class 6 cards ... "at the best fragmented state where no memory unit is occupied" ... which would leave a good probability of dropouts in high quality mode when some class 6 certified cards start to fill up.
 
Back
Top