[Tim Kolb]

In order to be of much help, I’d need some of my other questions answered. Does the media fill the screen? If Premiere Pro sees it as being as small as you’re saying, it wouldn’t…

Also…is your QT up to date? That makes a big difference.

I used ProRes on Windows in Premiere Pro CS4, but I never did on a Mac. With CS4 being two…and nearly three released versions back, it’s hard to troubleshoot as there simply aren’t as many people running it anymore to try to reproduce the problem.

TimK,
Director, Consultant
Kolb Productions,

Adobe Certified Instructor

[Tim Kolb]

Yes…the QuickTime player does the same thing to both clips…WMP needs to use QT to play the .mov file, but uses it’s own MP4 decoder to play the H264 clip.

I suspect if you get a player like VLC, it will be the same as Windows Media Player.

The odd thing is that the “spike” version is what most non-QT players would see…I don’t want to say that gamma value is “right”, but certainly the gamma shift that happens in QT seems to belong only to it.

I did some web classes not long ago that specified a QT H264 file for distribution…my stuff looked nicely saturated and dynamic…right up until I put it in QuickTime…it appeared the color all went out of it, but what is actually happening is a well-known QT gamma problem that’s been around for a long time.

If you search “QuickTime gamma shift” on Google, you’ll get more results than I can reasonably take Cow server space for.

At least you’ll see what it is and how others deal with it…lots of different approaches.

TimK,
Director, Consultant
Kolb Productions,

Adobe Certified Instructor

[Tim Kolb]

thanks Tom, yes…I read through it from your initial link in the thread. There are several discussions overlapping and it takes a bit to connect the dots.

I understand what the explanation is, but I do this relatively often (not with QT or ProRes of course as I’m encode verboten on Windows) and while there isn’t the advantage I’d like to see…there is certainly some.

It seems to me that perhaps we need to request a feature that simply acts as a “jumper” from the preview files to export. You’ve created the files already…

It’s probably also relevant that Adobe, like most vendors, have had to stay with QT 7.x for their QT interaction, which is 32 bit. on Windows they actually run their own application in between as a kind of frame server to get 32 bit QT to run in 64 bit PPro…I have no idea what they do on the Mac.

This kind of workflow hasn’t really been focused on by Adobe as they’ve been heading in a completely different direction of course…so it will take some urging.

TimK,
Director, Consultant
Kolb Productions,

Adobe Certified Instructor

[Tim Kolb]

I can second the endorsement of the JVC Verite monitors…they’re quite good.

If you’re looking at displays in general, typically an LCD with an LED backlight is a good starting point. Even on my (relatively) inexpensive laptop, the LED backlit display is rated for 95% of visible spectrum (75% should be better than almost any cold cathode LCD panel, thought the JVCs and the Flanders displays do a hell of a job of getting a visually accurate image).

Having a video I/O device from AJA, or BlackMagic, or Matrox is a must if you need to get to videotape as well…

On the source panel question…you can either route the video frame out to an output device (like a video I/O card, or even a display on the system…I have four displays). You can also drag the program panel to a system display, not making that display the “video output” if you will but maintaining it as desktop with the program panel and have it live there if you’d like…sometimes nice if you want action safe marks up…that sort of thing.

Lots of options…

TimK,
Director, Consultant
Kolb Productions,

Adobe Certified Instructor

[Tim Kolb]

Yes, I know…and it’s Adobe’s corporate philosophy that nothing should be transcoded intermediately just as Apple’s is that everything should be transcoded to ProRes…

Let’s be honest, there are situations where either approach is just not adequate, efficient, or a good fit. There are advantages and disadvantages to both and i don’t advocate one way of thinking over the other if the situation you have calls for an alternative.

Sure, it’s not like a “smart render” direct transfer of the frame material. Adobe-designed preview files overall to be just that, and that’s why they default to fast, small, and “good enough” MPEG 2 I frames. However, FCP users can create a mastering workflow by setting up sequences for it and specifying the preview render codec, thereby generating preview files in that codec.

But the effect will scale depending on what you’re doing with the footage of course. Heavy effects should be a substantial difference in encode time if you’re using preview files as the single frame transcode will still be quicker than re-building all the effects…

If you have a 30 second spot, it might be difficult to get much of a delta, but there is a difference.

What sort of tests have you done? Are you strictly outputting to a master clip? Are you feeding a transcode process? (edit timeline to H264…that sort of thing?) Is the source material ProRes already?…or is it some camera format and you’re ‘previewing’ to ProRes?

I’d be interested in knowing more about this as it seems like some of the FCP>PPro hurdles are real, but some items seem like they simply stem from not being able to think creatively about how to use the feature set in PPro in ways that might be originally unintended, but would still meet many former FCP user’s needs…

TimK,
Director, Consultant
Kolb Productions,

Adobe Certified Instructor

[Tim Kolb]

[Philipp Hampl] “and surely hope cs 6 will solve the problems (e.g no external monitoring when working with codecs other than those which are cuda-supported! That means: whether monitoring or mercury engine – and as prp is a resource eating monster you need the extra speed -at least on a Mac!!); but untill that: not “pro” enough.”

…this statement is incorrect.

There are no “CUDA” supported codecs or unsupported codecs…compression/decompression is done on the CPU…that’s not Adobe, that’s every company who has created a video codec…

CUDA helps in a variety of ways with general workflow in that it handles much of the scaling and effects work, freeing up the CPU to be able to concentrate on the decode/encode activities…which does help you play back video of course…but it’s secondary to the transfer of the other functions to CUDA.

When you say “external monitoring” I assume you mean an I/O card like AJA or Black Magic?

You can create a sequence for these cards and put any sort of media you want on it, but those cards interact with the computer through the PCIe buss…the motherboard. CUDA accelerated effects and functions that happen on the display card, and need to be piped back to the motherboard to go out the card. The bottleneck is being attended to by the hardware vendors and Adobe, but it has nothing to do with codec support within CUDA.

This isn’t an Adobe restriction…and there’s been some progress, but overall this is a computer architecture situation that is evolving. The CUDA processor cores are not on the motherboard (unless you are running a Tesla system), they’re on the display card.

I can slap a 4K RED file on a Kona sequence and see the images come out on the HDSDI monitor (I’m on Windows…so Mac may have different circumstances), it’s just that it isn’t as fast as running in non-I/O mode because of the frame back haul through the motherboard.

I understand what you’re attempting to say, but this is how some of the misinformation about how PPro actually works gets started. With so many people migrating from FCP, it makes it very difficult for them to sort out what’s real…and make an informed decision.

TimK,
Director, Consultant
Kolb Productions,

Adobe Certified Instructor

[Tim Kolb]

What are you viewing the clip in? Typically QuickTime’s gamma issues start to play a role in some of this…the “spiked” version might be what you actually have, it’s just that QT player doesn’t display it that way…

Are you on a Mac? Windows? How are you viewing your results to compare them?

TimK,
Director, Consultant
Kolb Productions,

Adobe Certified Instructor

[Tim Kolb]

[Tom Daigon] “” The ‘Use preview files’ option in PPro is exactly that – if there’s a preview file, it decodes the frame out of it, & re-encodes it into the final file. So while it’ll help in (non-CUDA) effects heavy compositions, it also incurs a generation loss. Generally, we don’t recommend using it (hence the default to off) unless you really are sure that’s what you want.””

I have several custom sequence configurations where I use CineForm 10 bit as my “preview” codec. It makes huge preview files, but I can check the “use previews” encode box when I output with no more loss than FCP would have with a ProRes timeline…and on a Mac you can simply set it up with ProRes in the same way.

As far as the “time here vs. time there” comparison…I think the ratio scales the delta in the two workflow concepts. If you have a high shoot ratio project, transcoding everything on the way in will still take longer than it would to simply encode the final, edited timeine.

I suspect the ratios become dependent on how well-configured your system is after that…

ProRes workflow is great because it runs well on a wide variety of configurations whereas decoding H264 DSLR or AVCHD in multiple streams and computing color correction, etc is a load for the system.

There are a lot of user-definable elements to PPro that new users don’t know about that causes a lot of inaccurate recommendations on workflow inside PPro.

(…and I have no doubt this was an Adobe person who said this BTW. They know what the designed pipeline idea is, but the software guys don’t often understand what some of the conditions are “on the ground”.)

In the case of FCP users coming across, this can be a relatively easy process from a block-diagram point of view, but you just have to rethink a couple things in PPro and get it set up to run the way you want it to…it has been and remains more flexible from a workflow and pipeline standpoint than most realize.

In my experience with PPro, I find that traditionally users have not been willing to invest the same kind of resources in building a machine to host the software as Avid or FCP editors do. If PPro has hardware resources, it performs rather well in my experience for an application as wide and deep as it is.

As far as hardware interaction…I suspect if you really look at these vendors, you’ll have to admit that the effort they’ve invested in FCP has appeared to be far greater than they’ve invested in the Adobe side of things for years running… I work closely with several and I think they’ve made Premiere Pro a lower priority than FCP based on the numbers of FCP users in the market for their product vs PPro users in the past…but that is shifting…and fast. PPro (and perhaps more accurately, “PPro’s ecosystem”) needs to catch up.

As far as stability…everyone’s experiences are different. I’d say that PPro’s everyday bread-and-butter timeline editing tools ar not as refined as Avid’s…that’s been Avid’s wheelhouse from the beginning. I do think that Adobe’s pipeline architecture has been a priority and the way they handle digital media has been their focus, and i think they have the lead in that area…now the editing functionality is getting more attention, which is good.

TimK,
Director, Consultant
Kolb Productions,

Adobe Certified Instructor

[Tim Kolb]

So it was AVCHD?

You did…or did not convert to 1280×720? You said “didn’t” but seemed to mention it for some reason…

If these files are uncompressed, you be running about 7.5 GBs per minute…yes? 1280×720 uncompressed would be about 3.5 GBs per minute.

Any files that play back in CS3 should play back in CS4 unless you have one of these freeware codec packs installed…several of these codec packages hose up multiple things with video editing sofware.

My recommendation would be to use MPEG Streamclip to convert the files to XDcamHDEX MPEG2 footage or something like that so it runs properly if you are really running into an issue. CS5 handles AVCHD pretty competently but CS4 just wasn’t optimized for it.

CS5.5 is current for a couple months yet (Adobe has made their update calendar public knowledge), so CS4 is getting pretty long in the tooth in computer software years… particularly with what Adobe has been doing with development. If you aren’t staying with CS4 because you are restricted to a 32 bit machine at this time, I’d recommend considering a jump.

Let me know if any of that is helpful.

TimK,
Director, Consultant
Kolb Productions,

Adobe Certified Instructor

[Tim Kolb]

I think you’ll find that the Premiere Pro user culture hasn’t developed the same way that FCP’s did…very few of us could make a living doing only Premiere Pro training/blogging/etc in the past. Lots of users but a completely different vibe on wanting that sort of peripheral support/development, or how ever you’d like to characterize it.

It’s starting to evolve as the influx of FCP users is pretty heavy, and of course they bring their desire for this type of ecosystem.

Adobe has been making very concerted efforts to try to help some of this start to grow.

TimK,
Director, Consultant
Kolb Productions,

Adobe Certified Instructor