Comments

p@mast3rs wrote on 4/19/2005, 1:29 PM
Doh! Im sorry I opted for that extra gym class instead of Math. :)
Jay Gladwell wrote on 4/19/2005, 1:31 PM

Riiight... like I really understood that!

Matt you are, in the truest sense of the word, a genius. To those with intelligence similar to yours, I'm confident that was a excellent explanation. To those of us who struggle to balance their check book, you lost me after the third paragraph!

It was Greek to me!


busterkeaton wrote on 4/19/2005, 1:34 PM
Matt, how did you arrive at the square root of negative 1 again?
mdopp wrote on 4/19/2005, 1:44 PM
Wasn't April 1st 18 days ago ;-)
rmack350 wrote on 4/19/2005, 1:45 PM
Matt,

Thanks. Obviously it'd take some time to walk through this, but I'm willing to make the effort.

Printing now...Something to while away my evening tonight.

Rob Mack
OdieInAz wrote on 4/19/2005, 1:52 PM
Believe it or not, mathematicians have no problem with square root of negative 1 (nor do electrical engineers). An analogy to grasp can come from the world of project management. In a given example, there is the concept of critical path -- those things that define a project duration.

Consider that the render task is really a project.. You can juggle things around , improved performance on varioius sub-tasks, and maybe improve duration. Then agian, maybe not. If you significantly reduce the time of task "A", then perhaps something else becomes the limiting facto - a new critical pathr.

So here we have V5/V6, HT/Non-HT, Dual processors, Dual channel, processors, MoBo chipset, disk drive, NZQ, Cache on cache, ..... and you get the message -- you rmilage will vary!!
FrigidNDEditing wrote on 4/19/2005, 1:52 PM
well, reading this makes me see 2 things - one, it's been a while since I took algebra :)

2 - HT isn't all it's cracked up to be - that's for sure.

Anyway, I understand the whole thing, and it's what I've always "understood" so to speak. No complaints here - the times are improved in V6 for me sometimes just a small amount, but it doesn't seem to affect me too badly negatively.

Thanx for the hard work Madison
John_Cline wrote on 4/19/2005, 1:52 PM
That was GREAT! I'd like to see more of these types of articles.

John
Jimmy_W wrote on 4/19/2005, 1:52 PM
LoL, Now c'mon buster does he really have to explain that again?
Just look at c and you will = d but don't take away from l m n o p average. Whats not to understand.
DigVid wrote on 4/19/2005, 1:56 PM
"Even if we knew the specs of your machines to it’s last detail, we can’t possibly know or even estimate the “average” value of all these variables."


That's why there's a Mac... ;-)
TheHappyFriar wrote on 4/19/2005, 2:27 PM
This reminds me of when I asked John Carmack if he could use ATI Trueform with real time stencil shadows. :)
chaboud wrote on 4/19/2005, 3:06 PM
Dude.. I didn't write that.

If I had, it would have been entirely indecipherable.

Rednroll wrote on 4/19/2005, 3:06 PM
Nice break down Matt. I understood most of it, but the first part when you went from EQ0 to EQ1. If I substitute "1" in for C0 and then invert the bottom divisors and multiple I get:

T=(W+WR)/P and not T=W/(P+R).

I wanted to make sure these equations where not equal and you just did some further variable extrapulations so I set W=2, R=3 and P=4, and they're definately not equal. So I'm just a little confused on how you got EQ0 reduced to EQ1 as an equivalent.

Oh and BTW, the other equations sure do look like some C code to me.

Red
chaboud wrote on 4/19/2005, 3:19 PM
This document was written with order-of-operations considerations falling in favor of C syntax, so precedence is as follows:

Parenthesis first.
* and / next.
+ and - last.

You could write this as:

T = ((W / P) / C0) + R

Which, if C0 = 1, is:

T = ((W / P)/1) + R

Which is:

T = (W / P) + R

PossibilityX wrote on 4/19/2005, 3:20 PM
Me hope I make purty video some day, real good.
Rednroll wrote on 4/19/2005, 3:37 PM
Ahhh...thanks, the parenthesis help me out.

Oh yeah, and isn't the square root of -1, the imaginary number "i"?
chaboud wrote on 4/19/2005, 3:45 PM
What follows is, because it is a simplification, not entirely correct, but I'll attempt to draw a picture of what is happening for people who are trying to get a handle on this.

In Vegas, there are a few contributing factors to a render. For this example, let's take a DV render to MPEG 2 with a few effects:

The Vegas 5 engine views this as:
*Read and Decode some DV, then do some filtering and processing, then hand that output to the MPEG compressor.
*While this is happening, MPEG compression work would be done separately, on another thread.

The Vegas 6 engine views this as:
*Read and Decode some DV, then hand that to the engine for filtering and processing.
*While this is happening, do some filtering and processing, then hand that output to the MPEG compressor. This can be done on multiple threads.
*While all of that is happening, do the MPEG compression on another thread.

The costs involved in managing threads and switching between them are not negligable, and the gains from using logical processors in HT may not be enough to overcome the costs incurred through threading. In light of the dual-core offerings from AMD and Intel, optimizing for multiple physical processors shows great promise.

As was stated in the initial writeup, one project can not serve as an example one way or another. We have several projects and benchmarking examples showing performance gains with HT processors, and Vegas 6 shows markedly improved performance on true multi-processor machines over Vegas 5.
apit34356 wrote on 4/19/2005, 3:46 PM
rednroll, square root of -1, is an imaginary number .
apit34356 wrote on 4/19/2005, 3:51 PM
SonyChabout, "Read and Decode some DV", assuming you mean a certain number of "frames" based on frame's properties --> output frame properies
chaboud wrote on 4/19/2005, 3:55 PM
Yes, mostly...

The important thing to understand here is that the reading and decompression is threaded before the engine gets to composite, filter, temporally resample, and otherwise play with your video

There are times when the engine will have to wait on frames to be read and decoded, but this threading allows for the engine's requests to be satisfied immediately in many cases.

If you view "hand that" in my earlier post as someone standing between two workers and managing the work done by one and the requirements of the next, you have a picture of what is going on.

bjtap wrote on 4/19/2005, 5:22 PM
This is all well and good, if not understandable. I would like to get this down into simpler terms. As someone else asked quite a while back.... why can't there be background rendering as Pinnacles (Avid) Liquid Edition.... then would we need all this 'math'?
To me, it is amazing to apply effects, transitions, etc and watch Liquid Edition quickly render it out, or continue editing for a few seconds as LE does it's thing.
Thanks,
Barry
Rednroll wrote on 4/19/2005, 5:46 PM
"rednroll, square root of -1, is an imaginary number ."

Yes, Calculus at work here. In Calc you deal with "complex numbers" . A complex number is composed of two parts, the first part is the "real part" and the second part is the "imaginary part". It's usually shown in math form of (REAL + IMAGINARY), or {a + ib} where the imaginary part is designate with the letter "i" infront of it. So the square root or -1 is actually in the imaginary part of the complex number so it would be SQRT(-1)= {0+i(1)} or simplified "i".

I always wanted to be an engineer, so I could wear the hat and drive the train. My boss keeps telling me, I have to work up to it before I reak those benefits. I'm holding in there.
BowmanDigital wrote on 4/19/2005, 6:18 PM
Thanks for bothering to address these concerns, u so didn't have to but just goes to show how much u guys want to make us users happy!
apit34356 wrote on 4/19/2005, 6:48 PM
Rednroll, nice explanation. Complex number theory is just a starting building block in the math world of an electrical engineer. Laplace, fourier, series, boundary...etc... mathematics is "air" engineers live by in the begining. Most Programmers usually do not apply enought math to their work in sound or video design, leading to some bad designs and mysterious problems.