Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

added support for frame rates: 48000/1001, 100 , 120000/1001 and 120 #1180

Closed

Conversation

splidje
Copy link
Contributor

@splidje splidje commented Dec 21, 2021

Fixes #393

added support for frame rates: 48000/1001, 100 , 120000/1001 and 120

// 23.976,
// 23.98,
// 23.97,
// 24000.0/1001.0,
29.97,
30000.0 / 1001.0,
48000.0 / 1001.0,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sadly, field recorders also offer 48000 * 1001 / 1000 as a rate, so it should be added as well.

Copy link
Collaborator

@reinecke reinecke Dec 21, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is the record speed, but what timecode do they write? I think I'd like to se evidence of timecode rates of 1001/1000 before adding those variants. SMPTE ST 12 only mentions 1000/1001 as being valid rates.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, right. These values are meant for rates with associated SMPTE time codes, which does not include audio data. For some reason I was thinking that all the NTSC related rates were part of this stew, but they aren't.

fields[i] = timecode.substr(last_pos, 2);
if (i < 3)
{
fields[i] = timecode.substr(last_pos, 2);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hours can exceed 99? or is that disallowed? If we're going to catch high frame counts, probably we should think about the full parse, and do the split based on separators, not a two character heuristic, if 100+ hours is legal...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've purely based this on experimenting with 120 fps with Nuke and FFmpeg.

ffmpeg -i <path> -timecode "00:00:00:119" <path>

FFmpeg has no issue with that, and reports that timecode back.

Also Nuke reports it in the metadata and moving 1 frame forward it jumps to 00:00:01:00 and so on.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can't help feeling that back-in-the-day they could have at least pre-empted over 100 fps and possibly over 99 hours. Doesn't seem unfathomable.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To utilize framerates over 99, we'd have to modify the timecode parser and formatter to allow it ~ it's hardcoded for two digit codes at the moment.

@meshula
Copy link
Collaborator

meshula commented Nov 11, 2022

@splidje Newer PR #1477 includes the full list of documented SMPTE time code rates. Let's close this PR in favor of that one, and carry any conversation over there.

@meshula meshula closed this Nov 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants