You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note, this happens for the ll-hls demo stream, but I also have a non-public live HLS stream that does not use ll-hls which shows the same issue. The playlists for this private stream look like:
The stream has correct Access-Control-Allow-Origin headers (CORS)
There are no network errors such as 404s in the browser console when trying to play the stream
Steps to reproduce
Load the video stream and open the network tab
Look for the fragment initialization segment url in the EXT-X-MAP
Search filter the network tab to only show requests for this resource
Expected behaviour
The expected behaviour is that the initialization segment would only be requested if a new initialization segment is found. Any references to previous initialization segments should use previously downloaded segments instead of re-downloading the same initialization segment.
What actually happened?
The same initialization segment is requested over and over again. You can see this also by looking for the log Loading fragment initSegment in the console output.
I believe the cause of the repeated requests relates to the changes to support multiple EXT-X-MAP tags ( #3859 ). Specifically the issue seems to be how LevelDetails are merged inside the level-helper. The chain of updating fragments to maintain references to the same initSegment Fragment works for Fragments that overlap between the old and new details, but for fragments which only appear in the new LevelDetails the initSegment is not updated. If requests for the non-overlapping fragments are made before another level merge occurs, the stream-controller will re-request the same initSegment.
A unit test I've used to test the functionality is:
it('sets initSegments on non-overlapping segments',function(){constoldPlaylistString=`#EXTM3U#EXT-X-VERSION:7#EXT-X-TARGETDURATION:1#EXT-X-MEDIA-SEQUENCE:27081#EXT-X-MAP:URI="init1638284459.mp4"#EXTINF:1.000000#EXT-X-PROGRAM-DATE-TIME:2021-11-30T22:32:19Zcamera27078.m4s#EXTINF:1.000000#EXT-X-PROGRAM-DATE-TIME:2021-11-30T22:32:20Zcamera27079.m4s#EXTINF:1.000000#EXT-X-PROGRAM-DATE-TIME:2021-11-30T22:32:21Zcamera27080.m4s`;constnewPlaylistString=`#EXTM3U#EXT-X-VERSION:7#EXT-X-TARGETDURATION:1#EXT-X-MEDIA-SEQUENCE:27082#EXT-X-MAP:URI="init1638284459.mp4"#EXTINF:1.000000#EXT-X-PROGRAM-DATE-TIME:2021-11-30T22:32:20Zcamera27079.m4s#EXTINF:1.000000#EXT-X-PROGRAM-DATE-TIME:2021-11-30T22:32:21Zcamera27080.m4s#EXTINF:1.000000#EXT-X-PROGRAM-DATE-TIME:2021-11-30T22:32:22Zcamera27081.m4s`;constoldPlaylist=M3U8Parser.parseLevelPlaylist(oldPlaylistString,'http://test.com/livevideo.m3u8',0,PlaylistLevelType.MAIN,0);constnewPlaylist=M3U8Parser.parseLevelPlaylist(newPlaylistString,'http://test.com/livevideo.m3u8',0,PlaylistLevelType.MAIN,0);mergeDetails(oldPlaylist,newPlaylist);constoldInitSegment=oldPlaylist.fragments[0].initSegment;constactual=newPlaylist.fragments.map((f)=>f.initSegment);expect(actual[0]).to.equal(oldInitSegment);expect(actual[1]).to.equal(oldInitSegment);expect(actual[2]).to.equal(oldInitSegment);});
Fixesvideo-dev#4450
For live video, merging playlists did not updated non-overlapping
fragments. Now, the level-helper will update any non-overlapping
fragmentHint or fragments to reference existing initSegment
fragments.
Now that we support AES-128, some older AES-128 code paths in the HLS
parser have become obsolete. This cleans up those unneeded code paths
and adds a test to ensure that the correct failure handling is used
when AES-128 cannot be supported by the platform.
What version of Hls.js are you using?
v1.1.1
What browser (including version) are you using?
Chrome Version 96.0.4664.55 (Official Build) (x86_64)
What OS (including version) are you using?
macOS Monterey version 12.0.1
Test stream
https://hls-js.netlify.app/demo/?src=https%3A%2F%2Fstream.mux.com%2Fv69RSHhFelSm4701snP22dYz2jICy4E4FUyk02rW4gxRM.m3u8&demoConfig=eyJlbmFibGVTdHJlYW1pbmciOnRydWUsImF1dG9SZWNvdmVyRXJyb3IiOnRydWUsInN0b3BPblN0YWxsIjpmYWxzZSwiZHVtcGZNUDQiOmZhbHNlLCJsZXZlbENhcHBpbmciOi0xLCJsaW1pdE1ldHJpY3MiOi0xfQ==
Configuration
Additional player setup steps
Note, this happens for the ll-hls demo stream, but I also have a non-public live HLS stream that does not use ll-hls which shows the same issue. The playlists for this private stream look like:
Checklist
Steps to reproduce
Expected behaviour
The expected behaviour is that the initialization segment would only be requested if a new initialization segment is found. Any references to previous initialization segments should use previously downloaded segments instead of re-downloading the same initialization segment.
What actually happened?
The same initialization segment is requested over and over again. You can see this also by looking for the log
Loading fragment initSegment
in the console output.I believe the cause of the repeated requests relates to the changes to support multiple EXT-X-MAP tags ( #3859 ). Specifically the issue seems to be how LevelDetails are merged inside the
level-helper
. The chain of updating fragments to maintain references to the sameinitSegment
Fragment works for Fragments that overlap between the old and new details, but for fragments which only appear in the new LevelDetails the initSegment is not updated. If requests for the non-overlapping fragments are made before another level merge occurs, the stream-controller will re-request the same initSegment.A unit test I've used to test the functionality is:
Console output
Chrome media internals output
No response
The text was updated successfully, but these errors were encountered: