site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com Hi Andreas, Regards, Helena On Jul 14, 2007, at 5:18 AM, Andreas Kiel wrote: Hi all, Still same thread and theme but another problem. 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 (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.ap... 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. 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) This email sent to site_archiver@lists.apple.com