Max Frames should either be MAX_INT or configurable without recompile #46859

New Issue

Carl Myers · 2015-11-24T19:38:02+01:00

Carl Myers commented

2015-11-24 19:38:02 +01:00

System Information
Irrelevant

Blender Version
2.76b f337fea

Short description of error
A 2-hour video at 60fps greatly exceeds the current hard-coded limit of 300k frames.
In the past, this limit was 30k frames: http://lists.blender.org/pipermail/bf-committers/2006-April/014435.html

Obviously, this is a repeating problem. We should either set it to MAX_INT and be done with it, or change it to be configurable at runtime. Is there any reason not to set it to MAX_INT? The resources aren't actually used unless you extend your project to be that length, right?

I'm new to deving on blender but would be willing to help out however I can, filing this feature request to get discussions rolling about the correct solution.

**System Information** Irrelevant **Blender Version** 2.76b f337fea **Short description of error** A 2-hour video at 60fps greatly exceeds the current hard-coded limit of 300k frames. In the past, this limit was 30k frames: http://lists.blender.org/pipermail/bf-committers/2006-April/014435.html Obviously, this is a repeating problem. We should either set it to MAX_INT and be done with it, or change it to be configurable at runtime. Is there any reason not to set it to MAX_INT? The resources aren't actually used unless you extend your project to be that length, right? I'm new to deving on blender but would be willing to help out however I can, filing this feature request to get discussions rolling about the correct solution.

Carl Myers commented

2015-11-24 19:38:02 +01:00

Changed status to: 'Open'

Carl Myers commented

2015-11-24 19:38:02 +01:00

Added subscriber: @cmyers

Campbell Barton commented

2015-11-25 07:36:28 +01:00

Added subscriber: @ideasman42

Campbell Barton commented

2015-11-25 07:36:28 +01:00

To use much larger int's, we would need to make sure the frame was never cast to a float,

At 300,000 we get 1/32 of a second precision for sub-frames (needed for motion blur), without any large changes we could increase the maximum frame to 524286 (which still gives 1/32, sub-frame precision).
MAX_INT sub-frames wont work at all with floats.

With doubles MAX_INT has more than enough precision.

To check on precision at different ranges, see P293

  def test_subframes_f(f):
      print("subframe: (%.20f)'th of a frame" % (1 / ((nextafterf(f, f + 1) - f))))

  def test_subframes_d(f):
      print("subframe: (%.20f)'th of a frame" % (1 / ((nextafter(f, f + 1) - f))))

So we can either bump the max frame a small amount, or go over the code checking we only ever use doubles for frame values.

To use much larger int's, we would need to make sure the frame was never cast to a float, At 300,000 we get 1/32 of a second precision for sub-frames (needed for motion blur), without any large changes we could increase the maximum frame to `524286` (which still gives 1/32, sub-frame precision). MAX_INT sub-frames wont work at all with floats. With doubles MAX_INT has more than enough precision. To check on precision at different ranges, see [P293](https://archive.blender.org/developer/P293.txt) ``` def test_subframes_f(f): print("subframe: (%.20f)'th of a frame" % (1 / ((nextafterf(f, f + 1) - f)))) ``` ``` def test_subframes_d(f): print("subframe: (%.20f)'th of a frame" % (1 / ((nextafter(f, f + 1) - f)))) ``` ---- So we can either bump the max frame a small amount, or go over the code checking we only ever use doubles for frame values.

Sergey Sharybin commented

2015-11-25 10:12:52 +01:00

Added subscriber: @Sergey

Sergey Sharybin commented

2015-11-25 10:12:52 +01:00

Changed status from 'Open' to: 'Archived'

Sergey Sharybin closed this issue

2015-11-25 10:12:52 +01:00

Sergey Sharybin self-assigned this 2015-11-25 10:12:52 +01:00

Sergey Sharybin commented

2015-11-25 10:12:52 +01:00

This isn't really a bug or a design task, this is something known and something we can't easily change because of the reasons explained by Campbell.

Sure we can go over the code changing float subframes to doubles, but it's just one of multiple things TODO. So thanks for the report, but archiving it as a TODO.

This isn't really a bug or a design task, this is something known and something we can't easily change because of the reasons explained by Campbell. Sure we can go over the code changing float subframes to doubles, but it's just one of multiple things TODO. So thanks for the report, but archiving it as a TODO.

Daniel commented

2016-07-06 15:30:11 +02:00

Added subscriber: @leance

Daniel commented

2016-07-06 15:30:11 +02:00

In my opinion, switching to doubles simply delays the problem but doesn't solve it completely. Also there might be a performance impact even for smaller projects.

Perhaps in order to support movie clips of any length, segmentation should be considered. This way, doubles needen't be implemented and the code won't require a review. Currently, the problem is that the 300k limit also applies to rendering a video. So it's not possible to render video's longer than 83 minutes (@60fps). So even if you were to make multiple clips and put them back-to-front in the timeline you can't render the entire thing. It should be possible to segmentise, or compartmentalise if you will, the render process to just reuse the frame numbers in a next segment. This way only code has to be added to the renderer which is more interesting work and can be done quicker. That way a very real problem that is keeping Blender from being usuable as a movie editor tool can be solved, increasing Blender's target audience.

Correct me if I'm wrong please.

And yes, there will have to be some tricky code for proper subframing in the space between segments but I still think this is the most realistic solution.

In my opinion, switching to doubles simply delays the problem but doesn't solve it completely. Also there might be a performance impact even for smaller projects. Perhaps in order to support movie clips of *any* length, segmentation should be considered. This way, doubles needen't be implemented and the code won't require a review. Currently, the problem is that the 300k limit also applies to rendering a video. So it's not possible to render video's longer than 83 minutes (@60fps). So even if you were to make multiple clips and put them back-to-front in the timeline you can't render the entire thing. It should be possible to segmentise, or compartmentalise if you will, the render process to just reuse the frame numbers in a next segment. This way only code has to be *added* to the renderer which is more interesting work and can be done quicker. That way a very real problem that is keeping Blender from being usuable as a movie editor tool can be solved, increasing Blender's target audience. Correct me if I'm wrong please. And yes, there will have to be some tricky code for proper subframing in the space between segments but I still think this is the most realistic solution.

Campbell Barton commented

2017-08-31 18:48:33 +02:00

Update: as of 44e10a5c66 - the maximum frame is now 1,048,574 which gives 1/16th subframe resolution.

24 fps: 12 hours, 8 seconds.
60 fps: 4 hours, 51 seconds.

@leance - using doubles for time wouldn't impact performance in a measurable way. If we move to doubles, we could get better subframe precision than we have now - with an 100,000 years of 60fps video.

Update: as of 44e10a5c66c271dfcd1074b4d82d2d838ec88cae - the maximum frame is now 1,048,574 which gives 1/16th subframe resolution. - 24 fps: 12 hours, 8 seconds. - 60 fps: 4 hours, 51 seconds. ---- @leance - using doubles for time wouldn't impact performance in a measurable way. If we move to doubles, we could get better subframe precision than we have now - with an 100,000 years of 60fps video.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Max Frames should either be MAX_INT or configurable without recompile #46859