I have no ability whatsoever to shuttle the Source or Sequence monitors. I only get an update when I release the CTI. And not only that, the update takes a second or two.
That seems a bit extreme, but blame the codec, not the program. PPro will cache frames after an initial play-through or scrubbing, but it shouldn't be that laggy.
Is this how FCPX does it? I'm intrigued by their skimmer, and I wonder whether it works on Long-GOP; and if Apple can skim or shuttle, can't Adobe?
Not sure, but isn't FCPX transcoding in the background?
If this is the way Pr handles Long-GOP, I'm going to go back to transcoding it all before editing, and start ridiculing the idea of native editing in Pr.
It's hard stuff to edit, period. I don't think there's any need to take such a hostile attitude, however. My system works "fine" with DSLR footage, though it takes far more of a toll than DVCPRO HD and similar sources do. I'm on a PC, though, so I can't give you any specific tweaking tips for a Mac. The bottom line is that it shouldn't be that laggy on your system, so something else is going on.
I don't have a CUDA card installed. If I got one, could I shuttle like I can with intraframe sources?
Nope. CUDA and hardware MPE have nothing to do with decoding or encoding--that's all CPU.
Thank you, Colin. I do blame the codec. But, the experience I reported here is not exaggerated.
I didn't mean to sound hostile, but I do look askance at claims made by companies that are misleading. While yes, it's true that one can edit natively, the downsides to doing so are rarely stated. And if the overall experience takes longer, then the increased productivity claims due to native editing are deserving of critique.
I do not know if FCPX transcodes in the BG. I was hoping somebody could answer that for me. I suspect it does, and that would certainly account for the awesome skimming that some are raving about.
After I posted, I noticed a very similar thread about lagging with h264. So, I know I'm not alone. And I do apologize for starting a similar thread. But, I think my question was answered long ago, with my experiences with Long-GOP and FCP: Long-GOP sucks as an editing codec. It's not a suitable editing format, and probably won't be until we have peta-Hz CPUs to decode it instantaneously.
I have edited a lot of XDCam EX, which is another dreadful Long-GOP codec, in FCP, and I've not had the same issues of lagging, or inability to shuttle with picture, and I'm just trying to figure out what's going on here.
I just imported some XDCam EX into Pr, and although the shuttling isn't as smooth as with ProRes, it is updating regularly, and much more so than with the h264. Again, this points to a weakness of h264.
You said that "PPro will cache frames after an initial play-through," and that does seem to fix the problem. That's good to know. But, I like to throw all my b-roll into one timeline, and shuttle that to look for shots. Some times, that's a couple hours worth of footage. The idea that I have to play it all in real-time every time I launch the app before I can shuttle efficiently it is a bit daunting. And that would lead me to believe that transcoding to intraframe is probably the way to go, and give up on (or ridicule) this idea of "faster DSLR editing," as is claimed on the Adobe site:
"Production Premium, with 64-bit performance on Windows® or Mac OS, is simply faster and more efficient than any other software for DSLR video production."
This actually may be true. I imported the same h264 into FCP7, and it sucks there as well, although the updating in the Canvas is better than in Pr CS5.5. And the first time I tried to edit h264 native in FCP was the last time: it was a major crash-fest. While this claim may be true, it's like claiming my sister is less ugly than yours.
I can shuttle all kinds of formats in the source viewer and the program monitor, AVCHD, EX, HDV, I'm on a Mac Pro 2008, even works on my MacBookPro.
Though sometimes, Premiere Pro has to 'stew' a bit with the sequence open before it's responsive. Sometimes it indicates what it's doing in the lower left border of the sequence pane, or lower right side. Sometimes it needs to load media fully, or produce 'pek' files before things work smoothly, sometimes it just seems to need to sit for a while and doesn't tell you why. Sometimes I get into this state and it doesn't want to come out of it, and a restart of the Mac fixes it. Sometimes I run Cocktail and clean out system cache files, then restart, and this seems to help.
I usually do get a 1/2 second of delay before the playhead starts playing, this happens most of the time, I think it needs to decode the video and put it into a buffer, that is annoying and I'm wondering if it happens with both Mac and Windows PPro.
What you have described happens with the Multicam monitor and the reference monitor, neither ever gang real time with the program monitor, even when they're set to ganged. After stopping the sequence, they 'catch up'. This should be improved, and is an area were FCP 7 is superior.
BTW, FCPX normally does transcode files, but this can be set to on or off on import, and it has the ability to play long GOP immediately, even before transcoding. When importing the file you have the choice to transcode it. However where those files wind up is set by FCPX, which is bad. I think the theory with FCPX is to not keep you from editing the files immediately, but to transcode them when it can, and then the editing experience has the ability to become much smoother, especially when the project gets complex.
That being said, the ability to import native files of all types and immediately edit rather than going through the whole transcode process is really a timesaver and disk space saver for me. The original files remain in their original locations, and can remain pristine and untouched by Premiere Pro (if you have that set) and Premiere Pro creates a companion meta data file for the files in a location of your choosing, sometimes next to the original file, or somewhere else. This is smart and versatile. Premiere Pro handles this better than FCP or Avid, in my opinion.
I think as CPU's power increase and use of powerful GPUs becomes more common, the need for transcoding will go away, and this is a good thing. It's much better to use the original source, one less generation, full use of the original file without any additional loss of color or latitude, etc. PPro has it right here.
Keith, thanks for that additional info.
What seems odd to me is that if I load an h264 clip in Quicktime Player, it doesn't shuttle smoothly, but it maintains a picture, and it updates periodically, much more than what I'm seeing in Pr.
I expect that the NLE "should" offer equivalent performance to QT Player when shuttling.
If I'm not getting it, then it seems to me that in this case, the NLE is at least somewhat blameworthy, or as I stated in my OP, I'm doing something wrong, or my settings are wrong. I'm seeing this lag in a Sequence I used New Sequence from Clip. So, the settings should be correct, as I understand how Pr works. I'm still learning.
You did confirm my suspicions about FCPX and transcoding, because that's the only answer that makes sense.
I have viewed AVCHD in VLC, which is the only app I have that will allow me to view it before importing into an NLE. And that is one highly compressed format. I don't have any footage on my system to test with Pr. I was using MC at the time, and of course had to turn it into DNxHD in order to do anything with it. But, I'm imagining that the AVCHD experience in Pr is probably much worse than h264. Can you confirm or refute?
I'm still coming to the conclusion that I should transcode before editing. I'm not concerned about drive space. I have lot's of that. I'm more concerned about wasting time.
I have learned that I can transcode to ProRes using two instances of MPEG Streamclip running four processes, and get my transcoding done fairly quickly by maximizing my eight cores. I separate my original files from the transcodes, and have them share the same file names. So, I could edit with the transcodes, and do my final rendering with the original files, just by doing some voodoo in the Finder when the app isn't running. This is what I did in FCP and AE, and I should be able to do the same in Pr. I was just hoping it wasn't necessary.
Really, for 5D or 7D footage, you don't need to transcode with Premiere Pro. I edit that footage all the time with a bunch of other codecs too, sometimes a 5D, 7D, AVCHD 60P, EX all running in a multiclip, and don't usually experience what you are seeing.
AVCHD plays about as well as 5D or 7D, maybe slightly more lag. I actually use a 60P version of AVCHD which I think is more stressful on PPro and it's fine for the most part. BTW, AVCHD is using H.264 encoding, the AVCHD denotes all the extra files that surround the .MTS files inside the AVCHD 'wrapper' and it's what Blu Ray and all kinds of AVCHD camcorders use. When you bring a AVCHD directory into PPro, it strips out everything and you wind up with those .MTS files.
I use the same 'selects' technique as you. I'll drop everything shot on a timeline and then do selects. Sometimes I'll sync a bunch of footage together (using PluralEyes -available for FCP and PPro) and do selects on a variety of shots. I scrub through 'virgin' shots to do this, and I can do it all day. Occasionally there will be a pause before the new clip appears in either the source viewer or program, like PPro needs to fill a buffer, but for the most part it's pretty smooth. If I'm doing a bunch of disk access in the background with other apps things bog down, and sometimes I'll notice this and I'll notice that I'm doing some background copying or whatever and I'll stop that and then PPro picks up.
I do have very fast eSATA RAID connections running around 200-250MB/second on 5 different separate drives.
Also, I think that where your 'media cache database' and 'media cache files' (check PPro prefs) are stored should be a fast drive with a fast connection. I use my fastest drives for that.
On the Mac, use Activity monitor to see if some other non-PPro process is taking up cycles when you're trying to shuttle, this would result in the problems you're seeing as well.
You have the ability to adjust the playback resolution of both the source viewer and the program viewer, it's a little menu in the right top corner of those panels. Adjust it to something other than what causes you problems. Intuitively having 1/2 or 1/4 would seem to make it work better, but sometimes having it full works better, even if the panel is not big, especially with H.264 encoded material.
BTW, Quicktime player is very bad playing back H.264 anything, the underlying engine is just not built for it. However, even on my Mac, which is not as fast as yours, QT plays back native 7D files fine, though scrubbing is not great. If you want to see how Premiere should play back on a Mac, use the free Movist, it's the best and simpliest and least expensive player of anything out there. QT will not play back AVCHD files that well if at all, as they are more highly compressed than Canon H.264.
That being said, if you can live with the transcoding model, using MPeg streamclip to Prores is probably the smoothest and fastest way, however, gave up that model a long time ago when I switched to PPro. It's a joy to not fill up hard drives with terabytes of prores nor take the initial time to transcode and instead use the source material directly. You'll also avoid strange QT gamma problems if you use the source files rather than the Mpeg / QT transcodes. Look up Shane Hurlbut's talks on these issues. Tons of former FCP DSLR and AVCHD editors have done the same. Figure out the time savings and hard drive savings and it behooves you to try to make the Premiere Pro non-transcode model work for you.
"If this is the way Pr handles Long-GOP, I'm going to go back to transcoding it all before editing, and start ridiculing the idea of native editing in Pr."
Yep, that's the conclusion I've reached. I'm on the Windows end with AVCHD 60p (it might have been my post you mention down below), and native scrub/shuttle is completely useless. A competing NLE flings this stuff around just fine and working native is a joy, so the standard response that "you need a better system" falls flat, particularly in light of certain marketing claims.
I'd love to stay with Adobe and would transcode for usable shuttle as a stopgap...IF I knew this problem was being addressed (at some level other than my wallet.)
KqK2, are you on Mac or PC, what's your hardware config so there's a reference...?
Are you on a 4,1 or 5,1 MacPro by any chance? There are a few threads going that show that those 2 models have trouble with H.264 footage right now, for some reason. Slow clip updates in the program monitor, poor shuttling, etc. More and more mac users are coming to the forum with these issues.
Keith Moreau wrote:
KqK2, are you on Mac or PC, what's your hardware config so there's a reference...?
I don't mean to crosspost either, but people appear to be having the same issue across platforms. So:
HP Z600 workstation
Xeon (single) 5520 2.5ghz, 4-core (8 w/HT enabled)
ATI FirePro V3700 (it's a low-end card, but I'd assumed that wouldn't matter.)
Separate 7200 drives for os/scratch-media cache/source
...everything tuned as per the many helpful guides on this forum.
AVCHD 60p plays fine at normal speed, and shuttling forward works for two or three seconds, then it starts to skip badly. Attempts at running the native footage back-and-forth in the source monitor, at different speeds and to get a feel for the movement, grinds to a maddening halt on my system.
As a performance reference on my own sytem, I'm comparing CS5.5 with Edius 6 which, while filled with tradeoffs of its own, handles native 60p AVCHD with highly addictive fluidity. I'd hoped for reasonably similar performance in Premiere.
Me? I'm on a 3,1 - the early 2008 model. I think I'm seeing a trend that it's Macs that are having the issues with H.264, and maybe not as much for Windows users.
There must be something wrong with your system, I'm on a pc and have never had any problems shuttling through any footage in premiere. Do you have a small sample file available of your footage that you say wont work?