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
The WebVTT codec mapping currently has this to say about WebVTT comments:
"The third and all following lines contain all WebVTT Comment Blocks that precede the current WebVTT Cue Block. These may be absent."
This does not say how multiple comment blocks are to be stored. mkvmerge separates them by a single \n, but this has the disadvantage that it doesn't allow to distinguish between different comment blocks and a single comment block that just happens to contain a NOTE in the middle after a newline. (Indeed, two comment blocks get merged when doing a mkvmerge->mkvextract roundtrip.) I therefore propose to use two line feed characters to distinguish different comment blocks.
Furthermore, mkvmerge strips comment blocks of their terminating WebVTT line terminator; this is currently against the spec, but I don't see a reason why this shouldn't be allowed. It is similar to not including the terminating line terminator of a WebVTT cue block.
The text was updated successfully, but these errors were encountered:
The WebVTT codec mapping currently has this to say about WebVTT comments:
"The third and all following lines contain all WebVTT Comment Blocks that precede the current WebVTT Cue Block. These may be absent."
This does not say how multiple comment blocks are to be stored. mkvmerge separates them by a single \n, but this has the disadvantage that it doesn't allow to distinguish between different comment blocks and a single comment block that just happens to contain a NOTE in the middle after a newline. (Indeed, two comment blocks get merged when doing a mkvmerge->mkvextract roundtrip.) I therefore propose to use two line feed characters to distinguish different comment blocks.
Furthermore, mkvmerge strips comment blocks of their terminating WebVTT line terminator; this is currently against the spec, but I don't see a reason why this shouldn't be allowed. It is similar to not including the terminating line terminator of a WebVTT cue block.
The text was updated successfully, but these errors were encountered: