G
gothika
I run a Athalon T-bird with MMX that supports SSE2. Have an oler
t-bird cpu with it as well.
They did come in pre-builts specifically made for video editing.
Do most of the current AMD's not have this?
t-bird cpu with it as well.
They did come in pre-builts specifically made for video editing.
Do most of the current AMD's not have this?
G
gothika
Never bothered benching the two against one another.
I'd picked up a couple of AMD machines built for video editing and was
happy with their speed.
I have noticed that when rendering with alot of effect layers a
friends P4 seems a tad faster.
Still whether an AMD or P4 it still seems a slow go when doing the
final burn.
G
gothika
Win2k pro will take a gig of ram with no need to any hack work.
Heck 98se will take that much.(I have a PII super running 98se with
just under a gig.)
I'd advise sticking with the simpler setup of fast ATA for starters.
Many argue that ATA100 is sufficient. It may be on most systems.
On my main machine which came with ATA100 built in I got ocasional
frame drops when capturing Some DV formats.(Mostly full or DV-cine and
miniDV shot in full 16:9)
133 increased my capture rate substantially. ( 47mbs vs 34mbs with
100)
I've been seriously considering a dual machine for some time now, that
or a blade/cluster setup.
I'm going to wait though, when 64bit finally gets out with the apps
needed the dual chip machines should drop in price.
To really see the advantage now your editing software will have to
utilize hyperthreading.
Most low end apps don't at this time.
You'll have to spend big bucks to get software that'll take advantage
of dual chipsets, at least as far as I know.
Others here may be able to point you to affordable software for dual
sets.
I've looked at Avid setups as well as a blade system that blazed
through heavy render jobs, at a hefty price tag though.
If you're looking to build a first system best to keep a realistic
budget in mind and accept a bit less speed in the hardware department
and spend a bit more on better editing software.
I have several 1gig AMD machines that I HOPE to one day find the time
to cluster into a small render farm.
I just stay too busy these days.
J
JAD
Hmmm noise on the PCI....well since the PCI has only a sound card and
the SCSI card (AGP video if you want to include that) I would say
that's a nit-pick of a con. Frame dropping seems to be a point in
which all is concerned, It has never been an issue with my setup at
home nor any (MAC included) at the LAB. Not saying at all, that ATA
sata or any other type of storage solutions are not feasible. Problem
is, I have never( well once on a backup machine PIII) used any other
solution, so I should have added "with my experience, my opinion would
be"......
the SCSI card (AGP video if you want to include that) I would say
that's a nit-pick of a con. Frame dropping seems to be a point in
which all is concerned, It has never been an issue with my setup at
home nor any (MAC included) at the LAB. Not saying at all, that ATA
sata or any other type of storage solutions are not feasible. Problem
is, I have never( well once on a backup machine PIII) used any other
solution, so I should have added "with my experience, my opinion would
be"......
K
kony
Having both a mid to high-end sound card and *ANY* drive controller on the
PCI bus is enough to degrade performance of either or both. The question
is then if that matters, since there's little reason these days to capture
uncompressed rather than lossless, the bitrate can always be lower than
(whatever drive or interface you want). However for the best performance
for capturing, nothing beats southbridge-integrated SATA if it's a "PC"
platform. The 33MHz 32bit PCI bus may deliver a realized max of around
120MB/s or lower, if there is NOTHING else on the bus being used, so it
effectively cripples even the highest-end SCSI w/ 15K RPM drives, to the
point of being slower than integral SATA RAID0 for a one-way capture
scenario. Now if we were considering high request I/O server duty it'd be
a different story, SCSI wins.
K
kony
Nothing older than Athlon 64 has SSE2. Athlon Palomino, Thoroughbred,
Thorton, Barton, Duron Morgan (and maybe another Duron?) have SSE(1).
T-Birds do not have SSE(1) or SSE2. If yours does it is not a T-Bird.
J
JAD
I am not sure of all the sound solutions in the lab, Aardvarks
'Aark24'(?) on some of the PC's, very nice setups. I am unfamiliar
with the macs, I believe that they are integrated. I have the SB
audigy 2 platinum at home, pretty low CPU usage. This I purchased
mainly because of the inputs on the front head.
Interesting, where would I see this degradation? Would I be spending
hours in front of a 'benchmarker' comparing or would this be something
that is real world? Are we again talking of 'dropped' frames, poor
video appearance, or rendering time increases? My partners and I have
not come across any of this type of problem (degradations) with these
rigs. I am always up for improvements when it comes to quality of my
work and time spent wisely. I am not into ' look my rigs faster than
yours' scenarios though. Also, unlike a few of my cohorts, just
because we have been doing it this way for 15 years it 'must' be the
'only way', is not my motto ;^)
Thanks for the input
'Aark24'(?) on some of the PC's, very nice setups. I am unfamiliar
with the macs, I believe that they are integrated. I have the SB
audigy 2 platinum at home, pretty low CPU usage. This I purchased
mainly because of the inputs on the front head.
Interesting, where would I see this degradation? Would I be spending
hours in front of a 'benchmarker' comparing or would this be something
that is real world? Are we again talking of 'dropped' frames, poor
video appearance, or rendering time increases? My partners and I have
not come across any of this type of problem (degradations) with these
rigs. I am always up for improvements when it comes to quality of my
work and time spent wisely. I am not into ' look my rigs faster than
yours' scenarios though. Also, unlike a few of my cohorts, just
because we have been doing it this way for 15 years it 'must' be the
'only way', is not my motto ;^)
Thanks for the input
K
kony
The degradation is seen when the drives and interface method "would" be
capable of exceeding 120MB/s yet can't. Then it stands to reason that
seeing it would require 1) fast enough drives 2) large continuous data
stream 3) comparison of performance on a server with (other) traffic on
PCI bus limited, contrasted with PC 32bit 33MHz PCI bus with sound, analog
capture and/or other devices in use simultaneously.
I was talking primary of drive performance itself. Dropped frames and
rednering times are relative to the data rate needed. Data rate lower
than realized drive transfer rate potential wouldn't matter. Rendering
times will increase if the process is drive-bottlenecked rather than CPU
or other bottleneck... depends on what you're doing.
My partners and I have
IF your situation is one where the job is pushing the limit of drive
throughput on PCI bus then clearly a change in drives, interface, and/or
bus applies. A "my rig is faster than yours scenario" may be something
that gets stressed too often, but in some cases that's what it does boil
down too, no magic bullet other than specing out best modern config for
the job, or use of more systems.
G
gothika
Have to disagree on that. Every diagnostic I've every run(Sandra
etc..) clearly shows my setup as having SSE2. That was one of the
primary reasons I bought these custom builds.
K
kony
It is simply IMPOSSIBLE for any kind of "custom build" to result in a
T-Bird supporting SSE, period. CPUs support the instructions or don't...
check AMD's website.
If your CPU is a T-Bird, that is, a Thunderbird, it doesn't support SSE
and there isn't anything that can be done to make that Thunderbird support
SSE. _IF_ you really do have a T-Bird and those diagnostics claim SSE
support, they're wrong. Again, check AMD's website.
S
Stacey
gothika said:
SSE not SSE2. If you have some application that claims this, it's a bug in
the app. AMD has never had SSE-2- support in anything until the AMD64.
S
Stacey
gothika wrote:
That was the drive not the interface. Look at your numbers, ATA 66 can move
47Mbs a sec cause it can move 66Mbs at the interface, it's just those older
drives couldn't move that much data mechanically. My ata100 WD 80 gig moves
46Mbs no problem.
[root@stephe stephe]# hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 140 MB in 3.02 seconds = 46.35 MB/sec
It's more about rotational speed and disk density than interface for
streaming video.
That was the drive not the interface. Look at your numbers, ATA 66 can move
47Mbs a sec cause it can move 66Mbs at the interface, it's just those older
drives couldn't move that much data mechanically. My ata100 WD 80 gig moves
46Mbs no problem.
[root@stephe stephe]# hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 140 MB in 3.02 seconds = 46.35 MB/sec
It's more about rotational speed and disk density than interface for
streaming video.
S
Stacey
JAD said:
http://www.geocities.com/fotocord/raid.html
This guy didn't think this noise from his raid card was "a nit-pick".
Why introduce possible problems when the "solution" doesn't solve any
problems itself? Like I said when an ata33 drive could only move 10Mbs,
multiple SCSI drive setups were the hot ticket for video capture. That's
not the case anymore. That money is better spend on a faster CPU or better
software!
S
Stacey
Toshi1873 said:
Depends on the application and the effects being used. The "speed test" file
for vegas video shows a 2.4 P4 is -at least- 2X as fast as an AMD XP2400.
Also an AMD of this speed can't keep up to do real time preview effects
either while the P4 does it without a hitch.
Have you actually used both types of systems yourself with video effects
rendering or just repeating what you've read AMD fanboys ("most people")
claim? Maybe on a pre-SSE2 app there isn't much difference?
I'm not a fan of either platform nor do I push one or the other, only based
on price/performance for the application do I recomend a solution. 99% of
the time it's AMD, yet people try to argue AMD are good for video editing
to push AMD's for everything? I've used both using real world apps against
each other and I'd NEVER build an AMD system for someone wanting to do
video editing.. Then again some people seem to just hate Intel and will
push the wrong hardware on other people because of their views on this
subject.
K
kony
It's quite believeable that a P4 is 2X as fast with encoders optimized for
SSE2, but is it even slightly optimized for the Athlon or just SSE2 vs.
completely unoptimized? If the latter it's no wonder anything without
SSE2 will far poorly.
You might want to restate that as "never build an Athlon XP system", since
Athlon 64 does have SSE2 and can generally do much better as a result.
The key of course would be which application, which codec (and version)
since Vegas Video might be a great app but not what everyone wants to use.
Also there's the age-old debate of which codec is better for quality,
since it's not always the newest, SSE2 optimized version someone might
want to use.
K
kony
Not even SSE... Palomino, which came after T'Bird, was the first Athlon
core to support SSE.
E
Erez Volach
....
E.V
Any app. that utilizes HT can benefit from SMP.
E.V
S
Stacey
No idea how e code is written. Since most of the "turn key" video systems
are built with P4's, My guess is most of the software is written with this
in mind.
Well until I have a chance to test one, I'll stick with P4's for video
workstations.
Premier also is very P4 friendly and is the "cornerstone" for video editing
just like photoshop is for photography. The main issue seems to be the
effects rendering, not the MPEG encoding that differs in the processors.
People looks at MPEG encoding and assume these represent video work, they
don't.
The encoding can be done on even something like a PII 350 as this work
requires no user interaction, you just start it and go do something else.
WHo cares if it take 4 hours or 8 hours or 30 minutes? But when you are
editing, to see what the edits are going to look like, the effects have to
be rendered and if each edit takes 4-5 minutes to even see if you even like
that one edit's effect, it can take DAYS to edit a 30 minute video! Most
people aren't going to have the patience for that.
J
JAD
WHo cares if it take 4 hours or 8 hours or 30 minutes? But when you
are
Hehehehhe A typical week in the life of an editor...............MPG
is rarely used like you said, less your authoring for the web. .MOV
NTSC then converted is common, But even that also like you said,
makes up the smallest amount of time. Transitions and recoloring,
removal of things like street signs, business advertising on walls,
fire hydrants, that's the weird kind of stuff we do, takes weeks,
depending on the length of the clip or if its a whole production
piece.
Anywho, we have a MAC that is showing its age, put it out there to
replace it, at the next slow down period (where we can do without it)
with a P4 and a SATA setup. One thing that was ask was how many drive
can we install (they were thinking of redundancy)
are
Hehehehhe A typical week in the life of an editor...............MPG
is rarely used like you said, less your authoring for the web. .MOV
NTSC then converted is common, But even that also like you said,
makes up the smallest amount of time. Transitions and recoloring,
removal of things like street signs, business advertising on walls,
fire hydrants, that's the weird kind of stuff we do, takes weeks,
depending on the length of the clip or if its a whole production
piece.
Anywho, we have a MAC that is showing its age, put it out there to
replace it, at the next slow down period (where we can do without it)
with a P4 and a SATA setup. One thing that was ask was how many drive
can we install (they were thinking of redundancy)
A
ancra
Yes! Another advantage for the P4 is that video work are menial
tasks. The P4 is a fastrunning, but 'stupid'
, cpu. If the workdoesn't require 'intelligence' or complex decisions, it performs well,
because it will have full use of its high clock frequency. Performing
a simple operation on a large block of data, is THE thing that P4s do
well.
If you compare cpus on a price basis, AMD will do better of course.
But for video, P4 is still ultimately best.
I can imagine sound encoding to work out on more equal terms (since
it's a little bit more problematic than video). Provided we compare
with code also optimized for 3DNow+.
For the AthlonXP to be in the running for media encoding at all, the
code must also be optimized for 3DNow+. And I gather that's not so
popular as SSE2.
SSE2 and 3DNow+ performs twice as many operations per
instruction&clock as old SSE.
In 32-bit mode, P4 is still better. The reason is again that the work
is so straightforward, that clock frequency is a factor.
But again, I'd like to reserve myself on sound.
Only 64-bit media benchmark I've seen is 'Lame' on Linux64. And that
achieves an astonishing (~X2) improvement. But 64-bit SSE2 works
pretty much exactly like 32-bit SSE2, aside from having twice as many
registers to fool around with. So my guess is that if the code doesn't
make use of those, the situation will be similar.
To beat the clock advantage, AMD would have to define their own vector
instructions, rather than implementing Intel's. But it's also a
question of software convergence. 3DNow+ hasn't been a wholesale
success, outside games and APIs. As Intel too, will be switching to
more powerful, but lower clocked cpu cores, AMD will get their chances
in the future. Maybe on SSE4.
ancra
P.S. As you have already touched, the situation can be utterly
reversed in other cases, A-XP can have a 30-85% advantage over the P4
on '386/'387 -code. (I've seen 200%, but sofar, I'm assuming that
involved throttling on the P4). Also, the P4C is doing somewhat better
than earlier P4.