1 person found this helpful
Xvid is a highly compressed OUTPUT file, not an edit file
You need DV AVI Type 2 with 48khz sound for best editing
Thanks for the swift reply! Hm. Ok... A couple more questions, then:
How should I compress compilations made in VirtualDub? I can output .avi files with these compression formats:
Cinepak Codec by Radius
ffdshow Video Codec
Intel IYUV Codec
Microsoft Video 1
Xvid MPEG-4 Codec (which we've already determined to be unsuitable for editing with Premiere)
So Xvid compressed .avi files are what I would normally output from a finished Premiere project? Is that why AfterEffects seems to handle the same .avi files with no problems?
That's another question: I can work with these same files without the need for rendering or anything in AfterEffects, but I'd really like to do the editing in Premiere if I can.
Still (very) open to suggestions...
1 person found this helpful
I would strongly suggest that you NOT use Xvid, or DivX (the commercial version), for anything but a delivery format. It is NOT meant to be edited and is a horribly poor choice as an intermediate format/CODEC.
I wonder why you do not have DV-AVI Type II as a choice. Is this a limitation of VirtualDub?
If you want quality, then the Uncompressed will be the best of your choices here, but with giant files. Look into adding Lagarith to your system, but maybe like the MS DV CODEC, VirtualDub will not see it?
Next choice would be MS Video 1, but you might experience OOS issues.
Incidentally, is it typical for Premiere to have to render a .jpeg file in order to work with it? That's the case with me.
I do not nomally use JPEG's, but in SD Projects, my .PSD's do need Rendering. By "need," I mean that I get a red line, but they play smoothly and fine. Now, if I do a bunch of Keyframed Effects, the smoothness of playback WILL be affected by Rendering.
Hey, thanks and thanks again, Snob! Did a little digging, and added both Lagarith and the Panasonic DV codec to my system. Happily, VirtualDub can see both of them.
Apparently, the problem is that VirtualDub doesn't yet support more modern versions of the MS DV codec, necessitating the use of older or third-party DV compatible codecs.
Every day is learning.
I have every anticipation that this should eliminate all my issues. Thanks again - you're the shiznips!
Well, perhaps I spoke a little too soon. Ah... should video created with the Lagarith codec need to be rendered by Premiere before it can be edited? Everything is fine once I've rendered the Lagarith-encoded clip, but that's going to entail a *lot* of rendering unless you're only working on very short projects. Any last words of advice, Wine Snob?
I wonder why you do not have DV-AVI Type II as a choice. Is this a limitation of VirtualDub?
VirtualDub can only see VFW codecs. The MS DV codec isn't a VFW codec; it's a DirectShow filter. MainConcept ($$) and Cedocida (free) have VFW DV codecs available.
More info, that's good... Thanks for your reply, Jeff.
*sigh* About to start tearing my hair out, here... so, if anyone's still listening, please correct me if I'm wrong - the Cedocida codec is a VfW DV codec, but is it true that it only supports output resolutions of 720x480? Cropping my stills to that size in VirtualDub is the only way I can export timelapse footage with the Cedocida codec, otherwise VirtualDub kicks out an "Imput format not supported" error.
In addition, even with video segments chopped down to 720x480 and encoded by Cedocida, Premiere still seems to need to render the clip for smooth playback and editing. Gaaaah!
Maybe these issues will be easier to address if I clarify what it is that I'm trying to do. I want to take a series of still-frames captured for timelapse, and convert them into a format that Premiere can work with natively. I'm accustomed to compiling my timelapse footage with VirtualDub, but so far, I haven't been able to output a video file that with a compression scheme that Premiere is happy with. Even uncompressed video shows up red upon placement into the timeline.
It's been over 10 years since I last dabbled with Premiere, and I'm a bit disappointed to find myself completely in over my head. All I'd like to do for now is convert my timelapse footage into video and edit it without spending days rendering the stuff - 'twas a bit foolish to think it would be that simple.
Suggestions? ...I'd be very grateful for any further assistance. If there's a way to move past these technical issues and get to work, I'd really love to know what it is.
the Cedocida codec is a VfW DV codec, but is it true that it only supports output resolutions of 720x480?
That's what DV is - 720x480. For NTSC video, there is no other frame size allowed. Only the PAR (0.9 or 1.2) and the frame rate (29.97 fps or 23.976 fps) can change.
even with video segments chopped down to 720x480 and encoded by Cedocida, Premiere still seems to need to render the clip for smooth playback and editing.
I haven't been able to output a video file that with a compression scheme that Premiere is happy with. Even uncompressed video shows up red upon placement into the timeline.
Make sure your sequence settings match your source footage exactly. In CS4, you can change the settings for individual sequences. In earlier versions you had to have a project-wide setting.
Check. Learning, learning... Thanks for peeking back in, Jeff.
So. Made a little progress - the stills were taken at a fairly high resolution (for video), 2592x1944. I cropped the footage to 1920x1080 and exported from VirtualDub using the Lagarith codec at 7fps. The resulting .avi was imported into a AVCHD 1080p preset. While this seems to have worked better than anything else I've tried so far, the footage still needs to be rendered before it can be viewed smoothly for editing. This can't be normal, right? Surely everyone isn't waiting 4x the length of *each clip* for rendering before they work on them?
I tried creating a custom sequence setting at 2592x1944 to attempt to work with the footage at its native resolution, but when rendering, Premiere just gave an "unkown error", and politely refused.
I guess I'm willing to interrupt the editing process to render each clip as I need to fit it into the sequence, but it seems that it just *can't* be this difficult to create clips from stills that Premiere can manipulate smoothly. It sounds as though it should be simple, in principle. No?
Incidentally, this has strayed pretty far from my original inquiry about working with Xvid files... should I open up a new thread about how to create clips from still footage that works well with Premiere? I've still got my eye on the prize, as it were. I'll check back, and, of course, thanks in advance!
Hm. One more point - didn't Premiere used to (10+ years ago) have a native capture format that it preferred, and could manipulate more quickly than footage from other sources? I guess I've been operating under the assumption that something like this is still the case, but upon further reading, it seems as though it could simply be that hardware limitations are restricting smooth playback.
Does avoiding the need for constant rendering in Pr now simply come down to processing power, or is there an encoding scheme that I can wrap my still footage in to allow Pr to handle it more effectively?
... ...I guess what I'd like to know is if there's any type of clip that's graced with a green bar above as soon as it's placed in the timeline.
I guess what I'd like to know is if there's any type of clip that's graced with a green bar above as soon as it's placed in the timeline.
You don't want a green bar unless you've rendered a red bar clip. What you want is no bar, or at worst, a yellow bar.
The resulting .avi was imported into a AVCHD 1080p preset.
Don't do that. There are no presets for the footage you want to work with. Create a custom setting using Desktop mode. Using the Lagarith codec, things still may not work perfectly smooth, but that may be true for anything you try. Premiere has a tendency to work best with professional video camera formats, and has varying degrees of success with other types of video.
Yeah, I'm getting the sense that Pr is a now a more specialized tool than I remember it being. I'm going to have to reshape my expectations, for sure. Anyway, I couldn't get the custom Sequence to work when I tried to match the (high) native resolution of the footage. Pr refused to render, perhaps it doesn't like resolutions above 1080p? My best success has been in reducing the footage to a 1080p resolution and working that way - I'll continue to pursue that course.
Just out of curiousity, Jeff, what types of footage don't receive a status bar when they're placed in the timeline? Is there a list of native formats somewhere that I could look at?
Thanks for the help, all. I'm sure questions this basic aren't the most gratifying for you guys, so I appreciate your time. I'll be out of your collective hairs after this, I promise.
perhaps it doesn't like resolutions above 1080p?
Outside of installing the RED plug-in, that seems very likely, as there are no standardized video specs above 1080p.
In your post #2 you list codecs available, including:
“ffdshow Video Codec”
I'd suggest winding your system back to totally eradicate this codec, it is known to not co-exist well with PrePro CS3/4, otherwise you may find difficulties that are unpredictable. In fact you may be experiencing them now!
Yes, FFDShow has smurfed many installations of PrPro. I saw that in post #2 and just got sidetracked.
Good call John,
Huh! No kidding!
FFDshow is installed through a codec pack for Windows 7, Shark007. It (in theory) allows you to customized the behaviour or disable any of the codecs included with it - it has a global setting to disable FFDshow completely, which is on... As far as I can tell, it's also set to use Microsoft's default codecs in every possible instance.
I'll definitely try rolling back my system if that might help; in light of the settings, do you guys think that's necessary? Also, if I do roll back to a state prior to the Shark007 installation (a while ago, which is why I'm reluctant), what sort of performance enhancement should I be looking for? General performance improvement, or might I be able to encode stills into a format that's native to Pr, i.e. requires no rendering until effects are applied?
Does saying thanks in every post get old?
For "ffdshow" comments just search the forum:
Example lnk below
post #3 & #5 particularly.
The conventional wisdom is do not intall any codec packs, thus avoiding all sorts of problems with PrePro.
Performance enhancement? I can only tell you about my own experiences (these echo Jeff Bellune's) PrePro would not open a project I had worked on prior to installing a codec pack. A new project would open but the playback was laggy, PrePro would crash, give the low memory warning etc. In short PrePro CS3 now works with minimal problems after rolling back.
If you have an image making programme, make the image, then roll back to prior to Shark007 installation, try for yourself.
I use a lot of stills in my productions, mainly jpeg, some gif, tiff and psd, the fact they have a red bar on top has not stopped me from working on/with them, they preview just fine. Maybe CS4 is different, requires more resources etc?
General performance improvement, or might I be able to encode stills into a format that's native to Pr, i.e. requires no rendering until effects are applied?
I always use .PSD format, as each still has undergone some enhnacements. JPEG's (except for the JPEG compression), TIFF's, TGA's, etc. will work too. You will always get the red bar, as PrPro will want to Render the still to multiple frames, based on your Duration, to video. This is not an issue, as John points out. Remember, you are starting with a single still image, and then telling PrPro to extend that to X Frames of Video.
Until you add Effects, the Rendering will not be necessary for smooth playback. It's just a fact of life.
This ARTICLE will give you some tips on preparing your still images for use in your Video Project. I use PS for this, but PSElements works well too.
As for FFDShow, and CODEC "packs," the fora are filled with horror stories on what happens with either/both. Use at your own risk.
I always install ONLY the particular CODEC's, that I need, when I need them. I also go to the source, if possible, even if it means that I will pay for these. Many free CODEC's are hacked, or reverse-engineered versions, and some do not work well at all.
Pfoo... seems as though I've got a bit of reading and experimenting ahead of me. Thanks for the links and all the advice, guys!
You're most welcome.
Happy reading and happy editing,