Closed nigelmegitt closed 5 years ago
Discussed on call 2019-03-20, consensus at this time is to support only media
time base.
We should also remove the need to support #region-timing
because times on regions really aren't helpful when you're not rendering into regions.
To be clear, by omission, #region-timing
was already prohibited, but it might be useful to make it explicit.
I think this is a sensible place to start - but it is casting the spec as distribution-focussed rather than creation or archive focussed; had we made that distinction yet (apologies if we have)?
@simpson-matt it's not my intention to cast the spec as distribution-focussed. However it is true that if we only permitted media timebase then both creation and archive use would require that the start time of the related media would need to be known to allow correct synchronisation, and any change to that time might need a change to the AD file's timings to compensate.
To make this concrete, if a video is created with SMPTE timecode beginning at 10:00:00:00
, and the AD file is correctly made and synchronised so that media time 0s
corresponds to the that timecode, and then, an edit is made that removes the first 10s, so that the new start timecode is 10:00:10:00
, then the AD file would need to be edited so that all the top level timings, e.g. div
begin
times if present, are 10s earlier, and any descriptions in the first 10s would need to be dropped.
Whether that is acceptable or not is of course a matter for this group to determine. I'm hoping it is acceptable, because it simplifies matters greatly further down the chain.
As per IMSC, I think it would make sense to allow only media timebase, effectively meaning that the first moment of the video is at time zero, and prohibit use of smpte and clock timebases. I'd also rather avoid smpte-style time expressions with frames because that then introduces the need for frameRate, frameRateMultiplier and dropMode, all of which add complexity.