Over the years, the discussion has gone back and forth with respect to what to do about HDV. Processor Intensive. In a ProApp, every frame has to be converted to an i-frame on-the-fly.
HDV was not supported in earlier versions of COLOR, and there are those who would argue that it is a triumph of engineering (over common sense) that it is editable.
I know we 'sneak it by' a lot of broadcasters who uncategorically regard it as a useless "consumer format". It does wreak a bit of havoc, since it can contribute to errors related to frame count -- since COLOR does not pay much attention to absolute frame numbers, but mostly goes by predictive duration based on frame rate.
However it does have it uses. Under the right shooting conditions, it looks alright -- that can also be said about Super8 reversal -- and there might even be some similarities there.
Where the HDV/COLOR workflow breaks down, is that most users of this format are usually strapped for one of those good/fast/cheap criteria, and also burdened by storage and bit-rate ceilings. COLOR does NOT export HDV, so a project will change horses at this point in the stream. That has ramifications for aspect ratio, storage, and data-rate, all at the same time. Rendering out of COLOR in ProRes is pretty much the only option if Uncompressed isn't attractive for the above-mentioned reasons.
If breaking up a codec into its color components is really necessary for last-ditch recovery efforts, then the Nattress Plugins are very useful for doing RGB/YRB splits. At this point, it might also be useful to observe that COLOR does do an RGB conversion on input and then grades are applied in those channels. Just one more layer of complication. So an operator
isn't
really dealing with the original native-format HDV files, anyway.
jPo