-
Notifications
You must be signed in to change notification settings - Fork 28
Description
Hello,
mkvmerge started writing CueRelativePosition and CueDuration elements beginning in version 5.9; but there was a bug in the early implementation: Up until version 6.3 CueRelativePosition pointed to the inner block of a blockgroup (if a subtitle packet is stored in a block and not a simpleblock). But mkvalidator doesn't seem to check whether CueRelativePosition (and probably CueDuration, too) is wrong and says that such files appear to be valid.
[Edit]: After noticing mkvalidator not complaining about a file with a wrong CueClusterPosition entry I looked at the code a bit and found out that CueClusterPosition is not only not checked, but that the check for the validity of the cues is highly inefficient: Currently all blocks that precede (in storage order) the block with the right timestamp (if it exists) are checked, although there is no need to check all these blocks: It is only needed to check the cluster that is actually referenced via CueClusterPosition whether it contains an entry with the right timestamp and TrackID. If there isn't a cluster at the right place or it doesn't contain (simple)block with the right timestamp, then we already know that an error is appropriate and the file is invalid; there is no point in checking whether a different cluster contains a block with the right TrackID and timestamp.
[Edit2]: And judging from the code, only the first CueTrackPositions is actually checked (i.e. if there is no (Simple)Block with the TrackID given in the CueTrack in any subsequent CueTrackPositions, then no error is raised).
Greetings
Andi