60fps timecode

[erik]

Hi
I want to ask if there is any problem to implement receiving 60fps timecode. Or implement generating timecode?
Resolume is becoming more than VJ software and this is kind a basic function to create more advanced setups.


Thanks

[Zoltán]

What's your source for 60FPS timecode?

[erik]

Hi Zoltan,

I thought that Grand MA is able to produce it, but then our light guy said it can only receive 60fps timecode.
Ok I see the problem, there are no generators except DJ link? (i have no experience, but i found it on Resolume Facebook forum)

Main problem why we need time code for Resolume setup is that Resolume is missing possibility of multi-channel audio playback, so we need to sync with other audio program.

[movebandit]

Don´t you think, that 30fps timecode isn´t enough ? I have never seen a production using 60fps Timecode
Just for Example: If you are playing a 60fps Video and receiving 30fps Timecode you´ll get a resync on every 2nd frame of the video. There is not much time ( like 16milliseconds / 1 Frame) to run out of Sync. So why do you need 60fps ? To run the video smoother ? Nope. Or are you talking about a genlock ?

[Christoph]

I don't think that higher framerates are a thing with common timecode protocols. This goes for LTC that we use in Resolume but afaik also for other timecode protocols like ArtNet timecode or MIDI timecode. Correct me if I'm wrong.

Common timecode framerates are 24, 25, 29.97 and 30.

However with the timecode implementation in Resolume if a clip is set to SMPTE timecode it will display exactly the frame of the incoming timecode, but there is no freerun implementation that would show any other frames that are not specified by that timecode. This means with a 30fps timecode and a 60fps file it would skip every second frame (and thus if there would be a 60fps timecode it would theoretically run smoother).

[Zoltán]

The SMPTE timecode standard only has two bits for the frames tens field, if you make every bit in the frame 1s you can only go up to 39.

If your MA can receive 60FPS timecode, it's probably not SMPTE.

[fiverecords]

It is clear that the SMPTE standard does not include frame rates above 30fps, but perhaps it could be arranged so that for each TC frame, two video frames run, or something like that, to take advantage of synchronization in videos with a high refresh rate.

[yannick.fullrez]

There was a recent question by a friend asking if it's possible to run 50fps on 25fps LTC. I said no sadly not but I would really love to see 50 or 60 fps timecode shows in Resolume. I researched and it lead me down the rabbit hole about SMPTE.

From what I could find the standards have been revised in 2014 and contain a solution to framerates higher than 30fps. The reason why nobody from TV uses it is probably because you can not differentiate interlaced and progressive anymore but we're VJs in 2025 who's still using interlaced stuff AND needing timecode come on! ;)

Their standard:
On framerates higher than 30fps you'd still use only 2 bits for the tens frame data per frame. Resulting in frames 0-29. Then starting another frame you set the field mark flag bit to 1. Resulting in a frame pair. Which theoretically also only shows 0-29, but with the bit a receiver can then interpret it as lets say 00:00:00:29.1 (the 60th frame out of 60) as 00:00:00:59.

You can read this in SMPTE ST 12-1:2014 (Revision of SMPTE 12M-1:2008) under section 12. There's also several diagrams for LTC implementations in section 9.6.6.

TL;DR TIL that 48, 50, 60fps LTC is entirely possible within SMPTE standards. Maybe if we get libltc to get an update it would be possible to integrate quickly into Resolume and other software.

[Christoph]

Interesting to know that it is possible technically.

Do you know if there is any other software or hardware that can send 60 fps LTC timecode?

[yannick.fullrez]

From my research there is not. I think old hardware is a big cause of that bottleneck. My mentioned approach is actually for VITC (analog devices,) which by my (noob) mistake is not entirely valid for LTC. LTC still supports these framerates though. Old devices would confuse interlaced and progressive signals.

So here's my correction: LTC expects a decoder to return the first frame from reading bytes 0-39 of the LTC packet and the second frame of the pair when starting bit 40 to support the doubled framerate.

Everyone I ask says it's limited, I feel like not a lot of people have ever really looked at the specs. There's even specs for high framerates up to 960FPS (ST12-3), it's not the exactly same to the SMPTE the industry is using now but it seems very similar. I can't talk too much about that one though, I spent more time reading up on ST 12-1 / 12M.

Edit: So yesterday I added a function to libLTC with the wrong approach in my last post. It makes libLTC support 60FPS LTC audio generation and decoding. But with what I learned now this means we can make it decode 30FPS LTC as 60 FPS LTC. Then 30FPS LTC could be interpreted as 60FPS which would benefit all.