Apple Event: May 7th at 7 am PT

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Does Compressor 4 tell you how long the compression actually took?

I'm new to Compressor and compression in general.


When I "Submit" a video for compression in Compressor 4, it creates an entry in the History window that shows you when the video was submitted for compression. It also gives an estimated time for completion while the video is being compressed (though it seems to me it fluctuates and can be wildly inaccurate).


I usually leave the computer while the compression is happening. If it's done when I come back, I don't know how long the compression actually took. I don't see anything in the entry in the History window that tells me that. Is there any way to know when exactly the compression completed, or how long it took?


Thanks

iMac (27-inch Mid 2010), Mac OS X (10.6.4)

Posted on Feb 20, 2013 7:49 PM

Reply
4 replies

Feb 21, 2013 5:26 AM in response to JDLee

Hi Jd, if you have SUBMITTED a job to a cluster (maintained by Qmaster) [not this computer], the transcode job pushed to Qmaster by compressor.app draws events and conditions in the various log in Qmaster. You can find these logs in your ~/library/application support/apple qmaster/logs for the cluster , theater vice controller, the transcoder daemons and job controller. These contain the start , end and I believe ELAPSED times for each job . It doesn't accumulate by a BATCH .. I will stand corrected though.


Simply browse these logs this with console.app. U can ofcourse "go troppo" and write some shell, perl or apple script to develop some system management facility records for your clients accounting by doing this... Just parsing the text records...


Anyway I recall,his info u want for JOB COMPLETION (elapsed time) is there despite its coarse data. Sadly I have not found a way to detail the CPU, storage and I/o .. Seems too much to do for my needs.


As u state, the SHARE MONITOR.app is for viewing dynamic job. It's a bit hit and miss when using over a cluster. Since mountain lion, it seems to jam up a,lots and magically ,come back to Liffey after many internal messages (see logs) that it failed on socket x n y ..... Sounds like its in need of some stability and robustness additions.


I've also found for very long and numerous multipass segmented transcodes that share monitor gets over whelmed.... Especially when the share monitor.app UI is utilised to "Expand all"... It gets super busy collecting traffic from Qmaster ..if u are using a cluster.


Hth


Warwick

Feb 21, 2013 5:44 AM in response to JDLee

Just to add to Warwick's comments…


Absent the share monitor, an estimate can be made by looking at the History panel for time of submission and comparing it to the Date Modified info of the output file.


If you open Console and go to Share Monitor, you can get to the transcode times at the job level. I don't see any batch ET info either.





User uploaded file


Russ

Feb 21, 2013 6:12 AM in response to Russ H

Hi Russ, thanks for the confirmation on the absence of BATCH job info. I gave up ages ago trying to find it somewhere as it is a compressor.app function and some obscure info used to be maintained I the old v3.xx compressor history.. I might go check it out for v4.x ~/library/app. Supp ./compressor/history/ when I'm in the studio tomorrow . Maybe some new magic in there! ... Just curious.

Thanks again

W

Does Compressor 4 tell you how long the compression actually took?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.