Re: time & timecode semantics in XML exports
Re: time & timecode semantics in XML exports
- Subject: Re: time & timecode semantics in XML exports
- From: Helena Ju <email@hidden>
- Date: Mon, 16 Jul 2007 11:19:23 -0700
Hi Andreas,
A Freeze frame can be detected by the presence of "stillframeoffset"
which specifies the offset in frames from the start media value. The
out and duration are used in calculating the useage of said
freezeframe (how long it is held). (p 64 of the current version of
the FCP XML documentation).
The contents of a freeze frame could be either a sequence or a single
piece of media. Imagine for example a composite of a picture in
picture setup in a sequence being used as a freeze frame. Then on
could recreate the freeze frame by creating the sequence and then
using the stillframeoffsest to see which frame of the sequence is
referenced and thereore, which media is being used.
The absence of a timecode scope is a coincidence and I suggest you
don't rely on it as an indicator of a freeze frame.
Please write up a bug if the Freeze Frames aren't roundtripping
through FCP as expected.
Regards,
Helena
On Jul 14, 2007, at 5:18 AM, Andreas Kiel wrote:
Hi all,
Still same thread and theme but another problem.
oh! on the whole timecode not being required thing... timecode
isn't required for file definitions where the file is present...
We just require it there when the file is not present.
Sequences however, must have timecode since it doesn't really come
from anywhere else.
That's not totally true. If you make a freeze frame from a nested
sequence the "first level sequence" doesn't have a <timecode>
(that's at least my theory). The last one does. And that's where
the problem starts.
I'm working on a project for one of the world's big broadcasters
and we try to build a solution which will give them an overview of
used material (sometimes to track rights).
Having a nested sequence which doesn't have a <timecode> entry
means obviously that it is a freeze frame.
To track the sources (and figure out which pictures are used) I can
use the <in> entry of the nested clip to retrieve the frame in the
original sequence (<out> and <duration> have to be ignored as it is
only 1 frame -- though they are there unfortunately, see below). If
one of the available clips (at this time) is a nested item as well
I've to repeat the step until I got anything resolved.
To proof this theory I created dummies for the nested sources and
reconnected them to some of the offline XMLs they provided me. I
was pretty surprised that these files weren't freeze frames any
more but standard clips.
To proof I made a simple project containing a sequence with one of
the dummies, dragged that into a new sequence, selected it, made a
freeze frame somewhere, a cut at that time in the timeline and
inserted the freeze frame there - the sequence plays as expected.
Then export as XML and re-import the XML and same result as
"expected" -- freeze frame is gone and the part of the original
sequence defined by <in> and <out> is played.
If use the dummy directly instead of the sequence with dummy and do
the same thing everything works fine with the round trip.
The workaround could be to render and replace the nested sequences
- but then they can't be resolved anymore (or extracted and resolved)
Is this a known problem?
And is my theory of resolving the things correct?
Regards
Andreas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden