-
External matte out of sync with its own original timeline footage: How to avoid this or how to add an offset???
Importing an external matte into its own original timeline shows the matte to be out of sync with the original footage.
That is, look at the timecode burned into the external matte on the first frame and compare it to the timecode of this same clip from which it was originally taken: they are out of sync.Simply create a test window in a clip, for example, a window over a face in the clip; export it as an alpha, then add it back into the same timeline as a matte;
Visually and by comparison of the first frame and its timecode, the matte is out of sync.
For me, it is consistently about 47 frames.
Duplicated this behavior over a dozen times with different codecs.Doing something wrong??? Any helpful thoughts would be appreciated.
Here is the setup used:
1. Use any clip, perhaps showing a face; create a mask for the face;
—Note the timecode for the starting frame of the clip.
2. Set up the alpha output: Add an alpha output to the node tree and verify the key in the final node using highlight and the key tab;
3. Set up the Deliver tab output; in the Deliver page choose a codec for the matte export;
4. Select the timecode export option so this burned-in timecode will be visible later in the exported matte;
5. Export the matte;
6. Import that matte into the source clip’s media pool as a matte;
7. In the node tree add an external matte and select the matte just created in this same timeline.
8. Now the matte is shown in the clip video as expected, HOWEVER IT IS OFFSET by some number of frames.View and compare the timecode of the original video and the timecode of the matte video: they are not the same. On my system this is a significant difference of about 47 frames.
Note that there is a media import option to add a timecode offset to video source but this option does not seem to be available for files imported as mattes.
Did not find anything in the documentation about offsets that seem to address this.
Any thoughts?
Thanks as always, Mike
-
6 Replies
-
-
Thanks, Noah; Sorry but I have made a video recording so I would have to learn that; it would surely be helpful from time to time.
But very simple really: I want to mask (and track) a face for later color adjustments.
My goal is to export that face mask as a matte (along with its tracking, etc.). For this purpose most of the other nodes in this larger tree are disabled so the output is only of the face mask.
The larger purpose is to off-load some of the system video processing demands. This clip has a very large node tree (two dozen or more) and the processing, while it works, is thus bogging down the system. Thus if one has several face masks, this process would have to be repeated for each one to gradually lower the burden on the system.
That exported matte is then brought in via the External Matte process. It is used in lieu of the set of nodes that built the face mask. That is, a series of nodes that created the face mask would include a tracked window, one or two filer nodes, a key node (the filtered key fed to the video input of a node where it is tweaked using curves and blur).
Those original now-redundant face mask nodes are then deleted, resulting in a more compact and efficient node tree. This is a major reduction in the burden on the system when one has four or five such face masks, plus other masks throughout the long clips.
Anyway, this exported matte is re-introduced as an External Matte to take the place of the node sub-tree that can then be deleted.
OK. Works. I can see the external matte, make further adjustments to it as needed, etc., BUT …
there is a time code offset between the imported matte and the original clip. Visually, one can see the mask offset from the face due to some movement during those 47 frames.For test purposes, I burned time code into the exported matte and so it can be compared on screen with the displayed time code of the original clip. It shows and offset, for me, consistently of about 47 frames.
Does this clarify the process and the problem??? Any thoughts would be appreciated.
Thanks, Mike
-
Do you have handles turned on when outputting your mask?
Is your mask shorter or longer than the clip it is designed for…or is it the same length, just offset?When you call up the clip attributes of your matte, you can go to the timecode section and set an offset…that might help, but unless you have handles turned on, there is something going on in your original setup.
Either you are looking at handles in your timeline, but not exporting them, or you are exporting handles, but not looking at them in your timeline.
Glenn
-
Excellent tips, Glenn;
Your tips are at the level of detail I really miss in nearly all Resolve online training.
It seems that the workflow *implications* of some settings, such as handles, do not receive as much attention after pointing out the feature itself. For example, handles are discussed with respect to the benefit to editors: never occurred to me that, in this case, I may be sending those handles to myself as part of the external matte.
Perhaps a good topic that might be included by Patrick Inhofer in his Lynda.com Resolve Guru series.
Much appreciated, Glenn.
Checking handles. I suspect I will find 24 frames set for handles, so in and out handles together would equal the 47-48 frame offset I am seeing.
Thanks again, Mike
-
please let me know if that is indeed the case.
Glenn
-
Glenn; yes, the handles removed THAT visible offset.
By THAT visible offset I mean that all the visible spatial offsets did not disappear.I discover–ah, it never ends–that there is another visible offset to deal with. I discover than my original clip needed a slight rotation to level the horizon. But THAT offset was not incorporated, it seems, into the rendered alpha output. Or, that it also needs the same rotation adjustment as the original.
As it is, the external matte image and the node tree image have a slight rotation misalignment.
The manual does discuss the order of operation with regard to sizing modes, but I have yet to understand how exactly this issue arises.
Onward and upward!
Thanks again, Glenn.
Reply to this Discussion! Login or Sign Up