Dafydd

Thanks for following up!

I wouldn't think it is a beta issue... I could roll-back to check, but I think is easier if you test it quickly - in a random rendering, with windows task manager running, do you get more than 2GB memory usage for PD13? How about CPU % and GPU %?
The GPU utilization can be found with GPU-Z (the app has a .zip version that does not require installation on your PC).

I was reading about the memory used by PD 13. So I did a test. I loaded 10.2 GB of video files out of a Canon 70D 1080P 29.97 fps In to PD 13. Files was around 90 Mbps bitrate. I shoot in All-I mode.

I produce to mp4 h.264 1080p highest bitrate 485000 Kbps. PD 13 uses 1.4 GB of my Ram. Then I loaded the same files in to a different video editing software and produce with the about the settings. I did forget to raise the bitrate up a little on the other one. So it render at 36000kbps. That software used 4 GB of my ram.

The video was like 16 minutes and 7 seconds long. I did not use and GPU hardware rendering. All CPU rendering time was 15 minutes and 56 seconds in PD and about the same in the other software. That was my test. I have 16 GB of DDR4 ram in the computer.
Intel i7 5960X overclock to 4 Ghz 16 GB of ram.
GoPro 4
Canon VIXIA HF G10
Canon EOS Rebel T3
Canon EOS 70D
My Vimeo Channel http://vimeo.com/user3339631/videos

Thanks Michael for taking your time to report.

I am convinced that CL does not use more that 2GB RAM. That's a limit like the hard limit on all the 32 bit software (even running on 64 bit OS).
So I was wondering if the "64 bit" porting of PD is just a new "packaging/wrapping" of the old 32 bit software, without any optimizations for the extended 64 bit memory space. That would affect performance in the way that we are discussing here - none of the CPU, GPU, memory, SSD/HDD are utilized at their maximum abilities.

I had the same issue when using the latest non-beta version of pd13.
That was the reason for trying the new beta software, but it was the same.. I7-4910MQ, 16gb ram, 256 samsung evo 850 pro, gtx-860m GPU

I should of put the build I'm using. PD 13 Ultimate Suite build 2403. It does install in the Program Files and not the x86 one. Plus I running Windows 7. I did go back and turn the paging file off and had the same clip in. I render to the same settings and got it to use 1.5 GB that time. That time it render in 14.43 minutes.

The other software I used I know it is 64 bit. It from the CS6 family. I had really never look at the memory usage that much. I will say oh PD 13 and the other one had the same render times. Intel i7 5960X overclock to 4 Ghz 16 GB of ram.
GoPro 4
Canon VIXIA HF G10
Canon EOS Rebel T3
Canon EOS 70D
My Vimeo Channel http://vimeo.com/user3339631/videos

Quote: I am convinced that CL does not use more that 2GB RAM. That's a limit like the hard limit on all the 32 bit software (even running on 64 bit OS).

I don't think that statements true at all. Work with some 4K streams or take a simple 1920x1080 and utilize 20 video tracks simultaneously with them, memory requirements will exceed 2GB easily. Some effects also can take considerable RAM during render. With a basic single track being used with basic 1920x1080 50/60p, 28Mb/sec you just don't need the memory footprint to render video. It's just a read render write serial task so no real advantage to using lots of memory, nothing to reside in memory. Bottleneck is render algorithm (CPU or GPU).

Probably be thankful it's not using much RAM or you wouldn't be able to use many video tracks simultaneously to bring out your creative side, you've got 100 to play with!

Jeff

Yes that looks to be true. I will get to Play with some 4K after Christmas from a GoPro 4 Black. That will be my first camera that can shoot 4K. Intel i7 5960X overclock to 4 Ghz 16 GB of ram.
GoPro 4
Canon VIXIA HF G10
Canon EOS Rebel T3
Canon EOS 70D
My Vimeo Channel http://vimeo.com/user3339631/videos

Jeff, can you achieve more than 2GB with 1080 formats?
Even those 4GB RAM usage are not that impressive to me, considering the total size of the files you used.

The 4K part of the code is relatively new and I have a feeling might be a different path, coded correctly - it does not involve GPU acceleration.
For example:
In program folder called "encoder pack" I see dll's for HEVC (one for each SSE capability), for nvidia kepler, for mp2 and mp4 (each cpu). Those are new compiled files, but is all the code really new? Maybe true for HEVC and Kepler encoders...
Of course this is just speculation.

You say that encoding is serial process and the bottleneck is CPU or GPU.
In my case and Peter's (OP) none are maxed out. I tried also a Disk RAM to eliminate any HDD limitations, with no success.

Can somebody from cyberlink Give us info if the software behavior is like expected or not? I7-4910MQ, 16gb ram, 256 samsung evo 850 pro, gtx-860m GPU

Quote: Jeff, can you achieve more than 2GB with 1080 formats?
Even those 4GB RAM usage are not that impressive to me, considering the total size of the files you used.

You say that encoding is serial process and the bottleneck is CPU or GPU. In my case none are maxed out. I tried also a Disk RAM to eliminate the HDD limitations.

Yes, even with 1080 or other "simpler" formats. It just takes some complex timelines and/or many added effects for significant RAM usage. Just the way it should be. Again, nothing in this serial encode process is related to the total size of the video files used on the timeline. Put 20GB of video on a single track of the timeline vs 1GB of video, your memory usage during encoding will be essentially the same, not 20x different. At any instant in encoding time you are only dealing with say 28Mbps of data from the single video track, 3.5MB/sec. That's nothing to deal with, significant RAM not needed and no need to retain large RAM data buffers during encoding. However, if you use your right hemisphere, and create complex timelines, RAM usage will increase to handle complexity of timeline. Just the way it should be. Pic attached with encode preview active so one can easily see the complexity.

Encoding speed will not be a function of HDD limitations at all, again data rate is just way too slow. Do faster HDD help, yes, definitely for OS and other parts of the PD editing process, just not encoding. The only encoding exception to this is the use of SVRT during encoding, here you really are measuring the rate of not doing encoding work and pure I/O so HDD performance will/should matter. A little dated but maybe of interest concerning HDD's and PD, http://forum.cyberlink.com/forum/posts/list/25978.page

Quote: Can somebody from cyberlink Give us info if the software behavior is like expected or not?

If you want an answer from CL, probably best to use CL support, http://www.cyberlink.com/support/contact-support.jsp this is a users to user forum. From a user to user forum, yes, the behavior is exactly as expected.

Jeff

Jeff, I would totally agree with you. But then I see lots of small reads and writes on HDD. there is no reason why it cannot be cached on RAM. Also, I understand that encoding is a quasi-serial process. But why is the CPU not used at 100%, even in pure software mode? Where is the hold-up?

I have an idea, but need to reboot my PC to check it...

Quote: Jeff, I would totally agree with you. But then I see lots of small reads and writes on HDD. there is no reason why it cannot be cached on RAM. Also, I understand that encoding is a quasi-serial process. But why is the CPU not used at 100%, even in pure software mode? Where is the hold-up?

I have an idea, but need to reboot my PC to check it...

Pegged at 100% for pure software mode.

Jeff

My CPU usage was not - 70% maximum in software, 35% with HA.
I rebooted and disabled the Hyper Threading in CPU. Now I have 6 cores, 6 threads (instead of 12).
Re-run the tests.
HA deactivated - CPU usage at 80%.
HA activated - GPU usage increased from 35% to 40%. CPU usage from 35% to 75% - so one explanation is that, in my case, PowerDirector cannot use hyper-threading optimally when GPU is activated... However, the resulting conversion speed is similar.
and still, not pegged at 100%, as I was expecting.
Memory is DDR3, triple channel, 667MHz, CAS Latency 9.0. I doubt that is the bottleneck...

PS: Jeff, do you have HT active on your i7? You have the view of all cores merged, so I couldn't tell (task manager-> View->CPU History).

Quote: PS: Jeff, do you have HT active on your i7? You have the view of all cores merged, so I couldn't tell (task manager-> View->CPU History).

Getting OT, but here is your answer.

All cores merged to one on purpose so you could easily see 100% utilization! HT was on for particular test above.

From what I've seen over the years on my platforms, HT with PD results in a 0-20% reduction in encode time, results are output format dependant. I've never seen HT cause an increase in encode times for what I've done, it does increase RAM requirements for a given timeline very modestly during encoding. CL also claims to support HT, http://www.cyberlink.com/products/director-suite/spec_en_US.html
"PowerDirector 13 is optimized for CPUs with MMX/SSE/SSE2/3DNow!/3DNow! Extension/HyperThreading/ Intel AVX2 technology"
and has for many releases.

My results quoted above was from a fairly in-depth look into HT with PD12 and multiple pds files and multiple output production formats, PD13 results probably similar as it appears not much has changed in core type technology, just peripheral fluff,

Jeff

Is there any news about this?
Is software working like it should, or is it a bug? I7-4910MQ, 16gb ram, 256 samsung evo 850 pro, gtx-860m GPU

Why complain that it uses too little RAM if it isn't necessary?
The best written programs don't need multiple GB of RAM.
Does the program perform adequately or is there a problem ?
MSI X99A Raider
Intel i7-5820k @ 4.4 GHz
32GB DDR4 RAM
Gigabyte nVidia GTX 960 4GB
480 GB Patriot Ignite SSD (boot)
2 x 480 GB Sandisk Ultra II SSD (striped)
6 x 1 TB Samsung 860 SSD (striped)

2 x LG 32UD59-B 32" 4K
Asus PB238 23" HD (portrait)

The low use of memory points to coding inefficiencies.
Why do you have a 64 bit OS, why when you have more memory installed usually performance of other software improves?

Quote: The low use of memory points to coding inefficiencies.
Why do you have a 64 bit OS, why when you have more memory installed usually performance of other software improves?

I don't think so. In some cases more memory usage simply doesn't help. And in fact, higher RAM usage can actually reduce performance if a small workset would have fit into the various L1/L2/L3 caches, but the larger workset no longer does. Sometimes this effect can be rather dramatic.

I suggest you compare performance of encoding with PowerDirector with other encoding than use more RAM. I personally have not find a faster one than PD, even though the newer PD tends to get slower than the older one.

The benefits of 64 bit are not just address space but use of more registers and better instruction set. A straight recompile of C code often gets a 10-15% boost from this alone, without rewriting anything - and memory usage goes up only because pointers become wider.
MSI X99A Raider
Intel i7-5820k @ 4.4 GHz
32GB DDR4 RAM
Gigabyte nVidia GTX 960 4GB
480 GB Patriot Ignite SSD (boot)
2 x 480 GB Sandisk Ultra II SSD (striped)
6 x 1 TB Samsung 860 SSD (striped)

2 x LG 32UD59-B 32" 4K
Asus PB238 23" HD (portrait)

Why even bother to code more than 32 bit if you don't use more that 1-2GB of RAM?
I actually don't know why they even bother to add cache RAM in devices like HDD, SSD, CPU, GPU, in OS...

Quote: Why even bother to code more than 32 bit if you don't use more that 1-2GB of RAM?

I spent valuable time in the post above explaining why one might want to, but you clearly didn't bother even reading it.

I actually don't know why they even bother to add cache RAM in devices like HDD, SSD, CPU, GPU, in OS...

Because "they" know much better than you about what works best.

Educate yourself a little bit.
http://www.brighthub.com/computing/hardware/articles/32165.aspx
http://en.wikipedia.org/wiki/Disk_buffer

The idea that the most efficient algorithms are always the ones that use the most RAM is ludicrous. This is simply not the case.
For video encoding for example, the encoding speed is limited by the CPU or GPU .
There would be no benefit to, say, pre-loading an entire video clip of many GB into RAM in this case before encoding.

In fact, it would be slower, because you would have to wait to finish reading the entire clip from the disk/SSD before starting the encoding process. Such an algorithm would use more RAM, and also take more time to encode. It's a very inefficient algorithm and I'm very glad that PowerDirector does not do this.

The more rational approach is to allocate a buffer of adequate size and read from the disk into that memory buffer as one is encoding, possibly using multiple threads so that the encoding is never delayed waiting for the disk. PowerDirector probably uses such an approach and may have chosen to buffer 1GB of video, deciding that buffering more did not offer any performance benefits.

Before complaining about low RAM usage, seriously ask yourself what you would want the extra RAM to be used for and how it would benefit the task. Many computing tasks do not benefit from more RAM usage. The best algorithms are often the ones that use the least RAM.
MSI X99A Raider
Intel i7-5820k @ 4.4 GHz
32GB DDR4 RAM
Gigabyte nVidia GTX 960 4GB
480 GB Patriot Ignite SSD (boot)
2 x 480 GB Sandisk Ultra II SSD (striped)
6 x 1 TB Samsung 860 SSD (striped)

2 x LG 32UD59-B 32" 4K
Asus PB238 23" HD (portrait)

You provided the link, maybe you can read it... Over and over.
Disk buffer. PD doesn't use 1GB of buffer. You are so smart that you can verify yourself how much.
When I edit a video file that is 8GB on disk and the software uses only 2GB RAM more than with the standard boats clip loaded... something is not OK.

Certainly this thread deviated, maybe you can start from the top see who started it and maybe actually read what is really about.

Me... I am tired to argue with smart-a**es.