cast: MPEG2-TS media playlists fail load due to mux.js dependency check

[JulianDomingo]

Have you read the FAQ and checked for duplicate open issues?
Yes.

What version of Shaka Player are you using?
v4.3.3.

Can you reproduce the issue with our latest release version?
Yes.

Can you reproduce the issue with the latest code from main?
Yes.

Are you using the demo app or your own custom app?
Custom app.

If custom app, can you reproduce the issue using our demo app?
Yes.

What browser and OS are you using?
Chrome, 1.52.

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
Google Nest Hub, 1.52.

What are the manifest and license server URIs?

TS media playlist: https://storage.googleapis.com/gtv-videos-bucket/hls/big_buck_bunny.m3u8
TS primary playlist (no issues): https://test-streams.mux.dev/x36xhzz/x36xhzz.m3u8

What configuration are you using? What is the output of player.getConfiguration()?

Default configuration.

What did you do?

1. Load the TS media playlist.

What did you expect to happen?

1. Loads successfully and starts playing the ocntent.

What actually happened?

1. Loads unsuccessfully because it fails the dependency check for MuxJs.

Reason:
When any manifest is loaded, Shaka eventually calls MimeUtils#getFullOrConvertedType when it initializes the DRMEngine for the purposes of querying for media keys:

shaka-player/lib/media/drm_engine.js

Lines 369 to 372 in 4e75ec6

	// We should get the decodingInfo results for the variants after we filling
	// in the drm infos, and before queryMediaKeys_().
	await shaka.util.StreamUtils.getDecodingInfosForVariants(variants,
	this.usePersistentLicenses_, this.srcEquals_);

=>

shaka-player/lib/util/stream_utils.js

Line 531 in 4e75ec6

const decodingConfigs = shaka.util.StreamUtils.getDecodingConfigs_(

=>

shaka-player/lib/util/stream_utils.js

Line 573 in 4e75ec6

const audioFullType = shaka.util.MimeUtils.getFullOrConvertedType(

During this time, at least for HLS content, Shaka has yet to lazy-load the streams and therefore relies on a "best guess" to determine the mimeType for each streamInfo object, and is updated later:

shaka-player/lib/hls/hls_parser.js

Lines 2289 to 2290 in a22bdc5

	const mimeType = this.guessMimeTypeBeforeLoading_(type, codecs) ||
	this.guessMimeTypeFallback_(type);

For primary playlists, Shaka doesn't have enough information to correctly determine the stream uses MPEG2-TS (see above two methods, guessMimeTypeBeforeLoading_() and guessMimeTypeFallback_()). As a result, Shaka sets the mimeType to be mp4-based when it's not text streams. This also means the MimeUtils#getFullOrConvertedType are only supplied mp4 mimeTypes in this scenario. Lastly, this means TransmuxerEngine#isSupported() returns false, because Shaka Player doesn't initialize a default transmuxer plugin for mp4:

shaka-player/lib/util/mime_utils.js

Line 50 in a22bdc5

if (TransmuxerEngine.isSupported(fullMimeType, contentType)) {

For media playlists, Shaka does have enough information to determine it's MPEG2-TS, because it has access to the file extension of the media segments. Therefore, when MimeUtils#getFullOrConvertedType is called, it's passed video/mp2t as the mimeType => TransmuxeEngine#isSupported() returns true because a video/mp2t fallback plugin is registered by default => Shaka tries to instantiate the video/mp2t MuxJsTransmuxer: https://github.com/shaka-project/shaka-player/blob/main/lib/transmuxer/muxjs_transmuxer.js#L33-L38

However, Cast receiver applications have prevented loading of mux.js library since Shaka v3.1.0+, as Cast only used mux.js for purposes of CEA-608/708 captions (but is now natively supported in Shaka Player). As a result, the lines above throw a TypeError which ultimately fails the load of MPEG2-TS media playlists.

[avelad]

@JulianDomingo Can we close the issue with the merged PRs? Or is something more needed?