Hard limit of 1000 frames

[mantissa-]

I'm trying to preview a file sequence that's 7000+ frames long, but mrv2 can only handle up to 1000 frames it seems? Is this a hard limit or can it be adjusted? I've previewed more than 1000 frames in the past with older versions.

[ggarra13]

What happens when you try to play them?

There shouldn't be any limit on the amount of frames, other than the amount of RAM you have.

mrv2 by default tries to use half of your available RAM for your cache. The amount of RAM used on a sequence (or movie file) depends on resolution and bit depth.

The speed of reproduction depends on the FPS, resolution, bit depth, cache settings and your hardware (particularly your hard disk).

You can check the Settings in, pun intended, in the Settings Panel (F9 by default). The Cache is in Gigabytes there. If it is set to 0, mrv2 will use the Read Ahead/Read Behind which are set in seconds and will not use that much of your cache memory, but you might not be able to scrub smoothly. If you set it too big, you may go into swap memory and can deteriorate the performance of playback.

If that's not it, please let me know what resolution, bit depth, pixel format, the amount of memory on your machine, and perhaps upload a single frame of your sequence somewhere so I can try it.

[mantissa-]

So I just tried it on two different machines and I'm getting the same behavior. Both are running Linux Mint 21.2.

Basically, I can set the end frame number from 999 to 7097 (the length of my sequence), but the timeline will only show frame 999 as the endpoint. Once the player goes past that the viewer goes blank and while the timecode will go the full length, it never shows anything.

My main machine is a threadripper box with 256GB of ram and I'm reading from an multi-nvme sdd raid setup, that's never been the bottleneck in my workflow.

I've attached two screenshots and an EXR for you to take a look at, I hope that illustrates the issue more clearly. mrv_end_frame.zip

[ggarra13]

I confirm the bug. There's a problem in the file listing on disk. It will take me some time to fix it (I may need help from Darby as the code is a tad convoluted).

You can work around the problem for now if you pad the sequence with 5 digits instead of 4. So, instead of:

test.0001.exr

call it:

test.00001.exr.

[BigRoy]

So the bug is that it's only capable of playing sequences of the same padding? Is the bug present for e.g. this as well:

frame.99.exr
frame.100.exr
frame.101.exr

[ggarra13]

No. Sequences with no padding also work. It's only when the sequence has a specific number of padded digits it seems.

[BigRoy]

Ah I see, so this will fail?

frame.09.exr
frame.10.exr
frame.11.exr
...
frame.100.exr

So the case where at least one file does define padding (e.g. 09 but one file exceeds the paddings length, like 100)? The files exceeding the initial padding length would then fail to load.

[ggarra13]

Yes. That's the bug. Actually, it is not when it exceeds the number of digits, but when it reaches the number of padded digits. That is:

frame.09.exr frame.10.exr frame.11.exr

will result in playback of 1-9.

[ggarra13]

Okay. I have a beta release of v0.8.2 that should fix the problem. You can grab it from:

https://sourceforge.net/projects/mrv2/files/beta/

If you report it is working okay, I'll make an official release of v0.8.2 soon.

[mantissa-]

I just gave it a shot on on my laptop, and the problem persists for me unfortunately.

[melMass]

For me the hard limit is 9999 (10K) frames if using a padding of 4 (I'll try 5 now that I've read this issue):

btw the remaining field is always growing

Using mrv 0.8.2

[ggarra13]

Yes, that should be correct. With a padding of 4 digits (ie 0001), you can only load up to 9999 frames. The 10000 frame and on will be assumed as a new sequence. You will need to use a padding of 5 digits or, alternatively, no padding at all.

[BigRoy]

With a padding of 4 digits (ie 0001), you can only load up to 9999 frames. The 10000 frame and on will be assumed as a new sequence.

I'd actually argue that that is still a bug in itself.

[ggarra13]

Regarding the remainining field, it will usually keep increasing to about half of the saving of the movie. Then it will start decreasing. I'll look at the code and see if I can improve the algorithm.

[ggarra13]

With a padding of 4 digits (ie 0001), you can only load up to 9999 frames. The 10000 frame and on will be assumed as a new sequence.

I'd actually argue that that is still a bug in itself.

I would disagree. But if you tell me a program like Nuke handles that gracefully, I'd be inclined to modify the code to also accept it.

[melMass]

Yes, that should be correct. With a padding of 4 digits (ie 0001), you can only load up to 9999 frames. The 10000 frame and on will be assumed as a new sequence. You will need to use a padding of 5 digits or, alternatively, no padding at all.

Thanks not a huge constraint once you know it imo thanks

if you tell me a program like Nuke handles that gracefully, I'd be inclined to modify the code to also accept it.

It does :)

[BigRoy]

I would disagree. But if you tell me a program like Nuke handles that gracefully, I'd be inclined to modify the code to also accept it.

FFMPEG I believe can actually also parse them - but maybe that's only if you don't provide explicit padding and just the start frame so that it assumes it has no padding at all, similar to how many applications can also play back:

1.jpg
2.jpg
3.jpg
...
11.jpg
12.jpg

And thus considering it to have no padding?

Since you can't run ffmpeg on start frame 999 if the file is named 0999 and you didn't provide the padding to the filename, etc. Anyway, I consider padding to be just padding "padding it to fill up to that length if it's shorter than that"

It does :)

For what it's worth, Fusion does as well. I believe After Effects does also, but I haven't tested that now.

Also, just wanted to state; I'm not too bothered by it. I also recall having this discussion with other devs with similar edge cases with regards to parsing/listing and pushing files like these through a pipeline. If suddenly the folder had a file named 00001.jpg would that mean that e.g. 10000.jpg is suddenly not a part of 9999.jpg sequence anymore? I can see how allowing frames to go beyond the padding length will make things like these much more complicated.

---

Oopsie

Seems like @ggarra13 changed my comment by mistake to this:

If suddenly the folder had a file named 00001.jpg would that mean that e.g. 10000.jpg is suddenly not a part of 9999.jpg sequence anymore?

No, 9999.jpg would not be part of the sequence while 00001.jpg and 10000.jpg would as they match the padding and/or number of digits.

I can see how allowing frames to go beyond the padding length will make things like these much more complicated.

It gets tricky when you have something like I posted:

test.01.exr test.99.exr test.100.exr test.1000.exr

What would be the right sequence length in that case? 1-99? 1-100? or 1-1000?. mrv2 would choose 1-99. FFmpeg also. I am too lazy to open Nuke to see what it does. I'll follow Nuke's behavior.

[ggarra13]

if you tell me a program like Nuke handles that gracefully, I'd be inclined to modify the code to also accept it.

It does :)

Those images show padding with five numbers (in the ##### characters) and the result is no padding in the file listing. Both cases are handled by mrv2 just fine.

Try loading this in nuke:

test.01.exr test.99.exr test.100.exr test.1000.exr

See if it recognizes the sequence as going from 1 to 1000, as 1 to 100 or as 1 to 99.

[BigRoy]

@ggarra13 His screenshot does show it's reading from 0-10316 however, but yes - it's not visible in the screenshot whether earlier files are Chant.0500.jpeg or Chant.500.jpg

Those images show padding with five numbers (in the ##### characters)

Which is quite weird actually since the files listed right hand side are not all #####, e.g. Chant.9999.jpeg isn't. I'd expect that sequence to be listed as Chant.####.jpeg but having frame numbers higher than the padding and so it also has frames like Chant.#####.jpeg (which are actually with padding of 4 for the sequence.)

[ggarra13]

btw the remaining field is always growing

I fixed this in the upcoming v0.8.3 (or sourceforge's beta once I push it).

[melMass]

Those images show padding with five numbers (in the ##### characters) and the result is no padding in the file listing. Both cases are handled by mrv2 just fine.

Nope 4 I showed the file list to express that but it wasn't super clear sorry. Nuke itself normalizes it to 5

[ggarra13]

melMass, can you try the example I showed in Nuke, to see what it does? So I know how I would need to modify my code?

Try loading this in nuke:

test.01.exr test.99.exr test.100.exr test.1000.exr

See if it recognizes the sequence as going from 1 to 1000, as 1 to 100 or as 1 to 99.

[ggarra13]

Ok. I tried the sequence I posted above in Nuke14.0v5 and it failed miserably. It just recognized test.1000.exr. So, I am going to close this issue as a non-fix one as mrv2 already does a better job than Nuke.

[ggarra13]

Oh yes, one more thing. I have a new beta of v0.8.3 that fixes the "Remaining Time:" in the Save Progress window.

You can grab it at:

https://sourceforge.net/projects/mrv2/files/beta/