'Just Send Uncompressed' Regarded as Bad

Home

Blogs

Software (Bruce)

There's been a bit of a push for 'uncompressed' as a file format definition for onsite video delivery - as if it's a magic bullet. But there's some severe problems with that specification, as many technicians have been finding.

There's some clear advantages too, and they shouldn't be ignored. First is that, by definition, it's as good as you can get (with the exceptions we describe below). Another is that it's a great source for encodes, especially if you need to do a lossy compression. It also sounds pretty good, especially when used as a buzzword synonymous with quality. Many people working in the creative field may not feel comfortable specifying compression for onsite playback, but will breathe a sigh of relief hearing uncompressed as the delivery format.

Before we get into the specifics, can we agree, based on our own individual experiences that uncompressed isn't needed? Didn't some video we saw before we started seeing some uncompressed footage look really, really great? Doesn't HDCam and HDCam SR look really good? They're both compressed formats. So let's define the real goal.

Onsite playback should ideally be of a quality that to even the trained eye, there are no bit-depth reduction, compression or down-sampling artifacts, and no loss of sharpness or visible errors of any kind - when compared to the edited master.

We can also specify that there should be no audible difference. As I write - and this may change, an audio delivery format of raw 16-bit integer samples at 48 KHz seems to be regarded as good enough. That is achievable within a reasonable bandwidth and storage space, so there's no reason to go much further.

So, on the meat. What's wrong with asking for uncompressed? Let's hit the basics first.

It isn't really a specification. You're asking the editor or creator to guess at the following parameters:

Packaging - Quicktime mov, .avi, folder of TIFF's, raw data, mp4, mkv etc. etc.
Pixel Format - You can have 4:4:4, 4:2:2, 4:2:0 and 4:1:1 uncompressed, let alone alpha channels, or weird color codings like 3:1:1 (used in HDCam). There are also sub-varieties of pixel ordering, such as yuv2 vs 2vuy, differences in video levels; and even something as small as the specified codec name being different can trigger a render or prevent smooth playback in systems not tolerant to that.
Frame size - if the piece is made in an edit house, you have a good chance that it will be an SD or HD frame size, but if the piece is made for a screen, someone is bound to get clever and try to create to the pixel dimensions. That's not a problem, until something shows up that doesn't match your workflow. Some cheaper DDR's will try to do a nasty upconvert to an HD frame size, or else you may have to do your own compositing onto an HD or SD frame, and deal with render times.
Luminance Sub-sampling - Some formats, such as HDV and DVC Pro HD sub-sample the luminance, and you should consider maintaining that sizing, rather than upsampling for no reason.
Pixel Aspect Ratio - Not defining this almost guarantees you'll get square pixels if you have an HD frame, or 1.1:1 for an SD frame, and that your content will be letterboxed (as the common denominator) even if a custom aspect ratio would work better in your situation. That could be a lot of black pixels you have to move around for no reason.
Bit-depth - 8 and 10 bit pixel bit depth is common, but 12, 14 and 16 are possible. This should be matched to your onsite workflow, to avoid poor conversions that will introduce banding, especially under manipulation.
Frame rate - the worst case of all would be your import software - often the free stuff that comes with video cards or DDRs, doing a poor conversion, but the best case - something like Final Cut Pro doing a full conversion render, could take hours.
Interlace Settings - Progressive or interlaced to start, then also field order. Sometimes the editors may decide to just do 29.97 fps to save rendering time, if they believe onsite playback will be progressive (as almost all screens are these days). That's not something that can be fixed - ever. (That would be 29.97 PsF as opposed to 59.94i)

So, you've got some really good opportunities for mess-ups there. And they happen - a lot. Since most large projects involve multiple edit houses, you're going to get multiple editors making different decisions as well. Try explaining why one video took an 30 minutes to prep but the next will take two hours to a nervous producer. I dare you.

But the primary problem with uncompressed content is file Sizes. Uncompressed video reaches insane sizes, and some simple things like a USB file copy can take hours. Drives have to be purchased and transported (in a protected way), and Internet transfers require huge costly connections, making any sort of onsite download unfeasible. Bear in mind that a 12-bit 4:4:4 frame at 2048 x 1080 - a reasonable, if high end request: say from a client in the visual field, is 12.65 MB, so you could fill a 250 GB drive with a 5 minute video piece! And that would take hours to copy onto your RAID array (with a common USB-2 drive), before you even started to put it on DDR's.

Bear in mind also that 4K (and beyond) is coming - fast. Even if you decide that you can swallow the problems with current file sizes, you might be locking yourself into a solution that you can't support in the future.

So, why has 'uncompressed' gained any kind of foothold as a delivery format? Well, the list above could apply to many compressed formats also. Briefing an editor fully, or creating an exact specification, is very time consuming, and sadly, as they say "no plan of attack survives contact with the enemy". In practice, that means that the creative process will consume every single minute up the deadline, and then formatting for delivery will be a last minute dash with corners cut as needed. It's just a fact of life.

In case you're curious, Synchromesh products will help with almost all of the problems described above, to some degree. We can tell you how. But I really want to just remind you to calculate for yourself what place compressed video should have in your workflow. Of course, specifying compression is another whole kettle of fish, but there's whole inter-tubes devoted to that, so I won't even attempt to blog it.

I will mention the only thing close to a short-cut is to find some standards. For instance, among other things, we provide an Avid DNxHD license with each Synchromesh player. I covered what and why in a previous post, but in this context, it's important to note that it removes almost all the flaws of uncompressed content covered above, and still meets our golden rule.

OK, over and out. I need to go and see if my uncompressed file has finished copying. I suppose the upside of uncompressed HD content: