Support seamless period switch from non DRM periods to DRM periods

[minhui-foxtel]

Is your feature request related to a problem? Please describe.

I noticed that seamless period switch from non DRM periods to DRM periods was disabled due to buffer errors that is mentioned in the original PR #3413.

Reinitialize source buffers when switching from non DRM periods to DRM periods for the first time. Otherwise we encounter buffer errors.

However, seamless period switch is still possible in this case from my recent testing. I'm not sure that something changed or not in the past two years.
Maybe just because we implemented a ProtectionController by ourselves, we uses MediaPlayer.attachProtectionController.

Describe the solution you'd like

dash.js/src/streaming/controllers/StreamController.js

Lines 620 to 629 in a1cc5b2

	function _canSourceBuffersBeReused(nextStream, previousStream) {
	try {
	// Seamless period switch allowed only if:
	// - none of the periods uses contentProtection.
	// - AND changeType method implemented by browser or periods use the same codec.
	return (settings.get().streaming.buffer.reuseExistingSourceBuffers && (previousStream.isProtectionCompatible(nextStream) || firstLicenseIsFetched) && (supportsChangeType || previousStream.isMediaCodecCompatible(nextStream, previousStream)));
	} catch (e) {
	return false;
	}
	}

Is it possible/proper to add a new setting to bypass previousStream.isProtectionCompatible(nextStream)?

I did see that there was still a playback issue when replace previousStream.isProtectionCompatible(nextStream) to true in DASH-IF sample, but not sure if it's just buffer errors that mentioned before.

Additional context

We're using dash.js@4.3.0, I'm sure no changes about this in latest dash.js.

[dsilhavy]

I still see this problem in Chrome Version 111.0.5563.64 on MacOSx.

A MEDIA_ERR_DECODE occured: Resetting the MediaSource

We need to reset the MSE for the first transition between non encrypted to encrypted content. One possible workaround would be to append the encrypted init segment of an upcoming encrypted period before starting the playback of the non-encrypted period. For now, I don't think a settings flag to disable isProtectionCompatible makes much sense.

Which platform are you testing on?

[minhui-foxtel]

I mainly checked this on Chrome based platform, from my Mac Chrome 110.0.5481.177 to old version of Chromes from TV, e.g. Chrome/88.0.4324.182 from a Hisense TV.
Indeed I can still see this problem in some devices, but it works well in most of devices I tested.
I have no confidence to talk too much EME/DRM stuff, just FYI 😄

[bwallberg]

This does work in shaka so it should at the very least be possible.

[dsilhavy]

@bwallberg Do you know how they implemented it? Are they appending an encrypted init segment before playback of mixed content (DRM and non DRM)?

[bwallberg]

@dsilhavy unfortunately not. Not yet anyway.

[dsilhavy]

Related issue #4396