Video Speed issue with high fps clips and hardware producing

optodata

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

Solved by

Dec 07, 2020 00:08

Here's something fun to start the week with.

I took a 720p 240fps clip and used the Video Speed tool to slow it down 8x so each frame would play out at 30fps. Using the timeline preview, everything is buttery smooth and it looks exactly as I expected.

However, when I use full nVidia hardware (NVENC+NVDEC) to produce the clip to the standard MPEG-4 1280 x 720/30p (16Mbps) profile, the output video does not have fluid, sequential frames. Instead it holds one frame for 8 frames then jumps ahead by 8 frames, resulting in a stop-motion video.

If I disable both NVDEC (turn off Enable hardware decoding under the Hardware Acceleration tab under preferences) and NVENC (uncheck Fast video render technology box on the Produce page), the CPU produces a perfect video.

So does using NVENC by itself. Even using both the CPU and NVDEC together works smoothly, so the problem only occurs when both NVDEC and NVENC are used together, which is the default hardware encoding setup.

I have packed a project with the 240p clip and the 4 output clips I produced, and they can be downloaded and tested from here. The problem clip is called "720p 30fps NVDEC + NVENC.mp4"

I'd like for at least one other member to confirm that using normal nVidia hardware encoding causes the same problem when producing before I report the issue. Note this is with the 457.30 Studio driver.

This message was edited 3 times. Last update was at Dec 07. 2020 16:07

tomasc

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

Dec 07, 2020 08:22

There seems to be a bug in the Video Speed Designer in the package presented here. The produced clips are only 100 sec. long. The source clip is 22 sec. 17 frames in a 59.94 fps TL, 22 sec, 8 frames in a 29.97 fps TL. In Speed Designer, it appears to be 12.5 sec. in a 29.97 fps TL. It is a 4.54x slowdown if we assume a 22 sec. Source clip. It is an 8x slowdown if we assume a 12.5 sec. Source clip(12ss15ff). The speed designer is not seeing the correct length of the source clip.

The source clip length appears correct in the PD17 speed designer to produce a 2:58:08(8x) clip. The use of nvidia hardware decoding and encoding a 720p30 16 Mbps mp4 produced the same bad jerky flying birds issue here. Found by mistake that producing 720p24 16 Mbps mkv(my previous project settings) gives good fluid flying birds in the video. Using the latest Geforce game driver. It looks like that the two issues presented may be separate ones.

This message was edited 2 times. Last update was at Dec 07. 2020 08:45

Warry

Senior Contributor Location: The Netherlands Joined: Oct 13, 2014 11:42 Messages: 853 Offline

Dec 07, 2020 08:37

I can confirm that CPU only gives the expected resul

However: CPU and NVDEC in my setup (maybe adding to the confusion) results also in a jumping birds video

tomasc

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

Dec 07, 2020 10:20

NVdec and cpu encoding doubled the rendering time to 32 sec. The birds are fluid in the video here. Did not test all configurations.

JL_JL

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

Dec 07, 2020 10:46

Quote There seems to be a bug in the Video Speed Designer in the package presented here. The produced clips are only 100 sec. long. The source clip is 22 sec. 17 frames in a 59.94 fps TL, 22 sec, 8 frames in a 29.97 fps TL. In Speed Designer, it appears to be 12.5 sec. in a 29.97 fps TL. It is a 4.54x slowdown if we assume a 22 sec. Source clip. It is an 8x slowdown if we assume a 12.5 sec. Source clip(12ss15ff). The speed designer is not seeing the correct length of the source clip.

The front end of the source clip was simply trimmed in the timeline for a timeline clip length of 12+sec. No issue with video speed.

Jeff

optodata

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

Dec 07, 2020 11:56

Thanks everyone!

To clarify, Jeff is correct that I trimmed the source clip on the timeline as there was a bunch of movement at the beginning that I didn't want to use. The Video Speed tool is set to 0.125x and the issue occurs at other settings, but it's more obvious at the slower settings. For example, at 0.25x the jumps are half as along and at 0.5x 1/4 as long but much less obvious.

It also doesn't matter what output profile is used. So far it seems like I have one confirmation and 2 "nothing going on here." The only test I need is to produce the project with fast video rendering unchecked but with Enable hardware decoding still checked.

Warry, these are actually mosquito-sized flies and I shot at 240fps to try and understand what each of them are doing in these weird swarms every evening at dusk. They bump into each other and just keep bobbing up and down for no reason I can imagine.

optodata

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

Dec 07, 2020 16:40

I now have some additional details.

The issue is not limited to nVidia. I get the same results when using QuickSync on my Surface Book 3 so I've updated the topic description.

Driver version is also irrelevant: the problem is present with nVidia's 457.30 Studio Driver and 457.57 Game Ready Driver and also with Intel's .7873 (Microsoft's most recent "official" SB3 video driver) and the latest OEM release .8935.

I've added the QuickSync sample to the linked OneDrive folder and have reported the issue on CS002271451.

AVPlayVideo

Senior Contributor Location: Home Joined: Apr 06, 2016 19:03 Messages: 703 Offline

Dec 07, 2020 17:55

Just out of curiosity I tested it here with my AMD Radeon RX570 gave the same problem with HA enabled, good with CPU usage only.
I did not register the rendering time it seemed to me the same. XEON-E5-2680 v4 / Mem. 16GB DDR4
M.2 NVME 512Gb / 2-SSD Sata3 1TB
AMD RX570 / Display Philips 272V8
Windows 11_64Pro / PD22/365

optodata

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

Dec 07, 2020 19:44

Thank you for testing. it looks like the issue occurs whenever PD hands off the slowed down video to any hardware encoder/decoder, which means the problem is internal to PD and not related to any specific driver API.