Look--all I know is the theory behind this stuff. I've done a hard scan through the protocol specs (not a detailed read, since I wasn't going to implement any of them). I do know that Mitsubishi used a FireWire A/V protocol stack--everything, up through HAVi and DTCP--that they bought off the shelf from a company called Vivid Logic
. That company doesn't do anything but make software for embedded 1394 A/V stacks, qualifying reference implementations with testing labs.
This is quite normal--nobody rolls their own communication protocol stacks if they don't have to. When a new set of protocols comes out, it creates a whole cottage industry of little companies specializing in pre-packaged software. Writing the communications software and, most importantly, testing it for correctness is a major task, and these companies have done it already. I've worked with several such companies in porting their products into the embedded application I was working on--I'm working with a company on something similar now (though for a small-device Java engine, not a comm stack).
The problem is that Panasonic, being the first on the scene, might not have had the benefit of such pre-packaged stuff and might have had to roll their own. Who knows? But from what I've read here, people have put FireWire protocol analyzers on the buses with their products and seen chatter that wasn't part of the EIC, EIA, AV/C or 5C protocols, so they must have implemented something proprietary between their tuners and the recorders. That's not to say that the tuners or recorders won't work with anything else--experimentation here has shown that they will, to some extent.
Mitsubishi's literature talks about them having been true to the standards, so I'd be surprised if there was anything proprietary in there. I'd expect that their, Sony's and JVC's current FireWire offerings (and RCA's upcoming ones) were at least built with software that was stringently tested to interoperate with other compliant software. Whether the manufacturers strayed from compliance after they'd gotten the stacks running on their platforms with the aid of the people they bought them from...who knows? In the world of telecommunications, when you add a protocol to a product, you only do it so that it can interoperate with any other product, yours or any other manufacturers, that speaks that protocol. Telecomm customers won't tolerate anything else--if your stuff won't talk to the stuff they've already deployed, whoever they bought it from, you stand to miss many, many millions of dollars in sales. In the world of competitive A/V equipment, that type of manufacturer cooperation is probably harder to achieve. Witness the OpenCable stupidity. I think that these CE companies see adoption of too many standards as taking away their product differentiation, and to an extent, that's true. When everything has to deliver mostly the same services, you have to compete largely on external features, like esthetics and ergonomics.
My current problem with Mitsubishi's D-VHS deck is its pricing. It was introduced at the same time as JVC's and JVC's is on sale all over the place online and discounted to the point that it's no more than the list price of the Mitsubishi. Having a built-in MPEG decoder with DV-MPEG translation and component-video outputs as well as 1394/DTCP, it's considerably more powerful than the Mitsubishi. I can't even find the Mitsubishi on sale online at all--the price-search engines I use turn up zilch for it, and no portal search I've tried finds it at any online stores. So, unless one had one of the Mitsubishi sets with an integrated tuner, which has the ability to deal with the deck's HAVi stuff, I couldn't recommend purchasing the Mitsubishi deck. Even then, if you used DV-camcorders, the JVC might be a better buy.
-- Mike Scott