HLS read codec type from first segment

[sergioavazquez]

Have you read the FAQ and checked for duplicate open issues?:
Yes
What version of Shaka Player are you using?:
2.3.7
Can you reproduce the issue with our latest release version?:
Yes
Can you reproduce the issue with the latest code from master?:
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, I get the same errors. In my custom app stream won't start and it does on shaka's hosted demo but it still throws the same errors and it takes a very long time to initiate.
What browser and OS are you using?:
Chrome 66, Ubuntu 16.04.
What are the manifest and license server URIs?:
sent to: [email protected] email subject is the same as the issue's title.
(NOTE: a copy of the manifest text or an attached manifest will not be enough to reproduce your issue, and we will ask you to send a URI instead)

What did you do?
Start reproduction of an HLS stream.
What did you expect to happen?
Stream being reproduced without errors.
What actually happened?
I get the following error:

Failed to load https://my.url.tv/folder/segment_540p_452131.ts: Request header field Range is not allowed by Access-Control-Allow-Headers in preflight response.
In shaka's hosted app, stream reproduction eventually starts but it doesn't on mine. After a while I sometimes get a 9009 error in my app which does not appear in the list of errors.

I tried reproducing Shaka's demo HLS stream in my application and it worked, no problem. The only difference I spotted between streams is that mine has .ts chunks instead of .mp4. Can that be causing the issue?

Keep in mind the stream causing this issue is the same stream I'm using with other web players without problems. I've also tested it with VLC successfully.

Regards,

[chrisfillmore]

Error 9009 was retired in v2.3.4, so it would appear you are using Shaka v2.3.3 or older.

This error:

Failed to load https://my.url.tv/folder/segment_540p_452131.ts: Request header field Range is not allowed by Access-Control-Allow-Headers in preflight response.

is a CORS error. The server does not support cross-origin requests which have the Range header. You can read more about CORS here:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

In order for you to use Range, the server will need to return an Access-Control-Allow-Headers header, in the preflight response, which includes Range. Can you share the full request/response cycle?

[sergioavazquez]

You're right, there was a miss-communication in the team, headers were missing. 9009 is an error we got a few weeks ago. Right now we're getting a 4032 error, after fixing headers. Can that be due to the .ts chunks? Sorry for the inconvenience...

[chrisfillmore]

I believe you are able to play in Shaka sample app because it includes mux.js to transmux your TS segments to fmp4. To enable this in your custom app, you will need to include window.muxjs.

[ismena]

@chrisfillmore Thanks for replying! LOL, If you're ever looking for a job, give a word, I'll personally refer you ;)

@sergioavazquez
Let us know how it goes after including mux.js!

[sergioavazquez]

Good catch! I installed the latest version of mux.js and made it available by adding it to window.muxjs. I now get a 6001 error. I'm forcing https on my localhost, widevine encrypted contents are working so that shouldn't be the problem. Thoughts?

[michellezhuogg]

@sergioavazquez
6001 Error is REQUESTED_KEY_SYSTEM_CONFIG_UNAVAILABLE, and can be cause by these reasons mentioned in the document.
Is there any specific reason that you're forcing https on your localhost? Plain http should work for localhost.

[kchandran1029]

hey guys , I am running into the same issue and I included muxjs ( locally built ) and I ensured window.muxjs is defined . is there anything else I need to do with muxjs ?

Unfortunately I am also getting 6001 , but I am using an encrypted content ( http://b028.wpc.azureedge.net/80B028/Samples/a38e6323-95e9-4f1f-9b38-75eba91704e4/5f2ce531-d508-49fb-8152-647eba422aec.ism/Manifest(format=m3u8-aapl))

Any advice is highly appreciated.

[kchandran1029]

Ok , quick update , I removed the DRM config, since it's un-encrypted and no more 6001 error. So Muxjs played it's role, but again , it's not playing back the content , stuck at the first frame and buffering.

Any thoughts ?

[chrisfillmore]

@sergioavazquez you mentioned that your Widevine content is working. What DRM are you using for the content which won't play? If you are attempting to play Fairplay-protected content, this won't work in Chrome (or in Safari... see #382).

[sergioavazquez]

@chrisfillmore I'm working on an app that supports DASH - Widevine. I'm sure the 6001 is coming from the fact that the asset has Widevine set up as its DRM by default, just like @kchandran1029 mentioned. For un-encrypted Dash assets, that's not a problem but I'm guessing since HLS and DASH are not supported that might be a problem. I'm going to remove it and let you know how it goes!

[kchandran1029]

@sergioavazquez : hey please let me know if you are able to get it play back , for me it's playing intermittently , but on demo app it works fine after an initial hickup , I get the below log on demo app --
Unable to fetch a partial HLS segment! Falling back to a full segment request, which is expensive! Your server should support Range requests and CORS preflights.

--

Then it just play back fine. In our custom app , it doesn't play . I am wondering if I need anything more than just muxjs . Do I need to override any default config , please help. Thanks

[sergioavazquez]

@kchandran1029 removing DRM config from the asset worked for me!! I use to get that same log and it turned out it was due to lack of headers in source's server. For testing purposes, try adding the following header to the server Access-Control-Allow-Origin: *
Thanks!!!

[kchandran1029]

@sergioavazquez : Thanks for the response , but is it playing fine for you ? Can you please test with the manifest I posted above ? I can't get it to play back.

[sergioavazquez]

@kchandran1029 : I got my HLS stream to work without problems. I tested your stream with my app and I experience the same behavior you describe, I can't get it to play, same error.

[kchandran1029]

It's weird , the demo app is able to playback the same after some initial hick ups , wondering what are we missing from demo app.

@sergioavazquez Would you be able to share the content or some test contents you have , may be with some decent timeshiftbuffer ? Thanks

[sergioavazquez]

@kchandran1029 unfortunately I can't share streams because they're not free, company policy, sorry.
But I just emailed another HLS stream that is not working on Shaka, not even in the demo app, but it does work on other players.

[sergioavazquez]

I've been testing HLS streams from diverse sources and most of them have problems.

Here are some of the streams I've been testing. Keep in mind all these streams work both with MediaElement and VLC.

• https://kissfm-cires21-video.secure.footprint.net/hittv/master.m3u8 Throws 405 on OPTIONS request. Your server should support Range requests and CORS preflights. Works on and off, refresh and reload to verify. It takes a very long time to start when it works.

• https://lsd2-latam.secure2.footprint.net/hls-live/streamroot_lsd2latam-tectv/_definst_/live/stream3.m3u8
  Returns error 4022 on both demo and custom app. Never works.

• https://rbtvdiglinear-i.akamaihd.net/hls/live/241719/ATfallback/master_1660.m3u8
  Returns error 4022 on both demo and custom app. Never works.

• https://lsd2-latam.secure2.footprint.net/hls-live/streamroot_lsd2latam-lared/_definst_/live.m3u8
  Never works. Response for preflight has invalid HTTP status code 405. Warns about lack of Range support: Your server should support Range requests and CORS preflights
  Error 3016 and 3014. All in demo App. (RADIO stream)

• https://rmtv24hweblive-lh.akamaihd.net/i/rmtv24hwebes_1@300661/master.m3u8
  Sometimes works, sometimes doesn't. Huge load times. Your server should support Range requests and CORS preflights. Throws 405 on OPTIONS request.

These are just a few, but there are 2 recurrent error patterns despite the fact that streams were gathered from different sources:
1 - OPTIONS and Range requests issues.
2 - 4022.

Thoughts?

[chrisfillmore]

These two playlists:
https://lsd2-latam.secure2.footprint.net/hls-live/streamroot_lsd2latam-tectv/_definst_/live/stream3.m3u8
https://rbtvdiglinear-i.akamaihd.net/hls/live/241719/ATfallback/master_1660.m3u8
...are variant playlists and cannot be provided to Shaka directly. This is why you are getting error 4022. You need to provide a master playlist. You can take a look at some of the playlist examples from the HLS spec to see the difference:
https://tools.ietf.org/html/draft-pantos-hls-rfc8216bis-00#section-8.4

Essentially, a master playlist is a playlist which lists other playlists, which are valled variant (or media) playlists. Those variant playlists list the actual video segments.

When playing HLS, Shaka will make a partial segment request using a Range header. I'm not familiar with the specific behaviour and reasons why (hopefully someone can comment). However, in order for this request to succeed, the server will need to allow the Range header in cross-origin requests, as I described before. This means the OPTIONS response must have:

Access-Control-Allow-Headers: Range, ...(other required headers here)...

Does that make sense?

[sergioavazquez]

Yes. I Understand why the 4022 occurs and I expected an explanation along those lines for the Range warning. However, I'm working on a video application were the ability to reproduce contents from all over the web is a key feature, and it looks like there are many streams that don't follow those guidelines.
I was hoping you would consider adding support for these. I don't always have full control over streams and this restricts the amount of contents that can be visualized by the player, contents that are actually playable.
Is this something you would consider?
Thanks!

[kchandran1029]

Hey Guys ,

Please let me know if I have to open this as new separate issue, I will be happy to do that , but I feel Shaka is having a hard time to play most of the HLS stream on Safari browser. Interestingly it works in Chrome. I have tested with couple of other players out there and they can play back the stream well.

Also, I assume this has a master play list

https://akamai-axtest.akamaized.net/routes/lapd-v1-acceptance/www_c4/Manifest.m3u8

Is there anything I am missing out or do we have a known issue with HLS playback on Safari ( Un-ecrypted ) ?

[TheModMaker]

When playing HLS, Shaka will make a partial segment request using a Range header. I'm not familiar with the specific behaviour and reasons why (hopefully someone can comment).

There are two reasons we do Range requests. First, we do it as part of manifest parsing to determine the start time of the first segment (since the HLS manifest doesn't tell us). We fall back to a full segment request, so supporting Range headers isn't required in this case. Second, we do Range headers whenever an HLS segment includes a byte range. This indicates that the segment is part of a larger file, so we need to send the Range header so we get only that specific data. Even if the byte range specifies the whole file, we have no way of determining that; so if we see a byte range on a segment, we need to set the header.

@sergioavazquez There is usually nothing we can do about the 3014/3016 errors (which are decoder errors) and the Range header errors because these are requirements from the browser. The browser rejects the media or the network request. Some players can play on Safari because they just set src= and the native HLS player doesn't have those limitations.

As for why we don't support the media playlists (error 4022), we need the codec information provided in the master playlist. If we don't have it, we could guess the codec as being multiplexed H264+AAC; but if we are wrong, we won't be able to play the content and will get a 3014/3016 error later. (this is a requirement of the browser)

@kchandran1029 I am able to play that asset fine on Safari. Are you using the hosted demo or a custom app? What errors are you seeing?

[sergioavazquez]

@TheModMaker I understand, but my point is that somehow other HTML players got around it. For example MediaElement and Clappr. I'm not using Safari but Chrome 66 and Ubuntu, so I have no native HLS support.

Here is the official demo of Clappr with one of the links that throws a 4022: Clappr

You can edit the source on the fly and test other streams too. I tested all the streams I mentioned in this issue and they all work perfectly, thus my reasoning that there's a way of making it work. I have no idea how they did it though, could you help?
Thanks!!

[TheModMaker]

We need to know what codec the media is to be able to play the content. If we don't set the correct codec when we initialize MediaSource, we'll get an error from the browser later. That is what happens in the RADIO asset you listed above; we assumed it was h264+aac and it was just aac. That is also why we need the master playlist, which usually has codec info in it (but some manifests don't).

On the other hand, we already make a segment request to determine the start time. So it may be somewhat easy to pull the codec from the container also. That would also allow us to play media playlists since (I think) codec info is the only thing that is required from the master playlist.

I'll rename the issue and mark this an enhancement. Tentatively scheduled for v2.5, but it may get pushed.

@kchandran1029 If you are seeing errors, please post a new issue.

[sergioavazquez]

Awesome! Let me know if there's something I can do to help! Thanks!!

[chahatmiddha561]

@TheModMaker - Hi, as you mentioned it is required to set range header for the first segment but can we customise using shaka configuration to not send range header in any case?
Or any flag we can set which will stop sending Headers with range for the first segment ?
#1431 (comment)

[TheModMaker]

@chahatmiddha561 There is no option to disable this feature. When we make a partial request for the first segment, we'll send the Range header to avoid downloading the whole segment; but if this fails, we will download the whole segment instead. So not supporting Range requests shouldn't inhibit playback (in this case).

[joeyparrish]

@sergioavazquez, while we had said we would consider this enhancement before, that was based on the fact that we already fetch segment headers to get timestamp info. This is something we're moving away from now to reduce startup latency. Therefore, I'm going to close this and mark it as "will not implement". We apologize for any inconvenience this may cause.

If you can, we would recommend you update your playlists to include MIME type and codec information.