@pmikep

If you could pop such a clip into a drop box folder for us to try out so we all have the same project then you may get some meaningful comparisons. I'm sure there are a few of us willing to try. Also tell us your export settings for us to copy and we could give give you our results. A lot of us have our our system specs visible in our signatures and I can see from yours you have had a few versions of MEP in the past so I'm wondering what you switched to.

It does on the face of it seem that MEP does not push systems but it does. On my old system I had to pause exports from time to time to prevent overheating issues but that was a lower spec and older machine.

Ray.

Thank you both for your quick replies. Good idea about uploading my test clip so we can all talk apples to apples.

It's morning here - I won't be able to get around to uploaded the clip until later in the day.

P.S. I stayed up way too late last night, downloading 4K test clips and playing. I found that, with some standard resolutions, and if I matched the encode profile closely, I got 50% on CPU and GPU and Magix flew. So it appears there is potential.

@pmikep

If your interest is in lower resolution projects then one thing you could do is try exporting the Demo.MVP that should have downloaded with the trial version. This would give all other members access to the same project and is something John EB and I did some comparisons with some years ago. The reason I have not used it as a yardstick since is that the material in it is lower res. but probably close to the res. that you are testing at.

Just be aware that if you are exporting unaltered material that Smart Render / Smart copy is not coming into play for H.264 material. 0.33x real time seems very respectable to me in any program, so if it occurs faster than that then SR / SC may be activated by default in an Export template.

Something else to be aware of is that non standard aspect ratios / resolutions will create more work for the encoder as will unmatched import and export profiles, and it could also alter the ratio of load between the CPU and GPU as resizing is GPU accelerated in recent MEP versions.

Peter

@pmikep

One simple reason for MEP not utilizing 100% CPU/GPU may just as well be that there are also other components in the rendering pipeline that may cause a bottleneck. Like reading from and writing to the disk. In particular if this will occur on same one. Neither do you state the amount of RAM available in your PC, nor the RAM size available/dedicated to the GPU. Memory also comes with a speed and latency, so CPU/GPU are not the only parameters affecting the rendering time. Even two PCs with same CPU/specifications may perform different on Benchmarking test.

I haven't forgotten about you all. I just received a new GTX-1050 Super. I plan to install it and do some more testing. After that, I'll post results and post a link to a representative test file for me. (The GTX-1650 Super seems to be a "smokin' deal" (as we say in the States). As fast as the venerable GTX-1060 and now has the Turing NEVC hardware encoder. Lower power. And lower price too.)

@pmikep

Hi

. . . . GTX-1050 Super . . . I plan to install it and do some more testing . . . .

Do be aware that:

1. for best performance the NVidia Studio drivers should be installed, not the gaming drivers.
    
2. if you wish to combine usage of both the UHD 630 and the GTX 1050 then you need a monitor plugged into both GPUs in order to keep both graphics cards activated, if you have a single monitor and it has 2 or inputs you can connect and input to each card, alternatively use a 'Headless Ghost' monitor emulator.
    
3. MEP does not support NVENC, HEVC video export done on the UHD 630. Video Pro X does.

John EB

Thanks, John. I have been trolling the forums off and of for a while and saw most of the above. While I wait for a custom power connector for my (unbeknownst to me, proprietary Dell P/S and mobo):

Hmmm ... I remember now that I would have had to click an extra step to get the Studio driver ... and now I remember NOT doing that. I will go back and do it again.

I had read here about how one needs to keep both GPU's "active" by having their individual outputs go to monitors or a Headless Ghost. Fortunately, I discovered the trick (by accident) that one can connect two cables to one monitor and Windows will think that you have two Displays. So that's a good use for a mostly useless VGA cable.

I wasn't clear about the last point about NVENC. I thought that MEP 2020 now did use NVENC on an Nvidia IF one first had a UHD 630 in the loop.

I didn't know that the UHD 630 could do NVENC encoding at all. (I thought that was purely an Nvidia thing.)

In any event, I've been reading here about the unresolved bugs in VPX and have decided to focus only on MEP.

@pmikep

I didn't know that the UHD 630 could do NVENC encoding at all. (I thought that was purely an Nvidia thing.)

NVENC is an Nvidia thing only and relates to a separate encoder chip on the GTX card. It was designed so you could record gameplay, among other things, without taxing the processing cores of the GPU.

The UHD630 has the equivalent hardware encoder chip on the Intel iGPU that uses Quick Sync to encode H.264 and HEVC with MEP.

I just wrote a very thoughtful post that took so long to craft that Magix timed me out. So it's lost.

I'll try to write it again tomorrow.

Yesterday I jury-rigged my Dell with a 2nd power supply to power the 6 pin PCIe power for the GTX-1650 Super. I played with MEP and a competitor's product last night. Some observations:

First, there is currently no "Studio" driver for the 1650 Super. The Super is so new that there are only two iterations of the driver, both "Game ready" drivers.

Next, at first I was using only one monitor, which was fed from both the UHD 630 (set as the primary GPU in my BIOS) and the Super. As far as MEP is concerned, this acts as a Headless Ghost for the Super. However, in a Competitor's product (DR) the Preview window did not work. So, to 'resolve' that problem, I had to add a second monitor, fed with the Super. So all my results below are with two monitors. (It turns out that MEP seems to run better this way too, as it allows the user to select different Video modes, as next.)

I started testing with the UHD 630 selected for the "Video mode" in MEP. (Program Settings > Display Options > Preview in Arranger.) I found that, depending on what size video I was trying to encode, I sometimes got faster encodes when the Super was selected for the Video mode. (My testing is just short clips, trimmed to 3 minutes or less (for the Trial version of MEP 2020 Plus). That is, no effects, transitions, rotations. color corrections, etc.)

Generally, for my system, Super seems to be the preferred setting. However, when I tried a 4K sample using the UHD for Video mode, I found that CPU dropped from 50% to 30%, and UHD GPU increased from 20% to 55%. (I also tried changing which display, the DVI one or the VGA one, was set as Display 1 in Windows. Didn't seem to make a difference.) Update: Whereas for a standard Full HD video, I found that the Super works better.

I can make a hand-waving argument why this is: QuickSync is optimized (by Intel) for certain tasks. Like encoding 4K. So it seems that one must be aware of what one is trying to do with MEP in order to chose the best GPU for Video mode. (BTW, I did all my testing with "Calculate effects on GPU" disabled.)

Next, I never saw 100% CPU or 100% GPU in MEP. Whereas I do get 100% CPU on Competitor's DR. And 100% GPU on the Super in Blender. (Although the free version of DR doesn't offer hardware acceleration, and Blender is using CUDA. So this isn't an apples to apples comparison.)

Since DR can get 100% CPU (even on my 8 core AMD FX) but MEP cannot, I don't think mine is a bottleneck problem, per se.

As for potential bottlenecks, it is true that I am running a single spinning disk on this Dell. But from what I've observed of Disk Usage in Task Manager, and from what others have said in another competitor's forum, I don't think disk writes are a bottleneck when it comes to mp4 encoding. For example, I have RAID 10 on my AMD box, which runs at the same speed as SSD for sequential writes, and I don't notice any difference in encoding speeds on it.

Although my RAM is not the fastest, I have noticed, during benchmarking latency settings in DRAM, that DRAM deficiencies seem to be mitigated by ever larger L3 caches on CPU's.

And while I only have 8 GB on this Dell, I'm not seeing memory go past 4 GB in these tests. So I'm not swapping to the HD. (Nor do I hear the disk trashing.)

I encoded a 2.5 minute 4K video of some puppies in 3 minutes. Almost 1:1. I will have to try that clip on my other box with another competitors product - the one that wins all the speed awards - to see what it does.

As I write this, I might try disabling the speed states for the i3 in BIOS and set Windows' Performance to 100% to see if the Windows' Scheduler makes any difference.

Also, by way of a footnote, I have disabled Real Time protection in Windows Defender, and I have also disabled allowing Windows to index content on my drive, both to stop extra read/write operations on my HD.

Okay, as a "sanity check," I just encoded the same 2.5 minute 4K video of puppies on version 15 of a competitor's encoder, known for winning all the speed awards. It did the video in 1 min, 40 seconds, using "Hardware Acceleration," which is well under MEP's current 1:1. (75% GPU use.) And that's on my old AMD box (PCIx Gen 2.0), with an old GTX-960, and an old version of the program.

My guess is that, with version 18 of Competitor CL, which is heavy into Nvidia, and which supports the newer NVENC motion estimation in the newer Nvidia drivers (greater than 411.x), and with a GTX-1650 Super, the encode might go to 1:30.

Considering that I didn't see people in this forum complaining that Nvidia's post 411 drivers broke something in MEP, it appears that Magix isn't as heavily invested/intertwined with NVENC as the competitor.

As for Image Quality, I don't have a keen eye. (And they're getting older.) Nor do I have a 4K monitor. I have heard that videophiles can tell the difference in Image Quality between Nvidia's NVENC and CPU encoding. (I wonder if they can tell a difference between NVENC and QuckSync?)

Anyway, I will keep playing with MEP and trying different combinations to see if I can make it faster. Has anyone tried the pay for Main Concept encoder? I used to use that in MEP 17 and liked it more than Magix's. More specifically, does the Main Concept encoder make heavy use of NVENC? (Again, one way to know is if Nvidia's post 411.x drivers broke Main Concept.)

@pmikep

To deal with your last point first. I have the main concept encoder and never use it. It doesn't seem to give the same quality output as Magix's own version and produces larger files and takes slightly longer to render as far as I've witnessed so far. Then again I don't use the MP4 encoder that much either as the files from that are not as clean looking as when using the HEVC encoder which is faster again (Although only by a small margin) and to my eye gives a more precise rendering of my original files along with a smaller sized end file. You don't need a 4K monitor to see differences in the results. Just compare an original file on playback to a rendered, exported video.

Speed of export on any machine will be more dependent on specific machine builds and how they are set up and the nature of the project. Difficult to judge in any meaningful way as if only one part of the equation changes, say the average bit rate and the type of encoding of an imported clip or the processing applied to it, can make huge differences to how a video gets rendered and which resources within a PC get to do which part of the rendering. It seems to constantly change as you watch the rendering take place. I have a lowly, aging NVIDIA graphics card which is now being used to greater efficiency than it was with the last version of MEP. Projects of ten minutes which used to take up to 16 hours to render on my old machine are now taking around half an hour, of which I could bring down the rendering time by upgrading to a newer graphics card. But it would only speed up the sections that are currently slow, the sections where graphic intense applications are in action. I doubt it will impact on the normal rendering of video frames that have no effects applied. That does seem to be codec dependent as you can see the changes in how the video is being handled. MP4 seems to load more into ram than HEVC and seems to make more use of my PCs processor than either graphics card. Most of my results may vary from your own experiences if you are using a different processor and graphics card combination and exporting different source files to different formats from myself.

I do have contact with another videographer that used Edius Pro 9 on a similar motherboard / processor to myself but he has graphics cards and monitors well over the specifications I would be willing to spend money on. We both use the same cameras and record projects at similar frame rates and we use similar project settings. The main difference as far as we can tell in use, his setup is more responsive in playback, particularly with scrolling speeds, with a more capable, higher resolution monitoring than I can achieve, but our rendering times are very similar.

Here is what I mean by sharing and alteration of resources during an export.

Ray.

Okay, I found John E.B.'s trick in the VPX forum, about setting the Windows' Graphics Setting to "Power Saving" (after selecting MEP for the program). Who knew there was such a setting buried in Windows? (Not me.)

When I did this, my 4K puppy video encode (above) dropped from 3 minutes to 2 minutes! That's for a 2.5 min video. So am now under 1:1 for Magix.

I also tried the Setting of "High Power." This seems to tell MEP to set my GTX-1650S as the Video Display when MEP first starts. So I had to manually set it back to the UHD 630 in MEP Program Settings for this particular encode.

BUT - setting the Graphics Setting to anything other than "System Default" does something else. It allows the GPU's to take more of the load. (And so my CPU works less.) So now I am seeing numbers like 60% - 70% in my UHD GPU, as CubeAce shows above. (I was wondering why I wasn't seeing those numbers before.)

Don't know why or what Windows is thinking here. (Win 10, 1903.)

So, if you have an internal Intel GPU AND an external GPU, my recommendation is to choose either High Perf or Power Saving in the Windows' Graphics Setting, and then change the GPU in the Video Display in MEP if necessary to get the best encode. Update: Maybe this helps even with only one GPU.

@pmikep

Hi

Thank you for detailing the results of your experiences with MEP and your hardware / settings. Most of this aligns with what has been detailed in various posts by other members but it is always interesting to see someone news test results. I may comment on a couple of your points when I have more time.

Re your latest post - please refer to the following comments from Magix support:-

The reason why the power saving options interact with the program settings is that when you select the high performance graphics card, the power saving Intel card is disabled. This means that it is no longer selectable in the program (even Quicksync is not possible), which automatically selects the Nvidia card. But this is not the case the other way around. Thus, if you select the power-saving Intel card  in the Windows settings again, the Nvidia card remains activated and selected in the display options. This has to be changed manually if necessary. 
However, the display option has no influence on the hardware encoding, since it is only for the display of the interface. 
In summary, if you want to use hardware encoding via Quciksync, the energy saving option must be set to either Default or Power Saving.

On my system with a Intel GPU and an Nvidia GTX1060 - Quicksync only works with the Windows Graphics setting set to Power Saving GPU. Default does not activate the Intel GPU for HW encoding. Strangely the export encoding preview window shows "(Hardware Encoding)" at the top but there is no activity on the Intel GPU in TM and the time to encode is longer.

Peter

Well, that is interesting. And seems different from what I've found in my experimenting. (I wonder how timely that post is from Magix Support. Like, does it cover this new video engine from Vegas?)

For example, when I have High Performance selected in the Graphics Settings, I still see the Intel GPU used in Windows' Task Manager. (Along with the Nvidia.) And I can change to the UHD in Video Display in MEP and it gives faster results with some encodes.

As to the former, perhaps I am assuming incorrectly that activity showing for the Intel GPU is synonymous with QuickSync? (I just learned that I can click on the thumbnail graph and Task Manager will expand to show more details. I assume that "Video Processing" implies QuickSync.)

As to the latter, I can see that I will need to make a short video to document my findings here.

FWIW, I ran the 3DMark benchmark and that program does not seem to be affected by which GPU is selected in Graphics Settings. And when I told the folks in a competing product forum about the Graphics Settings trick, they report no difference with the competitor's program.

So it might be software controllable by individual programs itself.

(Ironically, they have the opposite problem as here. They want to always run the Nvidia, but the program always selects the iGPU (on laptops, perhaps because a laptop display is connected to the iGPU and there's no way to get a Headless Ghost on the nVidia in a laptop).

@pmikep

QuickSync is explained on Wikipedia. Along with its development across various processors.

https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video

@pmikep

Hi

. . . . I assume that "Video Processing" implies QuickSync . . . .

No, the 3D graph shows the encoding load on the iGPU - video decoding and video processing are playback charts.

John EB

Well, that is kind of counterintuitive. But I played with HandBrake last night and set it to use QuickSync, and saw the 3D graph jump.

@johnebaker @pmikep

Video Decode is the decoding of frames whether it be for playback or prior to processing during an encode.

In VPX the decode is carried out on the Nvidia during HEVC (only). H.264 uses the Intel for decode.

During HEVC playback with the Nvidia selected in the "Preview in arranger" setting, the decode occurs on the Nvidia. If the Intel is selected the decode occurs on the Intel. With UHD630 selected in the preview settings the decode of H.264 and HEVC is carried out on the Intel.

AFIK the 3D graph is the acceleration by Direct 3D of textures, using the GPU.

To confuse things even more I read a comment from one of the Vegas Devs who stated that Quicksync activity is actually not visible in the Task Manager...... but this does not explain the jump in load during QS encoding?

Peter

A Studio driver was released today for the GTX-1650 Super. It is a point update too, from 441.41 to .66. I installed the 441.66 Studio driver and one of my 4K encodes, a sample beach scene that I downloaded from the Net, which encodes faster when I have the Super set as my Video Display, dropped from 1:05 to 45 seconds.

FWIW, the beach scene is 4096 x 2160 at 24 fps and the Super works better. Whereas the sample 4K of puppies is 4096 x 2304 and encodes faster on the UHD 630.

I did not test the Game Ready version of the same driver. So I don't know if it's the point update or the Studio part that is causing the increased performance.

Blender wasn't any faster. But then, Blender uses CUDA cores, not NVENC.

@pmikep

Hi

. . . . Blender uses CUDA cores, not NVENC . . . .

It wont use NVENC - NVidia caused some confusion many years ago by calling anything that uses the CUDA cores - 'CUDA'

CUDA refers to the CUDA cores in the GPU, they are separate from the main GPU, and are a very fast set of processors that can perform a variety of functions.

NVENC is what is call an API - which is a 'software program' that uses the CUDA cores for video encoding.

HTH

John EB

@johnebaker @pmikep

I think Nvidia created the confusion by calling the GPU Stream processors, aka Shader cores, CUDA, when CUDA was the name of the software layer (API) or parallel computing platform.

Likewise the confusion continues with NVENC which is the same name given to the NVidia ENCoder software which utilises a separate Hardware Layer, instead of the main GPU processors (cores), and is referred to as the NVENC Chip.

Peter