Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HLS playback treats ISMC1 subtitles as VTT if URLS doesn't have extensions. #4135

Closed
duggaraju opened this issue Apr 18, 2022 · 0 comments · Fixed by #4140
Closed

HLS playback treats ISMC1 subtitles as VTT if URLS doesn't have extensions. #4135

duggaraju opened this issue Apr 18, 2022 · 0 comments · Fixed by #4140
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Milestone

Comments

@duggaraju
Copy link
Contributor

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

What version of Shaka Player are you using?
3.3.2

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?
Both

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

What browser and OS are you using?
Chrome/Edge Windows 11

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

What are the manifest and license server URIs?
https://lldemo-usw22.streaming.media.azure.net/bc26fae2-d0d5-45f7-931e-5de6f8588127/07e87ae7-02af-44ae-a8f2-c2997c397342.ism/manifest(format=m3u8-cmaf).m3u8

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

What did you do?

Just play the URL and see if subtitles work.

What did you expect to happen?
subtitles work as expected.

What actually happened?

The issue lies with this code in hls_parser.js

async createStreamInfoFromMediaTag_(tag) {
goog.asserts.assert(tag.name == 'EXT-X-MEDIA',
'Should only be called on media tags!');
const groupId = tag.getRequiredAttrValue('GROUP-ID');
let codecs = '';
/** @type {string} */
const type = this.getType_(tag);
// Text does not require a codec.
if (type != shaka.util.ManifestParserUtils.ContentType.TEXT && groupId &&
this.groupIdToCodecsMap_.has(groupId)) {
codecs = this.groupIdToCodecsMap_.get(groupId);
}

It explicitly ignores the codec for text streams and then later the code assumes subtiltes to be VTT if codec is not present:

async guessMimeType_(contentType, codecs, playlist, variables) {
const HlsParser = shaka.hls.HlsParser;
const ContentType = shaka.util.ManifestParserUtils.ContentType;
const requestType = shaka.net.NetworkingEngine.RequestType.SEGMENT;

goog.asserts.assert(playlist.segments.length,
    'Playlist should have segments!');
const firstSegmentUri = this.variableSubstitution_(
    playlist.segments[0].absoluteUri, variables);

const parsedUri = new goog.Uri(firstSegmentUri);
const extension = parsedUri.getPath().split('.').pop();
const map = HlsParser.EXTENSION_MAP_BY_CONTENT_TYPE_[contentType];

const mimeType = map[extension];
if (mimeType) {
  return mimeType;
}

if (contentType == ContentType.TEXT) {
  // The extension map didn't work.
  if (!codecs || codecs == 'vtt' || codecs == 'wvtt') {
    // If codecs is 'vtt', it's WebVTT.
    // If there was no codecs string, assume HLS text streams are WebVTT.
    return 'text/vtt';
  } else {
    // Otherwise, assume MP4-embedded text, since text-based formats tend
    // not to have a codecs string at all.
    return 'application/mp4';
  }
}

This is because our URLs do not have an extension and it doesn't seem to do a HEAD request for subtitles so instead guesses the mime type incorrectly.

@duggaraju duggaraju added the type: bug Something isn't working correctly label Apr 18, 2022
@github-actions github-actions bot added this to the v3.3 milestone Apr 18, 2022
@avelad avelad modified the milestones: v3.3, v4.0 May 4, 2022
@github-actions github-actions bot added the status: archived Archived and locked; will not be updated label Jun 19, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 19, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants