Chances are you don't care about the technology that holds your video. And that's probably why you are not reading this. The truth is that it matters. Knowledge is power, and it's a choice to be a power user.

The goal of this second Digital Video article is to show you how to preserve more HDV video data than a default school or broadcast (been there done that) workflow does. This will also apply for oldskool DV footage, but this article focusses on HDV. When messing around with DV footage, you can ignore some MPEG (HDV) specific stuff.

History:

Digital Video and the YUV Color Model

He used to be a man with a tape in his hand

whoop diddy-diddy, whoop diddy-doo

I'm a student

At the chance of losing your interest, please allow me to tell you that I'm a student. I do a fancy media focussed study called "Art and Technology" in Enschede. Now that I'm well on the way of getting the paper degree that states how cool I am, I'm obligated to narrow my focus from knowing a tiny little bit about every media implementation in the world to some more specific form of media so I can actually make money with it. That's why I'm specialising in a branch called " Video Styling and Post Production."

School is a great place to get involved in projects. I did my share of working with professional equipment, compositing, editing, cg and it was fun while it lasted. But in my specific experience the world seemed to be rushing everything. There was barely time for artistic freedom (I study Art and Technology, not Media and Rushjobs). Just do the routine, spice it up a little, move on and don't look back. Also, and this bugs me because if there's a math guy and a language guy I'm the former, how video works under the hood is very untransparent in the average workflow. No one questions it though, and the problems it causes are simply a fact of life. Do you know how it sucks when you don't understand a given formula at math or science and you fail to use it by instinct? The numbers will work out, but it won't feel like you're in control.

So, to prevent myself from getting involved in the carousel again and again, plus given the lack of girls in Enschede, I moved up north to Leeuwarden to complete the "Video Styling and Post Production" branch. You know what else is fun, not having the study's kick ass equipment available. That's why I arranged access to a Canon HV20 consumer HDV camera. And I am excited about getting the most out of it (as it is) as possible.

Capturing - Basic procedure

So there we are, trying to go from 'whoop diddy-doo' to well.. having a digital video file. The procedure they try to teach us in class is insert tape, click capture. I don't know if you have access to Avid Xpress Pro through school, bought a €299 student license for Adobe Production Premium containing Première CS3 or are using another NLE I don't know, but any NLE basically rips the datastream from your tape and puts it in an YUV (YCC) color model representing container file. This will usually be the logical familiar container designed for that stream (.dv or .avi for DV, .mpg, .mpeg or .m2t for HDV) and will be dropped somewhere on your drive so you can mess around with it. Except for Avid Xpress, which is completely untransparent and bitchy about footage media, though interestingly enough the most populair professional NLE out there.

We know there's MPEG2 with a GOP of 16 frames on the tape. We know the data is supposed to be contained in an MPEG2 Transport Stream (TS), and we know the .m2t file extension is established for that purpose. Guess what? We want that .m2t file in our metaphorical hands before anything else happens because we want total control, which Avid Xpress, most pricy tool out there, doesn't give us.

So if you use Avid Xpress or if there's any other reason why you're not ending up with .m2t files, there's a free tool called HDVsplit.exe, only 3 bytes big, that does exacly what you need without giving any attitude. It will optionally split all your scènes and it's a kickass tool.

Optionally, you can let Adobe Première handle the capturing, at least you'll find some familiar files in your project folder, having the .mpeg extension. This is actually kind of cool because it's an .m2t in disguise. You can safely rename this file to .m2t.

MPEG is YUV. So?

As you know, camera footage is (usually) in the YUV model. That's the 8 bit Y'CbCr (YCC) space in the case of (H)DV. We also know YCC has black defined as 16 and white as 235 on the color scale. These rules are defined in the ITU-R BT.709 specification (or 601 for DV). Values exceeding that range are called supers. Below 16 is superblack and above 235 is superwhite. These are usually clipped off because of historical reasons (voltages representing the signals will start interfering with other signals), and cameras are not supposed to use those area's or your picture will look burnt or over-exposed on old televisions*. That gives us a total of 235 - 16 = 219 brightness variations, which is a bit lame if you compare it to the 255 shades in a standard 8 bit RGB signal.



Luckily, most cameras capture superwhite nontheless. The idea is that you can clip it if you don't want it. Clipping 7% extra white is surprisingly unnoticable without a reference, and professional NLEs like Avid Xpress handle this super well anyway, so bringing down the level somewhat still gives you real white in the highlights. However, no superblack is captured because we'll immediately notice black being blown out.

HV20 footage contains superwhite. This is cool if you want to post process your footage. If you want to tweak your image, it's always gonna have a better result if you had more range in your footage pixels to begin with.

Post production packages like Adobe After Effects, Fusion, 3d Studio Max' Video Post and probably every other one I haven't mentioned have no immediate bond with analog history and simply work in the RGB color model with the full color scale. So when passing your footage through there you'll want to have the broadest possible dynamic range in your color data. Just importing your .m2t in - for example - After Effects will leave you robbed of video data if you don't know or don't care about this conversion. Supers will be clipped. This is because software will usually assume for you that the absolute black and white positions according to the YCC specification are in fact black and white; there are no supers in RGB.

To illustrate the matter, here's a still imported from HDV MPEG2-TS in an YUV NLE and a RGB postprocessor:

.m2t -> Avid Xpress 5.7

.m2t -> After Effects CS3

(Tip: Open both images in new browser tabs and switch back and forth. Especially note the clouds.)

Color model conversion is bad

On the next pages, I'm going to further analyse picture quality whilst working towards a proper conversion method. It is important to note at this stage that you should concider your workflow, for frequent conversions between YUV and RGB degrade image quality. Rescaling between 219 and 255 color values introduces rounding errors, causing color banding (like converting your image to an old-skool animated gif) and other artifacts.

A good thing about Avid Xpress is it's ability not to remap while exporting as RGB. (Choose 709. Newer versions of Avid Xpress support 709 export for video as well. You don't have to resort to an image sequence anymore to keep supers in RGB export material.) Recently, Adobe Premiere changed their render engine from RGB to YUV, so maybe they have this option, too.

You might think that exporting as 709 RGB is the solution, but it's not. Apart from the fact that RGB posting on footage where black is not black is a pain in the ass, there's the problem of chrominance. Not only is it subsampled in YCC space - eventually introducing blur - but while YUV luminosity is pinned between 16 and 235, often extended in super to 255, chrominance is actually pinned between 16 and 240. That's the theoretical bandwith, for chromachannel utilization in YCC is very bad, using about 1/4th of the chroma channels' bandwidth. Therefore, swapping between YUV and RGB - even if you carefully use 709 RGB values and lossless compression in both spaces - will wash out color data more and more like using a cheap brand of detergent to wash your clothes all the time.

Take this workflow for example. Imagine making a video for which you need to composit a few shots, edit the shots together and add some post effects that span the entire video. The client wants the product on DVD:

Action	Software**	Format	Model	Quality Generation
Capture	HDVSplit	.m2t	YUV	1st
Precomp	Shake	.tga	RGB	2nd
Cut	Avid Xpress	.mov*	YUV	3rd
Post	After FX	.avi*	RGB	4th
DVD	TMPGEnc+DVDLab	.vob	YUV	5th

* These are default containers that support both color models, but the corresponding software works with the specified model internally.
** These are ofcourse examples. There are a lot of other possibilities.

That sucks as bad as it is, so really, think it through.

Now that we know this, we can prevent multiple generations of dataloss by minimizing the amount of color model conversions that would go by unnoticed to the unknowing video editor. But even better, let's manage the initial conversion ourselves to utilize the detail that's hidden in superwhite.

A detailed analization of HV20 footage will follow on the next pages, leaving us with no choise but to do the best color conversion possible.

Pagina's:
[1][2][3][4] Volgende pagina (2) >>