unified handling of timespan and time quantisation
| Reported by: |
Ichthyostega |
Owned by: |
Ichthyostega |
|
Priority:
|
grave
|
Milestone:
|
0integration
|
|
Component:
|
lumiera
|
Keywords:
|
design interfaces data professional sanity
|
|
Sub Tickets:
|
#84, #732, #741, #743, #744, #745, #760, #765, #855, #1258
|
Parent Tickets:
|
#12, #55, #283, #751, #767, #768
|
As Lumiera Architect,
I want time-spans and time quantisation to be handled by a common framework,
to avoid quality problems and to allow integration of sequences with different framerate
design and investigation of requirements
The foundation for time handling is in place: we use a micro-tick scale, together with C++ marker types, to enforce a common usage pattern and to ensure any grid alignment (which implies information loss) happens as late as possible. However, some advanced topics have been postponed for further research, especially how to deal with time intervals, when having to consider frame quantisation. Can an interval itself be frame quantised? Shall intervals be shifted automatically to align to grid, or is it better, conceptually to grid-align the start / end-point?
- investigate the problems related to frame quantisation
- consider especially that a
TimeSpan can serve as minimalistic representation of a clip, and the underlying media can itself impose another grid.
- either find a suitable usage policy for gavl_time_t or write some C library functions
- incorporate the findings into a Quantised Time Interval representation, which handles quantisation automatically within the established framework
Acceptance Criteria
- given
-
a medium with implicit time-grid-A
- when
-
an interval from this media is taken and placed into a context with implied time-grid-B
- then
-
- a definition of »correct handling« is available
- alignment and adjustments for according to this definition are performed
- automatically
- as late as possible
- and with minimal data loss
Change history
(19)
| blockedby: |
→ 84
|
| Owner: |
set to Ichthyostega
|
| Status: |
new → accepted
|
| blockedby: |
84, 732 → 84, 732, 741
|
| blockedby: |
84, 732, 741 → 84, 732, 741, 743
|
| blockedby: |
84, 732, 741, 743 → 84, 732, 741, 743, 744
|
| blockedby: |
84, 732, 741, 743, 744 → 84, 732, 741, 743, 744, 745
|
| blockedby: |
84, 732, 741, 743, 744, 745 → 84, 732, 741, 743, 744, 745, 760
|
| blockedby: |
84, 732, 741, 743, 744, 745, 760 → 84, 732, 741, 743, 744, 745, 760, 765
|
| blocking: |
283, 751 → 283, 751, 768
|
| blocking: |
283, 751, 768 → 283, 751, 767, 768
|
| blockedby: |
84, 732, 741, 743, 744, 745, 760, 765 → 84, 732, 741, 743, 744, 745, 760, 765, 855
|
| Description: |
modified (diff)
|
| blockedby: |
84, 732, 741, 743, 744, 745, 760, 765, 855 → 84, 732, 741, 743, 744, 745, 760, 765, 855, 1258
|
| blocking: |
283, 751, 767, 768 → 12, 55, 283, 751, 767, 768
|
| Description: |
modified (diff)
|
| Keywords: |
design interfaces data professional sanity added
|
| Summary: |
unified handling of timespans and time quantisation → unified handling of timespan and time quantisation
|
| blockedby: |
84, 732, 741, 743, 744, 745, 760, 765, 855, 1258
|
| blocking: |
12, 55, 283, 751, 767, 768
|
| Parent Tickets: |
→ 12, 55, 283, 751, 767, 768
|
| Sub Tickets: |
→ 84, 732, 741, 743, 744, 745, 760, 765, 855, 1258
|
(In #84) Time wrapper type is now integrated and in use by Proc. Joel promised to adapt time handling in GUI too. Closing the main issue for now, and opening a new ticket for the remaining task of handling timespans and time quantisation