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
CodecDelay states "This timestamp value MUST be subtracted from each frame timestamp in order to get the timestamp that will be actually played."
CueTime just says "Absolute timestamp of the seek point." But "absolute timestamp" can be interpreted in different ways. The interaction of these two elements is unclear and underspecified. Questions:
Should CueTime's absolute timestamp value be Cluster.Timestamp + Block.Timestamp, or should it be Cluster.Timestamp + Block.Timestamp - CodecDelay? If the latter, should it also account for any potential DiscardPadding in a block group?
Should the duration of the cue account for CodecDelay? If so, should it also account for any potential DiscardPadding in a block group?
In my experience cues have not accounted for CodecDelay or any DiscardPadding. Assuming this is correct, it may also be worth calling out that applications should account for CodecDelay (and DiscardPadding if feasible, though that's harder) when using CueTimes because it's pretty easy to accidentally skip it.
For example, let's say an Opus track is saved with 5 segments with each being 10 seconds long (ignoring any codec delay or padding) with CueTimes of 0s, 10s, 20s, 30s, and 40s. It would be technically incorrect for the application to blindly take these CueTimes and use them or present them to the user. The actual media times for these segments are be [0, 9.9935] for the first segment, [9.9935, 19.9935] for the second segment, etc. until [39.9935, 49.9935] for the final segment.
The text was updated successfully, but these errors were encountered:
CodecDelay
states "This timestamp value MUST be subtracted from each frame timestamp in order to get the timestamp that will be actually played."CueTime
just says "Absolute timestamp of the seek point." But "absolute timestamp" can be interpreted in different ways. The interaction of these two elements is unclear and underspecified. Questions:CueTime
's absolute timestamp value beCluster.Timestamp + Block.Timestamp
, or should it beCluster.Timestamp + Block.Timestamp - CodecDelay
? If the latter, should it also account for any potentialDiscardPadding
in a block group?CodecDelay
? If so, should it also account for any potentialDiscardPadding
in a block group?In my experience cues have not accounted for
CodecDelay
or anyDiscardPadding
. Assuming this is correct, it may also be worth calling out that applications should account forCodecDelay
(andDiscardPadding
if feasible, though that's harder) when usingCueTime
s because it's pretty easy to accidentally skip it.For example, let's say an Opus track is saved with 5 segments with each being 10 seconds long (ignoring any codec delay or padding) with
CueTime
s of 0s, 10s, 20s, 30s, and 40s. It would be technically incorrect for the application to blindly take theseCueTime
s and use them or present them to the user. The actual media times for these segments are be [0, 9.9935] for the first segment, [9.9935, 19.9935] for the second segment, etc. until [39.9935, 49.9935] for the final segment.The text was updated successfully, but these errors were encountered: