Adobe Premiere, why does it take so long?
- The14thGOD
- Joined: Sat Feb 21, 2004 1:12 pm
- Location: Everywhere
- Contact:
Adobe Premiere, why does it take so long?
why does it take so long to render a video? im just messing aroundwith it to get a feel for it, and it takes 10 mins to render a 1 min video, that is insane! and theres one speical effect in it, opacity, which is not that big lol. (first time using this, im used to Ulead video studio 7).
is there maybe some prefrence i have to change or something?
its reading off a SATA drive, does that matter? i would think not..
thanks in advance for the help
is there maybe some prefrence i have to change or something?
its reading off a SATA drive, does that matter? i would think not..
thanks in advance for the help
- The14thGOD
- Joined: Sat Feb 21, 2004 1:12 pm
- Location: Everywhere
- Contact:
- rose4emily
- Joined: Fri Jan 23, 2004 1:36 am
- Location: Rochester, NY
- Contact:
Get used to it.
Unlike specialized encoding programs, that do nothing but convert one format to another, general-purpose video editing tools have to run most footage through several extra steps in the rendering/encoding process.
In the case of Premeire, I believe it:
Decodes the source video.
Converts to the RGB colour space.
Applies effects and performs compositing operations.
Converts back to YUV (if you're using a YUV codec, such as any of the MPEG-family codecs).
Performs any needed format changes (framerate, rescaling, cropping...).
Encodes to whatever output codec you chose.
That'll easily take 10 times as long as just decoding and playing the source footage, unless you've got some sort of specialized video processing hardware (which, to the best of my knowledge, doesn't come into play with most current video editing applications - though future apps (especially high-end ones) are likely to start making heavy use of GPU processing power).
Also, remember that the AMD 64 is a powerful processor, but that a 32-bit application hardly uses it to its full potential. Premeire is a 32-bit app on a 32-bit OS (some might say I'm 30 bits over on the OS side of things, but I'm not currently in the mood to take sides in that argument). The large on-chip cache 512-1024K should help speed it up a bit, along with the fast memory bus, but your machine isn't going to run full-speed until 64-bit Windows and 64-bit Premeire are both available (I'm assuming you missed the Win64 beta), or you switch to some 64-bit Unix-ish OS and learn to compile apps from source (big pain, but sometimes worth it for performance/compatability reasons).
Also, your rendering time will vary somewhat with not only effects and processing, but also the nature of your source, the number of shart cuts the video contains, and your encoding parameters. Video footage that has "a lot going on" often takes a bit longer to encode, due to the resulting increase in bitrate (disk bottleneck) or required processing for improved compression (processor bottleneck). Encoding features that maximize the quality to bitrate ratio also tend to make encoding take longer when used.
Probably the best suggestions I have related to rendering performance are that you should keep your disk(s) defragmented, and maintain plenty of "free" space on them - and that it's often best to render and encode anything long overnight. Even a tediously slow process seems instantanious when you sleep through it.
Unlike specialized encoding programs, that do nothing but convert one format to another, general-purpose video editing tools have to run most footage through several extra steps in the rendering/encoding process.
In the case of Premeire, I believe it:
Decodes the source video.
Converts to the RGB colour space.
Applies effects and performs compositing operations.
Converts back to YUV (if you're using a YUV codec, such as any of the MPEG-family codecs).
Performs any needed format changes (framerate, rescaling, cropping...).
Encodes to whatever output codec you chose.
That'll easily take 10 times as long as just decoding and playing the source footage, unless you've got some sort of specialized video processing hardware (which, to the best of my knowledge, doesn't come into play with most current video editing applications - though future apps (especially high-end ones) are likely to start making heavy use of GPU processing power).
Also, remember that the AMD 64 is a powerful processor, but that a 32-bit application hardly uses it to its full potential. Premeire is a 32-bit app on a 32-bit OS (some might say I'm 30 bits over on the OS side of things, but I'm not currently in the mood to take sides in that argument). The large on-chip cache 512-1024K should help speed it up a bit, along with the fast memory bus, but your machine isn't going to run full-speed until 64-bit Windows and 64-bit Premeire are both available (I'm assuming you missed the Win64 beta), or you switch to some 64-bit Unix-ish OS and learn to compile apps from source (big pain, but sometimes worth it for performance/compatability reasons).
Also, your rendering time will vary somewhat with not only effects and processing, but also the nature of your source, the number of shart cuts the video contains, and your encoding parameters. Video footage that has "a lot going on" often takes a bit longer to encode, due to the resulting increase in bitrate (disk bottleneck) or required processing for improved compression (processor bottleneck). Encoding features that maximize the quality to bitrate ratio also tend to make encoding take longer when used.
Probably the best suggestions I have related to rendering performance are that you should keep your disk(s) defragmented, and maintain plenty of "free" space on them - and that it's often best to render and encode anything long overnight. Even a tediously slow process seems instantanious when you sleep through it.
may seeds of dreams fall from my hands -
and by yours be pressed into the ground.
and by yours be pressed into the ground.
- Scintilla
- (for EXTREME)
- Joined: Mon Mar 31, 2003 8:47 pm
- Status: Quo
- Location: New Jersey
- Contact:
What codec are you using?
If you're exporting, you should be using a lossless codec like HuffYUV. And you're not changing any settings like framerate or resolution, right?
If you're just rendering previews, it's suggested to use a fast MJPEG codec (like PICVideo's) on a fairly low quality setting for to speed things up.
If you're exporting, you should be using a lossless codec like HuffYUV. And you're not changing any settings like framerate or resolution, right?
If you're just rendering previews, it's suggested to use a fast MJPEG codec (like PICVideo's) on a fairly low quality setting for to speed things up.
- NeoQuixotic
- Master Procrastinator
- Joined: Tue May 01, 2001 7:30 pm
- Status: Lurking in the Ether
- Location: Minnesota
- Contact:
If you're just creating a test render, make sure you render out to a simple format. There is no need to create a MPEG, or Xvid render for tests, it just takes too long. I use Vegas 5 and I prefer to render a test to MJPEG or just uncompressed if I'm too lazy to set a compressor. The the MJPEG renders very fast and so does the uncompressed. However, the uncompressed file is HUGE! and would play slow on old computers (it plays fine on my computer though). I like to use full quality on the MJPEG since I am testing to see how the video plays and looks.
I just did a test render of the first 3 seconds of a video I'm working on and heres the rendering times and file sizes (with uncompressed audio):
Uncompressed: 6 sec, 123 mb
MJPEG at quality 20: 4 sec, 14.3 mb
MJPEG at quality 10: 4 sec, 2.36 mb
Huffyuv in RGB: 5 sec, 31.6 mb
Lagarith: 7 sec, 16.5 mb
Xvid: 11 sec, 1.99 mb
MPEG-1: 27 sec, 914 kb
Cinepak
: 47 sec, 6.80 mb
However, only 3 seconds and consisting only of crossfades this is not the best test, but you get the idea. I suppose a MJPEG might render faster at lower quality as Scintilla says, but I would need to render a large portion out to see the difference.
I just did a test render of the first 3 seconds of a video I'm working on and heres the rendering times and file sizes (with uncompressed audio):
Uncompressed: 6 sec, 123 mb
MJPEG at quality 20: 4 sec, 14.3 mb
MJPEG at quality 10: 4 sec, 2.36 mb
Huffyuv in RGB: 5 sec, 31.6 mb
Lagarith: 7 sec, 16.5 mb
Xvid: 11 sec, 1.99 mb
MPEG-1: 27 sec, 914 kb
Cinepak
However, only 3 seconds and consisting only of crossfades this is not the best test, but you get the idea. I suppose a MJPEG might render faster at lower quality as Scintilla says, but I would need to render a large portion out to see the difference.
Insert clever text/image here.
- The14thGOD
- Joined: Sat Feb 21, 2004 1:12 pm
- Location: Everywhere
- Contact:
wow, lots of info lol
im just using mpeg layer 1's, and i just hit "enter" to preview it i guess it would be...doesn't creat a file to my knowledge
i have another question, i posted that while i was doing the rendering part, and then i went to bed after i watched it. when i watched it though it went all crazy, like the audio wouldnt match up and the scenes woudl lag and repeat one another. any idea what may be cuasing this?
thanks for the help (this areas better for help then adobe forums =P)
im just using mpeg layer 1's, and i just hit "enter" to preview it i guess it would be...doesn't creat a file to my knowledge
i have another question, i posted that while i was doing the rendering part, and then i went to bed after i watched it. when i watched it though it went all crazy, like the audio wouldnt match up and the scenes woudl lag and repeat one another. any idea what may be cuasing this?
thanks for the help (this areas better for help then adobe forums =P)
- Scintilla
- (for EXTREME)
- Joined: Mon Mar 31, 2003 8:47 pm
- Status: Quo
- Location: New Jersey
- Contact:
I suggest changing your preview codec to something that doesn't use temporal (inter-frame) compression.The14thGOD wrote:im just using mpeg layer 1's, and i just hit "enter" to preview it i guess it would be...doesn't creat a file to my knowledge
i have another question, i posted that while i was doing the rendering part, and then i went to bed after i watched it. when i watched it though it went all crazy, like the audio wouldnt match up and the scenes woudl lag and repeat one another. any idea what may be cuasing this?
Which means no MPEG-1, no MPEG-2, no MPEG-4 (DivX, XviD, 3ivX, etc.)...
If the previews are still acting up and going crazy, then close Premiere, re-open, and try previewing a smaller section.
I've noticed that Premiere Pro sometimes gets massively confused on sections of the timeline it's already rendered; so far this is the only way I know of to fix that.
- rose4emily
- Joined: Fri Jan 23, 2004 1:36 am
- Location: Rochester, NY
- Contact:
To elaborate on what Anubis said, MJPEG really is the fastest preview codec you're going to find in practical use, since it uses a relatively simple and computationally efficient intraframe compression technique (also known as JPEG, hence MJPEG).
Uncompressed and losslessly compressed codecs tend not to play smoothly in real time. Most effective lossless compression techniques are actually quite computationally intensive, and uncompressed video is at such a high bitrate that most disks aren't able to read it fast enough for real-time playback. Even in a fast computer such as yours, the disks form a pretty nasty bottleneck. Short of putting together a RAID array (preferably not just basic striping raid, since the performance gain comes with a greatly increased chance of data corruption and hardware failure without a fallback), it's unlikely that you can play anything over VCD dimensions smoothly in realtime (and even that assumes nothing in the backround is trying to use the disk, and that the volume on which the file is stored isn't too badly fragmented).
Uncompressed and losslessly compressed codecs tend not to play smoothly in real time. Most effective lossless compression techniques are actually quite computationally intensive, and uncompressed video is at such a high bitrate that most disks aren't able to read it fast enough for real-time playback. Even in a fast computer such as yours, the disks form a pretty nasty bottleneck. Short of putting together a RAID array (preferably not just basic striping raid, since the performance gain comes with a greatly increased chance of data corruption and hardware failure without a fallback), it's unlikely that you can play anything over VCD dimensions smoothly in realtime (and even that assumes nothing in the backround is trying to use the disk, and that the volume on which the file is stored isn't too badly fragmented).
may seeds of dreams fall from my hands -
and by yours be pressed into the ground.
and by yours be pressed into the ground.
- The14thGOD
- Joined: Sat Feb 21, 2004 1:12 pm
- Location: Everywhere
- Contact:


