AVCHD / "Advanced Video Codec High Definition" & Cheap cams & Linux?

Question

Hi!
A customer of mine seems to have his mind set on the general awesomeness of the "Advanced Video Codec High Definition". I can't seem to understand why anyone would want to have a multi-track video editor work with that random assortment of specs - at least as long as it's coming from a (relatively) cheap cam...
So my first impression: "The cam costs significantly less than 20000$ and therefore the video quality can't really get noticeable worse if one just converts the video files with ffmpeg to whatever '60 minutes of video per CD' format it sees fits".
Am I wrong / missing the point? Do you have any experience with "Advanced Video Codec High Definition" cams & archlinux / gnu software etc that should concern me?
Thanks!

Answer 1

So... does that mean, that usually the cams just encode with one of those "generic-jpeg-intel-codecs"  (or don't compress at all) and the client-side software (that isn't used on a linux platform anyway) or something else does the rest? Or what would be a realistic / common scenario?
Also: for someone who didn't pay much attention to "video standards" in the past, just to understand the general principle... which one of the following two is closer to "the truth"?
(a) To ensure high video quality, it needs to be taken care of that in every step between the camera recording the raw video and burning the finished / rendered "movie" onto a portable medium, the software & hardware is capable of working with the advantages of "AVCHD".
or
(b) Someone obviously has been going around putting AVCHD-stickers on random objects and telling people to buy only those. If one just ignores those stickers, everything should be just fine.
And finally: Does anyone have a cam that says its "AVCHD" and used kdenlive or something & other open software to do a DVD of some sort? Was everything in between manageable with a "normal modern desktop pc" (no highend hardware)?
It seems to me like you are looking for some documentations so go there http://www.vcodex.com/h264overview.html and skip to the section 4 "h264 in practice"
Basically h264 advantage is for the same video quality, your clip takes much less space (or for the same space it will have better quality). But it will need more power to decode/encode.
Even a "low-end" camera like for example the Panasonic Lumix TZ7 (one of the best compact I think) offers 9Mbps, 13Mbps or 17Mbps when you record AVCHD. With those bitrates a "generic-jpeg-intel-codecs" will be okay. (actually the generic-jpeg-intel-codecs on the cam is a dedicated Digital Signal Processing chip aka DSP chip)
proposition (a) everything capable of working with AVC/h264 can work with AVCHD, it's just a marketing name, there is no special features.
Ensuring high quality is another beast, online guides and common sense help: the less you convert (colorspace for example) or reencode, the less information you will lose.
(b) AVCHD just means the cam can record in h264 instead of DV or Motion Jpeg.
For your final point, beyond a bitrate of 3Mbps dual-core Core 2 Duo CPU feels really sluggish when encoding to h264 but they are good enough to encode to dvd/mpeg2 format. I can't say about kdenlive/openshot/cinelerra and other NLE though, but every open source NLE can work with AVC-HD (via gstreamer or ffmpeg).
Like Gusar asked, it would be great if you can tell us your workflow.