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

Frame rate chart in Apple documentation isn't lining up with real-world results #323

Open
IAmVigneswaran opened this issue Jan 10, 2024 · 7 comments
Assignees

Comments

@IAmVigneswaran
Copy link
Contributor

Apple Feedback Assistant ID: FB13528135

DESCRIBE THE BUG:

The documentation provided on this link does not seem to be accurate or correct.
https://developer.apple.com/documentation/professional_video_applications/fcpxml_reference/story_elements/conform-rate

The information provided has no correlation with real-world results.

For example, the chart indicates that no scaling happens between 23.98 and 60 but we are finding that there is in fact a calculation required to time values in the local clip timeline to achieve the same timecode location as Final Cut Pro is showing for containing/anchored objects. And this is only one such example.

A chart with pull-up/pull-down rates between timeline and media rates would be what we hope to find in that section of the documentation.

We have documented this issue here.

TheAcharya/MarkersExtractor#81

@latenitefilms
Copy link
Contributor

Are you able to share some FCPXMLs of where things aren't lining up to what you expect as per the documentation?

@IAmVigneswaran
Copy link
Contributor Author

Are you able to share some FCPXMLs of where things aren't lining up to what you expect as per the documentation?

I forgot to attach them. But I can always send the FCPXMLs if they request for more details.

@latenitefilms
Copy link
Contributor

It would be great if we could have an example here of where the documentation is wrong/incorrect.

Here's the DTD for conform-rate:

<!-- A 'conform-rate' defines how the clip's frame rate should be conformed to the sequence frame rate -->
<!ELEMENT conform-rate EMPTY>
<!ATTLIST conform-rate scaleEnabled (0 | 1) "1">
<!ATTLIST conform-rate srcFrameRate (23.98 | 24 | 25 | 29.97 | 30 | 60 | 47.95 | 48 | 50 | 59.94) #IMPLIED>
<!ATTLIST conform-rate frameSampling (floor | nearest-neighbor | frame-blending | optical-flow-classic | optical-flow) "floor">

Are you able to produce an example Library where FCPX is doing something that doesn't match the below image?

@IAmVigneswaran
Copy link
Contributor Author

There are a lot of different combinations against timeline frame-rate. I would have to create a new test library. Will update this issue once I have performed some extensive test.

@latenitefilms
Copy link
Contributor

It would be good to just have one simple example where what you're seeing in a FCPXML differs from that chart.

@joema4
Copy link

joema4 commented Jan 12, 2024

There is a possible terminology issue. The above-mentioned chart is denoted "rate conforming" in the docs, but there are two different types of rate conforming:

(1) Retiming, whereby the clip is run at a different rate to match the timeline. This is only done for small adjustments such as a 24.0 clip in a 25.0 timeline. (2) Frame duplication/discarding in a pattern that maintains longer-term sync at the cost of motion cadence. E.g, a 24.0 clip in a 30.0 progressive timeline would duplicate every fifth frame. That is also called "rate conforming". To my knowledge, there is no official term to differentiate those two methods.

In the 24.0 to 25.0 case, the original clip timecode will not match. BTW, "timecode" is actually just a per-frame label, although we normally view it as time. For a 24.0 clip in a 25.0 timeline, the rate conforming algorithm is to retime the 24.0 by running it 4.16% faster. In that case, the 24.0 clip timecode will progressively get out of sync vs the 25.0 clip's timecode.

The stated scenario was mixing 23.98 fps and 60 fps frame rates, and the above chart shows a blank for that combination. However if you put a 60 (or 59.94) fps clip in a 23.98 fps timeline, they are "rate conformed" by a certain pattern of frame discarding on the 60 fps clip. That discard pattern will result in a timecode resync interval every 24 frames. In between those resync points, the individual clip timecodes will progressively diverge. That is because frames are being discarded from the 60 fps clip to stay in sync (overall) with the 23.98 fps clip.

You can inspect that by adding the FCP built-in "timecode" effect to each clip, stack the clips on top of each other, and adjust the viewer scaling to see both timecodes simultaneously. You can use clip skimming to skim to a given timecode on one clip, set a marker, then repeat on the other clip, set a marker and line them up. A 23.98 and 59.94 clip (inc'l timecode) will stay in sync long term, but during 24-frame intervals they will grow out of sync.

This assumes the 59.94 or 60 clip are NDF, otherwise timecode will rapidly get further out of sync. By convention, 23.98 and 24.0 are always NDF. 29.97 and 59.94 are by convention DF, but some cameras allow setting those to NDF.

Even with NDF, there is no guarantee that a random clip timecode on a 23.98 clip will match a timecode on the 59.94 fps clip. If the 59.94 frame has been discarded during rate conforming, that timecode value will be missing. But the timecode values should match every 24 frames.

If you aren't certain whether your 59.94 or 60.0 fps clip is DF or NDF, you can check that using a metadata viewer in MediaInfo, Invisor, or command-line tools like ffprobe.

@latenitefilms
Copy link
Contributor

I think the best solution to solve this is to build a "Test Library" with every combination of Timeline Frame Rate and Source Clip Frame Rate, and then update the FCPXML Documentation on FCP Cafe.

FCPXML is insanely confusing, and the documentation sucks - so I think we can do better on FCP Cafe.

I'll continue to update the FCPXML page over the coming weeks and months. Stay tuned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants