The vast majority of QT timecode tracks do not do this, including those from high-end cinema cameras, and I think this is a complete red-herring for the Lightworks problem you (and I) are having. The timecode inside the QT wrapper is not (ever) actual SMPTE-layout timecode, but there is a way of specifying the various flags and fields in a record so that it is similar. time, and the MediaInfo header you posted shows that your original file has it. "YES! That's why I've extracted TCs from H264 non-standard metadada by myself and rewrapped them into standarized place - a Timecode track (tmcd) inside the QuickTime container."Īctually, the Quicktime container has had standardised timecode for a very long. But if so, the LABEL still is the primary reference, because if you change it the program carries on happily with the new value. It's possible that LW also now has some other label/timecode information embedded in the binary part of the ED5. Fortunately, this is now beginning to change even on video.īut 'timecode' is *not* synonymous with SMPTE timecode, and Lightworks doesn't make that mistake. On videotape, actual time was always getting confused with timecode or the position on the tape - hence the mess that is traditional SMPTE timecode. I imagine the term LABEL was chosen rather than timecode because it is generic and does not imply time-of-day - for example, you used to have KeyKode labels for film, and there's no time involved at all there. That used not to matter, it does now, and all applications are going to have to adapt. Because the LABEL is typed, it knows how to do this whether for probing the clip or making a SMPTE-formatted timecode-string.Īs I say, a clip (or edit) can have multiple LABELs - for example so that you can display different kinds of timecode, all accurate and formatted correctly (because properly typed: SMPTE timecode cannot do this.)Īn advantage of this system is that you can change a LABEL later, and everything works with no further changes.Ī disadvantage is that since it assumes a constant frame-duration (individual frames aren't labelled) LW has problems with variable-frame-rate material. Internally, LW works in floating-point time: when it needs to, it adds the internal time to the LABEL start and uses the result to find a frame, generate a timecode, and so on. This defines the standard, the start-value, the number of samples (frames), the length of each frame in seconds, and the type of the medium that the track of samples comes from (which helps define the relationship between position of the sample and the time it is needed for playout.) A LABEL (unlike a SMPTE or time-of-day timecode) is fully typed - here is an example: When a clip is recorded/imported, it is given one or more LABELs. The way Lightworks handles these things used to be as follows (it still behaves in accordance with this): It is a display only, and is definitely not timecode." "I'm sorry, but that isn't a fact at all. it will handle TC properly according to the video specification (frame rate and so on)." "Other fact is that Lightworks is handling TC even without any TC reference track.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |