[HLSTree] New hls_ignore_endlist, hls_fix_mediasequence, hls_fix_discsequence params to fix faulty live services

[CastagnaIT]

Description

Plutotv its a good example of faulty live service that violates the HLS specifications in different ways (not all specified here)
by providing malformed data on variant child manifests:

EXT-X-DISCONTINUITY-SEQUENCE: has inconsistent number between manifest updates, for example on first downloaded manifest could be of value 2, on the next update become 0 or 1. A decreasing number is not allowed on sane HLS.

EXT-X-MEDIA-SEQUENCE: has inconsistent number between manifest updates, that cause impossibility to keep track of the sequence of segments between updates, i couldn't figure out if there is a logical pattern, because the numbers seem pretty random...

EXT-X-ENDLIST: make a wrong use of EXT-X-ENDLIST tag, sometimes the service send a manifest update without segments, and specifying this tag although the live stream is not ended, thereby forcing the stop of playback

EXT-X-PROGRAM-DATE-TIME: sometime there is not a precise value, so on first downloaded manifest there is X PTS value, on next manifest update X varies by some seconds, or also they replace the original value with others, this leads to any kind of side effect since the fixes are based on this

To "fix" this bad situation i have add these new parameters to inputstream.adaptive.manifest_config property:

hls_ignore_endlist: allow to ignore EXT-X-ENDLIST, there are two situations

1. At playback start, can be sent the first manifest without segments and with EXT-X-ENDLIST
2. While in playback, can be sent the manifest update without segments and with EXT-X-ENDLIST
   for the case 2, to mitigate buffering problems the time to perform the next manifest update is temporarily halved

hls_fix_mediasequence: allow to try correct a malformed EXT-X-MEDIA-SEQUENCE value, the corrected value is determined by finding the corresponding segment in the updated playlist referring to the PTS value of the segment provided by the EXT-X-PROGRAM-DATE-TIME tag. so to use this paramenter it is strictly required that the manifest provides EXT-X-PROGRAM-DATE-TIME tag

hls_fix_discsequence: allow to try correct a malformed EXT-X-DISCONTINUITY-SEQUENCE value, the corrected value is determined by checking whether a segment falls within an existing period if found use that sequence number to fix EXT-X-DISCONTINUITY-SEQUENCE in order to work EXT-X-PROGRAM-DATE-TIME tag is needed.

However malformed manifest update can lead to any kind of playback oddities, such as segments played multiple times, or periods switched before the end of their playback, due to the impossibility of determining the right sequence number and segment to be played. In the worst case it will cause unexpected problems with Kodi VideoPlayer by freezing the playback either temporarily (a few seconds) or permanently.

Motivation and context

fix #1507

How has this been tested?

#KODIPROP:inputstream.adaptive.manifest_config={"hls_ignore_endlist":true,"hls_fix_mediasequence":true,"hls_fix_discsequence":true}

https://r.mjh.nz/PlutoTV/64b67f0424ade50008a3be17-alt.m3u8

played for more times until to catch ADS discontinuities

Screenshots (if appropriate):

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Clean up (non-breaking change which removes non-working, unmaintained functionality)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that will cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• None of the above (please explain below)

Checklist:

• I have read the Contributing document
• My code follows the Code Guidelines of this project
• My change requires a change to the Wiki documentation
• I have updated the documentation accordingly

[glennguy]

Looks good @CastagnaIT