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
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
The text was updated successfully, but these errors were encountered:
mkver
changed the title
mkvalidator doesn't detect wrong CueRelativePosition
mkvalidator doesn't detect wrong CueRelativePosition, CueDuration and CueClusterPosition
May 5, 2018
mkver
linked a pull request
Feb 8, 2019
that will
close
this issue
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
The text was updated successfully, but these errors were encountered: