-
Notifications
You must be signed in to change notification settings - Fork 7
Should we restrict the timeBase to media? #1
Comments
Discussed on call 2019-03-20, consensus at this time is to support only |
We should also remove the need to support |
To be clear, by omission, |
### Prohibit the following features: * `#clockMode` * `#clockMode-gps` * `#clockMode-local` * `#clockMode-utc` * `#markerMode` * `#markerMode-continuous` * `#markerMode-discontinuous` * `#region-timing` * `#timeBase-clock` * `#timeBase-smpte`
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 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. |
Permit only media timebase. Closes #1. Merging this to allow easier review and reduce the open issues. If there are strong reasons to re-enable other time bases, we can revert this change.
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.
The text was updated successfully, but these errors were encountered: