[James Poll]

Just a thought…

You don’t have “Show Audio Time Units” selected by any chance (under the sequence’s hamburger menu)? If that’s turned on, you can scrub and zoom down to the audio sample level, but video cuts and splices will only happen on frame boundaries, which may be either ahead of or behind where your scrubber is.

Good luck!

[James Poll]

Hi James,

Don’t know if you found a solution yet, but what I would probably do in your situation is the following:

1) Apply your grade across everything by using the adjustment layer.

2) Make a copy of all the untreated clips that make up the original sequence, and put them into a nest.

3) Put the untreated nest above the adjustment layer, and apply a long fade-out to it, which should then reveal the treated version underneath.

Good luck!
James

[James Poll]

Could you not just go under the “wrench” menu in your sequence and un-check “Show Clip Markers”? It doesn’t actually get rid of them, but at least you won’t have to look at them… which I gather is the idea?

[James Poll]

Hi Alessandro,

I was able to fix my crashing issue, but the visual feedback of the Trim looping seems to be either broken or removed from CC 2014.2.

For the crashing, it turns out that we needed to adjust a playback setting for Premiere to work with our AJA Kona LHe+ cards. In the “Playback” section of Premiere Pro’s preferences, under the “Video Device” area there is a “Setup” link for the AJA Kona card. In this setup box we had to make sure that the “Video Format” was set to “Match Control Panel” and *not* “Match Sequence”. Once this change was made, my crashing issues dropped to almost zero.

The broken Trim feedback is still extremely frustrating, but I work around it by using the “play around edit” function while in Trim mode, as this will loop the scrubber and give me visual feedback on my production monitor.

So far the system has been pretty solid, but we do suffer from other Premiere Pro bugs, like randomly occurring red frames and crazy flickering on clips that have Broadcast safe or (to a lesser extent) Three-way colour corrector applied.

Probably my biggest beef right now is the fact that I cannot trust Premiere Pro to export my video as I see it on the timeline. It has happened on several occasions that production staff have come back to the editor saying that there are red frames or other visual glitches in a video in the archive. When we check the sequence in Premiere, everything is fine. It is during export via the Media Encoder that these errors are introduced. As far as I’m concerned, the lack of “what you see is what you get” is a capital offence for a non-linear editing system. We never had any of these problems with CS6 – they all got introduced in CC. Had I known about all these glitches a couple of years ago, there’s no way I would have recommended that our company go with Premiere Pro, because the editor needs to have confidence that the software will deliver “what you see is what you get”. All the great funky features in the Creative Cloud (and there are lots of really great features) don’t amount to a hill of beans if I can’t trust my system to export properly.

Good luck!

[James Poll]

Duh, sorry, forgot to mention that Premiere Pro itself is at version 2014.2 – 8.2.0 (65) Build.

Thanks!

[James Poll]

I get this problem all the time, usually with files coming from an iPhone or iPad which uses VBR compression.

The only way I’ve been able to work around it, is to convert the source files to a new QuickTime file using MPEG Streamclip (https://www.squared5.com). Streamclip seems to be able to do the conversion without the audio drift.

Hope this helps. Good luck!

[James Poll]

I had a similar experience with PPro CS6. In my case, the denoise effect would actually work on exported material, but it would only pop in a couple of seconds after every cut (so you would hear hiss at the cut point for a second or two, followed by a quick drop to the noise-reduced audio). It was really annoying, because the noise kept popping in and out during playback of the final movie file.

It seems to me that the denoiser requires some “read-ahead” time to make the necessary calculations, and apply the noise reduction. When you play the clip on the timeline, it has time to read ahead and apply the reduction before you hit a cut point, but on export, it doesn’t read ahead and only starts to process *at the cut point*, which means that you have to wait a second or two before you notice any noise reduction.

This is just a theory (which seems to fit the evidence)… I don’t know if this is what is actually happening or not, and I haven’t had time to go back and explore it some more.

Has anyone else had a similar experience, or been able to work around this? It’s pretty stupid, actually… the denoise effect isn’t half-bad, but if it doesn’t work on export, then the plugin is essentially useless (as is Premiere’s export function, since you can’t count on your final export being what you see/hear on your timeline).

[James Poll]

Hi Steve,

Don’t know if this helps, but I’ve had similar experiences with slow exports to H264 when using Looks (and we’re on PrPro CS6).

Here’s what I do to work around the problem:

Don’t try to export directly to H264 from Premiere. Our sequences are built on our delivery codec, which is DVCProHD. With the entire timeline rendered, I export the sequence as a hi-res DVCProHD file, then turn around and drop that DVCProHD MOV back into Media Encoder for a conversion to H264.

Usually I am able to get a “fast export” of my sequence to the hi-res MOV, and the subsequent conversion to H264 is also quick, since you’re just going from one format to another, and nothing needs to be re-rendered/encoded.

Hope this helps.

[James Poll]

The sequences are 1/2 hour interview shows, so we have about 20 minutes of multicam in each episode (the rest is titles, credits, etc).

Because we need to do a final output to DVCProHD .MOV for delivery, we use DVCProHD sequences for editing.

Doing the actual multicam is not the problem, the problem is that when we add LUT Buddy and/or colour correction, we get red render bars, and the render takes a long time to crunch through.

My thought (and I may be wrong about this) was that – even though only 1 camera is “on air” at any given time – PPro is still reading all 3 video streams, and converting from either C300 or H264 (depending on the camera angle) to DVCProHD (the sequence codec), even though it really only has to convert 1 stream (whichever camera angle is visible).

I guess I could re-phrase the question to ask, if there was a way to commit or collapse (as we would say in FCP 7) a multicam sequence so that only the final chosen clips are used on the timeline, would our render times be significantly faster?

[James Poll]

Yes, we do get red render bars with the LUT Buddy. But even without any effects, it just seems that the conversion from C300 and/or H264 to the DVCProHD is taking an inordinate amount of time. This is why I was wondering if PPro was processing/transcoding all the streams of the multicam, even though only 1 is visible.

The system is pretty beefy. I don’t have the exact specs with me, but these are new Dell workstations, with the nVidia K5000 for acceleration, and we have 32GB of RAM and I believe it’s a 12 core CPU.
We’re connected to a SAN for storage, with a 10gig pipeline, so throughput shouldn’t be an issue.

I also notice that CPU usage seems quite low when rendering.