fix: improve accuracy of package framerate detection

[from-the-river-to-the-sea]

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

bug fix

• What is the current behavior? (You can also link to an open issue here)

Sofie sometimes detects the framerate of video packages incorrectly, particularly in the case of progressive scan files. This is because buildPackageFormatString looks at codec_time_base to determine a video's framerate. In certain video formats (such as XAVC MXF and H.264 MP4), codec_time_base is often double that of the video's actual framerate. Both ffmpeg and DaVinci Resolve export files which have this same characteristic. At first glance, it might seem that codec_time_base is counting fields instead of frames, but this also happens with progressive scan files. Beyond that, there are some progressive scan files I've encountered which have codec_time_base values like 499/50000, despite having an r_frame_rate of 50/1.

This discrepancy can result in false warnings in the rundown view where Sofie says that a package has the wrong media format, even though the package is actually of the correct format (or vice versa).

• What is the new behavior (if this is a feature change)?

In this PR, buildPackageFormatString has been changed to look at r_frame_rate instead of codec_time_base when determining a package's framerate.

• Other information:

buildFormatString has not been changed, as it doesn't seem to have access to r_frame_rate data. I'm not sure how much we care about this, seeing as buildFormatString seems to be for the older Media Manager and doesn't seem to be part of the Package Manager data flow.

Also of note is that this will cause interlaced packages to report their frames per second instead of their fields per second. If this is not desired, a conditional statement that checks deepScan.field_order could be added which retains the existing behavior for interlaced content. Such a change might look like this instead:

if (stream.r_frame_rate) {
	const formattedFramerate = /(\d+)\/(\d+)/.exec(stream.r_frame_rate) as RegExpExecArray
	let fps = Number(formattedFramerate[1]) / Number(formattedFramerate[2])
	if (
		deepScan.field_order === PackageInfo.FieldOrder.TFF ||
		deepScan.field_order === PackageInfo.FieldOrder.BFF
	) {
		fps *= 2
	}
	fps = Math.floor(fps * 100 * 100) / 100
	format += fps
}

[jstarpl]

Looks good. It definitely seems like r_frame_rate is the "frames per second" (frames, not fields!) value, while what codec_time_base means can vary. I think the use of codec_time_base may have been used to facilitate the non-standard use of format monikers like "1080i5000", where the 5000 refers to the sampling rate rather than frame rate.