Do not tear down media source between periods

[dsparacio]

You do not need to tear the source buffer when
Period switch continuity is signaled or Codecs Match

More info coming for codec matching tables.

[wilaw]

Re-prioritizing this old feature request and making it the top priority from the DASH IF. Some more background here:

Currently the Media Source and its Source Buffers are torn down and then re-established at period boundaries. This results is a noticeable visual and audio gap between periods. This is done out of conservatism, as the transition between dissimilar codecs has lead to unrecoverable RTEs in the past. Much of this may have been due to fragile SourceBuffer implementations in the browsers, which have since matured.

We would like to re-examine the workflow and implement the following optimizations:

1. If the mime-type and codec string identifiers match exactly across a period boundary, then the relevant Sourcebuffer (audio, video or text) can continue to be used without interruption. There should be no need to append any init segments and the segments can be linearly appended. This use-case covers much of the ad content used today, since HLS has a requirement for codec continuity across ad insertion (discontinuity) markers. Example: switching from mimeType="video/mp4" codecs="avc1.4d401f" to mimeType="video/mp4" codecs="avc1.4d401f" . Test vector: http://dash.akamaized.net/dash264/TestCases/5a/nomor/1.mpd
2. If the mime-type and prefix of the code identifier match, then re-use the existing source buffer. It may be necessary to append the new track's init segment before appending segments. An example would be switching from mimeType="video/mp4" codecs="avc1.4d401f" to mimeType="video/mp4" codecs="avc1.64000d". I could not find an existing multi-period test vector with this condition - you may need to craft one by hand.
3. If the manifest explicitly signals period continuity as defined in ISO/IEC 23009-22 1:2014/Amd.3 then treat it as case[1] above.

[KameshDevarakonda]

I was wondering if this feature is being worked on in the near future?

[aescarcha]

@KameshDevarakonda It's being worked on :)