Upper limit of more than 99 hours for Timer filter?

Suggestion
1

Hi,

is the current limit of 99:59:59.999 for the Timer Duration field an arbitrary choice, or would extending this to say 999 or 9999 hours pose a technical problem (int size or something)?

Background info for this oddball request: (tl;dr: 100 hours divided by a remapping speedup of 1000x is only six minutes of usable time; at speedup 1’000’000x it’s only 0.36s)

This is relevant for a workaround of another issue of the Timer and/or Simple Text filters that’s probably more difficult to tackle.

I have high-speed footage of an older Keyence camera that encodes 4’000-150’000fps into 15fps avi video. Compressing this via Properties->Speed to true proportions and blowing it back up via filters isn’t really possible (and I do not fault Shotcut for not supporting that, this is some specialized piece of video, I know). However, I do need a real-time text overlay…somehow. Doesn’t really matter if the internal units are fake, as long as the rendered video shows correct values.

Since the Simple Text filter only allows the display of variables, e.g. the very useful frame count, but no calculation with these, I cannot make an evaluate[[frame count] * [time per frame]] kind of overlay.

Timer on the other hand has two separate issues while providing some sort of calculation ability that the Simple Text filter lacks:

a) Timer speeds below 1 have no intermediate ticks, they only update once per full tick. For example, at a speed of 0.00016 (which btw lacks resolution for this niche application), the transition from zero to 0.00016 takes 1.5ish minutes (I guess 6250 frames @ 60fps, so 1:34 plusminus some rounding stuff?). In between, the time output is frozen at 0.00000 and then suddenly jumps ahead, which isn’t terribly helpful. This limitation could also be noted in Timer Video Filter

b) There’s no sub-millisecond resolution format in the output format anyway, so even if everything else works, multiple video frames from 100kfps+ footage will sit at the exact same timecode. Again, not a terrible limitation of Shotcut, my own eyes max out at 400-500Hz. And although we are now entering the 1000Hz display era, actually saving kHz+ framerate video because anyone can SEE that is unlikely. The only purpose would be saving high-speed footage with a correct fps value instead of a predefined slowdown like my 15fps video - but that’s a thing of the camera, and typically not needed for processed video.

So - my current workaround is mapping millseconds into seconds, gaining 1000x leverage. For example in a 15000fps video, I can run Speed=1, because real 15000fps in 15fps video are a 1000x slowdown, and milliseconds to seconds is a factor of 1000x as well, that cancels nicely. And because speed is equal or greater than 1, I also get an updated timestamp every frame. Set up Format to “SS.SS” or “SS.SSS”, add some aligned text overlay stating “this is milliseconds”, and this works fine.

For videos with greater framerate, this falls apart - sure, video with 150’000fps works with speed 0.1x, but only gets an updated time in 0.066ms increments every ten frames as described. Doubling down on the workaround is an option at this temporal resolution → mapping microseconds into seconds. 150kfps@15fps, running at Speed 100x yields microseconds in the Timer seconds field and therefore an update every frame.

And this is where my original request comes from…a limit of 100 hours = 6’000 minutes = 360’000 seconds in the Timer Duration field is good for 6 minutes = 360 seconds of 1000x speedup footage (ms mapping), but only for 0.36 seconds at 1’000’000x speedup (µs mapping). The camera cannot capture six minutes at 15kfps - but it can do three seconds at 150kfps. And that causes the Timer to stop at 12% of the video, because it runs into the 99h 59min 59.999s (359’999.999µs) limit

There’s another workaround for that, of course, and that’s limiting the thing to 100’000 “seconds” and putting the 100k decimal place manually into the static text…but let’s be real here, that’s a timer reset and a text change ten times per real second, and while I’m glad that’s theoretically possible, it’s not a very practical solution. An extension of the maximum value the Duration timer can hold would be SO much more convenient…(even if capped at the seemingly also-arbitrary values of 596 or 1193 hours!)

2

This should be something you can try yourself if you are comfortable editing a text file.

Find your Shotcut installation and look for this file:
share\shotcut\qml\filters\timer\ui.qml

Scroll in the file until you find the ClockSpinner definition for the duration field:

ClockSpinner {

                id: durationSpinner



                maximumValue: 100 \* 60 \* 60 - 0.001 // 99:59:59.999

                onTimeStrChanged: {

                    filter.set('duration', durationSpinner.timeStr);

                }

                onSetDefaultClicked: {

                    durationSpinner.timeStr = \_defaultDuration;

                }



                Shotcut.HoverTip {

                    text: qsTr('The timer will be frozen after the Duration has elapsed.') + '\\n' + qsTr('A value of 0 will run the timer to the end of the filter')

                }

            }

Change this line:

            maximumValue: 100 * 60 * 60 - 0.001 // 99:59:59.999

To this:

            maximumValue: 1000 * 60 * 60 - 0.001 // 999:59:59.999

I tried it and the UI works. But I did not make a clip long enough to see if it works in the video.

3

What kind of resolution would you actually need here?

A while back I tried to do something similar with slowmotion + timer (I wanted to count how many (mili)seconds it took me to fall down and then completely slow down on skis) and I hit the same update issue as you mention.

I then added to my todo list to implement miliseconds precision to the date_time display in the gps text filter (one of the keywords there show the video file’s original date and time, but even though the internal time is stored in miliseconds, it uses strftime to print it to a string and this call doesn’t have a milisecond format so the result is only in hours:minutes:seconds at best), and your thread made me remember it and finally give it a try.

5

Quick update: I managed to add 9 digits of precision to the file_datetime_now keyword via the existing “decimals X” extra argument.

So something like: #file_datetime_now%H:%M:%S.decimals 9# at 0.000001x speed at 19s+2frames in a 29.97fps project prints:

image
image566×193 3.18 KB

My only dilemma is that this works easily for the file_datetime_now because all the extra precision is just calculated on the fly if needed but for gps_datetime_now I’ve exposed up to miliseconds as that’s what’s stored in the internal structs (maybe at some point if someone has an actual use case would be worth it to rewrite all the variables or workaround but for now I don’t think it’s worth it). Anyway, I’ll wait for the beta to finish and then raise a PR.