Legacy film frame rates

Scratch can do it. Please make it so that Resolve can handle legacy film frame rates such as 16 and 18fps.

In Super 8, for example, it's possible to have 18fps with sound. While we can work around the picture part of things by treating everything as 24 and then loading that up in Scratch when we're done to render out to 18fps, it gets complicated with audio.

Please, Please, Please add native support for these frame rates.

-perry

I should point out that by Native Support, what I mean is this:

1) Import at 16 or 18 (or other) frame rates, and have the file reflect that rate
2) When you make a new timeline from that file, have that timeline default to that frame rate
3) when playing back, play back the video at that frame rate (I get that this can be tricky, since output is over SDI, which doesn't support those frame rates. perhaps the rate can be pulled up in real time in the same way 23.98p can be displayed at 59.94i
4) when you export, allow selection of that frame rate in the export window

Basically, one should be able to import, work with and export a file at a legacy frame rate without the application trying to conform it to a broadcast standard rate.

Thanks!

This very much please. I've run across films originally shot at everything from 12 to 36fps. I just want to be able to work with it at the original frame rate and then export it in the original frame rate. Even if it does need to be conformed to current broadcast standards that should be the final step, totally separate from any grading and editing.

I've really curious what people who have the Blackmagic 16mm scanner do? After all, there are all sorts of odd legacy film frame rates out there. I can't believe that Blackmagic can't play back films scanned on its scanner.

I should point out that by Native Support, what I mean is this:

1) Import at 16 or 18 (or other) frame rates, and have the file reflect that rate
2) When you make a new timeline from that file, have that timeline default to that frame rate
3) when playing back, play back the video at that frame rate (I get that this can be tricky, since output is over SDI, which doesn't support those frame rates. perhaps the rate can be pulled up in real time in the same way 23.98p can be displayed at 59.94i
4) when you export, allow selection of that frame rate in the export window

Basically, one should be able to import, work with and export a file at a legacy frame rate without the application trying to conform it to a broadcast standard rate.

Thanks!

You can set the timeline to play back at at frame rate you like in the master project settings. If you have a 25fps sequence and play back at 16 then things will look slow but I'm sure that if you had everything at 16fps in the first place then that side of things should be covered.

Having said that, if you bring in 16fps footage into a 25fps sequence and have your mixed frame rate settings set to 'None', then it will be shorter, such that if you now play back at 16fps it will cancel out and play back in real time. Then all you do is export as an image sequence, or maybe a QT file if you can find software that will conform the frame rate to 16fps again. Problem solved?

You can set the timeline to play back at at frame rate you like in the master project settings. If you have a 25fps sequence and play back at 16 then things will look slow but I'm sure that if you had everything at 16fps in the first place then that side of things should be covered.

This only addresses playback within the application. You still can't render out at the native frame rate, because Resolve forces you to use a preset list of frame rates, none of which include legacy frame rates.

Scratch allows you to specify the frame rates at each stage of the process, so you can easily work with non-broadcast frame rates. Resolve should too.

Yes, you can kind of work around it by exporting an image sequence, but if the deliverable is QuickTime you can't do it. I appreciate the suggestions, but it's a clunky workaround for a problem that shouldn't exist. A feature length film at 4K is many terabytes as an image sequence, which then has to be loaded into another application if you need to make a containerized file. That's a lot of unnecessary data wrangling and wasted disk space.


Sent from my iPhone using Tapatalk Pro

Yes this please. My goal is to output a file that is at the 16 (or 18) frames-per-second speed that the original film was shot at. But then I found Resolve 14 doesn't do that.

I'm importing scans of 8mm/Super-8 as uncompressed TIFF sequence-of-images. On the timeline, I can tell Resolve to playback at 16FPS. But when I go to output the edited/graded movie, I get 'Fractured Flickers' 24fps playback.

As the input is a sequence-of-images, I figured I could slow the clips down on the timeline to get the proper speed playback, albeit with some form of pull-down to make up the mis-match between the clip playback rate and the output frames-per-second rate. Here's what I found out:

•1 – The only way you can get a custom speed on the editing timeline – one other than 75%/50%/25%/10% on the drop-down menu – is by grabbing the clip's speed handle and arbitrarily stretching it. Really hard to hit 66% consistently that way (converting 16fps to timeline 24fps.)

•2 – Resolve handles the speed stretching by interpolating the frames in between the actual frames. The method Resolve uses looks like interlaced footage. It appears that the interpolation routine uses odd rows from one frame and even rows from the other.

The interlace look is unacceptable. The trick might work, though, if the slowing down to 50% involved the complete doubling of each frame in the original, as in a 1-1-2-2-3-3-4-4-5-5-6-6 sequence

I don't know what I'll do when I start working on the 18fps stuff. It could be done with a 24fps output and a doubling of every third frame thus, 1-2-3-3-4-5-6-6-7-8-9-9, but that would introduce an extremely noticeable judder in the output.

So yes, please, make Resolve ingest and output at 16fps and 18fps at least.

Karen,

The way do this (now) is to bring the file into resolve with a 24fps timeline frame rate. Then change the Clip Attributes in the bin so the scan is at 24fps. Do your grading in Resolve at 24fps, and export to a 24fps image sequence. Now bring that image sequence into Scratch (which you can get for $75/mo, paying for it as you need it). In Scratch, you can specify the frame rate for the clip as 18, and the Construct as 18, and your export as 18. You can specify whatever frame rate you want in Scratch.

If you do it this way, you don't have to do any time stretching, which could result in artifacting. But it's a major pain to work with audio this way, it means having a second application around for doing the export, and it means you're generating a whole new set of very large files when you render from Resolve just to bring it into Scratch. Prepare to have lots of free disk space for this. but it does work, and it's the closest we can get to native support of odd frame rates at the moment.

+1....

Maybe I'm doing this wrong, but if you create a timeline at say, 60 fps and put your clips on the timeline, you no longer can change the project framerate. In Delivery, you can only use the project framerate. So it's impossible for us to make a 30fps proxy render of our project without creating a new timeline and adding everything back in?

Having a set of predefined framerates is strange, yes, but so is the inability to change the framerate for any delivery format.

I do a lot of highspeed work and we pick framerates arbitrarily, like it might be 400 or 1000 or 1150. There's really no way to work with those in Resolve as-is, right?

There is- you import and interpret them as 24/25/30/60 whatever you need.
Have you shot this 1000fps video to play it at 1000fps?
It's basically impossible to have timeline at 1000fps purely due to needed computation restrictions.
I agree that more fps choices are needed as current ones are a bit "legacy".
Problem is that because Resolve is free people keep asking about almost every possible feature.

Can you imagine having ability to set timeline to 1000fps and people importing 24p footage and trying to use motion adaptive interpolation to get 1000fps? Good luck with this

Yes, you can kind of work around it by exporting an image sequence, but if the deliverable is QuickTime you can't do it. I appreciate the suggestions, but it's a clunky workaround for a problem that shouldn't exist. A feature length film at 4K is many terabytes as an image sequence, which then has to be loaded into another application if you need to make a containerized file. That's a lot of unnecessary data wrangling and wasted disk space.


Sent from my iPhone using Tapatalk Pro

You can use Cinema Tools on Mac to change QT fps, but 16/18fps are not supported.
You can get some developer to make such a tool for QT. It should not be that difficult at all. In this case you export e.g. 24p and later change fps (and also with QT Pro you can add your original audio).

You can also export 24p MOV and then use ffmpeg to adjust framerate with copy video command (and again- adding original audio). No need to use huge image sequences exports.

Yes, you can kind of work around it by exporting an image sequence, but if the deliverable is QuickTime you can't do it. I appreciate the suggestions, but it's a clunky workaround for a problem that shouldn't exist. A feature length film at 4K is many terabytes as an image sequence, which then has to be loaded into another application if you need to make a containerized file. That's a lot of unnecessary data wrangling and wasted disk space.


Sent from my iPhone using Tapatalk Pro

You can use Cinema Tools on Mac to change QT fps, but 16/18fps are not supported.
You can get some developer to make such a tool for QT. It should not be that difficult at all. In this case you export e.g. 24p and later change fps (and also with QT Pro you can add your original audio).

That only changes the playback rate, right? What you can't do is change the number of frames for the conform. Like if you have a 60fps timeline and you want to make a quarter resolution 30fps version as a proxy you CAN change the resolution, but you can't tell Resolve to skip frames on the output.

This is exactly what we want- to adjust playback speed. We don't want to create/remove frames.
Interpolation of frames can be done in Resolve, but this always going to have side effects.
Issue here is inability to export native 18fps video file. In order to solve this you export 24p file (with imported assets being also interpreted as 24) and the re-write file with ffmpeg at 18 fps with copy option for video part. This is workaround, but quite easy and quick.

There is- you import and interpret them as 24/25/30/60 whatever you need.
Have you shot this 1000fps video to play it at 1000fps?
It's basically impossible to have timeline at 1000fps purely due to needed computation restrictions.
I agree that more fps choices are needed as current ones are a bit "legacy".
Problem is that because Resolve is free people keep asking about almost every possible feature.

Can you imagine having ability to set timeline to 1000fps and people importing 24p footage and trying to use motion adaptive interpolation to get 1000fps? Good luck with this

I don't need to play it back at 1000fps, I want to master my project at 1000fps. I want my timing to be consistent with what was shot. So if I recorded the 1000fps video with sync audio, what framerate should I import it into Resolve so I maintain audio sync without dropping frames? I don't need to playback 1000fps, I would be fine playing back at 30fps, whether that's by skipping frames or playing in slow motion. I just want to maintain sync with the media and other applications (like Fusion or our shot logger) we're running.

To be honest, the issue is more that there shouldn't be an assortment of fixed framerates, it should be a float value. I highly doubt Resolve internally handles timing with if/then statements based on an enum. It's much more likely that time just gets divided/multiplied by the framerate.

How do you want to use "original" audio if your clip will be played at e.g. 30fps instead of 1000? Such a clips have always "other" audio which is most likely unrelated to clip itself.
Audio is synced to final fps timeline (e.g. 30), not to original 1000fps clip.
I'm bit lost.

How do you want to use "original" audio if your clip will be played at e.g. 30fps instead of 1000? Such a clips have always "other" audio which is most likely unrelated to clip itself.
Audio is synced to final fps timeline (e.g. 30), not to original 1000fps clip.
I'm bit lost.

The audio is synced to the video only if the video is interpreted at 1000fps. Otherwise the audio will be stretched/compressed. If I interpret the video as 30fps, the audio will be way too short and will be out of sync.

My concern isn't that I can play back a 1000fps clip at 1000Hz. I'd be fine with having the option to skip frames to maintain playback speed or to play all frames at the highest possible framerate the system will allow, playing back likely as slow motion.

You can use Cinema Tools on Mac to change QT fps, but 16/18fps are not supported. You can get some developer to make such a tool for QT. It should not be that difficult at all. In this case you export e.g. 24p and later change fps (and also with QT Pro you can add your original audio).

You can also export 24p MOV and then use ffmpeg to adjust framerate with copy video command (and again- adding original audio). No need to use huge image sequences exports.

The point is to not have to make duplicate copies. There's no reason to have to go through the extra steps. The idea would be to bring in an 18fps (or 16 or whatever) file, set the timeline to that frame rate, and export at that frame rate. And then it's done. I don't want to have to make extra files and go through extra steps.

And if there is audio with an 18fps film, this whole suggestion doesn't work, because you can't put 18fps audio into a 24fps timeline without changing the speed, which you then have to change again later when you change the resulting export's frame rate back to 18. That's unacceptable because of the risk of altering the audio. It's very hard to work with a soundtrack that's playing back 25% faster than it should be, so it's also impractical.

Yes, you can change the frame rate in a quicktime in its metadata. But dealing with audio is a whole other level of complication. We currently have a job with about a dozen 18fps Super 8 Sound films, and it's a nightmare to manage all those duplicate copies just to get the end result. If the films were at 24fps, it would be a simple matter of a single batch export from Resolve and then it's done. That's it. That's what we're looking for.

I think Perry's suggestion is a good one. This kind of thing is very important for film archiving.

Try Lightworks. As a Film editor (accepts most BMD Decklink I/O cards) as opposed to a Video editor it probably has had this capacity for at least twenty five years. Tip: set the timeline frame rate to 24fps to Import legacy/mixed frame rates.

Try Lightworks. As a Film editor (which accepts most BMD Decklink I/O cards) as opposed to a Video editor it probably has had this capacity for at least twenty five years. Tip: set the timeline frame rate to 24fps to Import legacy frame rates.

Again, the idea here is to do everything in one application - for 24fps, we can do it all in Resolve. for 18fps we can't. I can also do the frame rate conversions in After Effects or Scratch (Scratch is very fast and lets you make ProRes on Windows), but now that we're on Resolve for Linux, and can make ProRes files directly upon export, I want to avoid having to make extra files.

that said, I'm curious how setting the timeline to 24 solves the problem of 18fps source remaining at 18fps on export? I don't use Lightworks so I really know nothing about it.

I have edited in Lightworks for many years but as I'm in PAL land, I've worked exclusively @ 25fps. However, the Lightworks forum recommends that the '24fps' setting is simply a Default for mixed/legacy frame rates. To the best of my knowledge, with a 24fps Timeline set, Lightworks outputs whatever frame rate you import/specify.

Lightworks is unlike any other NLE (so the learning curve can be a challenge to those brought up on Video editors) but it might be worth a try and it will run on your Linux system. I usually Export a DPX Sequence then render out Deliverables as required, using propriety software. (All three platforms are supported. Note: LW 'Free' is limited to a 720P output but Like Scratch, there is an attractive Monthly subscription for Exporting all the usual NLE files.)

Recently Lightworks got a GUI that is closer to other NLEs, so it became less intimidating for new users.

The point is to not have to make duplicate copies. There's no reason to have to go through the extra steps. The idea would be to bring in an 18fps (or 16 or whatever) file, set the timeline to that frame rate, and export at that frame rate. And then it's done. I don't want to have to make extra files and go through extra steps.

And if there is audio with an 18fps film, this whole suggestion doesn't work, because you can't put 18fps audio into a 24fps timeline without changing the speed, which you then have to change again later when you change the resulting export's frame rate back to 18. That's unacceptable because of the risk of altering the audio. It's very hard to work with a soundtrack that's playing back 25% faster than it should be, so it's also impractical.

Yes, you can change the frame rate in a quicktime in its metadata. But dealing with audio is a whole other level of complication. We currently have a job with about a dozen 18fps Super 8 Sound films, and it's a nightmare to manage all those duplicate copies just to get the end result. If the films were at 24fps, it would be a simple matter of a single batch export from Resolve and then it's done. That's it. That's what we're looking for.

I understand your pain- there is always one thing missing
Old film fps should be in Resolve- I'm surprised there are not already there.
In the same time so many people want this one things to be added, but for many this is very different thing

How do you want to use "original" audio if your clip will be played at e.g. 30fps instead of 1000? Such a clips have always "other" audio which is most likely unrelated to clip itself.
Audio is synced to final fps timeline (e.g. 30), not to original 1000fps clip.
I'm bit lost.

The audio is synced to the video only if the video is interpreted at 1000fps. Otherwise the audio will be stretched/compressed. If I interpret the video as 30fps, the audio will be way too short and will be out of sync.

Exactly, but your final master never will be at 1000fps, so why do you need audio to be synced to original speed? If you have original audio with 1000fps video you can only use it when you output 1000fps master, but this is unlikely the case.
You don't shoot 1000fps to use it at original speed, but as slowmo, so it's original audio is about useless.

How do you want to use "original" audio if your clip will be played at e.g. 30fps instead of 1000? Such a clips have always "other" audio which is most likely unrelated to clip itself.
Audio is synced to final fps timeline (e.g. 30), not to original 1000fps clip.
I'm bit lost.

The audio is synced to the video only if the video is interpreted at 1000fps. Otherwise the audio will be stretched/compressed. If I interpret the video as 30fps, the audio will be way too short and will be out of sync.

Exactly, but your final master never will be at 1000fps, so why do you need audio to be synced to original speed? If you have original audio with 1000fps video you can only use it when you output 1000fps master, but this is unlikely the case.
You don't shoot 1000fps to use it at original speed, but as slowmo, so it's original audio is about useless.

Andrew, we are not talking about a non existing/hypothetical 1000fps, we are thinking of real legacy restoration projects that run at 16/18fps...

Yes, I know. These are 2 separate things and I agree that legacy film fps should be added, but things like 23.765fps (or 1000fps timelines) not necessarily.

v14.2, which came out today finally adds support for 16 and 18fps. Just downloaded and did some preliminary testing on our Windows Resolve system. 18fps works as advertised! For one of the feature films we're doing right now this will literally shave 2 days of file wrangling off our schedule!

Thank you, Blackmagic!

+1

Ok: we'll say Jean Claude => never happy but maybe someday?

-Timeline Format (1080p or +): => Time line Frame rate => 16,667 FPS
-Edit tab: RETIME (Interpolation) from 16.667 to 25 FPS + motion interpolation
-Delivery to 25 FPS

(No emergency: it's for Santa Claus in a few years but it's soon ...)

It's a very personal process when you are in 50 Hz (France)

...It's a very personal process when you are in 50 Hz (France)

And here in 50 Hz Australia!

This is great!
I have some Super 8 footage that was shot at 24 fps but (contrary to my explicit instructions) was scanned at 18 fps. ProRes422

Here's what I found when loading it into Resolve (disclaimer: I'm a beginner with Resolve):

When I add the 18fps clip to the media pool, Resolve asks if I want to to change the project settings to match (project settings initially set to 24 fps). If I say YES, and change the project settings to 24 fps (how the film was shot) the playback looks normal.

However, if, when starting a new project and adding the clip to the media pool, if I say NO to changing the project settings to match the new clip, and THEN change the projects settings to 24 fps, the playback does not look correct (it looks slow-mo; 24 fps shot clip playing back at 18 fps).

Not sure what the difference is when choosing Yes or No when initially adding the clip to the Media Pool, but there does seem to be a difference. I know, I'm a newb. Be gentle.

Added support for 16 and 18 fps timeline frame rates
Added support for 95.905 fps timeline frame rate

Am I missing something obvious here, or wouldn't it just be easier at this point to support arbitrary timeline frame rates?

Am I missing something obvious here, or wouldn't it just be easier at this point to support arbitrary timeline frame rates?

My opinion: because a lot of the underpinnings of the database rely heavily on the designated timeline speed of the project, this is not something that can be easily (or arbitrarily) chosen. As it is, I suspect it took a lot of engineering to even provide 16fps and 18fps. Bear in mind that dissolves, tracking, keyframes, transitions, and dozens of other things all depend on the system knowing what speed at which they have to happen.

Am I missing something obvious here, or wouldn't it just be easier at this point to support arbitrary timeline frame rates?

My opinion: because a lot of the underpinnings of the database rely heavily on the designated timeline speed of the project, this is not something that can be easily (or arbitrarily) chosen. As it is, I suspect it took a lot of engineering to even provide 16fps and 18fps.

If that is true (and I hope it's not), then that would be a serious code smell. As a programmer, that sounds like code begging to be refactored.

Am I missing something obvious here, or wouldn't it just be easier at this point to support arbitrary timeline frame rates?

My opinion: because a lot of the underpinnings of the database rely heavily on the designated timeline speed of the project, this is not something that can be easily (or arbitrarily) chosen. As it is, I suspect it took a lot of engineering to even provide 16fps and 18fps.

If that is true (and I hope it's not), then that would be a serious code smell. As a programmer, that sounds like code begging to be refactored.

Hi Micha,
Seriously, can you explain why?

Seriously, can you explain why?

Generally, you make your own life as a programmer much easier if in various parts of the code variables like "duration of a frame" are used, or "amount of frames per <time unit>", such that there is then only one place where the source of all these variables is defined, namely the timeline frame rate, and changing it changes the behaviour of all that other code in one fell swoop. The behaviour that Marc describes implies that there are many places in the code where different code paths are taken depending on whether the frame rate is 16, 18, 24, 25, 50 or 60 frames per second. Adding support for new frame rates then becomes a lot of work because all those code branches have to be changed to add special cases for the newly added frame rate, which is a form of technical debt (Wikipedia). Here is some further reading: Change Preventers.

Seriously, can you explain why?

Generally, you make your own life as a programmer much easier if in various parts of the code variables like "duration of a frame" are used, or "amount of frames per <time unit>", such that there is then only one place where the source of all these variables is defined, namely the timeline frame rate, and changing it changes the behaviour of all that other code in one fell swoop. The behaviour that Marc describes implies that there are many places in the code where different code paths are taken depending on whether the frame rate is 16, 18, 24, 25, 50 or 60 frames per second. Adding support for new frame rates then becomes a lot of work because all those code branches have to be changed to add special cases for the newly added frame rate, which is a form of technical debt (Wikipedia). Here is some further reading: Change Preventers.

Hi, Thank's
I am absolutely not convinced by your explanations but if you say that it must be as simple as this: What does BMD do not have already done what you say ...

I am absolutely not convinced by your explanations but if you say that it must be as simple as this: What does BMD do not have already done what you say ...

I'm not sure why you're not convinced. It's a simple thing. We don't know if the frame rates were hard-wired in the Resolve code, but given the amount of time and effort it took to get this far, I'm guessing there were at least some places where frame rates weren't easily modified variables. That's both messy (from a programming standpoint), and hard to maintain, because now you have to search for all instances in probably millions of lines of code, for places where the frame rate is referenced. It's a big deal because missing an instance of this means weird bugs could creep in and be hard to find, among other things.

What Micha is saying is spot-on. Resolve has been around for like what? 20 years almost? I'd be surprised if there's not at least some code in there that prevents things like totally arbitrary frame rates.

As for why they haven't done it sooner, well, this is not something that everyone needs, so I'm sure they have to prioritize things and work on more pressing issues first.

We agree on one point: an obsolete code is not easy to evolve. But it's done for 16/18 fps.

In return, when I see how quickly from one version to another BMD is able to offer a lot of new functionality: not so obsolete as that.

We agree on one point: an obsolete code is not easy to evolve. But it's done for 16/18 fps.

In return, when I see how quickly from one version to another BMD is able to offer a lot of new functionality: not so obsolete as that.

None of us know the code, so this is all conjecture on all parts. But I can tell you as someone who has spent a fair bit of time coding, it's probably easier to add a new feature than it is to muck about in code that underlies the entire application.

Again, I'm simply guessing here - BMD may have decided that it doesn't make sense from a support point of view to offer arbitrary frame rates (arbitrary rates are really an edge case, where standard rates like 16, 18, 20 are all standards, just old ones for film). Or they may have more fundamental reasons not to, based on the code itself and how certain things are handled.

We agree on one point: an obsolete code is not easy to evolve. But it's done for 16/18 fps.

In return, when I see how quickly from one version to another BMD is able to offer a lot of new functionality: not so obsolete as that.

None of us know the code, so this is all conjecture on all parts. But I can tell you as someone who has spent a fair bit of time coding, it's probably easier to add a new feature than it is to muck about in code that underlies the entire application.

Again, I'm simply guessing here - BMD may have decided that it doesn't make sense from a support point of view to offer arbitrary frame rates (arbitrary rates are really an edge case, where standard rates like 16, 18, 20 are all standards, just old ones for film). Or they may have more fundamental reasons not to, based on the code itself and how certain things are handled.

Hi,

As you say: None of us know the code, so this is all conjecture on all parts. And for the coding: not badly given too.

I'm not sure why you're not convinced. It's a simple thing. We don't know if the frame rates were hard-wired in the Resolve code, but given the amount of time and effort it took to get this far, I'm guessing there were at least some places where frame rates weren't easily modified variables.

That's my take as well. Or looking at it another way: if it were easy to do, Blackmagic would've done it already.

That's exactly what I say. If BMD did not do it before, it's not that easy (sorry, but English is not my first language, I'll try to remember it in the future and avoid answering to avoid confusion.)