Forum Replies Created
-
Are you using a preset of some kind?
It is possible to start making random adjustments such that you create a file that is simply a non-optimized combination of parameters. The presets are usually the best bet for optimal compatibility.
TimK,
Director, Consultant
Kolb Productions,Adobe Certified Instructor
-
It’s not the percentage, it’s some particular point in the timeline.
In cases where I have issues like this, I will create a shorter range and export, and I’ll keep shortening the range and “zero in” on the spot if there is nothing else that’s immediately obvious to you.
I’d start by exporting the second half of the timeline…if that works, keep backing up the starting point until it falls over.
It may be a strange spot in a source clip that plays back well enough but has a slight issue with a complete decode…it’s hard to say.
TimK,
Director, Consultant
Kolb Productions,Adobe Certified Instructor
-
I’d echo Steve’s comments.
When your CPU is being used as heavily as Adobe’s encoding process (it uses pretty much every CPU thread it can acquire), everything else the computer is doing will be affected…
TimK,
Director, Consultant
Kolb Productions,Adobe Certified Instructor
-
The preview codec is set either by virtue of some setting attached to the sequence setting (DVCProHD preview renders to DVCProHD), or by the user when you make a custom sequence setting.
If the preview codec is defaulting to QuickTime at your office and is defaulting to MPEG I-frame on your laptop…is your office computer a Mac and your laptop is Windows?
TimK,
Director, Consultant
Kolb Productions,Adobe Certified Instructor
-
Just go into the interpretation settings in PPro and change the pixel aspect to 1.0, which is what it’s supposed to be.
Who knows where the wrong pixel aspect flag came from…but it’s easy to fix.
TimK,
Director, Consultant
Kolb Productions,Adobe Certified Instructor
-
It was a pretty small thing…but many people do transcode to these formats because they’re 10 bit as well as 4:2:2.
Minutiae aside, as I said, I agreed completely with the -substance- of what you were saying.
TimK,
Director, Consultant
Kolb Productions,Adobe Certified Instructor
-
Tim Kolb
March 17, 2014 at 8:40 pm in reply to: PPro CC – zooming out of a timeline kills performance, CPU load skyrocketsTwo items that are in play here…
First MPEG2 (XDcamEX) is far easier to decode than MPEG4 (H264 or in this case, AVCHD)…it’s just simply not as complex.
Second, Premiere Pro is working with a sequence that is wide open for decode…in FCP7, you could set up a sequence with the specific video decode settings (and of course you’d have to rewrap the XDcamEX footage as “mov” making it unusable outside of FCP…)and everything else renders…
In Premiere Pro, the application is looking down the timeline to see what you’ll be playing back and it may be spawning 2, 3, or more decoders to buffer the material up, and in the case of MPEG Long GOP, the frames are encoded and decoded out of order, so the buffer has to work in increments of 12, 20 or whatever # of frames…and in some cases where a decoder is a single-threaded operation, Adobe is spawning multiple iterations of the same decoder to occupy multiple CPU threads to be as efficient as possible…
So…while it does seem like a peculiar behavior to change buffering method based on the timeline’s zoom factor…comparing FCP7 and Premiere Pro CC responsiveness is difficult as the flexibility to do all the stuff that PPro can do doesn’t exist in FCP and does come at a cost, and systems with 5 year old CPUs will definitely show their age when any H264 format is used on the timeline…the same CPU setup on Windows would likely behave similarly.
TimK,
Director, Consultant
Kolb Productions,Adobe Certified Instructor
-
Tim Kolb
March 17, 2014 at 1:13 pm in reply to: PPro CC – zooming out of a timeline kills performance, CPU load skyrocketsXDcamEX and AVCHD are long GOP formats that need to buffer up to play. It sounds like the software must be trying to buffer in relationship to how much timeline you have viewable in the panel…which is a bit wacky, but I wonder if you’d see the same amount of slow down if you didn’t have two different heavy-load decode schemes trying to buffer up an entire timeline simultaneously?
I don’t do long projects as a rule, so I don’t really have a complex timeline to test this on Windows to see if the behavior is the same…it’s a curious behavior though.
TimK,
Director, Consultant
Kolb Productions,Adobe Certified Instructor
-
CineForm would technically be a “10 bit” 4:2:2 container, but I agree with both replies here. Shooting directly to a higher quality format in-camera would make a difference, but converting it after the fact really won’t gain you anything unless (as previously mentioned) you need a different format for your computer to handle the footage as FCP users would do with ProRes, etc…
TimK,
Director, Consultant
Kolb Productions,Adobe Certified Instructor
-
DNxHD is very versatile as an MXF wrapped file…and very high quality.
DNxHD in a QuickTime wrapper is a little less versatile.
CineForm is still more versatile than either ProRes or DNxHD in terms of format flexibility, color space, frame size…and CineForm even has a RAW and 3D version of the format (There are several levels of purchased versions of the CineForm codec that have some of the more specialized features).
TimK,
Director, Consultant
Kolb Productions,Adobe Certified Instructor