Resolve 16, 60FPS looks like 30FPS (NVENC)

Hi all,

I posted months ago about an audio skipping issue with Resolve and NVENC encoded video (slightly variable framerate). This is gameplay video, not professional. The problem has been completely fixed but now I have another issue preventing me from using Resolve.

I have a short 60FPS video which is simply me scrolling back and forth over some terrain and buildings in a game. It's smooth, and MediaInfo shows it as 60FPS. I bring this into Vegas, simply encode it using my typical YouTube settings, and the result is indistinguishable from the original. Smooth scrolling, MediaInfo reports 60FPS.

I do the same in Resolve, making sure project settings are 60FPS, and timeline is 60FPS. I encode it, and in MediaInfo the result reports 60FPS but when viewing the video it appears to be 30FPS. If I had to guess, every other frame appears to be missing. I feel like I simply missed a setting but I can't figure out what it is.

Thanks for any help,

Mark

One assumes that you're set to 60FPS on the export page right?

Could it be that the recorded video is 59.94, and you've set the timeline to 60.0? Seems to me that if you did that it might have the tendency to repeat frames, ie it's 60 fps but adjacent frames are duplicates. I don't have any experience in this but something you might check.

One assumes that you're set to 60FPS on the export page right?

Yep, it's set to 60 everywhere I could find, and the result says it's 60.

Here's some more info.

The original file, encoded by OBS Studio using NVENC, is variable frame rate.

Frame rate mode : Variable
Frame rate : 60.000 FPS
Minimum frame rate : 58.824 FPS
Maximum frame rate : 62.500 FPS

The result, encoded with Resolve, says it's 60.

Frame rate mode : Constant
Frame rate : 60.000 FPS


Here are the original and the Resolve recordings. You can see Youtube recognizes both as 60FPS videos. These are unlisted videos with monetization turned off and comments turned off.

Original:

Resolve:

You can see how the resolve version looks like a 30FPS video.

Original Clip Attributes


Project Settings


Render Settings


Let me know if you need to see anything else.

-Mark

Variable framerate and Resolve don't go together.

Variable framerate and Resolve don't go together.

Well, if they are intent on getting the YouTube crowd to use resolve it's something that needs to be fixed. The other editors can handle it so hopefully some day it will work. I'm tired of crashing in Vegas every 10 minutes.

Well, if they are intent on getting the YouTube crowd to use resolve it's something that needs to be fixed. The other editors can handle it so hopefully some day it will work. I'm tired of crashing in Vegas every 10 minutes.

Yeah, that's why I'm here too

If it's really a problem, try transcoding with Handbrake to a non-variable framerate format before using in Resolve.

Yes, but variable fps is atm. nothing good/well supported. Try to avoid it, by using capture tool which can properly capture screen at constant 60fps.

Yes, but variable fps is atm. nothing good/well supported. Try to avoid it, by using capture tool which can properly capture screen at constant 60fps.

I think that's the hard part for people outside of YouTube gaming recording to understand. The NVENC encoder is built into the NVidia video cards and takes no extra processing power, so we can play games without any lag. I have no idea why NVidia chose to make it VFR, I was surprised it was a variable framerate when I first found out about it.

I've sent the original files off to Blackmagic by request so it is something they are looking into. Maybe it's easy to solve and we'll get lucky. I think the simple answer is to force treat it like 60 and don't worry about audio sync because generally the encoder tries to compensate by raising the framerate slightly higher than 60 after it dips. I doubt Resolve is built to fudge things but maybe it can anyway.

Lightworks supports VFR clips by analyzing and creating an index file on import.

I wonder if the variable frame rate is a function of the game you're playing. Perhaps there's a setting in the game software that will make it constant. Something to look at.

I wonder if the variable frame rate is a function of the game you're playing. Perhaps there's a setting in the game software that will make it constant. Something to look at.

No, it's the NVENC encoder. NVidia makes it, embedded in the graphics cards. If the card gets too overloaded to show the game and encode it drops the framerate slightly, at least that's how it appears to work. It's an ingenious system, and the latest version on the RX series cards can look as good as software encoding.

Well, if they are intent on getting the YouTube crowd to use resolve it's something that needs to be fixed. The other editors can handle it so hopefully some day it will work. I'm tired of crashing in Vegas every 10 minutes.

Yeah, that's why I'm here too

If it's really a problem, try transcoding with Handbrake to a non-variable framerate format before using in Resolve.

Have you tried using a constant bitrate? I just read this on the NVIDIA forums, which makes me thing it's the bitrate control I'm using.

mcerveny's answer is correct. The frame rate has no meaning in NVENC other than deciding rate control parameters.

Now this could mean that even with a constant bitrate it could change framerate to keep it constant, which seems crazy, but I use CQP which is a constant quality control. Hmmm.

Here's the post and link that refers too.

https://devtalk.nvidia.com/default/topi ... -in-nvenc/

What about NvEncReconfigureEncoder() ?
I think that frame rate (frameRateNum/frameRateDen) is used only for estimating average frame rate input to NVENC to achieve rate control (eg. quality and size that is computed from "*BitRate" and "frameRateNum/frameRateDen") (rcParams - rateControlMode (CBR, VBR, CostQP ...), averageBitRate, maxBitRate, targetQuality). NVENC encode frame as fast as possible and do not add PTS/DTS to frame (only elementary stream).
Same as NVDEC decode frame as fast as possible and you must queue decoded frame before display to match PTS/DTS timing (https://devtalk.nvidia.com/default/topi ... play-rate/).

No, it's the NVENC encoder. NVidia makes it, embedded in the graphics cards. If the card gets too overloaded to show the game and encode it drops the framerate slightly, at least that's how it appears to work. It's an ingenious system, and the latest version on the RX series cards can look as good as software encoding.

Just to be specific, the improvements to NVENC in the Turing cards place it slightly ahead of x264 Fast preset in PSNR, which is not bad.

As others have mentioned OP, Resolve can't deal with VFR media. You'll have to experiment with taking load off the GPU to ensure you don't lose any frames, or transcode first with a different tool.

There should be mode in games/recording apps where you can force constant fps, eg. 60 and encode it this way. This should be easily possible these days. This would allow to have nice gaming footage inside your video. As for today so often gaming footage inside commercials etc. looks crap.

AMD Adrenalin drivers have user-adjustable Frame Rate Target Control. I'm certain NVENC or VCE can encode real time CFR 60 fps even when GPU 3D engine is stressed, as these are separate ASICs.

So the one blurb from the NVidia dev forum was the key. In CQP mode the frame rate floats slightly. I just made multiple recordings in CBR mode and each time was able to produce a fixed frame rate recording at 60FPS.

Unfortunately Resolve still produces bad output, with a 60FPS video showing 30FPS like performance. Time to upload the media and project file.

Original
https://drive.google.com/open?id=1BZb1H ... _DD2XQdA0N

Resolve Encode
https://drive.google.com/open?id=193AwV ... gRuIbFaXQx

Project File
https://drive.google.com/open?id=1buBRb ... -0hy57VGjz

Resuggesting that you try using Handbrake to transcode to a constant _Frame_ rate, not a constant bit rate. Handbrake's Video tab has options to set the Framerate value and to either Peak Framerate or Constant Framerate, select Constant Framerate.

Resuggesting that you try using Handbrake to transcode to a constant _Frame_ rate, not a constant bit rate. Handbrake's Video tab has options to set the Framerate value and to either Peak Framerate or Constant Framerate, select Constant Framerate.

I have no desire to introduce yet another piece to my workflow. I do appreciate the suggestion, I have handbrake, but it's easier just to edit in something else, even if it occasionally crashes. I *think* the Resolve team wants to fix this which is why I'm offering up examples.

In addition I did take care to use my terms correctly because it is darn confusing. Yes, constant BIT rate does effect FRAME rate in NVENC when it comes to comparing the BITRATE modes CQP and CBR. CQP will allow FRAME rate to float a bit. Why they did this? The explanation was to help the algorithm ensure a constant quality in CQP mode.

Original
https://drive.google.com/open?id=1BZb1H ... _DD2XQdA0N

Resolve Encode
https://drive.google.com/open?id=193AwV ... gRuIbFaXQx

Project File
https://drive.google.com/open?id=1buBRb ... -0hy57VGjz

Your original file is not good. It's till VFR:
Frame rate mode : Variable
Frame rate : 60.000 FPS
Minimum frame rate : 58.824 FPS
Maximum frame rate : 62.500 FPS

Have you tried in such a case set 60fps at clip attribute level (you may loose audio sync though)?

Original
https://drive.google.com/open?id=1BZb1H ... _DD2XQdA0N

Resolve Encode
https://drive.google.com/open?id=193AwV ... gRuIbFaXQx

Project File
https://drive.google.com/open?id=1buBRb ... -0hy57VGjz

Your original file is not good. It's till VFR:
Frame rate mode : Variable
Frame rate : 60.000 FPS
Minimum frame rate : 58.824 FPS
Maximum frame rate : 62.500 FPS

Have you tried in such a case set 60fps at clip attribute level (you may loose audio sync though)?

Bah, I must have read constant bitrate thinking it was framerate. Well, that explains it then.

As far as I know clip attribute is set to 60? In edit mode I right click on clip and select attributes:

Hmm...try setting to eg. 50 and back to 60. It probably won't help, but maybe.

Original
https://drive.google.com/open?id=1BZb1H ... _DD2XQdA0N

Resolve Encode
https://drive.google.com/open?id=193AwV ... gRuIbFaXQx

Project File
https://drive.google.com/open?id=1buBRb ... -0hy57VGjz

Your original file is not good. It's till VFR:
Frame rate mode : Variable
Frame rate : 60.000 FPS
Minimum frame rate : 58.824 FPS
Maximum frame rate : 62.500 FPS

Have you tried in such a case set 60fps at clip attribute level (you may loose audio sync though)?

Am I missing something here ? Aren't we supposed to use the original VFR file to test with?

anyway, while it stutters a bit at the beginning and somewhere in the middle, it generally runs 60-fps smooth in player like MPC-HC, Pot Player and VLC...however it's always half fps in Resolve, repeating each frame twice, tried to trick it with 120 fps - no go...

Yes, but variable fps is atm. nothing good/well supported. Try to avoid it, by using capture tool which can properly capture screen at constant 60fps.

Premiere Pro and VEGAS Pro [16] have VFR Compensation. Edius Pro handles this very well. Lightworks handles it. iMovie and Final Cut Pro X handle it with aplomb (cause... iPhone). Most lower-end (consumer/prosumer) NLEs handle it - at least on Windows.

That's why people are expecting it to work in Resolve - it works in a lot of the other "popular" NLEs on the market. Can't really blame them.

VFR footage is very well supported across the industry. Just a few NLEs fail to support it well - Resolve being one of them... and probably Avid, because they're always a decade late for stuff like this (no one in that market uses them, anyways).

Premiere Pro and VEGAS Pro [16] have VFR Compensation. Edius Pro handles this very well. Lightworks handles it. iMovie and Final Cut Pro X handle it with aplomb (cause... iPhone). Most lower-end (consumer/prosumer) NLEs handle it - at least on Windows.

It may be possible that Resolve is not for you.

We've told all our post customers for more than a decade, "variable-framerate file formats are bad for post for a lot of reasons." You can choose to not listen to us, or to maybe stop and consider that we have a point.

I would also bet you're recording in a Long-GOP H.264 or H.265 codec, which is also bad for post. I strongly suggest that you convert this to DNxHD or DNxHR (or ProRes if you're on a Mac), at a constant framerate, and use that as the basis for your show. You'll get much better, more predictable results with better formats.

Beyond that, the answer would be not to use Resolve and go back to iMovie or FCPX.

Premiere Pro and VEGAS Pro [16] have VFR Compensation. Edius Pro handles this very well. Lightworks handles it. iMovie and Final Cut Pro X handle it with aplomb (cause... iPhone). Most lower-end (consumer/prosumer) NLEs handle it - at least on Windows.

It may be possible that Resolve is not for you.

We've told all our post customers for more than a decade, "variable-framerate file formats are bad for post for a lot of reasons." You can choose to not listen to us, or to maybe stop and consider that we have a point.

I would also bet you're recording in a Long-GOP H.264 or H.265 codec, which is also bad for post. I strongly suggest that you convert this to DNxHD or DNxHR (or ProRes if you're on a Mac), at a constant framerate, and use that as the basis for your show. You'll get much better, more predictable results with better formats.

Beyond that, the answer would be not to use Resolve and go back to iMovie or FCPX.

Let me worry about what's for me, and you worry about your post customers.

But thanks for the kind thoughts.

P.S. My post had nothing do with the formats I'm recording.

Sent from my SM-N960U using Tapatalk

The problem has to do with the format.

You can re-flag those files as CFR 60p.
Mkvtoolnix will do the job, but then you need to re-mux back to mp4 with eg. ffmpeg as Resolve doesn't support MKV.

You can re-flag those files as CFR 60p.
Mkvtoolnix will do the job, but then you need to re-mux back to mp4 with eg. ffmpeg as Resolve doesn't support MKV.

I'll give that a try. They start off MKV and OBS has a nice remuxer built in. Thanks.

It may be possible that Resolve is not for you.

We've told all our post customers for more than a decade, "variable-framerate file formats are bad for post for a lot of reasons." You can choose to not listen to us, or to maybe stop and consider that we have a point.

I would also bet you're recording in a Long-GOP H.264 or H.265 codec, which is also bad for post. I strongly suggest that you convert this to DNxHD or DNxHR (or ProRes if you're on a Mac), at a constant framerate, and use that as the basis for your show. You'll get much better, more predictable results with better formats.

Beyond that, the answer would be not to use Resolve and go back to iMovie or FCPX.

Hi Marc,

so the only reason many of us amateurs are here is because Resolve seems to be making a push to get into the prosumer market via Youtube, where we use many of these tools every day. They don't have too do this, but I'm here to encourage Resolve to find a way to support these VFR issues because there's a lot of us that need them and what Resolve can provide.

They don't have to do this, I'm simply giving them all the information I have to see if they can.

If you have the Studio version, try the Frame Blending option under Retime and Scaling.

This is not the solution.
We want original frames, not some interpolated ones.

You can re-flag those files as CFR 60p.
Mkvtoolnix will do the job, but then you need to re-mux back to mp4 with eg. ffmpeg as Resolve doesn't support MKV.

I'll give that a try. They start off MKV and OBS has a nice remuxer built in. Thanks.

It's not about re-wrapping itself. You need to to set 60p and probably also tick "fix timings". These are options of mkvtoolnix not every re-wrapping tool.

Curious, I will have started by transcoding the clip in DNXHR HQX + use Constant Bit Rate. Not tested.

Mark doesn't want to transcode.

It may be possible that Resolve is not for you.

We've told all our post customers for more than a decade, "variable-framerate file formats are bad for post for a lot of reasons." You can choose to not listen to us, or to maybe stop and consider that we have a point.

I would also bet you're recording in a Long-GOP H.264 or H.265 codec, which is also bad for post. I strongly suggest that you convert this to DNxHD or DNxHR (or ProRes if you're on a Mac), at a constant framerate, and use that as the basis for your show. You'll get much better, more predictable results with better formats.

Beyond that, the answer would be not to use Resolve and go back to iMovie or FCPX.

Hi Marc,

so the only reason many of us amateurs are here is because Resolve seems to be making a push to get into the prosumer market via Youtube, where we use many of these tools every day. They don't have too do this, but I'm here to encourage Resolve to find a way to support these VFR issues because there's a lot of us that need them and what Resolve can provide.

They don't have to do this, I'm simply giving them all the information I have to see if they can.

Anytime someone says this application is deficient in an area where most others aren't, people like him jump in to say "it may not be for you."

That's just a rewording of the age old "so, why are you here?" forum meme.

And it's a tired one.

Sent from my SM-N960U using Tapatalk

Beyond that, the answer would be not to use Resolve and go back to iMovie or FCPX.

If not those two Resolve would be still at stage of 100K$ price for ability to import DPX and TIFF only

Let me worry about what's for me, and you worry about your post customers.

Bear in mind that when people ask for free advice on the internet, sometimes the answers you get may not be what you expect or what you'd prefer to hear, but it doesn't make the advice wrong. More people than me have told you the same thing in different ways, so I think the weight of rationality is on our side. Variable frame rates and H.264 are just awful for post (meaning editing, sound mixing, and distribution), and there is no easy way around that.

so the only reason many of us amateurs are here is because Resolve seems to be making a push to get into the prosumer market via Youtube, where we use many of these tools every day. They don't have too do this, but I'm here to encourage Resolve to find a way to support these VFR issues because there's a lot of us that need them and what Resolve can provide.

There's always the point where you're just asking for something unreasonable and uncommercial. It's kind of like telling Tesla, "hey, I'd love to buy one of your $120,000 electric cars, but I've only got $10,000. Can you make me a $10,000 version with most of the same functionality as the big cars? You'd sell a lot of them!"

There's a point where you're outside the intended market that Resolve is trying to appeal to. I think an application that records video games is already so highly-specialized, it's beyond what cinematographers, TV show producers, filmmakers, film students, commercial people, and people shooting shorts for YouTube need.

Several people have provided the correct answer -- convert the H.264 variable-framerate material to an easier codec, like DNxHD or DNxHR 60fps constant-framerate -- and that will absolutely work. If you don't do that, the system is going to throw up under the strain of having to convert the footage AND make all the changes you want (editing and color) in the session. You can take our word for it, or you can ignore it at your own peril -- it's totally your choice.

Let me worry about what's for me, and you worry about your post customers.

Bear in mind that when people ask for free advice on the internet, sometimes the answers you get may not be what you expect or what you'd prefer to hear, but it doesn't make the advice wrong. More people than me have told you the same thing in different ways, so I think the weight of rationality is on our side. Variable frame rates and H.264 are just awful for post (meaning editing, sound mixing, and distribution), and there is no easy way around that.

so the only reason many of us amateurs are here is because Resolve seems to be making a push to get into the prosumer market via Youtube, where we use many of these tools every day. They don't have too do this, but I'm here to encourage Resolve to find a way to support these VFR issues because there's a lot of us that need them and what Resolve can provide.

There's always the point where you're just asking for something unreasonable and uncommercial. It's kind of like telling Tesla, "hey, I'd love to buy one of your $120,000 electric cars, but I've only got $10,000. Can you make me a $10,000 version with most of the same functionality as the big cars? You'd sell a lot of them!"

There's a point where you're outside the intended market that Resolve is trying to appeal to. I think an application that records video games is already so highly-specialized, it's beyond what cinematographers, TV show producers, filmmakers, film students, commercial people, and people shooting shorts for YouTube need.

Several people have provided the correct answer -- convert the H.264 variable-framerate material to an easier codec, like DNxHD or DNxHR 60fps constant-framerate -- and that will absolutely work. If you don't do that, the system is going to throw up under the strain of having to convert the footage AND make all the changes you want (editing and color) in the session. You can take our word for it, or you can ignore it at your own peril -- it's totally your choice.

I wasn't talking about my footage, I was responding to someone else - merely stating a fact. I am not the OP, so I dunno WTF you're even talking about.

I don't shoot with a phone or record game footage.

I'm merely stating that this deficiency is getting long in the tooth, considering everything else supports this footage.

Your response to me was a meme.

And that other part is misattributed to me. I didn't write that.

The way around it is so difficult, that almost every other major NLE has implemented it. Make more sense, please.

Considering what Petty stated, this seems well within the intended market for Resolve.

Sent from my SM-N960U using Tapatalk

Several people have provided the correct answer -- convert the H.264 variable-framerate material to an easier codec, like DNxHD or DNxHR 60fps constant-framerate -- and that will absolutely work. If you don't do that, the system is going to throw up under the strain of having to convert the footage AND make all the changes you want (editing and color) in the session. You can take our word for it, or you can ignore it at your own peril -- it's totally your choice.

There is no correct answer Marc, I have my own workflow that does not include taking time to convert.
I'm not on a video per week or per month schedule, it's more like daily videos where editing needs to be fast. I want to use Resolve for the feature set and are hoping they can find a way to support it like other video editors have. Adobe had the same answer 3 years ago before they finally added support for VFR. Reasoning was similar.

That's it. Either they do or they don't, they are the deciders on this. I bought Sony Vegas with money that could have been used to buy Resolve. There is a market for editors that support VFR devices, and adding VFR support can potentially increase the Resolve market share. I'm using it for games but video from most smart phones can also be VFR.

I see it as a business decision.

[Rohit Gupta]

Just to set the record straight we do support VFR clips else none of the phone recordings etc will ever work. In this case there is a specific pattern which is running into a bug. We will have a fix in a future update.

Just to set the record straight we do support VFR clips else none of the phone recordings etc will ever work. In this case there is a specific pattern which is running into a bug. We will have a fix in a future update.

Excellent news, thanks for looking into this and fixing the issue!

It may be possible that Resolve is not for you.

We've told all our post customers for more than a decade, "variable-framerate file formats are bad for post for a lot of reasons." You can choose to not listen to us, or to maybe stop and consider that we have a point.

I would also bet you're recording in a Long-GOP H.264 or H.265 codec, which is also bad for post. I strongly suggest that you convert this to DNxHD or DNxHR (or ProRes if you're on a Mac), at a constant framerate, and use that as the basis for your show. You'll get much better, more predictable results with better formats.

Beyond that, the answer would be not to use Resolve and go back to iMovie or FCPX.

Hi Marc,

so the only reason many of us amateurs are here is because Resolve seems to be making a push to get into the prosumer market via Youtube, where we use many of these tools every day. They don't have too do this, but I'm here to encourage Resolve to find a way to support these VFR issues because there's a lot of us that need them and what Resolve can provide.

They don't have to do this, I'm simply giving them all the information I have to see if they can.

I do not understand English well, but the essence is clear. Today I ran into the same problem and I don’t know what to do. And I agree with the tolakram. Yes, according to experts, this is probably unnecessary, but most consumers for one reason or another face this problem. And to say, like Mark, that a program is not possible for you, it is a reluctance to solve the problem. What's so hard to give people what they want. Personally, I initially switched to DaVinci Resolve as a friend advised me and I don’t want to switch to other programs or even try them, because I like DaVinci.