TOPIC:

Your original A6600 120 fps clip displays in FCP as a "high frame rate clip". As mentioned on page 90 of the FCP User's Guide, that is indicated by a spinning wheel icon on the thumbnail. See attached.

I don't know why Apple chose to represent high-frame-rate clips that way vs just showing the frame rate in the Inspector. However they documented this in the User's Guide, which can be downloaded and searched as a PDF: support.apple.com/guide/final-cut-pro/welcome/mac

The metadata of multiple clips can also be viewed side-by-side in a spreadsheet-like format using Invisor. I strongly recommend checking things like this. It should especially be checked when planning a workflow, not after a workflow is implemented and you find something doesn't work: apps.apple.com/us/app/invisor-media-file...or/id442947586?mt=12

Such clips can be slowed down using the normal FCP retiming controls like any other high frame rate clip.

The 120 fps Sony clip does not show source timecode in FCP, the same as all the other Sony MP4 clips regardless of frame rate. You can process all those clips using the QTChange utility I previously mentioned, which enables FCP, Compressor and other apps built with AVFoundation to read and display that timecode: www.videotoolshed.com/handcrafted-timecode-tools/qtchange/

However even if you do preprocess the clips with QTChange, there is an issue whereby a high-frame-rate MP4 clip (at least from Sony mirrorless cameras) may not retain that format upon re-encoding. That is likely because of the same old issue with non-standardized timecode representation in MP4 containers and how AVFoundation handles that. Some manifestations might be unique to high-frame-rate clips, at least with Compressor.

One solution is just reprocess the output clips of Compressor with QTChange, which seems to restore that readable timecode.

Re source timecode from certain iPhone clips not showing in FCP, I tested several of those cases and Resolve Studio 18.1.4 also behaves like Final Cut. It also does not show source timecode from those iPhone clips.

I believe all these issues can be traced back to ISO and other standards organizations not defining a proper spec for MP4 metadata -- and especially timecode. Ten years ago Apple mentioned this looming problem and recommended the industry use either MP4 metadata modeled after Quicktime, or anything else which would fulfill the requirements. ISO and the other standards bodies never did that, so here we are today.

This is why you don't have problems like with with MXF files from a pro camera like the Sony FX6 or others. MXF is a professional container format with good metadata support for timecode designed in.

Apple Technical Note TN2174 from 2013, stating the need for industry standardization about timecode metadata in MP4 containers:
developer.apple.com/library/archive/tech...s/tn2174/_index.html

Joe, the Sony clip does show its framerate in the FCP Inspector info tab, as does the iPhone camera clip and the Mavis.app clip. They all show the "spinning wheel" icon on the Browser thumbnail or preview.

The iPhone camera app doesn't include a TC track in its recordings but the Mavis app does include a QT TC track.

So, to transcode the Sony MP4 and the Mavis (non-HEVC) files into HEVC with the original timecode intact, you just need to use EditReady. QTChange isn't needed...

Really thank you both, your knowledge is impressive.

I still need to check the QTChange process, if I can add the TC after transcoding from Compressor that would be great.

The idea after transcoding to H265 is because there is a first color grading before the multicam edit.

I'm aware the ideal multicam workflow would be working with original files preferably transcoded to Proress, but new Macs work with H265 at 4K at full speed, and the saving space is awesome, we can work with just few affordable 4TB NVMe M.2 disks, we are developing an interview format which needs lots of clips and delivery almost in a daily basis and more, so the first step is to apply color correction and noise reduction to the clips, then keep them in H265 (as there are 4 cameras/angles in 4K for >1.5 hour) then edit in multicam, adding covers and so...

FCPX is an amazing piece of software, the performance and transcode speed is amazing, so we love to keep working with it.

Dave, I'm so sorry my OP wasn't clear enough, I'm reading it and I'm aware that the problem is not exposed clearly, in part for my insufficient English, as is not easy to me express technical needs sometimes even in my native language.

cocoua wrote:

Dave, I'm so sorry my OP wasn't clear enough, I'm reading it and I'm aware that the problem is not exposed clearly, in part for my insufficient English, as is not easy to me express technical needs sometimes even in my native language.

I realized that there might be a language issue, especially after seeing the naming of the sample media folder/archive you provided. Some of the terminology involved is difficult for most of us, even in our native languages. I hope we helped, if only somewhat...

Note:
Since you included the "Editready rewrap" folder in the media archive, I thought that you might have access to EditReady. If so, EditReady can transcode files, it isn't just for "re-wrapping". Also, it may run faster than Compressor, out of the box. Again, both the Mavis generated media (I made in my testing) and the Sony file you provided transcoded with EditReady into HEVC files do have proper timecode...

DaveM wrote:

...So, to transcode the Sony MP4 and the Mavis (non-HEVC) files into HEVC with the original timecode intact, you just need to use EditReady. QTChange isn't needed...

Dave, I think a possible source of confusion is when cocoua says FCP shows 60 fps for a 120 fps clip, he is just looking at the top row of Inspector. Yes if you select Inspector's General or Extended view then look down that pane, it shows 119.88 fps. It's possible he didn't do that and the confusion comes from focusing on the top-line item with Inspector in Basic view. Maybe cocoua could comment?

Re transcoding Sony MP4 rewrapped files from EditReady, that works on *input* for viewing in FCP and Compressor. It is not maintained for output from FCP (or in some cases, Compressor). The Compressor method I previously drew the graphic about does not work for 120 fps. I don't know why; maybe a combination of poor timecode support in MP4 plus 120 fps. Tracking down the cause would take more work.

In all the cases I examined so far, processing the exported output files with QTChange seems to work, provided the timecode was there from the start (even if not visible to FCP or Compressor).

I understand the situation cocoua is facing. My team includes several distributed editors and we're shooting lots of RED material, so we can't send that via internet. Using HEVC transcodes is a good workaround, provided the timecode and other issues are solvable. We previously used an AWS cloud service which transcoded a ProRes version to H264 but it didn't use a Quicktime container so FCP could not read that timecode. We are transitioning to another platform yet to be finalized, so I need to examine this area for my own team.

Timecode is just one area of the difficulty. There's the issue of consistent filenames, FCP relink, etc. If the proper workflow is not researched and thoroughly tested, it can cause extreme stress on the editor, asst. editor, etc, plus missed deadlines. However the underlying cause of those problems is often not well understood throughout an organization so the preproduction workflow investigation and testing frequently do not get the needed priority and staffing.

joema wrote:

Dave, I think a possible source of confusion is when cocoua says FCP shows 60 fps for a 120 fps clip, he is just looking at the top row of Inspector. Yes if you select Inspector's General or Extended view then look down that pane, it shows 119.88 fps. It's possible he didn't do that and the confusion comes from focusing on the top-line item with Inspector in Basic view. Maybe cocoua could comment?

Yes, you are correct. I was looking at the metadata. I actually don't know why that says 60p...

joema wrote:

... <snipped> ...

Timecode is just one area of the difficulty. There's the issue of consistent filenames, FCP relink, etc. If the proper workflow is not researched and thoroughly tested, it can cause extreme stress on the editor, asst. editor, etc, plus missed deadlines. However the underlying cause of those problems is often not well understood throughout an organization so the preproduction workflow investigation and testing frequently do not get the needed priority and staffing.

Thanks for that added info. I agree that post is sometimes given short shrift in terms of workflow organization/planning and implementation. I totally agree that comprehensive testing is needed prior to executing a project, if at all possible, for all the reasons you gave. Even something as simple, and seemingly trivial, as "globally" unique filenames is an important aspect of the workflow.

I know that many better-budgeted productions have at least one person whose responsibility is to oversee workflows and communicate between various groups in a project.

The projects that typically suffer the most from lack of planning and execution of any sort of structurerd workflow (it almost goes without saying) are many independent documentary film projects. Some don't even really budget for post until they are done shooting or beginning to edit. "A good editor costs what? It's going to take how long?"...

joema wrote:

Dave, I think a possible source of confusion is when cocoua says FCP shows 60 fps for a 120 fps clip, he is just looking at the top row of Inspector. Yes if you select Inspector's General or Extended view then look down that pane, it shows 119.88 fps. It's possible he didn't do that and the confusion comes from focusing on the top-line item with Inspector in Basic view. Maybe cocoua could comment?
.

I see! dind´t even think in looking there... so weird, the only think comes to my mind is "60" refers to the speed when played, even if the original material has "more frames per second"... so you are looking at a 60 fps video, even if it has encoded many frames more that wouldn't be showed when played (so this would mean FCPX only plays at 60fps even if you have a >120Mhz monitor or it wont play at 120fps if you dont have >120Mhz?)

cocoua wrote:

joema wrote:

Dave, I think a possible source of confusion is when cocoua says FCP shows 60 fps for a 120 fps clip, he is just looking at the top row of Inspector. Yes if you select Inspector's General or Extended view then look down that pane, it shows 119.88 fps. It's possible he didn't do that and the confusion comes from focusing on the top-line item with Inspector in Basic view. Maybe cocoua could comment?
.

I see! dind´t even think in looking there... so weird, the only think comes to my mind is "60" refers to the speed when played, even if the original material has "more frames per second"... so you are looking at a 60 fps video, even if it has encoded many frames more that wouldn't be showed when played (so this would mean FCPX only plays at 60fps even if you have a >120Mhz monitor or it wont play at 120fps if you dont have >120Mhz?)

I guess that the fastest a clip can play back is 60 FPS. Anything with a higher frame rate will likely drop some frames, depending on the Rate Conform setting (but I'm not sure).

I recorded around 8 seconds of video in my tests. The clips all play back in 8 seconds in FCP or QT Player, whether 120 FPS or 240 FPS.

The clips do retain all of their frames, however. So, if you retime a 120 FPS clip to 25% in a 30 FPS timeline, it would play back each frame.

I'd imagine that the Rate Conform setting in the Video Inspector would affect playback at certain speeds.

I would say that 60 FPS is a hard limit in FCP as it is the fastest you'd use when delivering a video for most uses... (?)

Joe, or someone else, may have further insights into this...


Addendum:
I imported one of my test clips into DaVinci Resolve Studio 18.1.4. Resolve allows the user to make a 120 FPS project. The clips seems to play back at 120 FPS but the frame rate icon blinks mostly red rather than green. When the clip is used in a 30 FPS timeline it plays back without issue at 30 FPS.

Whether the clip is played back without any visual "glitches" in an application that supports 120 FPS (in this clip's case) may have to do with the GPU, macOS, and the connected display. This is different from editing with the faster frame rate clip, as far as I know...