32 is adding support for "updates" in Event style variant playlists. Look in that issue for more details on why this is a useful feature.
20 is fixing a bug where, if the caller deletes a HLSParser in the middle of a parse, the callback for a finish parse never happens.
Change Notes
Added a facility in the C HLSRapidParser level of mamba to be able to exit early out of parsing HLS if the client of the parser requests. This is only done in response to a new "Location" style tag. This is done because the strategy is to look for the last "Location" URL from the old playlist in the new playlist, as that tag should be unique.
Add a couple of update(eventVariantPlaylist:...) methods in HLSParser to support updating event variant playlists (one method is synchronous and one is asynchronous). These new methods will do sanity checks to see if it's possible/allowed to do an "update" rather than a parse from scratch.
HLSParser can be configured with a UpdateEventPlaylistParams struct (there's one provided by default with default values). This can be used to change (1) the minimum size required for a update (it's not really a win to update small playlists and in fact can be slower) (2) the maximum time between updates (i.e. if we have a copy of a variant from 10 minutes ago, there are so many new fragments between now and then that it's likely to be faster to just parse from scratch). This is here mostly to configure for unit tests, but users can use it to tune results if they are unhappy with defaults.
To fix #20, the HLSParseWorker how keeps a strong ref to the parent HLSParser while the parse is happening. The strong ref is dropped when the parse is complete to avoid retain cycles.
Pre-submission Checklist
[x] I ran the unit tests locally before checking in.
[x] I made sure there were no compiler warnings before checking in.
[x] I have written useful documentation for all public code.
[x] I have written unit tests for this new feature.
Description
This PR addresses issues #32 and #20.
32 is adding support for "updates" in Event style variant playlists. Look in that issue for more details on why this is a useful feature.
20 is fixing a bug where, if the caller deletes a
HLSParserin the middle of a parse, the callback for a finish parse never happens.Change Notes
HLSRapidParserlevel of mamba to be able to exit early out of parsing HLS if the client of the parser requests. This is only done in response to a new "Location" style tag. This is done because the strategy is to look for the last "Location" URL from the old playlist in the new playlist, as that tag should be unique.update(eventVariantPlaylist:...)methods inHLSParserto support updating event variant playlists (one method is synchronous and one is asynchronous). These new methods will do sanity checks to see if it's possible/allowed to do an "update" rather than a parse from scratch.HLSParsercan be configured with aUpdateEventPlaylistParamsstruct (there's one provided by default with default values). This can be used to change (1) the minimum size required for a update (it's not really a win to update small playlists and in fact can be slower) (2) the maximum time between updates (i.e. if we have a copy of a variant from 10 minutes ago, there are so many new fragments between now and then that it's likely to be faster to just parse from scratch). This is here mostly to configure for unit tests, but users can use it to tune results if they are unhappy with defaults.HLSParseWorkerhow keeps a strong ref to the parentHLSParserwhile the parse is happening. The strong ref is dropped when the parse is complete to avoid retain cycles.Pre-submission Checklist