Digital Video Questions? Answers from an Expert
Page 3 of 4

DMN: So within certain limits, I guess the old saying, "you can't be too rich, too thin, or have too much RAM" still holds, unless you're talking about more than four gigs, right?

Bryant: To a certain extent, yes. On most of our processes, we never use more than a gig. If you're RAM-dirty, meaning your software eats up RAM more than it should, then more RAM would help. But if you're compositing, lots of RAM is good. If you're doing nonlinear editing, I haven't seen a package that needs more than a gig. Even with our HD stuff, when we're running full-bore, 100% on the processors, spawning as many threads as we can, we're never over a gig on the amount of memory that we're actually using at any one time.

Now there could be some benefit to more RAM because a lot of the stuff we're working with now, playing with different frame buffers that we're accessing in memory -- with more memory, you're allowed to play a bit more. I think I'd have to say it really matters how the software application uses the RAM. Some are very good. After Effects can use a ton of RAM and it loves it. Combustion and a few of the other compositing packages like lots and lots of RAM. But most of the nonlinear editing packages I've seen don't use much more than a gig.

DMN: So a good rule of thumb would be if you're going to be doing a lot of compositing, then go ahead and invest the money in tons of RAM, but if you're going to be doing just digital video editing, it's not going to do you a lot of good to go over a gig.

Bryant: That's typically true -- more then that and I think you're wasting your money.

DMN: A lot of people are wondering about rendering as it relates to codecs. What takes the most time -- is most of the work done in the combining of one shot with another? It used to be going to a codec took lots of time, and I guess it still does if its one of those asymmetrical codecs, like CinePak or MPEG-2. But now, is processing power so fast that getting to the codec is not what takes up all the time any more?

Bryant: Yes, to a certain extent. I think as soon as you come on line and you start doing uncompressed codecs, it's the easiest because you're not compressing it. But any time you do compression, the compression algorithms are getting so good, and they're being optimized for Xeons and Pentium 4 extensions, getting to the codec is not that big of a deal any more. Except for, as you mentioned, the more asymmetrical codecs like MPEG-2, where the motion estimator and your pre- and post-filtering is taking all the time, you're still slowing down. The more compression, the longer it takes to render. The quality is a big part of this -- I've seen really crappy MPEG-2 stuff that you'd never want to show, but then I've seen stuff that takes ten years to produce that you can't tell apart from HD -- that's how good it is. There's a tradeoff for codecs: The slower the codec, the better it's going to look. But you give up time. A lot of people are saying, for digital cinema and home video on demand, "So what if it takes ten days to entirely encode a movie in this codec? We don't care because the money in the back end is big, if we can get great quality to the home at a low bit rate."
[an error occurred while processing this directive]
DMN: Unless you're doing a live broadcast, because you don't have enough time to spend 25 hours compressing.

Bryant: Yeah, you'll go to somebody like Thomson a get a head-end that can do that on the fly, in real time. But you'll pay for it -- it's not going to come easy. It's like anything else. For most codecs, you can buy a hardware version that's going to cost you 10x but it's going to be real time, versus the non-real time, software based. If you look at the quality you can get with a software-based MPEG-2 encoder versus a hardware-based, the MPEG-2 software one just kicks its butt. Because you look at good quality at low bit rate.

MPEG-4 is coming around the corner, that's going to be low bit rate. You have Microsoft Corona, which is a low bit rate codec. At NAB, Microsoft showed me Corona, that was a 4.5 megabit stream of HD that looked pretty decent -- there were some color problems, but I kept having to tell myself, this is lower bit rate than what my DVD is, so this is pretty fantastic.

DMN: They're all getting ready for HD, aren't they, because it takes up such a tremendous amount of bandwidth? It has a very high bit rate until it's compressed.

Bryant: Especially for the Digital Cinema push, I think people are going to come up with their own codecs, and with that, MPEG-2 is one option, MPEG-4, Corona is another one. And you have all those other players out there. And the studios themselves say, the lower the bit rate, the easier it is to get to the cinema, but it's also easier to pilfer and pirate, so what are you going to do about protecting our assets?

DMN: And that's holding up the technology as well, isn't it?

Bryant: Definitely. That's holding it up more than anything else. It's like MP3s, the record company is freaking out because MP3s are going to take all their money. I can see why, because the quality I can get downloading an MP3 and burning it to a CD is just as good as my going out and buying it in a store. So what's my motivation?

DMN: And that just smashes the business model of the record companies.

Bryant. Yes. And unfortunately, I don't know how to fix it. That MP3 codec is so good, that it's a very difficult situation. I feel sorry for them, because I don't know how they're going to make money any more. I think the reason they still make money is because the saturation of people with Internet access is not that great, or people who go out and buy CD-Rs so they can burn their own CDs.

DMN: It might just be too complicated for everybody to do it.

Bryant: Exactly. But then if you have Steve Jobs and Apple, they're going to make sure that everyone can do this at home.

Prev 1 2 3 4 Next

Related sites: • Broadcast NewsroomDigital Post ProductionDigital ProducerDigital Video EditingDTV Professional
Related forums:


[an error occurred while processing this directive]