-
Notifications
You must be signed in to change notification settings - Fork 289
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
Conversation
…01, 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, |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Fixes #393
added support for frame rates: 48000/1001, 100 , 120000/1001 and 120