Bug 147252

This is my first WebKit bug and (hopefully) future patch so pardon any mistakes in the contribution process! There are two problems that I've seen in the SourceBuffer implementation when it is in sequence mode: 1. In the coded frame processing algorithm, step 1.3, the condition should be checking if the source buffer's mode is "sequence" and if the group start timestamp is valid. The condition currently looks like this: if (m_mode == sequenceKeyword()) 2. According to the specification, "sequence" mode indicates that "[m]edia segments will be treated as adjacent in time independent of the timestamps in the media segment" [1]. In the current implementation of the coded frame processing algorithm, the timestamp offset (when it is non-zero) is being added to each sample's presentation timestamp and decode timestamp, regardless of the append mode. For the audio MIME types "audio/mpeg" and "audio/aac", the specification says that the generate timestamps flag should be set [2], and therefore the mode will be "sequence". I've found that in some cases (such as in the URL provided in this report), the samples of the audio already have the correct presentation timestamps. Consequently, when the generated timestamp offsets are being added to each sample, the effect is that each sample's presentation timestamp is doubled and the audio plays incorrectly, and sometimes not at all. For "sequence" buffers, it seems that the samples' timestamps should be *set to* the generated timestamps, not offset by them. I believe that falls in line more accurately with the specification. I have a patch to address these that I will attach shortly. [1]: https://w3c.github.io/media-source/#idl-def-AppendMode.sequence [2]: https://w3c.github.io/media-source/byte-stream-format-registry.html