Skip to content
This repository has been archived by the owner on Sep 21, 2023. It is now read-only.

Should we restrict the timeBase to media? #1

Closed
nigelmegitt opened this issue Dec 11, 2018 · 5 comments · Fixed by #9
Closed

Should we restrict the timeBase to media? #1

nigelmegitt opened this issue Dec 11, 2018 · 5 comments · Fixed by #9
Labels
pr open Issue with an open pull request

Comments

@nigelmegitt
Copy link
Collaborator

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.

@nigelmegitt
Copy link
Collaborator Author

Discussed on call 2019-03-20, consensus at this time is to support only media time base.

@nigelmegitt
Copy link
Collaborator Author

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.

@nigelmegitt
Copy link
Collaborator Author

To be clear, by omission, #region-timing was already prohibited, but it might be useful to make it explicit.

nigelmegitt added a commit that referenced this issue Apr 4, 2019
### Prohibit the following features:

* `#clockMode`
* `#clockMode-gps`
* `#clockMode-local`
* `#clockMode-utc`
* `#markerMode`
* `#markerMode-continuous`
* `#markerMode-discontinuous`
* `#region-timing`
* `#timeBase-clock`
* `#timeBase-smpte`
@nigelmegitt nigelmegitt added the pr open Issue with an open pull request label Apr 4, 2019
@simpson-matt
Copy link

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)?

@nigelmegitt
Copy link
Collaborator Author

@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.

nigelmegitt added a commit that referenced this issue Jun 6, 2019
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.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
pr open Issue with an open pull request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants