Quote Rendering of certain 3D transitions (flip blinds, flip boxes, paper, paper airplane) slow my computer to a crawl when either playing from the timeline or producing even short 1-3 min clips. CPU usage drops dramatically when the transition is encountered to less than 10% and little or no GPU usage. After rendering clip continues to stutter during playback. Other 3D transitions behave 'normally'.....

AMD FX 8350 8 core, 16 GB ram, GTX 1050, SSDs, etc.
DirectX 12, PD16.0.3434.0, NVida 411.70, WDDM 2.4,
Open CL, etc..

The old Fx Cpu is not fast enaugh because it hasnt Gpa optimized Functions
The Gpu Accelation must be activated manually in Settings

The Export File Format and Codec should be the same Like input Source

H264 mainfile must encodet in h264 same Dimensions for fast encoding Mac Book Pro M1 sowie Mac Mini M1 16 GB Ram 512 GB HDD sowie Asus Expert Book B9

27 Zoll MSI Optix via Thunderbolt

Also, here are some things you can do to deal specifically with the slow playback during transitions. Choose the one that works best for your current project:

1. Change to non-real time preview - this is best for verifying that the transition works the way you want it to with your clips. You will have no audio and the playback will be slower than normal, but there will be no skipping


2. Keep real time preview, but lower the preview resolution to HD or Normal. You will lose some detail but it usually speeds up playback


3. If you're happy with the transition and won't be making any other changes to that section, you can select the area and use Render Preview to create an internal produced copy, which PD will use for playback instead of processing the transition each time. Note that if you do change anything in the affected section later, the green line showing the pre-rendered area will shrink or disappear, and you will have to use render preview again


4. If you're happy with the transition but still may make edits in that section, select the area and use Produce Range. You can then delete the selected clips and replace them with the produced clip. Note that you would normally select both entire clips connected with the transition so you can easily drop in the produced replacement. This clip shows how to select the section and use Produce Range, but it's the same procedure for Render Preview:

YouTube/optodata

DS365 | Win11 Pro | Ryzen 9 3950X | RTX 4070 Ti | 32GB RAM | 10TB SSDs | 5K+4K HDR monitors

Canon Vixia GX10 (4K 60p) | HF G30 (HD 60p) | Yi Action+ 4K | 360Fly 4K 360°

Quote Rendering of certain 3D transitions (flip blinds, flip boxes, paper, paper airplane) slow my computer to a crawl when either playing from the timeline or producing even short 1-3 min clips. CPU usage drops dramatically when the transition is encountered to less than 10% and little or no GPU usage. After rendering clip continues to stutter during playback. Other 3D transitions behave 'normally'.....

How did you judge no GPU usage with your GTX1050? I question as that does not sound correct for some transitions.

I believe what you are seeing is simply the difference between transition coding implementation. From what I've seen, it's kind of a mixed bag but the transitions with the "3D" in the upper left-hand corner primarily utilize the GPU, the "3D like" transitions which lack the "3D" icon in the upper left corner, some are CPU implementation, some are GPU. The paper and paper airplane which you reference are GPU implementations, while for instance the "Chain Reaction" transition also appearing in the "3D like" category is CPU.

Because of the above, how they perform for each user will be highly dependent on hardware and in particular, relative GPU and CPU performance and things like if the user configured GPU decoding or not. Obviously, anything one does to dumb down the timeline playback complexity will help with that (shadowfiles, preview quality, real time...)

In any case, the final produced video should play back smooth in a media player.

Jeff

Quote

How did you judge no GPU usage with your GTX1050? I question as that does not sound correct for some transitions.

I believe what you are seeing is simply the difference between transition coding implementation. From what I've seen, it's kind of a mixed bag but the transitions with the "3D" in the upper left-hand corner primarily utilize the GPU, the "3D like" transitions which lack the "3D" icon in the upper left corner, some are CPU implementation, some are GPU. The paper and paper airplane which you reference are GPU implementations, while for instance the "Chain Reaction" transition also appearing in the "3D like" category is CPU.

Because of the above, how they perform for each user will be highly dependent on hardware and in particular, relative GPU and CPU performance and things like if the user configured GPU decoding or not. Obviously, anything one does to dumb down the timeline playback complexity will help with that (shadowfiles, preview quality, real time...)

In any case, the final produced video should play back smooth in a media player.

Jeff

WIN10 task manager will monitor GPU usage and I also use a windows gadget - GPU Meter....

BTW looking back in time I found a rendered file when Win 7 & PD 12 & Radeon 6450 rendered all 3D transitions successfully @ 3840x2160. AMD FX8350 8 CORE, 16GB, Win 10 Home Prem 64-bit, GTX 1050 2GB, 250GB SSD, 1TB Hitachi SATA 2, PD16

Quote WIN10 task manager will monitor GPU usage and I also use a windows gadget - GPU Meter....

BTW looking back in time I found a rendered file when Win 7 & PD 12 & Radeon 6450 rendered all 3D transitions successfully @ 3840x2160.

Strange to me, WIN10 should have shown a load in 3D graph of the GPU tab as attached. I've configured for CPU decoding and CPU encoding so obviously no activity of the GPU there as shown.

Jeff

To confirm my suspicions that PD16 is behaving badly with 3D transitions, I reinstalled PD13, split a 2 min 4K video clip, dropped a single 'flip boxes' transition and produced it at the same resolution and format with hardware encoding enabled.

With PD13 the GPU engaged at the transition and the total time to produce was 2 min 15 sec.
With PD16 the GPU did not appear to engage at the transition and the total time to produce was 11 min 43 sec.

Both PDs were configure exactly the same. AMD FX8350 8 CORE, 16GB, Win 10 Home Prem 64-bit, GTX 1050 2GB, 250GB SSD, 1TB Hitachi SATA 2, PD16

Quote To confirm my suspicions that PD16 is behaving badly with 3D transitions, I reinstalled PD13, split a 2 min 4K video clip, dropped a single 'flip boxes' transition and produced it at the same resolution and format with hardware encoding enabled.

With PD13 the GPU engaged at the transition and the total time to produce was 2 min 15 sec.
With PD16 the GPU did not appear to engage at the transition and the total time to produce was 11 min 43 sec.

Both PDs were configure exactly the same.

I tried to replicate what I think you did as well as possible with your 411.70 driver on a GTX1070. Timeline shown in attached pic, 2 min 4K content with details provided, split at 1:00 and added horizontal flip boxes transition. Configured PD13 and PD16 as close as possible, keeping in mind PD13 did not do GPU video decoding here.

Produce Times:
PD13 v3130: 4:00 GPU hardware encoding
PD16 v3424: 2:40 GPU hardware encoding

Attached also is the WIN10 task manager showing the PD16 encode process at 1:12:25 seconds, (post flip box transition) and you can easily see the prior GPU 3D load through the transition and the hardware encoding load.

For one to get a ~5x increase in encoding time as you show something different going on for sure.

Jeff

I've produced a 20MB video showing a GPU side-by-side comparision of PD13 v. PD16 for producing the same input file.

As you will see there is quite a difference in how the two PDs handle the file.

Enjoy


https://www.dropbox.com/s/9hlpoqwgp05607x/PD13%20VS%20PD16%20COMPARE%20v3.mp4?dl=0 AMD FX8350 8 CORE, 16GB, Win 10 Home Prem 64-bit, GTX 1050 2GB, 250GB SSD, 1TB Hitachi SATA 2, PD16

Quote I've produced a 20MB video showing a GPU side-by-side comparision of PD13 v. PD16 for producing the same input file.

As you will see there is quite a difference in how the two PDs handle the file.

Your right about the difference, I've not seen that on my platforms, all Intel. Things to me look normal up to ~40sec in your video. Differences in what both PD13 and PD16 are doing, (even though you have the same settings), but, as I mentioned prior, PD13 could not GPU decode 4K content. At this point PD16 is slightly outperforming PD13, in part because your GTX1050 is doing the decoding of the 4K stream. At ~52sec in your video, PD13 still normal, PD16 loading a big mess and not normal in my view, unsure what's going on here. Finally, things back to normal type loadings at ~1:19 for both PD13 and PD16 after you cut the 9min out of PD16.

Just curious, what happens if you deactivate hardware encoding on the Produce section for both PD13 and PD16 on your setup. I realize not the intent as your GTX1050 should hardware encode much faster than your FX8350. Does PD16 still struggle through the 3D transition? This result may give CL a little more to work with to resolve if the issue still exists in PD17.

Since I can't replicate, I can't tell you if things might improve for you in PD17. I also doubt the trial an option to evaluate this, one would have to use the 30-day guarantee or lease option to check.

Jeff