Quote Uploaded to the OneDrive.

Thanks, but that just has the plain clip, and not any of the edits in this image. Can you please upload that PDS file?

Quote Bottom line it is safe to say that GPU rendering lowers the quality. Something that I was able to prove at the beginning.

No, that's waaaay too broad a statement. Also, you found that the bitrate seemed to have been overwritten, which will drasticaly reduce the visual quality. I can produce various options quickly and you can decide.

Quote I don't think we will be able to produce any better quality than what it is.

It bugs me that the artifacts are there. Many people may not even see them but it makes me crazy....(just me).

Well this is the final cut (after adjusing bits and removing gpu rendering)

https://www.youtube.com/watch?v=AP26KircHGE

Anywhere that you see black you can notice tons of artifacts.

One thing to keep in mind is that YouTube completely re-renders everything into a streamable format, and that can sometimes affect the quality and make existing artifacts more obvious. Obviously we all want to have the best quality going in so that it ends up looking great in all resolutions.

Hi dk74, optodata, tomasc, Jeff et al -

In between doing a few other things, I tried to follow this thread but got myself tangled.

optodata - the clip you uploaded to OneDrive... is that the original clip from dk74's drone? Downloading now, so I hope so.

Earlier, in the absence of an original clip, I used this original clip from DJI P3P (shared by a forum member some time back) & rendered it in PDR17, using the closest profile I could make. Here's the produced file. Admittedly, there's no editing, titles, transitions etc... but there aren't any ghastly artefacts either.

Cheers - Tony
Visit PDtoots. PowerDirector Tutorials, tips, free resources & more. Subscribe!
Full linked Tutorial Catalog PDtoots happily supports fellow PowerDirector users!

Quote Hoptodata - the clip you uploaded to OneDrive... is that the original clip from dk74's drone? Downloading now, so I hope so.

Yes, that's OP's original clip. The packed project there isn't the full one he used for the Saturday Creek YT vid, but I'll update it as soon as the full one arrives.

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°

It's getting late here, but I've produced 7 versions of the "testingRenderingV2" project, which is OP's 35 sec clip with a title at the opening 4 seconds.

The 7 clips are: SVRT, nVidia hardware encoding, QuickSync encoding and CPU-only encoding. I also produced the last 3 using H.265 with a 60Mbps bitrate for artifact comparison. All clips, projects and screen captures are in the OneDrive folder I linked to in an earlier post.

The producing times are all very reasonable in H.264, but there's no way dk74 would ever want to use H.265 with a 3770K:

Clip Type	Produce Time
H.264 SVRT	0:18
H.264 nVidia	0:22
H.264 QS	0:30
H.264 CPU	0:35
H.265 nVidia	0:25
H.265 QS	1:08
H.265 CPU	6:36

Unfortunately, I don't have a 4k monitor, so when I view these clips fulls screen in VLC in HD, I might be seeing scaling artifacts as well as producing imperfections. I'll leave it to other members to evaluate the full screen 4k quality of each clip.

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

Thanks, but that just has the plain clip, and not any of the edits in this image. Can you please upload that PDS file?

I'll send it to you once I get home. Basically the original pds contains white balance correction thats it - thus the reason you can't use SVRT i.e

Quote
No, that's waaaay too broad a statement. Also, you found that the bitrate seemed to have been overwritten, which will drasticaly reduce the visual quality. I can produce various options quickly and you can decide.

There got to be a reason why bitrate is getting overwritten when using GPU and degrading the quality. You didn't experience the same on your produce?

Quote It's getting late here, but I've produced 7 versions of the "testingRenderingV2" project, which is OP's 35 sec clip with a title at the opening 4 seconds.

The 7 clips are: SVRT, nVidia hardware encoding, QuickSync encoding and CPU-only encoding. I also produced the last 3 using H.265 with a 60Mbps bitrate for artifact comparison. All clips, projects and screen captures are in the OneDrive folder I linked to in an earlier post.

I truly appreciate the help here - honestly!

I'll check them out once I'm home.

Thank you.

Optodata is an extremely lucky man here. The GOP pattern of IBBPBBPBBPBBP means there is only 1 keyframe (I) in every 13 frames that a left side trim on a clip will land by chance on that keyframe. As a result, SVRT is active and used here.

These 35 secs 4 frames test project is interesting. I already posted my results earlier in a pm. The H.264 SVRT of 18 sec. above is 20 sec. on my pc. See the attached screenshot for information.

Dk74 – The 5 to 1 file size ratio of GPU rendered versus CPU rendered clips you found has been reported in the past. I believe it has to do with the particular GPU and the driver used. 452 MB versus the 99.4 MB you obtained here. The GPU to CPU rendered clips can have a ratio closer to 1 depending on the graphics card and driver used.

Quote There got to be a reason why bitrate is getting overwritten when using GPU and degrading the quality. You didn't experience the same on your produce?

I know that you saw that in your original testing, but that's not anything I've ever encountered. I wonder if somewhere in your testing you might have unintentionally changed the produce profile. Things like that have happened to me at times, so it might help to double-check the results by producing each one again.

If you download all of my produced clips, you'll see that the H.264s are each 100Mbps and H.265s are 60Mbps. How they were produced had no effect on the bitrate setting I specified, which is what I'd expect to see on your PC as well.

Quote

I know that you saw that in your original testing, but that's not anything I've ever encountered. I wonder if somewhere in your testing you might have unintentionally changed the produce profile.

Only difference was to select/diselect gpu render. So no idea.

Quote Optodata is an extremely lucky man here. The GOP pattern of IBBPBBPBBPBBP means there is only 1 keyframe (I) in every 13 frames that a left side trim on a clip will land by chance on that keyframe. As a result, SVRT is active and used here.

These 35 secs 4 frames test project is interesting. I already posted my results earlier in a pm. The H.264 SVRT of 18 sec. above is 20 sec. on my pc. See the attached screenshot for information.

Dk74 – The 5 to 1 file size ratio of GPU rendered versus CPU rendered clips you found has been reported in the past. I believe it has to do with the particular GPU and the driver used. 452 MB versus the 99.4 MB you obtained here. The GPU to CPU rendered clips can have a ratio closer to 1 depending on the graphics card and driver used.

Honestly I wouldn't focus on SVRT tests. My SVRT tests also showed almost no artifacts.

In reality you will not be able to use SVRT because of grading etc... This is where degradation happens.

Quote I think you mean that with a constant 100Mbps bitrate, the 24p video will have more data per frame (4.16Mb/frame @ 24p vs. 3.33Mb/frame @ 30p). In theory, more data allows for higher quality in each frame.

Not exactly, because in both cases you are compressing from the same frame size, namely 3840x2160. Since end Mbps was fixed, yes the 24p has less compression per frame, but is lacking frames at only 24 vs say 60 per sec. At 100Mbps bitrate compression, one is typically well above common visible detection when things are done right for H.264. However, 24fps is way below adequate speed to catch anything of motion with recompression clarity. So yes, you get a better frame resolution with less compression at 24p for items that have no motion, so then simply take a still. When you have motion, 60fps is about the only way to get reasonable recompression clarity. This is especially true for glistening water, blowing grass, leaves, sky….. on and on. So, in this case, I do think you can get a much better compression clarity with higher fps vs the 24fps which was used, you have fast camera movement of fine features, grass.

The GPU encoding improper bitrate was common for AMD GPU’s with certain drivers and for PD17 H.265 it was never resolved. CL said they would notify when corrected, I’ve never seen a patch mention it. Many past posts on it over many releases and also pleased AMD hardware users as high bitrates are not of interest to them. I've not recently seen this issue with PD and Nvidia hardware. However, since you are color grading, entirely a CPU processing task in PD, it often is of little advantage to have the GPU do the encode in that situation. Your bottleneck will be the CPU doing color grading, the encode is only a small fraction of the total produce time.

Jeff

Quote Optodata is an extremely lucky man here. The GOP pattern of IBBPBBPBBPBBP means there is only 1 keyframe (I) in every 13 frames that a left side trim on a clip will land by chance on that keyframe. As a result, SVRT is active and used here.

These 35 secs 4 frames test project is interesting. I already posted my results earlier in a pm. The H.264 SVRT of 18 sec. above is 20 sec. on my pc. See the attached screenshot for information.

Not sure what you are trying to imply here, but a lucky man may or may not be one of them. The source file, P0430098.MP4, is anything but a GOP pattern of IBBPBBPBBPBBP. That is simply PD's standard GOP often used for H.264 and what was defined by "Profile Analyzer" which does not match source GOP patterns. Don't trust me, feel free to verify yourself. In this case the source has no B frames at all nor a length of anything near 13 frames.

In all, probably not important as OP has stated his desire to apply editing features incompatible with SVRT produce.

Jeff

Quote
The GPU encoding improper bitrate was common for AMD GPU’s with certain drivers and for PD17 H.265 it was never resolved. CL said they would notify when corrected, I’ve never seen a patch mention it. Many past posts on it over many releases and also pleased AMD hardware users as high bitrates are not of interest to them. I've not recently seen this issue with PD and Nvidia hardware. However, since you are color grading, entirely a CPU processing task in PD, it often is of little advantage to have the GPU do the encode in that situation. Your bottleneck will be the CPU doing color grading, the encode is only a small fraction of the total produce time.
Jeff

I am running AMD RX480 so seems like I'm impacted.

Quote

In all, probably not important as OP has stated his desire to apply editing features incompatible with SVRT produce.

Jeff

Correct. Especially if you may run in P-LOG where heavy editing will be required. SVRT will never be used.

So as I suspected it is the PD software issue with my hw (AMD).

Quote Not sure what you are trying to imply here, but a lucky man may or may not be one of them. The source file, P0430098.MP4, is anything but a GOP pattern of IBBPBBPBBPBBP. That is simply PD's standard GOP often used for H.264 and what was defined by "Profile Analyzer" which does not match source GOP patterns. Don't trust me, feel free to verify yourself. In this case the source has no B frames at all nor a length of anything near 13 frames.

The original file is 42 frames distance between keyframes(I) as Jeff has pointed out. I had assumed the custom profile in the new PD17 Profile Analyzer/SVRT matched that.

SVRT has been working on short clips in previous versions of PD. See this previous link on SVRT posted earlier on this thread: http://powerdirector.helpmax.net/en/appendix/svrt-when-can-i-use-it/ . “If the total duration of the production is less than one minute and any portion of the video requires rendering, the entire production will be rendered for efficiency reasons.” The 35 second clip here is less than 1 minute and SVRT in PD17 worked.

There is a trial of ColorDirector that has hardware decoding checked by default if one want to try that.

I've been going cross-eyed trying to figure this out. I can't offer anything useful on GOP patterns or GPU drivers, so I'll leave that to people who know what they're talking about.

optodata - I viewed (repeatedly) the original Parrot file & your rendered versions at full screen with monitor resolution set to 3840x2160, as well as doing my own set of renders produced to H.264 3840x2160 23.976fps @ 100Mbps

It's difficult to provide evidence of what I observed... screen captures add another complication, even though Camtasia was recording the UHD screen correctly... and screenshots only half tell the story because there's no motion (which is the root of the issue).

The best I could manage was these comparison screenshots (100% crop) from VLC Player showing the original, rendered file, rendered file with titles & another that was pre-rendered before adding titles (which made zero difference, BTW).

There's definitely some extra blockiness introduced in rendering when titles are on screen (i.e. more than rendering without titles or transitions). Yes, I know, that's the issue originally posted. BUT I couldn't replicate that issue using the DJI P3P clip I tested previously... so it's not as simple as "PDR's too weak" or "Titles cause image quality issues".

dk74 - next time you have your Parrot out for a fly at Mill Creek, try recording that same run along the creek using 3840x2160 @ 30fps &/or 1920x1080 @ 60fps. That's what I'd do anyway - just to compare the output from PDR. (I did that with my own drone when I first got it).

That all I got

Cheers - Tony
Visit PDtoots. PowerDirector Tutorials, tips, free resources & more. Subscribe!
Full linked Tutorial Catalog PDtoots happily supports fellow PowerDirector users!