You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In most cases, each element spawns at least one thread and communicates with other elements via channels.
38
+
39
+
## Timestamps
40
+
41
+
- Inputs always start PTS from `queue_sync_point.elapsed()` when first packet arrives. If ahead of time processing is enabled it might lead to unexpected behaviors.
42
+
- Input is responsible for maintaining continuity of the stream until it sends EOS event. After EOS, it is expected to synchronize with `queue_sync_point.elspased()` again.
43
+
- Queue handles input offsets. If input does not have offset then timestamps from inputs are preserved. If input has an offset then queue calculates the value based on first packet (from audio or video track).
44
+
- Queue handles pausing inputs. Pause offset is calculated based on difference between `queue_sync_point.elapsed()` on pause and resume calls.
45
+
- When `ahead_of_time_processing` is enabled queue might be processing PTS value a lot larger than `queue_sync_point.elapsed()`
46
+
47
+
## Alternative approach
48
+
49
+
- Inputs always start from some epoch.
50
+
- Queue synchronizes on the first packet
51
+
- How audio and video sync should work?
52
+
- Eos needs and generation number
53
+
- On each track audio and video synchronizes for current epoch
0 commit comments