'Judder' on produced video...

GerryQ

Member Joined: Aug 26, 2015 14:43 Messages: 63 Offline

Solved by

Nov 13, 2019 11:00

Hi,

I've just been playing with a short video shot with a GoPro Hero 6.
The camera was facing out of the side window of a small helicopter...

I cut a 35 minute flight down to 3 minutes.

Files from the GoPro all mpeg PAL 4K 25fps
(I'm in the UK, and produce videos for old kit as well as new !)

Now, all looked great in the preview window - all smooth.
I 'Produced' into HD using h264. - again 25 fps...

However, upon watching the video, I noticed that the scene during take-off definitely has some issues. It seems to 'Jerk' the movement several times a second - as though movement was in steps.
Not massive, but noticeable and I wasn't happy...

I tried again with lens correction removed. - Same story.

I noticed that the video played fine in both timeline viewer and on the 'Produce' windows player...

Things to try...

I 'Produced' the same clip in h265 4K 25fps.
Now to my eyes at least, this was slightly better ! - Or was it a slightly faster 'Stepping' that was less annoying ? !

So now I turned off any hardware acceleration and tried again.
This time, the video produced far slower (No surprise, but now HD took much longer than 'Accelerated' 4K rendering).
I noted that whilst the HD versions with either lens correction applied or not had both been 324Mb in size, the resultant video was now 336Mb... (Hardware acceleration off produced a larger produced file size)
However, whilst marginally better, the 'Step movement' was still there ! - Seen as the view from the helicopter panned across the airport buildings.

I tried several viewers, not just PowerDVD to see if this was an issue - but it was there all the time.
The only viewer playing smoothly was from within PowerDirector 18 itself !

Yes, I checked... When I look at the file shot directly from the GoPro using PowerDVD, then everything is smooth as it should be, it is the 'Producing' that is causing the issue.

Playing around, I switched hardware acceleration back on and this time 'Produced' into mpeg2 (1920x1080 - still 25fps).
Now surprisingly, the 'Step movement' had gone !! - The video movement looked far better...
But naturally the file size was now much larger at 544Mb.

Now for the REALLY ANNOYING part...

I have a stand-alone version of PD-15 on my computer.
I could not import the pds file from PD-18 as not compatible, but I just loaded the take-off clip and 'Produced' it.
h264, 1920 x 1080 , 25fps exactly as before...

BINGO ! - Smooth video with no 'Step-movement' at all...

Anyone any idea as to what's going on ?

I had seen all the negative forum comments regarding PD-18, though not experienced any before today...
It would seem that PD-15 works better with my GoPro Hero 6 Black.

Why am I paying a subscription for an inferior product ?

I'm now going to have to trim all the the 35 minutes down to 3 mins once again this time in PD-15 to produce a video.
I've lost confidence in PD-18 for future work.
- I suppose I'm lucky that this is only 35 minutes of footage to work through...

But as I reached this point in writing the post...
I've just re-visited my previous projects from PD-18 to see what they look like - There are panning errors here as well - just that the helicopter pan highlighted the problem... The previous 'Hand-held' pans also have the same problem - Just that I'd thought them to be 'Operator error'. (The raw camera files are perfectly smooth whilst panning, the produced files judder whilst panning - I was better with the camera than I thought)

I'm 'Mightily Miffed ! ' - Thanks CyberLink - I've hours of work to re-do with an old program that you haven't 'Improved' !

optodata

Senior Contributor Location: California, USA Joined: Sep 16, 2011 16:04 Messages: 8630 Offline

Nov 13, 2019 14:14

It would really help to have more details, such as screenshots or screen recordings showing the problem. Better yet, actual copies of the source and produced clips, and even the actual project (if you're comfortable sharing them).

You can use Pack Project Materials... from PD's File menu and send everything to a cloud folder (Google Drive, OneDrive, etc.) and then paste the link to it here. That way, other people can try producing your exact project and see if the issues show up on other systems or if it might just be an issue with your setup.

It would also help to follow the steps listed in the Read Me Before Posting sticky thread so we can see what kind of shape your computer is in. The more info and specifics you can provide, the more likely it is that your fellow forum users be able to figure out what's going on.

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°

GerryQ

Member Joined: Aug 26, 2015 14:43 Messages: 63 Offline

Nov 13, 2019 19:18

Quote It would really help to have more details, such as screenshots or screen recordings showing the problem. Better yet, actual copies of the source and produced clips, and even the actual project (if you're comfortable sharing them).

You can use Pack Project Materials... from PD's File menu and send everything to a cloud folder (Google Drive, OneDrive, etc.) and then paste the link to it here. That way, other people can try producing your exact project and see if the issues show up on other systems or if it might just be an issue with your setup.

It would also help to follow the steps listed in the Read Me Before Posting sticky thread so we can see what kind of shape your computer is in. The more info and specifics you can provide, the more likely it is that your fellow forum users be able to figure out what's going on.

Hi optodata,

Many thanks for the reply.

To illustrate the problem, I am currently uploading some files to google cloud... Then I'll find out how to share them !

I have uploaded the raw clip taken via the GoPro Hero 6 Black - in 4K. Whilst short, it's still quite a large file at 658Mb

I have uploaded two rendered clips... One from PD15 and the other from PD18.
I have uploaded pds files - One from each program...

The GoPro clip was added to the time-line.
It was trimmed at the start and finish to the same length - around 36 seconds.
A lens correction was added - GoPro Hero 6 superview. (From downloaded library of such profiles)

The two rendered clips were both produced as h264 - 1920x1080 - 25fps - mpg files.
PD 15 version = 67.4Mb, PD 18 version = 66.1Mb (No great difference here)

Hardware acceleration was allowed with both programs.

Here's a notable feature.
My copy of PD15 took 26 seconds to render the clip.
My copy of PD18 took a mere 5 seconds ! (PD18 seems to recognise all hardware correctly and 'Optimise' quite well !)

My PC runs Win 10.
Ryzen 2700X, over-clocked to 4GHz, water-cooled.
Nvidia 1070 Graphics card. 8Gb
32 Gb RAM
Project files on SSD, Win 10 and program files run on alternative SSD, I tend to write my renders to a spinny disc archive drive...

Link to all files...
https://drive.google.com/drive/folders/1AafXncyJyCAOptTcBrIKYtrhkgk4Sg_q?usp=sharing

Now whilst I applaud the awsome speed of the render from PD18 - the clip doesn't look that good - Not to me anyway !

Video shot from the back of a tiny helicopter by my better half - it's not BBC quality, but this isn't her day job !

Thanks for looking.

Gerry

optodata

Senior Contributor Location: California, USA Joined: Sep 16, 2011 16:04 Messages: 8630 Offline

Nov 13, 2019 20:43

Thanks for sharing the files. I've run several versions through PD18 using ONLY the PD15 project file (to be more consistent with your results using PD15), and as far as I can tell, it's the hardware encoding in combination with the lens correction that causes the issue in PD18.

I made 4 versions of the clip: an As-Is version using the Best Matched Profile (4K/25p); the same profile but with No Lens Correction (these are labeled NLC); the HD profile that you're producing to (labeled HD); and again but without the lens correction (labeled NLC-HD).

I also produced using my GTX2070, my Intel UHD Graphics iGPU, and the CPU by itself. These are labeled nVidia, QS (for QuickSync) and CPU. There's also a single SVRT version which obviously has no lens correction and is 4K, and is essentially just the trimmed section of your original clip.

All clips are available for download here, and in my testing on HD monitors, the most obvious judder is on the HW-produced clips with the lens correction in place. I also tend to see it on all of the 4k clips, but that's likely due to VLC reducing the pixel size to fit on my HD monitor. I don't notice the judder on the HD, CPU-produced clip with the lens correction.

For reference, here are the producing times I saw:

	As-is (4K)	NLC (4K)	As-is (HD)	NLC (HD)
nVidia	0:29	0:12	0:06	0:08
QS	0:36	0:16	0:17	0:15
CPU	0:36	0:25	0:26	0:10
SVRT	n/a	0:05	n/a	n/a

This message was edited 1 time. Last update was at Nov 13. 2019 20:47

tomasc

Senior Contributor Joined: Aug 25, 2011 12:33 Messages: 6464 Offline

Nov 14, 2019 12:05

I did run GerryQ's PD15 project and see no problem in cpu and qs encoding in both 4k and HD.

I do see a problem in the TakeOff_PD18.mp4. Using VLC frame advance (E key) one can see that every 5th frame is a repeat of the fourth one causing the judder like when an extra frame has to be added to 24 fps to make 30 fps. I beleive that the problem is in the Nvidia encoding as the GOP is longer and missing all the b frames. The audio bitrate is also cut in half. See the screenshot.

I had to leave the pc on last light to download the Judder testing folder. I have tested and checked each produced clip. Optodata has duplicated exactly the problem in clip #6. The video GOP is bad and audio bitrate again is cut in half. The Nvidia encoders appear to produce these bad results under these conditions.

Clip#00-encode-res-GOPM=?,N=??-Audio bitrate-notes

01-cpu-4k-M-3, N=13-64 kb/s
02-cpu-hd-M=3, N=13-384 kb/s
03-cpu-4k-M=3, N=13-64 kb/s NLC
04-cpu-hd-M=3, N=13-384 kb/s NLC
05-nv-4k-M=3, N=13-64 kb/s
06-nv-hd-M=1, N=25-192 kb/s GOP is different and Audio bitrate is cut in half.
07-nv-4k-M=3, N=13-64 kb/s NLC
08-nv-hd-M=3, N=13-384 kb/s NLC
09-qs-4k-M=3, N=13-64 kb/s
10-qs-hd-M=3, N=13-192 kb/s Audio bitrate is cut in half.
11-qs-4k-M=3, N=13-64 kb/s NLC
12-qs-hd-M=3, N=13-384 kb/s NLC
13-svrt-4k-unknown-64 kb/s
14-Original-4k-M=1, N=13-192 kb/s

Notes: NLC = No Lens Correction, nv=Nvidia, qs=Intel Quick Sync.

Observations: When lens correction is enabled in HD resolution, audio bitrate is cut in half for both Nvidia and Quick Sync encoding. A custom profile was used in the 4k tests. Hopefully Cyberlink support can maybe work on a solution if Nvidia encoding is desired.


Filename	Take-Off mediainfo.jpg	Download
Description	Good encoding vs bad encoding causing the judder?
Filesize	359 Kbytes
Downloaded:	7 time(s)

This message was edited 1 time. Last update was at Nov 14. 2019 12:15

optodata

Senior Contributor Location: California, USA Joined: Sep 16, 2011 16:04 Messages: 8630 Offline

Nov 14, 2019 17:24

That's a very helpful analysis with some key technical findings!

Since the HW encoding is to blame for the glitches, unchecking the Fast video rendering technology option on the Produce screen will allow the CPU to cleanly produce videos. Fortunately, OP's machine is more than capable of doing that quickly.

One of us should submit this to tech support. I'm happy to do so, unless GerryQ wants to as he uncovered the issue.

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°

tomasc

Senior Contributor Joined: Aug 25, 2011 12:33 Messages: 6464 Offline

Nov 14, 2019 17:47

Quote That's a very helpful analysis with some key technical findings!

Since the HW encoding is to blame for the glitches, unchecking the Fast video rendering technology option on the Produce screen will allow the CPU to cleanly produce videos. Fortunately, OP's machine is more than capable of doing that quickly.

One of us should submit this to tech support. I'm happy to do so, unless GerryQ wants to as he uncovered the issue.

I agree that one of you should submit a ticket to tech support as this is a PD18 issue. LOL. Since the project is only 3 minutes long it may take only about 2 minutes to produce in HD with the cpu.

GerryQ

Member Joined: Aug 26, 2015 14:43 Messages: 63 Offline

Nov 15, 2019 07:05

Ye gods !

I am amazed, gob-smacked and totally impressed by the work and analysis undertaken by both tomasc and optodata in the pursuit of improving PD-18...

Both of you have my most heart-felt and sincerest thanks for the generosity of your time.

If either of you would like to raise this issue with CyberLink, then I'd be most grateful.

You are both avid contributors to this forum with vastly more experience than I.
(I do read far more than I post and recognise your previous inputs)

It would seem that I should pursue the route of removing the Nvidia's speed enhancement and see what I can 'Produce' without it.
The speed reduction may not fall that far behind PD-15 anyway.

I will have a play and advise as to what I discover on my machine.

I'm still shocked that you could actually diagnose the 4th/5th frame repeat so quickly !

Gerry

This message was edited 2 times. Last update was at Nov 15. 2019 08:44

GerryQ

Member Joined: Aug 26, 2015 14:43 Messages: 63 Offline

Nov 15, 2019 08:43

And so I have a solution...

All I had to do was simply 'Un-tick' the "Fast video rendering technology" check box...
Bottom left on the 'Produce' window.

I had earlier tried playing with the settings in the "Edit/Preferences" area to no avail. ( ! ? ! )

The take-off clip rendered in 24 seconds on my machine - still quicker than PD15 (26 seconds), but nearly 5 times slower than when using it (5 seconds).

The 'Produced' clip exhibited no judder in the movement !

File size was 67.2Mb against the faster rendering's 66.1Mb.

To correct my earlier projects, all I have to do is re-open them (I still have the pds files) and re-render.
OK, they'll be slower, but the longest is only 7 minutes...

Now this DOES still pose a question for the CyberLink team in as much that it means the "Fast video rendering Technology" is effectively useless on my machine with the Nvidia 1070 8Gb graphics card. This glitch seems to have only been introduced with PD18.

I note that I don't play games on this PC, the graphics card was chosen over offerings from AMD as it was better with PowerDirector when I purchased it a couple of years ago. I cannot use it with the program for the time being.
Please fix this CyberLink, as it wasn't a cheap component in the build !

Many thanks once again to Tomasc and optodata.

Gerry

JL_JL

Senior Contributor Location: Arizona, USA Joined: Oct 01, 2006 20:01 Messages: 6091 Offline

Nov 15, 2019 12:22

Quote I beleive that the problem is in the Nvidia encoding as the GOP is longer and missing all the b frames. The audio bitrate is also cut in half. See the screenshot.

06-nv-hd-M=1, N=25-192 kb/s GOP is different and Audio bitrate is cut in half.

I believe what you are observing in the GOP difference you state for clip #6 is a config difference, I don't believe optodata results are for CL as delivered product but the results are occurring from perhaps a 3rd party codec tweak. You might want to verify Format profile and Codec ID in the trimmed off section of your attached pic are indeed as expected for the PD18 product. That GOP structure does not exist in any version of PD I've seen without some user intervention unless subscription is unique in this regard.

Jeff

tomasc

Senior Contributor Joined: Aug 25, 2011 12:33 Messages: 6464 Offline

Nov 15, 2019 23:20

Quote

I believe what you are observing in the GOP difference you state for clip #6 is a config difference, I don't believe optodata results are for CL as delivered product but the results are occurring from perhaps a 3rd party codec tweak. You might want to verify Format profile and Codec ID in the trimmed off section of your attached pic are indeed as expected for the PD18 product. That GOP structure does not exist in any version of PD I've seen without some user intervention unless subscription is unique in this regard.

Jeff

I actually duplicated optodata's clip#10 results in PD17 as I ran a series of test on my own on a fairly new hardly used pc meant originaly for editing GoPro videos using their QUIK application. Did not knowing that optodata was doing the same type of testing at the time. See the screenshot. Audio bitrate is again cut in half in the QS encoding. Do not want to bring up anything about this because both Gary and Optodata had repeated the same issue.

I am having a terrible time trying to buy a newly released Nvidia super card as most retailers don't have them yet or are sold out and the only ones available are about $70 above msrp. Can't do testing here with Nvidia card until I get one.

Jeff - Is it possible that you ran the Nvidia encoding test here and got a different result. What would be a good tool to verify Format profile and Codec ID here...


Filename	Take-Off produced file properties.jpg	Download
Description	See what happens with Quick Sync encoding.
Filesize	285 Kbytes
Downloaded:	2 time(s)

JL_JL

Senior Contributor Location: Arizona, USA Joined: Oct 01, 2006 20:01 Messages: 6091 Offline

Nov 15, 2019 23:22

Quote I believe what you are observing in the GOP difference you state for clip #6 is a config difference, I don't believe optodata results are for CL as delivered product but the results are occurring from perhaps a 3rd party codec tweak. You might want to verify Format profile and Codec ID in the trimmed off section of your attached pic are indeed as expected for the PD18 product. That GOP structure does not exist in any version of PD I've seen without some user intervention unless subscription is unique in this regard.

Had some time to download the files and play a little on my platform. To me it looks like that strange GOP structure tomasc noted occurs in this one instance of clip #6 settings when one uses Hardware Decoding and then one experiences the frame repeat as tomasc pointed out and the playback jitter. Turn off Hardware Decoding and leave Hardware Encoding on, the GOP is then proper and no repeat frame issue and playback is smoother.

To me it appears as another new decode anomaly in PD18 with this clip #6 settings vs what I guessed earlier of some 3rd party codec causing the GOP anomaly for PD.

Jeff

tomasc

Senior Contributor Joined: Aug 25, 2011 12:33 Messages: 6464 Offline

Nov 16, 2019 01:01

Four heads can be better than two. From Jeff's post I can see now that Hardware decoding checked caused the audio bitrate to be cut in half when Intel QS is used. I ran each test twice to make sure. Here are the results as follow:
Pref HA/no Decode cpu/qs Encode, Produce time - File size:

01- ......hardware decode, cpu encode =28 sec. 69136 KB
02- no hardware decode, cpu encode =43 sec. 69201 KB
03 ........hardware decode, ...qs encode =16 sec. 70124 KB
04- no hardware decode, ..qs encode = 43 sec. 71556 KB

Observation: GOP is M=3, N=13, and audio bitrate is 384 bps in all 4 tests. File size increases slightly when no Hardware Decoding is used. Unchecking it fixed the audio bitrate cut in half problem in both PD17 and PD18. These problems only appear when Lens Correction is used. Encoding time increases significantly when Pref/HA/Hardware Decoding is unchecked. Jeff is right on this one!!

GerryQ

Member Joined: Aug 26, 2015 14:43 Messages: 63 Offline

Nov 17, 2019 10:19

Many thanks for your inputs.

I did indeed re-visit the previous few projects and re-rendered with the 'FVRT' box un-checked.
All produced videos with a marked improvement.

I hadn't even picked up on the audio change from the helicopter clip - after all, the noise of a 'Robinson R44' is hardly one for the discerning audiophile !

There was a 'Video' composed from the stills taken on the trip. I had added transitions and a sound track.
The only actual 'Movement' was the transitions themselves and there was requirement for neither lens correction nor colour enhancement as all this had been taken care of with the original photos.
I confirm I rendered this one in high speed - and all looked fine with the result.

The final project was actually 14 minutes long. There were lens corrections (GoPro) and some clips had LUTs applied (Shot under-water). I confess that I used high speed rendering for the HD version. (I don't personally use these ! ), but the 4K h265 version was rendered by the cpu alone. This took an age ! - I left it running when I went to bed.
Checking the result this morning I was pleased as to how it had turned out.

I can confirm that the judder error was independent of the use of the GoPro Hero 6. I have video recorded with my Fuji X-T3.
This camera alows a myriad of choices for the recording format, the clips were Long GOP, 4K, 25fps, 200mbps, 4:2:0 10 bit.
These clips behave in an identical way with regard to exhibiting 'Judder' when the Nvidia graphics are used to speed things up.

Over to CyberLink to explain why PD18 seems to not like playing and sharing its Fast rendering toys with the NVIDIA GeForce GTX 1070 graphics card. It's pretty much a standard choice ?

Gerry

JL_JL

Senior Contributor Location: Arizona, USA Joined: Oct 01, 2006 20:01 Messages: 6091 Offline

Nov 17, 2019 11:14

Quote These clips behave in an identical way with regard to exhibiting 'Judder' when the Nvidia graphics are used to speed things up.

Over to CyberLink to explain why PD18 seems to not like playing and sharing its Fast rendering toys with the NVIDIA GeForce GTX 1070 graphics card. It's pretty much a standard choice ?

As was mentioned, one can leave FVRT to use hardware encoding, just unselected hardware decoding from pref > Hardware Acceleration and I think you won't have your jitter. Try and see.

I doubt CL will explain anything about PD18 hardware encode and/or decode capability or lack thereof. The best a forum userbase can do is recommend items to work around the deficiencies.

Jeff

optodata

Senior Contributor Location: California, USA Joined: Sep 16, 2011 16:04 Messages: 8630 Offline

Nov 17, 2019 12:01

optodata

Senior Contributor Location: California, USA Joined: Sep 16, 2011 16:04 Messages: 8630 Offline

Nov 25, 2019 14:03

Good news! I've heard back from tech support that they have confirmed the issue on their nVidia test system and have forwarded the issue to engineering for resolution.

They also said:

We further found that the judder condition occurred when producing the video clip in 1080P/25 frame rate, but not occurred when producing it in 4K/25 frame rate.

As workaround, if you would like to edit the video now, you may choose to export the video in 4K resolution using hardware encoding, or apply software encoding to export the project in 1080P. It could be the possible solution.

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°

GerryQ

Member Joined: Aug 26, 2015 14:43 Messages: 63 Offline

Nov 26, 2019 06:58

Quote Good news! I've heard back from tech support that they have confirmed the issue on their nVidia test system and have forwarded the issue to engineering for resolution.

They also said:

We further found that the judder condition occurred when producing the video clip in 1080P/25 frame rate, but not occurred when producing it in 4K/25 frame rate.

As workaround, if you would like to edit the video now, you may choose to export the video in 4K resolution using hardware encoding, or apply software encoding to export the project in 1080P. It could be the possible solution.

Many thanks optodata...

So they say they didn't see this judder effect at 4K ??

If you read my original post, I conceded that the 4K looked better... Or was it that the 'Judder' was faster ?
I'll re-investigate.

At least they're looking into this, which is good.

4K is where the hardware help is really needed - HD generally renders fairly quickly (Using my PC anyway.)

That said, the last clip from the latest batch, 14 minutes long, with lens corrections and a few underwater colour corrections...
The 'HD' render took OVER 4 HOURS ! - It was like going back in time to when I was rendering in windows 98.
I will have to cut far more next time.

Thanks once again for your help,

I await the next PD18 update with interest.

JL_JL

Senior Contributor Location: Arizona, USA Joined: Oct 01, 2006 20:01 Messages: 6091 Offline

Nov 26, 2019 07:54

We further found that the judder condition occurred when producing the video clip in 1080P/25 frame rate, but not occurred when producing it in 4K/25 frame rate.

As workaround, if you would like to edit the video now, you may choose to export the video in 4K resolution using hardware encoding, or apply software encoding to export the project in 1080P. It could be the possible solution.

The issue is very clearly to see if one produces to 4K/25fps with hardware decode and encode so obviously difference in platforms or CL didn't debug sufficiently. The underlying issue appears the same as tomasc noted with the repeated frame.

The best workaround maintaining some produce speed until CL properly debugs is to simply not use hardware decoding, just use hardware encoding.

Jeff

This message was edited 1 time. Last update was at Nov 26. 2019 07:57