Extremely Long Export Times

Having some issues with export times in FCP. We don't do alot of editing in my office and we've just upgraded to HD for some of our stuff and the export times when trying to make .movs is taking forever.
Our original footage is recorded as .WMV 1280 x 720. We have Flip4Mac, but were having issues with render times and export times when trying to export as .wmv(One 15 minute video took over 4 hours to export and then at 90% complete Flip4Mac crashed FCP) so I converted the files to .mov using Ultra MP4 Video Converter. This helped with the rendering, but our export times are still ridiculous...even for HD...I would think. Like I said we haven't worked much with editing especially with HD footage.
Anyway, I had 7 sequences totaling around an hour and a half of footage and did a Batch Export to make them Quicktime Movies. It's been over 14 hours of Export Time and I'm still only at 52% complete.
Am I doing something wrong...is there anything I can do at any step along the way to make both my rendering and exporting times shorter?

Perhaps now would be a good time to explain your workflow.
This is how I deal with non-native source material ....
• move original material to hard drive on computer. Put in scratch folder.
• open up Compressor and import all files to be converted.
• select preset that will convert to ProResLT at an editing framerate, video size and audio sampling rate/depth.
• launch batch. Note: if you have a multi core Mac, using quick clusters in QMaster will speed this process markedly.
• once process is complete, import ProResLT files into FCP and edit. Once finished, export using "current settings" & "self-contained".
• open up Compressor again and import the exported ProResLT files.
• select the preset for the delivery format (h.264 or whatever) and launch the batch.
you are done.
x

Similar Messages

Extremely long export time

Hi,
I got some big problems while exporting footage from AME and PP CC 2014. I mean – the time of exporting is extremely long. It take 4 hours to export 15 minutes of 1080p footage (with not best quality of render settings). There is no big difference in time while exporting with or without effect same as AME or PP.
I shoot my footage on SONY A7S in XAVC S and my export settings are H.264, VBR 1, 16/20.
My PC spec:
Intel Core i7 3770K 3.5 3.9 GHZ
32 GB DRR3,
HDD 2TB, SSD 128GB
GeForce GTX 770 2GB
WINDOWS 7 ULTIMATE 64 BIT
I will appreciate any help cos this problem make me sick already

I checked the log file and there are no errors in the file.
There are no ORA- xxxx error messages.
The last line in the log file is as follows:
"Processing object type schema_export/table/index/domain_index/index "
I just checked the export job run this morning and it is still on the same
index object "A685_IX1" . This is a spatial index. It has been sitting at
this same object according to the job status for at least 24 hours.

Premiere Pro CS6, Extremely Long Export Times - ProRes

All,
Trying to figureout what I'm doing wrong. My sequence is 1920x1080, 29.97 and ProRes 422. The entire thing has already been rendered. I've checked "Use Previews"
See below:
Any suggestions? It's a 5:30 sequence.
Thanks!

All video movies on Mac are Quicktime, even uncompressed, which can be achieved with Quicktime None or Animation 100%. Both of those are 8-bit, though, which would defeat "Use Maximum Render Quality," if so desired.
IINM, image sequences may not require QT. But, then you migh have issues if the next app in the transcode process don't accept image sequences. And they're not available as a Preview File Format on Mac.
However, ProRes is a perfectly fine preview file format. It's just that Pr doesn't always use the Previews on export, the way it should.
I usually master to ProRes, and when doing so, Pr usually will use the Previews, and they are fast.
In any event, I don't normally experience the overly long exports from Pr. Looking back at the OP, a 2 hour export for a 5:30 sequence is outragous, and I believe is a sign of something else amiss, other than typical Pr behavior.

Extremely long "reading" times in media browser

We are running CC2014 on 3 edit systems with a shared 10Gbit 36TB Synology NAS. Each workstation has approximately 12TB of local raid storage as well. We shoot P2 primarily and I have a little over 17TB archived on the Synology. Lately, we have had extremely long "reading" times in Media Browser on all the machines. I don't quite understand how Premiere is indexing and displaying as sometimes the "reading" time is relatively quick, ie. under 10 seconds and then other times it can take 3-5 minutes to display clips within a directory.
My Directory Structure is:
Media
     P2 footage
          (P2 folders/ie. cards are all saved with their shoot dates here)
          Our total archive of P2 footage is around 70 cards.
It appears that when Media Browser is pointed to a P2 Card folder it is indexing the entire "P2 footage directory, ie. all 70 cards", rather than just the individual folder containing 1 P2 card's footage. Ist this the case?
Would I get better read speeds in Media Browser if I organized my P2 footage into more directories, ie. by year and quarter or by year and month?
Really need to know how the indexing works. Does premiere cache preview files for each clip and if so, how long are these previews valid. It seems that when I media browse a new P2 Card/Folder, it has forgotten any previous preview files that have been made and cached.
Any explanation or help would be appreciated.
We have copied large numbers of cards/folders from the Synology to our local raids to see if the latency was due to the network but the results are the same when we media browse on the local raid copies.

We are working on this issue. Could you open a support case and submit your
project so we can have support see if it is fixed in a later release?
br
William Wheeler wrote:
Is anyone experiencing long deploy times using Eclipse with the Portal/XML Beans facets...it takes approx 30 mins to deploy our ear file. The ear contains:
3 large schemas projects (using XML Bean Builder facets)
1 Control util project
1 Portal Web Project
1 Ear Project
3 Util projects
Is there some validation options that can be turned off or other actions to speed this up?
Bill Wheeler

Longer export times even though clip is rendered. I don't understand.

Just curious about this. I added a time code generator to a clip and rendered but it took 5x longer to export a ref movie as opposed to the same clip without the time code filter. If it is rendered, why the much longer export times? Everyday is a learning experience.
Thanks in advance.
Best.
Tom

Because a filter is applied, the reference file cannot just point to your source file as it normally would, it has to include the filter because the filter cannot be referenced. This means that it basically has to render the movie and the filter into the reference file.
However, since you rendered first, this leads me to the following questions:
1. Where are your source files located?
2. Where are your render files located?
3. Where are you exporting the reference file to?
4. What are your sequence settings?

Extremely long build times using object oriented code

We have a LabVIEW application that we need to build an .exe for distrubution purposes. The application relies on several object-oriented classes for data handling and dynamic dispatch type casting and function selection. Currently it takes approximately 1.5 hours to build the application and it seems that most of the time is spent processing the object oriented files. Has anyone else seen this issue and are there any creative ways to improve the build times?

Hi again. We are still having issues using LVOOP due to extrmely long .exe build times as well as long labview loading times. I traced the source of this to one class hierarchy, shown below. This hierarchy also relies heavily on overriding top-level functions, declared as virtual VIs in the top level class, which I suspect contributes to this problem. While debugging another issue, I was trying to build a small piece of my main code into an .exe to verify its functionality and experienced the same extremely long build times. When I removed this class hierarchy from the VI, it built extremely fast. Also to be clear, I am using neither the mean function or Mean.vi anywhere in this set of code. To date we have been delighted with LVOOP and how it has made our code cleaner, mroe robust, and more maintanable. However, when creating new functionality in the code we often elect NOT to create new objects (even though they would be beneficial) because we are hesitant to introduce the extra time (load and build) required for LabVIEW to handle these classes. If our entire system was rewritten in LVOOP, I would suspect that it would become unmaintainable and unbuildable due to the LVOOP overhead. I was hoping that LV2009 would address some of these issues but, alas, it did not. Still looking for a way to improve this and thanks in advance for all of the replies.

Extremely long display times for HTML in mail and Safari

Is anyone else experiencing similar lags in HTML rendering?
Since upgrading to Mountain Lion, I am experiencing extremely long render times for display HTML email messages in mail. I am also experiencing extremely long render times in Safari. I have Chrome installed on this same computer, if I goto the same website on Chrome and Safari, Chrome displays the page immediatly, Safari will take between 30sec and 1 minute.

The only way it can get fixed is if you report it to Adobe. Posting it here may not be sufficient. There is an Acrobat feature request forum here and a bug report form here: https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform

Extreme long execution time

Hi,
lately, I realized that Jubula needs extremely long for all the progresses...
For example, deleting TestResults or after execution of TestCases, the Progress "Collecting Information" and "Writing Report to Database" needs about 15-20 minutes!!
I use the embedded database and html toolkit and my project is not big at all!
I already had larger projects and never experienced that long progresses!
Any ideas/suggestions why Jubula is suddenly working that slow?
Thanks

Hi Nicole,
Thanks for your question! I think the problem is that the h2 database isn't designed for productive use - it doesn't scale well and will indeed get slower and slower with time (not necessarily size of the project, just time).
If you need to keep using it then you can do the following:
- stop Jubula
- perform an export all to export all of the projects
- you can also copy the database files (from your home directory under .jubula) to back them up
- delete the database files from your home directory
- connect to the database: this will recreate the database
- then you can import the projects you exported
Like I say, this isn't the preferred way of working, but the steps above should help with the current performance. Bear in mind that you should ensure that you have backups before you delete the database!
Hope that helps,
Alex

Long export times

My company is moving over to Premiere Pro CC from FCP 7. As a relatively newer user of Premiere Pro CC (2014v8.1) I'm trying to figure out how to set my system for faster exports.
For Example;
I edited a project in 720p (media was shot in 4K-Sony SxS) import and playback were fine until adding basic Color correction. Then extremely choppy playback until I rendered the timeline.
Exported the 14:27 timeline to XDcam422HD 60(50mbps) 59.94fps with a data rate 50.11Mbits/s.
It took 1hour and 18minutes to export!
For an experiment, I re-edited the exact sequence in Final Cut Pro X 10.10.4 (I have a copy on the same machine) Did the same export.
Both Files are identical in size, Mbits.sec, etc. The Export time was 7 Minutes!
I am sure there has to be a group of settings that I am not aware, that I haven't tweaked or modified to improve the export times.
Like I said the company is moving us to Premiere ProCC and I want to make sure I can export nearly as quickly. These export times seem unbelievably long and must not have something not set correctly.
My Sysytem is:
Mac Pro (Late 2013)
3.5 GHz 6 core Xeon E5
Graphics card: AMD Firepro D500 3072
16GB Ram
Yosemite 10.10.1
Premiere Pro CC 2014:
V8.1
Mercury Transit is enabled
13 GB allocated to PPro
Any help would be appreciated as we will roll this out division wide (about 35 edit stations) within a year.
Thanks in Advance
Mark

For those interested, This has been solved by removing the "adjust color" filter from my timeline and using the the "use previews" check box. Render speed increased to just 11 minutes. Thanks

Extremely long compression time

I am trying to compress a 6 minute video into a quicktime movie. It starts out saying it will only take 3 minutes to share. Then it quickly moves up to 17 minutes before coming to a halt.
Anybody have any ideas on what I am doing wrong or is this common? On previous videos this has never happened. I've tried doing a different video and it is also taking an extremely long time to compress.
Thanks for the help

I think possibly it could have something to do with my video settings. I don't know much about video settings.
We are producing these videos that range from 7-30min from a video camera. We don't need audio (already took that out) and we don't need the best of quality on the video. It obviously needs to be decent enough to see what is going on without straining, but beyond that I don't need much.
Does anybody have any suggestions on the type of video settings I could use in the expert settings? I believe iMovie is trying to compress much more information than I really need. Thanks for the help.

Premiere Pro export issues. Unknown error messages, extremely slow export times, strange I/O & disk usage

Hello,
I'm hoping I can start getting answers to some big issues I've been having running Premiere pro. I've had similar issues with CS6 but it seems like with CC and every recent update, the problem hasn't been resolved, its even worse.
The main issue I have is seeing the 'unknown error' message everytime I try to export a file. I'm working with RED footage. When I turn off the CUDA support, I can export without the error but my export time goes from a few minutes to sometimes hours in the render time!
I've looked through pages and pages of forums and there are so many people saying the same thing, with millions of opinions of what the problem is. Regardless, the only thing I tried that worked so far is turning off the CUDA support.
Now something I recently noticed, is that the difference isn't the GPU usage, I still show GPU being used at 500mb or 1gb out of the 2gb that it has (GTX 680)
The strange thing is without the mercury playback option, I'm seeing that disk usage and I/O go way down to kbs from a very high number. This would make sense why I'm seeing such huge changes in render times even though it still shows my 6 core CPU maxed out and ram over 40gb out of 64 that are installed.
Does anyone have a suggestion on what may be happening here? Its the only thing that has plagued my system using Premiere since day one and there seems to be no way around it..

Best way to get a real answer is go to the Tweaker's Page, download the most recent PPBM benchmark test, and run it. It's a folder that has a resource monitoring/logging program and a PrPro project with files that is short but HEAVY in effects, both AE and PrPro, so it tests all parts of a system's capabilities from disc in/out to GPU capability/use to CPU, fsb, RAM, you name it ... and after sending that back in you get a complete report on where your computer did well and what the choke-points were.
Also ... over on the Hardware forum is the place where the techies amongst us hang ...
Neil
Tweaker's Page ...
http://ppbm7.com/index.php/tweakers-page
Hardware Forum ...
https://forums.adobe.com/community/premiere/hardware_forum

MacBook pro Extremely long booting time After 10.10.1 + strange icons when booting

Hi all,
since the Yosemite update and the sequential patch, I've been experiencing lots and lots of issues with this releade
I posses a
MacBook Pro (13-inch, Mid 2012)
2,5 GHz Intel Core i5
After a week after the Yosemite update my Mac just froze, and for a couple of days I was unable to access it. after 4 attempts of Clean install i was finally able to restore it. but the issue with long booting time and free after sleep/wake action are the same .
I'm experiencing strange icons during boot as follows:
Only after a second reboot and clearing ram with Cmd+Alt+P+R i'm able to get rid of this , and the reboot shows this
That after 5 mins changes into this
This routine keeps happening, every single time i have to restart my mac.
Any suggestions?
tnks

Well , i guess i a HDD issue, when i was experiencing the initial issues with yosemite , I've installed the system an external Hdd and everything was working fine.
So i guess my suspicions were correct. I have to change my hdd.

Extremely long sync time

I have an 8 gb 3G iphone w/ virtually no photos, about a gig of music, 3 gigs of video and a gig of apps. It takes 8 hours plus to sync since using 3.0. After the first sync, a daily sync only takes 20 to 30 min, with no change in music, video, photos or apps. I read a post about deleting back-up and starting over. Not working. I'm going on 7 hours again to sync and it's only 3/4 done. Any help is appreciated. I'm using an Intel iMac, 2.16 ghz with iTunes 9.02. Again, it's been like this since using 3.0 software.
TIA

I agree that it is probably related to an app. One of my apps was causing long sync times, many users reported it, and the developer figured out that he could store its content in the iPhone's "cache" area instead of its "data" area. (This was acceptable - the app creates a local mirror of one's online content). This simple change shortened sync times considerably because the sync did not need to run through all that data each time anymore. The app does its own syncing to its cloud, so it's no big loss to have it excluded from the iPhone sync.
You may have an app with a similar issue. You say you have a gigabyte of apps? That's a lot! Since most apps are tiny, that does sound like you have at least one app that maintains a large database, whether it be maps, game assets, or whatever. You should find a way or a utility to list your apps by size, because the biggest apps would be the most likely suspects.

Extremely long deploy times in Portal 9.2 in dev

Is anyone experiencing long deploy times using Eclipse with the Portal/XML Beans facets...it takes approx 30 mins to deploy our ear file. The ear contains:
3 large schemas projects (using XML Bean Builder facets)
1 Control util project
1 Portal Web Project
1 Ear Project
3 Util projects
Is there some validation options that can be turned off or other actions to speed this up?
Bill Wheeler

We are working on this issue. Could you open a support case and submit your
project so we can have support see if it is fixed in a later release?
br
William Wheeler wrote:
Is anyone experiencing long deploy times using Eclipse with the Portal/XML Beans facets...it takes approx 30 mins to deploy our ear file. The ear contains:
3 large schemas projects (using XML Bean Builder facets)
1 Control util project
1 Portal Web Project
1 Ear Project
3 Util projects
Is there some validation options that can be turned off or other actions to speed this up?
Bill Wheeler

Extremely long rendering times

I am trying to render a 13 minute project.
FCS 2 is telling me it will take 30+ hours.
Is this normal?
Am I doing something wrong?
Best,
Evan Jacobs

So, your source clips are Quicktime Animation, and you're editing them on a "standard" timeline, whic makes me assume that it's a DV/DVCPRO NTSC timeline, with your source material residing on your internal drive.
There are a number of things here that will cause long render times:
1. The nature of the Animation codec in this situation would indeed cause longer than normal render times. Animation is a high-quality mastering codec. When used on a Sequence that is set to use a compressed codec, such as DV/DVCPRO NTSC, your clips will need to be rendered.
To check the Sequence Settings, press Command - 0 (zero).
2. It is not recommended to use your Internal drive as a scratch drive. Not only is that one hard drive reading your source files, writing render files, but it is also running your entire OS, plus any other programs that may be open. That's a LOT of work for one hard drive, so expect less than optimal performance.
Try moving your source material to an external firewire drive.

Extremely Long Export Times

Similar Messages

Maybe you are looking for