[Tim Kolb]

Hi Eric,

In my case, I’m currently running a Quadro 4800 for CUDA capability and I’m also running a Quadro 560.

The 4800m lights up a 24″ UI and a 30″ overlay/UI display and the 560 lights two 17″ LCDs on the flanks.

I have a pic here: https://tinyurl.com/68nmow5

(Hopefully I put this link in here correctly)

I started that system with a Quadro 4500 and a Quadro 540, so I’ve been running this basic configuration for a while.

You do have to watch the card firmware and that sort of thing with OSs in flux and all that… I had to make some BIOS updates and that sort of thing when I jumped from the 4500 to the 4800.

(Because they’re Quadro professional display cards, the tech support I received from PNY certainly streamlined the process).

Otherwise there was really no issue.

(I’m actually not certain you retain all the display outputs as live if you use an SLI link…but I’m not an expert.)

TimK,
Director, Consultant
Kolb Productions,

[Tim Kolb]

[Alex Udell] “…you said it much more verbosely.”

🙂

I get that a lot…

However, i am never accused of being vague.

My only thought would be if the client is somehow connected to terrestrial broadcasting and they have some desire to have the frame count reflect drop frame timecode…

But, my earlier post asks the same thing…I would think that 30fps would be far simpler.

TimK,
Director, Consultant
Kolb Productions,

[Tim Kolb]

Can you “trim” the clip in QT Pro and save it in two pieces and see if the repeated audio is still there?

The QuickTime format is interesting…it starts out by allocating room for an index file…then, when the clip gets long enough so that the index file is full, but it’s “land-locked”, QT makes a slot for a new index file further into the clip and first migrates the whole index file it created initially into it (filling it halfway immediately), then adds the data to it as necessary, and this process repeats as necessary as the continuous clip gets longer…

(For very long QT captures, those successive index file “migrations” get pretty large…)

I wonder if there is a new index file there that somehow doesn’t bother FCP or QT, but throws PPro off because it has a slight variation…or defect?

Do you have other long DV clips that behave the same way? Is it possible to do a test? Also…are you using the Kona card in this process at all?

Keep in mind that QuickTime is still principally 32 bit and the fact that CS5 being a 64 bit app can even deal with it is a feat of adaptation. On the Windows side, Adobe had to write its own QT frame server to act as a go between so that 32 bit QT codecs can be used by the 64 bit applications. I wonder if whatever special accommodation Adobe had to make on the Mac side is suddenly facing some pointer in the index file that it doesn’t fully understand?

I’d be curious what you find.

TimK,
Director, Consultant
Kolb Productions,

[Tim Kolb]

[Bob Dix] “Ps.And , yes we now have serious processing power with a new i7 Quad-Core Professional WorkStation Server Processor designed for CS5”

That’s great, but your question is regarding Premiere Elements…version 4.

The version comparison from Adobe is here:

https://www.adobe.com/products/premiereel/upgrade/?view=compare

The system requirements for version 9 (current version) is here:

https://www.adobe.com/products/premiereel/systemreqs/

Since I see no evidence that Premiere Elements 9 is a 64 bit application, I assume that version 4 must not be either…therefore it doesn’t matter how much RAM you may have, Premiere Elements as a 32 bit app is limited to 4 GB max.

It’s possible that there is an issue with how it handles the H264 files (since it’s basically foreign for the software so it’s depending on outside media components like QT to interpret the footage) and it hits its memory ceiling?

I have no idea…

The basic limitation is that the software was never tested with a format that didn’t exist when it was released, so I’d guess there is no official line on it…and Premiere Elements being a 79.00 USD program is likely upgraded without much hesitation by most users, whereas it takes a bit more to upgrade professional applications, especially when they require hardware upgrades as well…

I’d say you’d probably eliminate lots of headaches by getting current at least… No software company supports legacy applications 4 versions back…it’s just impossible to do so.

The chart shows that Premiere Elements 4 does burn to Blu Ray though…but I don’t know what it will encode. I did some training for Elements once upon a time, but it was version 7.

TimK,
Director, Consultant
Kolb Productions,

[Tim Kolb]

[Ann Bens] “Put in a cheap Nvidia which runs on the same driver along the main nvidia card and you still will have your 3 monitors and MPE hardware.”

Yup…just like Ann said.

I run 4 displays with one NVIDIA CUDA capable Quadro card and one older Quadro card. Works fine.

Keep in mind that CUDA acceleration assists with edit preview through effects processing during editing. (The CUDA accelerated effects are marked in the Effects Folder)

If you have straight video clips on a timeline with no effects (color correction, transparency, position/scale, etc), there will be no difference in performance with the way CUDA augmentation is implemented at this point.

Video decode is done on the CPU (video codecs are all currently coded to run this way so it isn’t some “limitation” imposed)…so CPU core count and torque are still key, but CUDA effects augmentation definitely helps as how many of us edit with no color correction or any other effects?

If you plan on using Premiere Pro to edit, you’d run into limitations pretty fast as any effects that the CPU has to handle and process hobbles its capability to decode video streams…

TimK,
Director, Consultant
Kolb Productions,

[Tim Kolb]

Not sure what you’re looking for here…

Premiere Elements 4 was a 2007 release…the Canon 5D MkII didn’t even appear until a year later…and MPEG4 support was only introduced in Premiere Elements designed for AVCHD (a much more likely consumer video format considering Premiere Elements is aimed at consumers for their personal media), which is very low data rate compared to DSLR, which is up around 50 Mbits/s.

PPro CS5 handles DSLR H264 (H264 is a subset of MPEG4) pretty well, but you have to have some serious processor cores to make it usable.

I think it’s unrealistic to expect Premiere Elements 4 to handle DSLR footage…the other formats mentioned are either MPEG2, or DVCProHD…both far easier to process…not to mention they existed when Premiere Elements 4 was written, which is why they’re supported.

TimK,
Director, Consultant
Kolb Productions,

[Tim Kolb]

I would personally choose a 23.976 frame per second edit timeline and import the PAL projects…then I would interpret the PAL (25 fps) material to 23.976 fps, which will be better and more accurate motion representation for you. I’d allow the top/bottom crop versus scaling unless there is really critical content on those extreme borders…

Then, you can export that material at that framerate for an NTSC-compatible MPEG2 file. (often used for feature film encoding when shot on film at 24fps)

25fps to 29.97fps conversions are a pain and the motion compromise, particularly for an animation company would be unacceptable in my opinion.

TimK,
Director, Consultant
Kolb Productions,

[Tim Kolb]

[Alex Udell] “Isn’t 29.97 short hand for “drop frame time code?” which is a method of counting frames, not a method of drawing them?”

Drop frame timecode was invented to accurately count elapsed time for 29.97 frames per second…that’s why drop frame timecode exists.

Video frame rates were originally set up to the electrical system the television system was using…The USA (as well as other countries) had a 60 Hz power grid so 30 fps (60 interlaced fields) made a nice synchronization and it just minimized the conflicts between frame refresh and power frequency. PAL is 25p/50i because the electrical system in the countries that adopted it was running at 50 Hz instead of 60 Hz. (PAL also has 100 more lines of resolution…France actually broke away with SECAM and were experimenting with broadcasting 1000 line plus images right after World War II…but that’s a story for another time.)

When it came time to add color to black and white in the NTSC… (PAL standards were established later and therefore were better prepared for color images and until the recent advent of digital television, PAL SD images simply slaughtered NTSC SD for accurate, high quality color rendition…but once again, I digress)…a compromise had to be made if that huge installed base of Black and White televisions were not to be made instantly obsolete. Americans may be the most backwards compatible culture there is in some of these areas (some would say that “compatible” is not a necessary component to that description), and TV was one of the biggest examples.

In order to create color images that color TVs would see, but maintain B&W images that older sets would see, the color would have to be a “layer” that the black and white sets could simply ignore. If you look at your waveform monitor while looking at an analog NTSC signal, you’ll see that small vertical rectangle that straddles the line at 0 which comes in between the frames…that’s the “burst”…which is the modulated color signal. If you look at a waveform and see no burst, the image you are viewing will be black and white as the “color layer” that gets laid on top isn’t there…

Well…this color information was…more information. Since the outgoing signal couldn’t simply be structured as a color signal natively, the color info was added to the information stream…which took some space. Since the FCC wasn’t willing to re-issue broadcast licenses for a “channel and a half” of band-width…the solution had to be something done serially.

Slowing the frame rate by 3/100ths of a second allowed the necessary space to stick in this murky color overlay so that it could be used by color sets, but the framerate was still usable by the existing 30fps black and white sets. It’s why “analog component video” in NTSC terms is still one Y’ channel (the black and white signal) and the metaphorical longitude and latitude color coordinate system “Cb and Cr” (digital) and “Pb and Pr” (analog…Sony also labels them as R-Y and B-Y) to add a given hue and saturation to each luma pixel (SVHS separated composite into “Y” and “C” in the cable, but it was still just a more cleanly handled ‘composite’ signal) as opposed to an RGB additive system, which would store the information with far better quality albeit a higher data load, all things being equal…

The problem with 29.97 frames per second is that you still need 30 frame numbers to account for the images that occur every second, but you end up with an accumulated error…about 3.6 seconds every hour, amounting to well over a minute a day. Mistakes that would happen because of the error could cost lots of money in botched air slots, etc. A minute is two commercials and each commercial is revenue for the TV station and when it comes to money…broadcasters respond.

By removing (“dropping”) the first two frames (XX;XX;XX;00 and XX;XX;XX;01) from every minute EXCEPT each tenth minute, you create an incremental correction that keeps the studio clock and SMPTE timecode on the same page throughout the broadcast day.

When it comes to web-based video, I have no idea why the OP’s client specified 29.97 other than they have some old TV dog like me who has no clue that the web doesn’t use fractional frame rates since there is no “color under” in Flash or H264…therefore I’d think deploying a video on the web would favor 30 fps even…but there may be some reason why the client uses DF timecode internally or something.

If you start the program out as being broadcast on television in a formerly “NTSC” system (there is no NTSC and PAL in HD, only framerates, even though some professional equipment manufacturers still label their stuff that way)…then you have to have 29.97 and DF timecode because even though we no longer have a need for the stupidest video framerate decision ever made (ooops…did I type that out loud?) as digital television no longer needs to allow for this…we have to be the most backwards compatible culture ever…

Therefore the framerate compromise we (NTSC countries) made in 1953…still haunts us today.

Don’t even get me started on why American NTSC black is 7.5 IEEE gray…

It may sound like I’m old and cranky, but really…

oh, excuse me…

I need to get my walker over to the window and yell at some kids on my lawn…

TimK,
Director, Consultant
Kolb Productions,

[Tim Kolb]

So…the key source is a nested sequence, or a ProRes clip?

…or is the trasck matte inside the nest sequence and the issue shows up when that sequence is placed in a new sequence?

Have you tried a simple, static matte, just to see if the track matte behavior is consistent whether the key matte source is moving or still?

Are you using alpha or luma?

(…and you are, of course, re-targeting the matte video track in the effect when you move the matte, right?)

TimK,
Director, Consultant
Kolb Productions,

[Tim Kolb]

Why is the file returning to 30.00fps? Are you trying to pick a preset after you’ve setup custom parameters?

(29.97 or 30.00 may make a difference in some web deployment situations…but I would think those situations would actually favor the nice round 30 fps as opposed to the analog-television borne 29.97…)

TimK,
Director, Consultant
Kolb Productions,