Quote I've seen this on both of my machines and it started maybe 6 months ago (give or take). Reproducing it is simple:

Take a 15 second clip, split it a couple times, render it with SVRT
(you do not even need to add a transition, just split)

I had tried clips from:
GoPro Hero 5 black
GoPro Session 5
GoPro Hero 8
Insta360 Go 2


They all have this strange behavior...same on both of my machines (both Intel based (one i5, one i7), one with GTX1050 one with GTX960. To me it seems like a pretty generic problem (I've updated drivers and PD several times).

I use SVRT all the time as most of my videos in my workflow are 90% a single clip from one camera, but any time I split, transition or use a clip from another camera you get this "dullness"

Note: This actually caused me to not renew my PD365 subscription...however I have decided to at least give this forum a chance.

Note2: I know I can work around it in a few ways (none of these are satisfactory considering my old copy of PD16 does this just fine):

• 1) choose a non svrt resolution
• 2) deselect svrt
• 3) choose NVIDIA NVENC instead as fast rendering technology

Examples (both same project, only selecting SVRT rendering was changed :

https://youtu.be/iC77ozw0itY



https://youtu.be/MEF7ZZYmj34

Are you using YUV or RGB in pref > Display. I suspect YUV. You may want to try RGB and see if the issue is resolved. At every split, even if no transition, the footage is reencoded with CPU encoding. As such, in pref > Hardware Acceleration, make sure hardware decoding is not checked.

Jeff

Quote

Are you using YUV or RGB in pref > Display. I suspect YUV. You may want to try RGB and see if the issue is resolved. At every split, even if no transition, the footage is reencoded with CPU encoding. As such, in pref > Hardware Acceleration, make sure hardware decoding is not checked.

Jeff

Thanks for responding Jeff.

I tried both of these suggestions and rendered after each pref change. Still seeing the problem. Then for giggles I restarted PowerDirector (just in case) (because the turn it off and on suggestion is always forthcoming...lol). The problem persists.

It is frustrating to have a feature that I have been using for years in older versions of PD broken for such a long period of time. Other people must be seeing this, I doubt my environment is all that unique. I have workarounds of course (like not using SVRT) but my general workflow is perfect for that feature.

Most of my videos are pretty simple as follows and SVRT preserves the original quality while reducing my render time significantly:

fade in to intro clip from camera one (approx 15 seconds): switch to camera 2 (no transition) (3 minutes) : switch back to camera 1 (5 seconds) then fade out.



Again, thanks for your time and suggestions. I appeciate it.

Quote Thanks for responding Jeff.

I tried both of these suggestions and rendered after each pref change. Still seeing the problem. Then for giggles I restarted PowerDirector (just in case) (because the turn it off and on suggestion is always forthcoming...lol). The problem persists.

It is frustrating to have a feature that I have been using for years in older versions of PD broken for such a long period of time. Other people must be seeing this, I doubt my environment is all that unique. I have workarounds of course (like not using SVRT) but my general workflow is perfect for that feature.

Most of my videos are pretty simple as follows and SVRT preserves the original quality while reducing my render time significantly:

fade in to intro clip from camera one (approx 15 seconds): switch to camera 2 (no transition) (3 minutes) : switch back to camera 1 (5 seconds) then fade out.



Again, thanks for your time and suggestions. I appeciate it.

I gave up on SVRT as it always had issues of one form or another for me. When it works it's great, but for me and my clips that was just too infrequent. If you attach a clip and pds project that has the issue for you, maybe a unique solution can be found that keeps SVRT and prevents full encoding.

For reference, PD16 never had YUV display, it was introduced at PD18 and often these color changes associated with non-default GPU settings, say color adjustments. For most of PD pref settings, it is often best to make change shutdown PD and restart. If not, some appear to not take effect.

Jeff

Quote

I gave up on SVRT as it always had issues of one form or another for me. When it works it's great, but for me and my clips that was just too infrequent. If you attach a clip and pds project that has the issue for you, maybe a unique solution can be found that keeps SVRT and prevents full encoding.

For reference, PD16 never had YUV display, it was introduced at PD18 and often these color changes associated with non-default GPU settings, say color adjustments. For most of PD pref settings, it is often best to make change shutdown PD and restart. If not, some appear to not take effect.

Jeff

Yeah, I had given up on it with 365 as well but when my subscription came up for renewal I needed to decide what was more important to me, faster rendering times or some new bells and whistles. For 5 days I went back to my old PD16 and was happy with the SVRT working and fast rendering but there are some other advantages to 365 over the bells and whistles. I wish I could have both.

I can easily attach a project and clip but if it cannot be reproduced with your own clip I'm not sure it buys me anything as that would mean I have something local and somewhat unique on both of my machines. As I've said, it happens across multiple machines, multiple cameras, multiple source resolutions and framerates. Now, if there is some magical logging switch that would allow me to see which codecs are being picked up or decisions being made at render time to compare with somebody whose SVRT is working that would be a plus.

attached files all reside in:
C:\Users\Public

Quote Yeah, I had given up on it with 365 as well but when my subscription came up for renewal I needed to decide what was more important to me, faster rendering times or some new bells and whistles. For 5 days I went back to my old PD16 and was happy with the SVRT working and fast rendering but there are some other advantages to 365 over the bells and whistles. I wish I could have both.

I can easily attach a project and clip but if it cannot be reproduced with your own clip I'm not sure it buys me anything as that would mean I have something local and somewhat unique on both of my machines. As I've said, it happens across multiple machines, multiple cameras, multiple source resolutions and framerates. Now, if there is some magical logging switch that would allow me to see which codecs are being picked up or decisions being made at render time to compare with somebody whose SVRT is working that would be a plus.

attached files all reside in:
C:\Users\Public

I could repeat the issue with your footage in PD21 and absence of the issue in PD16. The issue appeared to start at PD18. The two dimmed issues occur in the region as one goes from SVRT (no encoding) to CPU encoding prior to and after the two splits.

I could not define an acceptable profile or a setting that prevented the dimming issue. It appears inherent to this footage and recent PD18 to current SVRT "improvements". I did notice many SVRT anomalies in the PD21 interface SVRT track and profiles with your source footage that I don't see with my footage.

Typically, SVRT does not work well with highly variable bitrates in source footage, often not even an option. Your footage, as well as most GoPro footage has rather variable bitrates and this sample file the bitrate spans from ~55 Mbps to over ~100 Mbps with an average of about ~70 Mbps. If you read SVRT rules, one will see "The bitrate is similar to that of the destination export profile.".

I tried to replicate this issue with my Canon video cameras and could not. My source file bitrate is very near constant. I do not see this dimming issue in PD21 near the split regions.

One could submit to CL support, I'd doubt any real resolution would be forthcoming. Probably best to stick with PD16 or accept the fact you need to encode the entire timeline for acceptable results is my view of your issue.

Jeff

Quote
One could submit to CL support, I'd doubt any real resolution would be forthcoming. Probably best to stick with PD16 or accept the fact you need to encode the entire timeline for acceptable results is my view of your issue.

If I was a CL employee (and I was allowed to read this forum) I would be very appalled and upset reading this. Users apparently have given up hope that there will be any repairs for bugs and flaws that are obviously already around for 3 or more versions.

Or, I would be very satisfied and pleased. Bugs are accepted, let’s continue adding stickers and fonts.

So far, I have seen that CL support very responsive, and sometimes they listen. I would certainly report the problem and see what happens.

Quote

I could repeat the issue with your footage in PD21 and absence of the issue in PD16. The issue appeared to start at PD18. The two dimmed issues occur in the region as one goes from SVRT (no encoding) to CPU encoding prior to and after the two splits.

I could not define an acceptable profile or a setting that prevented the dimming issue. It appears inherent to this footage and recent PD18 to current SVRT "improvements". I did notice many SVRT anomalies in the PD21 interface SVRT track and profiles with your source footage that I don't see with my footage.

Typically, SVRT does not work well with highly variable bitrates in source footage, often not even an option. Your footage, as well as most GoPro footage has rather variable bitrates and this sample file the bitrate spans from ~55 Mbps to over ~100 Mbps with an average of about ~70 Mbps. If you read SVRT rules, one will see "The bitrate is similar to that of the destination export profile.".

I tried to replicate this issue with my Canon video cameras and could not. My source file bitrate is very near constant. I do not see this dimming issue in PD21 near the split regions.

One could submit to CL support, I'd doubt any real resolution would be forthcoming. Probably best to stick with PD16 or accept the fact you need to encode the entire timeline for acceptable results is my view of your issue.

Jeff

Jeff,

I want to thank you for having invested your time (lots of it) and effort into looking at this. At least I know it isn't just me and I'm not going crazy (sometimes that is enough). It's also good for me to know that it's been "broken" in this scenario for several versions and not just in 21. I've working in software long enough to know the priority that would be assigned to something like this with multiple workarounds present. It's not like they'd advertise v22 with "now with fixed SVRT for variable bitrate source".

I would hope that with the prevelance of action cameras that it might eventually be looked at but I suspect many people upscale or downscale when rendering anyway so perhaps my use case is a bit of an outlier. I doubt it though...these days 90% of people are either capturing video with their cell phones or action cameras (sometimes DSLRs). Yes, you occasionally see full fledged camcorders but they are getting more and more rare.

So, one more question then. Do you know of a way for me to turn off SVRT and keep it turned off (other than selecting a different profile to encode with). Perhaps there is a "hidden" registry setting to disable it altogether. I still want to encode with my closly matching profiles without PD automagically turning on the SVRT checkbox.

Again, I appreciate the time and effort.

Quote


If I was a CL employee (and I was allowed to read this forum) I would be very appalled and upset reading this. Users apparently have given up hope that there will be any repairs for bugs and flaws that are obviously already around for 3 or more versions.

Or, I would be very satisfied and pleased. Bugs are accepted, let’s continue adding stickers and fonts.

So far, I have seen that CL support very responsive, and sometimes they listen. I would certainly report the problem and see what happens.

I will definitely consider contacting support but I am not optimistic of a fix given that the problem has apparently been around for years.

Quote So, one more question then. Do you know of a way for me to turn off SVRT and keep it turned off (other than selecting a different profile to encode with). Perhaps there is a "hidden" registry setting to disable it altogether. I still want to encode with my closly matching profiles without PD automagically turning on the SVRT checkbox.

I'm not sure I fully understand the question. Typically, PD just remembers the last produce setting. So if you unselect SVRT, your next PD session would not have SVRT active. If SVRT is not active, but say Nvidia encoding was selected, your next session would have Nvidia encoding selected. If nothing was selected in "Fast video rendering technology:" CPU encoding would be used for the next session.

I've not seen a method to hardcode permanently, CPU, SVRT, hardware (Nvidia, AMD, Intel) encoding as a permanent default, but I've never desired such a feature.

I typical create my preferred profile settings and appropriately name and mange things that way. Sometimes I have to use CPU encoding when hardware based encoding has issue in PD. Sometimes I have to turn off hardware decoding in pref to get acceptable results. The most robust method I've seen has been no hardware decoding and no "Fast video rendering technology" (SVRT or Hardware) but that comes with significant encode times for some formats and timelines.

Jeff

Quote

I'm not sure I fully understand the question. Typically, PD just remembers the last produce setting. So if you unselect SVRT, your next PD session would not have SVRT active. If SVRT is not active, but say Nvidia encoding was selected, your next session would have Nvidia encoding selected. If nothing was selected in "Fast video rendering technology:" CPU encoding would be used for the next session.

I've not seen a method to hardcode permanently, CPU, SVRT, hardware (Nvidia, AMD, Intel) encoding as a permanent default, but I've never desired such a feature.

I typical create my preferred profile settings and appropriately name and mange things that way. Sometimes I have to use CPU encoding when hardware based encoding has issue in PD. Sometimes I have to turn off hardware decoding in pref to get acceptable results. The most robust method I've seen has been no hardware decoding and no "Fast video rendering technology" (SVRT or Hardware) but that comes with significant encode times for some formats and timelines.

Jeff

It would be lovely if it remembered globally but in my experience it does not.

Just for giggles I tried it just now. Here is what I tried:
1) new project
2) add clip (from my Go 2)
3) selected my go2 profile
4) deselect SVRT
5) save
6) render
7) shutdown PD
start up PD (new project)
9) different clip from Go 2
10) go to export ... SVRT is checked!!!

It's a small thing to have to remember to uncheck but a bit of a pain in the you know what :

Quote


It would be lovely if it remembered globally but in my experience it does not.

Just for giggles I tried it just now. Here is what I tried:
1) new project
2) add clip (from my Go 2)
3) selected my go2 profile
4) deselect SVRT
5) save
6) render
7) shutdown PD
start up PD (new project)
9) different clip from Go 2
10) go to export ... SVRT is checked!!!

It's a small thing to have to remember to uncheck but a bit of a pain in the you know what :

Not sure, maybe something unique with PD365(subscription) vs my PD21(perpetual). I repeated your steps with your footage provided prior, at step 10 SVRT was not checked. Does your PD16 behave the same?

You could put in a suggestion at File > Rate Us & Provide Suggestions on what you'd like to see.

Jeff