How do I tweak or change settings in Avid Media Composer ("MC") such that it fully utilizes the resources in my computer?
I don't understand why it takes MC so long to export a file to *.MOV.
You can see the screen shot below that was taken while MC was in the middle of exporting for over one hour.
The CPU was running at only 14% of it's capacity.
Only 15% of the DRAM4 was being utilized.
Only 4% of the Video Card (GPU) was being used.
Below this screen shot is my system specs.
i9-9980xe with 18 physical cores and 36 threads (18 cores can each run at 4.4Ghz)
128GB Corsair DRAM4 running at 3400 Mhz
Nvidia Titan RTX Video Card
2TB SSD Samsung
Asus Prime X299 Deluxe II motherboard (BIOS tweaked CPU to 4.4Ghz and RAM to 3300Mhz)
Media Composer 2018.12.1
all running very cool with great temperature control
The only thing causing a bottle neck is Avid MC. So I think there must be a way to change somthing in the MC software so that it takes full advantage of the above resources
Thats an easy one. When you do a QT export and select custom you invoke the legacy 32bit QT engine. Thats not optimised for multicore processors.
Try mixing down to one codec and then doing a same as source export you will find it a lot faster.
Broadcast & Post Production Consultant / Trainer Avid Certified Instructor VET (Retired Early 2022)
Still offering training and support for: QC/QAR Training - Understanding Digital Media - Advanced Files * Compression - Avid Ingest - PSE fixing courses and more.
Mainly delivered remotely via zoom but onsite possible.
T 07581 201248 | E pat@vet-training.co.uk
how can I get MC to use more of the GPU. That helped a lot Pat but it still only uses 48% of the GPU, while it does use most of the CPU. thank you
Exporting a file is mainly a CPU task. GPUs are mainly image processing tools.
Jef
_____________________________________________
Jef Huey
Senior Editor
This is what my exports looks like with everything rendered. I do not mixdown video. 70min uhd timeline to dnxhr_lb mxf (media processor). I mixdown audio first, seems to speed up export significantly (although im not 100% sure).
4.7ghz overclock on 14 cores.
Black Ice Nemisis GTS 480mm radiator.
Everything else is ekwb.
Then i compress to h265. Files are half the size of h264 and they look better. It also helps with the vimeo quota.
Media Composer will not use more gpu than what you're seeing. They need to improve the software for that.
If possible try my method and send an update. I am curious if media composer will use 18 cores.
Again, if you use any type of “Custom” QT export setting, you are in the hands of the ancient Apple Quicktime engine. You’re addressing it from inside MC, but it is not Avid code you’re using there.
From MC, export Same as Source quicktime or Op1A MXF, then use the resulting file in a third party encoder. For h264, Handbrake is free and fast, but there are many other solutions.
MC does not feature a complete encoding feature, it is limited in that sense.
Best workaround is to the fastest export type you can get from MC, then use third party apps for further encoding (like h264 and h265).
@cls105
cls105:I am curious if media composer will use 18 cores.
It defitely uses 32 threads on Threadripper. I saw an avid demo of a duel 28 Xeon playback 8k in real time using all 56 cores at near max. I can't find the youtube video anymore but it was impressive.
The Puget Systems 16 core recomendation is only partly correct. With Prem Pro it is the codecs that limit performance mostly not the edior. .h264 has diminishing returns past 16 and x264 is a bit different Full Frame Codecs is generally an all core export.
Avid has no such limitation except legacy single thead plugins and 32bit components.
show me that it uses most the cores on the 32 core threadripper. take a screen shot while transcoding or exporting.
also coreprio has really improved thread use for threadripper (although I wouldnt considering using it right now for media composer)
https://www.extremetech.com/computing/283114-new-utility-can-double-amd-threadripper-2990wx-performance
But I want to see 32 cores maxed out.
I can't speak for the 2nd gen Threadrippers or the 32core with the funny memory layout but this is on a background transcode of Sony XAVC-L 50 10bit to Avid DNxL 365x 1080p50
If i do the same transcode in foreground then it is only 80-90% utilization. If I use the Nablet Plug in then its only 50% utilization.
Also to note that your i9-7940 and mine are about the same speed when all cores are used.
When editing I don't often see more than 60% utilization in which case higher clocks is better.
As somebody who has some programming experience I can tell you distric uting work across mutliple cores isn't that easy a task.
The process of editing, transcoding and many other functions require a sequence of steps to be completed. Useing one core you push the tasks in one end and they pop out the other end. Pure CPU speed is the determining factor on throughput.
Now consider 2 cores. You now have to split the workload and send different parts through each core. But what if the result of those 2 processes is needed to set off the 3rd process. One core may complete first but have to wait for the second core to complete. You now have dead cpu time.
Multiply that up to 16 cores and the logistics of splitting tasks into 16 elements that all complete at the same time is impossible. Even the task of splitting jobs into those 16 cores is a massive job. But as the core count goes up you will find more dead CPU processing time as cores wait for other processes to complete to combine the results.
For specalist tasks like transcoding we can make better use of mutliple cores as we often have lots of similar tasks to perform but its almost impossible to get 100% as something always gets there first.
And finally ypu have to write the code to utilise multiple cores effectively and that code is wasted on lower core count hardware. So you either define a minimum core count and write code for that or you produce more general code that works well with lower core counts but is less efficent at higher core counts. Avid seems to not have forced MC users to have to have mega core counts to use their software. Other systems make a different choice.
Pat Horridge: Multiply that up to 16 cores and the logistics of splitting tasks into 16 elements that all complete at the same time is impossible. Even the task of splitting jobs into those 16 cores is a massive job. But as the core count goes up you will find more dead CPU processing time as cores wait for other processes to complete to combine the results. For specalist tasks like transcoding we can make better use of mutliple cores as we often have lots of similar tasks to perform but its almost impossible to get 100% as something always gets there first.
I believe there are no disputes on the engineering requirements and its difficulties. However if a free tool like handbreak, vlc and open source render engines like ffmpeg can do it I start having some 'minor' issues with Avid's timeframe to provide an alternative to quicktime. Just saying.
Jeroen van Eekeres
Technical director, Broadcast support engineer, Avid ACSR.
Always have a backup of your projects....Always!!!! Yes Always!!!!
A.V.I.D....... Another Version In Development
www.mediaoffline.com
Jeroen van Eekeres: Pat Horridge: Multiply that up to 16 cores and the logistics of splitting tasks into 16 elements that all complete at the same time is impossible. Even the task of splitting jobs into those 16 cores is a massive job. But as the core count goes up you will find more dead CPU processing time as cores wait for other processes to complete to combine the results. For specalist tasks like transcoding we can make better use of mutliple cores as we often have lots of similar tasks to perform but its almost impossible to get 100% as something always gets there first. I believe there are no disputes on the engineering requirements and its difficulties. However if a free tool like handbreak, vlc and open source render engines like ffmpeg can do it I start having some 'minor' issues with Avid's timeframe to provide an alternative to quicktime. Just saying.
Yes its easier to implement if you are doing a process as a core element of your application. Thats what VLC and the like concentrate on.
Avid Mediacomposer isn't just VLC or handbrake. Its a m,uch more compelx beast with many more requirements that raw speed in any particular area. So I imagine the demands to overhaul and implement programming time on just improving the effiecency of one element of its functions are someehat divided.
Don't get me wrong I'd love a kick ass fast export function and I do think a replacement for QT is long overdue. The inability to do a fast H264 / H265 .mov or MP4 export is a mission critical function not being provided. But I also know there are a long list of imporvements, changes and new developments that are being worked on that compete with the needs to replace QT.
Pat Horridge:Don't get me wrong I'd love a kick ass fast export function and I do think a replacement for QT is long overdue. The inability to do a fast H264 / H265 .mov or MP4 export is a mission critical function not being provided. But I also know there are a long list of imporvements, changes and new developments that are being worked on that compete with the needs to replace QT.
Of course. We aren't disagreeing. But what makes the quicktime issue stand out are 2 things.
1. When MC went 64 bit in version 6 Avid could and should have forseen the need for a 64bit quicktime replacement. It might have been impossible to have it ready at the time of its release but the framework in which MC would be able to integrate other (new) import/export engines in future versions should have been implemented at the time. That a market for products like Drastic's mediareactor was created is IMHO absurd.
2. While the writing was on the wall for years, the announcement by Apple that Quicktime was EOD/EOS and that 7.7.9 was the last windows version to be released meant that we are now depending on Microsoft to keep developing OS's that will remain able to run 'legacy 32bit' software. Now while I do not fear this becomming an issue anytime soon, the moment the words 'unsupported' or 'no longer supported' become a reality is anybody's guess. (Just a question of when Microsoft copies Apple's business model but that's another story) However I look at this, I do not consider this a viable situation.
"Avid Mediacomposer isn't just VLC or handbrake."
Correct, VLC, handbrake, ffmpeg don't charge customers a subscription.
That's the only reason why I find Avid's pace, dissapointing.
I think the original point I was trying to make is to answer cls105's original question and that is, he was not sure if MC could use more than 14 cores (24 treads) and if cores over clocks is better and if having more core’s is currently useful in day to day use. My answer as an independent editor is yes as 20% of the time. I am using background renders and transcodes or doing transcodes in Media encoder and I can still carry on editing with limited loss of performance. With the advantage of Process Lasso to manage program priorities and core allocations for different programs it is fluid. The benefit of more cores is debatable as the Dev's tackle the challenge of multithreading with the near end of More’s Law. The advantage of not slowing down when I have a lot going on, is for me, more valuable than doing one task faster. Someone in a collaborative workflow might see it differntly.
This aside, background export will greatly enhance productivity and have a bigger benefit for more cores, (wishful thinking).
When moving from SD to HD there was no change in render times and playback as SD at the time in MC was single core and HD was multicore and my dual dual core system could benefit from having 4 cores. Now the sweet spot seems to be between 14 and 20 on a single processor of 4ghz and higher. The latency penalty of a dual processor system is very high and outweigh the benefit of the extra cores for up to 4k imo.
The systematic removal of all 32bit components in MC should be the highest priority and is probably the most intensive and longest problem for dev’s to tackle. The new 64bit components would then hopefully be more optimized for more cores.
© Copyright 2011 Avid Technology, Inc. Terms of Use | Privacy Policy | Site Map | Find a Reseller