Speed Bladed clips with optical flow applied won't render

Redifer wrote: Take that into FCPX.

At this point there are already several ways to do this. It's an AVC file, isolated. I could leave files in place on import. Since I didn't want to make a whole test project with just one clip and rather have it between two of my own existing clips, I copied it to library, because I found out long ago that having some files outside the library (in this instance in my downloads-folder on the system drive, whereas my other clips live on an external raid) can cause jumps at the edit points in the preview playback - and perhaps other things? So I copied it to one of my test libraries.

Then there is the option to create optimized media or not. Same thing here. I once decided I never wanted to worry about disk space and bought enough of it. I usually optimize everything, just in case. In my theory, working with highly compressed interframe coded clips puts unnecessary strain on the CPU, particularly with time effects, which I use excessively. Think of it: you usually don't throw a whole clip into the timeline, it's a selection already, a subclip. In and out points of your selection exist in reference to I-frames outside the range you see in the project. Now you want to have a selection (or, with speed blading, part of the selection) analyzed for optical flow. It's clear that FCP X needs to look at the whole clip to do this, isn't it? That is, if you didn't transcode to intraframe before. I would have optimized your Test clip on a second run, but for the sake of his experiment, I didn't optimze it.

Redifer wrote: Speed blade it. Adjust one area so it is faster or slower than the rest.

I speed bladed it after about one third, then slowed the rest to 22%, cmd+9 to monitor what was happening. Set quality to optical flow. Analysis took a second or two.

Redifer wrote: What I would do at this point would be to cut (regular blade) the part that's been speed adjusted and apply optical flow to only the retimed part, as there is no need to optical flow anything at 100% speed.

I think there actually is. For two reasons. First, as I wrote above, FCP X can't isolate the selection from the rest for analysis. Second, you usually (and by default) leave speed transitions checked in the retime editor. Didn't blade the clip itself. If I had wanted an abrupt, jerky speed change, I would have bladed the clip before hitting cmd+r.

Redifer wrote: Now render (select all and Control + R). It will render except for the part that has been optically flowed.

Rendered selected - preview clearly too smooth not to be optical flow. Rendered all (short clips before and after) = same.

Redifer wrote: Try to export. FCPX will complain. Tell it to STFU and export anyway. It will be fine.

Didn't complain. Export was fine.

Redifer wrote: The problem is that it makes realtime previewing impossible without exporting. Optical Flow isn't always desired, sometimes frame-blending achieves a more desirable result, etc. Can't tell without exporting first.

Yes. Off the cuff I can't tell you, but I do know there is a bug, sth. like this happened to me too. And that's he problem. Like cockroaches, some bugs will not show up in bright daylight and can't be reproduced on all systems or in any circumstances. I understand your frustration.

Well, thanks for trying. It affects me on ProRes clips as well, even clips that were originally recorded in-camera as ProRes 422HQ. So like Ronny says it's not related to the codec of the clip. I am using Mac OS 10.12.5, FCPX 10.3.4 and a Mac Pro late 2013. I dont know what other variables could effect the bug but it seems to be dependent on hardware. Maybe a Mac Pro bug since it uses a Xeon processor and not an i-processor? Or maybe something to do with the type of GPU it has?

As for optically flowing stuff even at 100% I find that Optical Flow can sometimes produce undesirable effects even at 100% speed. So I don't give it the chance. I cut right before the speed begins to ramp and after it ends ramping and that's always worked really well for me.

Did that too. Reset retiming and applied it again, using speed blade (at a different point!) and blade afterwards, as you suggested: quality remained set to optical flow, instant playback without rendering. If I don't err, this indicates that the whole clip had been analyzed and that the flow data were stored.

How to delete them? Used Library Manager, which showed there were indeed FLOW data stored for the project, but wasn't sure if I could just clean them (because it said that this would affect 20 GB of media which is just impossible - any advice?).

So I deleted the clip in he timeline and inserted it again. I repeated what you did. Perhaps the blading of the already speed bladed clip caused the error?

No, this time the analysis was triggered again, but everything worked fine. Good to know, for future reference. Didn't know about unwanted artifacts on 100% parts through optical flow.

EDIT: as a sidenote, I use two custom shortcuts for retiming that fit my needs: alt+cmd+r sets automtaic speed (=conform to project framerate), alt+shift+r sets quality to optical flow.

OK, we know this bug exists. Several of us get it. I have it on a 2015 5K iMac, a 2013 Mac Pro, and a retina MBP. I know a post house in New Orleans that never gets it on either of their iMacs. So yeah, it's there for some folks. I've tried everything, nothing "fixes" is. It's a bug. Report it, let's hope it gets fixed in an update or two.

I have been able to reproduce the bug, but only by accident and only once. Let me explain.

I tested Joe's clip on different Macs with different combinations of FCPX/Mac OS. Could not reproduce the issue on any machine. One of the Macs was running FCP X 10.3.3 with MacOS 10.12.5. So while I was at it, I decided to update FCP X to 10.3.4 on that machine.

When I launched FCP X again and opened the project in which I had tested Joe's clip, I noticed that the part of the clip that had been retimed and to which I had applied Optical Flow suddenly was un-rendered. I tried to render it, but couldn't. Then I trashed the render files for that project, and I could render the retimed part of the clip again.

I started all over again, trying to reproduce the issue once more, but did not succeed.

Joe, is it possible at all that your project was started in FCP X 10.3.3 or older, so before you updated to 10.3.4? If so, we have a situation that we could reproduce, which would make it much easier to file a bug report. Submitting a bug report without a reproducible scenario does not make much sense.

- Ronny

just to illustrate ... latest version of FCPX and OSX 10.12.5 but had the same issue with former releases too
deleted before all rendered files too. Retiming set to 50% for the full clip so nothing specific

I get this bug almost daily with new projects, new libraries, 10.12.5 & 10.3.4. This started for me on 10.3.3.

ronny courtens wrote: Joe, is it possible at all that your project was started in FCP X 10.3.3 or older, so before you updated to 10.3.4? If so, we have a situation that we could reproduce, which would make it much easier to file a bug report. Submitting a bug report without a reproducible scenario does not make much sense.

I think you might be on to something here, but I'm not exactly sure what it is. I created a brand new Library and imported some footage. Speed bladed, applied Optical Flow, rendered, all was good! But what's weird is the last sequence I tried this is I know for sure was created after the most recent FCPX update. FCPX hasn't been updated in the last 30 days according to my App Store app, and I've only owned the drone for two weeks so far. So I'm not sure. Like I said you're on to something, just gotta figure out exactly what the trigger is.

What's funny is that the bug is now no longer affecting me even on older libraries with already imported clips.

Just opened an old library of 10.3.0 with optical flow. That was a hit. The bug showed up. Now, Redifer, do you still say that fcp.co suppresses unwelcome criticism?

Sometimes, yeah. But I don't think anyone here consciously tries to "suppress criticism". But when I see comments like "I'm with Ronny" it creates a divide where none needs to be and makes me feel like I'm supposed to shut my mouth.

Anyway I don't think the age of the event or Library is the key. I get the bug on a library created 16 June 2017. But I don't get the bug on a library created today or yesterday, nor do I get the bug in a library created 20 March 2014. I honestly can't tell the difference between the libraries. Obviously there MUST be a difference between them or maybe the events or the projects, haven't figured it out yet.

I did notice this though: If I speed blade a clip in a bugged library and then copy paste that clip to a project in an unaffected library, the bug reproduces. HOWEVER, if I consolidate the media into the library (copying the clip from the affected to the unaffected library) the bug goes away.

I had my own bug-thread, here , and I felt being answered with some condescendence . Like God forbade to ask.

Did this to keep things simple for me:

Axel wrote: I just sent feedback to Apple and linked to this thread in the comment.