shaka-player
shaka-player copied to clipboard
Missing tracks from HLS manifest (no DRM)
Have you read the FAQ and checked for duplicate open issues?
Yes
If the problem is related to FairPlay, have you read the tutorial?
Not related to FairPlay.
What version of Shaka Player are you using?
4.8.0
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?
Tried both, same issue.
If custom app, can you reproduce the issue using our demo app?
Yes.
What browser and OS are you using?
Chrome on Windows 11.
For embedded devices (smart TVs, etc.), what model and firmware version are you using?
I didn't tried on embedded device. What are the manifest and license server URIs?
I'm using an HLS video, no DRM/license needed: <geo blocked!>
I think it only works in Italy though (geo blocked otherwise).
What configuration are you using? What is the output of player.getConfiguration()
?
We can refer to the demo player using the m3u8 linked above: <geo blocked!>
What did you do?
Just start the video.
What did you expect to happen?
In the manifest, there are 3 bandwidths for 1080p: 4231000, 5185000 and 7517000.
I expect to be able to use the track with the higher bandwidth.
What actually happened?
With Shaka player, only the first one is available.
I tried various players, online and offline, and I see that some players can use the higher bandwidth. Not sure if I can say names, but JWPlayer, from the demo page, shows the 3 1080p resolutions and it allows to select one of those based on the bandwidth.
If you can't open the m3u8, these are the lines for 1080p:
#EXT-X-STREAM-INF:BANDWIDTH=4655000,AVERAGE-BANDWIDTH=4231000,CODECS="mp4a.40.5,avc1.64002A",RESOLUTION=1920x1080,FRAME-RATE=50,VIDEO-RANGE=SDR,AUDIO="audio-aach-96",CLOSED-CAPTIONS=NONE
c5-clr-video=3899968.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=5704000,AVERAGE-BANDWIDTH=5185000,CODECS="mp4a.40.5,avc1.64002A",RESOLUTION=1920x1080,FRAME-RATE=50,VIDEO-RANGE=SDR,AUDIO="audio-aach-96",CLOSED-CAPTIONS=NONE
c5-clr-video=4800000.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=8269000,AVERAGE-BANDWIDTH=7517000,CODECS="mp4a.40.5,avc1.64002A",RESOLUTION=1920x1080,FRAME-RATE=50,VIDEO-RANGE=SDR,AUDIO="audio-aach-96",CLOSED-CAPTIONS=NONE
c5-clr-video=7000000.m3u8
The shaka-player demo reports only the resolution, but using the Chrome developer options I can see that the loaded file is indeed 3899968.m3u8.
I have more info, the same channel is available using DASH: <geo blocked!>
This has the same info (3 bandwidths for 1080p). In this case, however, I can see all the track with, for example 'player.getVariantTracks();'. The demo player also starts with the higher track, 'id="video=7000000".
However, when the user select 1080p from the UI view, the track is downgraded to 'id="video=3899968"'.
When the track id="video=7000000" if forced from code (e.g. player.selectVariantTrack(track, true)) the UI reports that 'automatic resolution' is set.
As I said, this is the case with DASH: with HSL, I didn't found a way to select this track even from javascript.
The content is geoblocked and I don't have a VPN to try in Italy. Please unblock Spain so I can try. Thanks!
The content is geoblocked and I don't have a VPN to try in Italy. Please unblock Spain so I can try. Thanks!
I can't unblock that stream, but I found some examples online that should be visible from Spain. For example: https://dash.akamaized.net/dash264/TestCases/1b/qualcomm/1/MultiRatePatched.mpd
It is not the same case explained earlier in this issue, but it has the same symptoms so I think it is related.
This manifest has the same 1280x720 resolution defined with 3 different bitrates: when loaded with the demo player, there is no option to change it. From the Chrome dev tools, I can see it is loading the first one (lower bitrate) for me but I don't know if this is due to adaptive mechanisms or if it just sees the first one.
Using JWPlayer (the demo website) I can see the 3 tracks:
The shaka.ui.ResolutionSelection
element specifically only shows one video track per resolution. According to a comment, it considers all other tracks of the same resolution as "duplicates".
https://github.com/shaka-project/shaka-player/blob/a2f26351c0d230006c89b1361235fceb183fa734/ui/resolution_selection.js#L109-L125
I'm not sure what the logic behind this decision was, though. I can definitely see the value in showing multiple bandwidths of the same resolution.
Perhaps we can change this, and put the old behavior behind a UI config in case someone actually wanted it.
Thank you for this!
Do you think it makes sense now to also include the bandwidth on the reported string on the UI? https://github.com/shaka-project/shaka-player/pull/6536/commits/e8befe52d9abe60462ef6e3fe37cdf529864505d#diff-db81155ab24ca3eb75017cdb7fde712e6879488499d1a19e12033b5ea410be68R167
I think it is now reported only for 'audio only' tracks (which I didn't tested): https://github.com/shaka-project/shaka-player/pull/6536/commits/e8befe52d9abe60462ef6e3fe37cdf529864505d#diff-db81155ab24ca3eb75017cdb7fde712e6879488499d1a19e12033b5ea410be68R165
but if we now can select multiple tracks with the same resolution, it would make sense to report this video bandwidth value on the UI as well (similar to the screenshot I posted above).
I could of course change this only in my instance.
Yeah, that's something we should also be doing. I'll re-open the issue.