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.

Sign up for GitHub

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

Jump to bottom

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

Closed
wants to merge 1 commit into from
Closed

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

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 17 additions & 4 deletions src/opentime/rationalTime.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,15 +10,17 @@ namespace opentime { namespace OPENTIME_VERSION {

RationalTime RationalTime::_invalid_time{ 0, RationalTime::_invalid_rate };

static constexpr std::array<double, 4> dropframe_timecode_rates{ {
static constexpr std::array<double, 6> dropframe_timecode_rates{ {
// 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 •
edited
Loading

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.

59.94,
60000.0 / 1001.0,
120000.0 / 1001.0,
} };

// currently unused:
Expand All @@ -37,7 +39,7 @@ static constexpr std::array<double, 10> non_dropframe_timecode_rates
}};
*/

static constexpr std::array<double, 16> valid_timecode_rates{
static constexpr std::array<double, 20> valid_timecode_rates{
{ 1.0,
12.0,
23.97,
Expand All @@ -49,11 +51,15 @@ static constexpr std::array<double, 16> valid_timecode_rates{
29.97,
30000.0 / 1001.0,
30.0,
48000.0 / 1001.0,
48.0,
50.0,
59.94,
60000.0 / 1001.0,
60.0 }
60.0,
100,
120000.0 / 1001.0,
120 }
};

bool
Expand Down Expand Up @@ -118,7 +124,14 @@ RationalTime::from_timecode(
unsigned int last_pos = 0;
for (unsigned int i = 0; i < 4; i++)
{
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.

}
else
{
fields[i] = timecode.substr(last_pos);
}
last_pos = last_pos + 3;
}

Expand Down