Add support for upstream discard to HLS

[stevemayhew]

Use case description

It is undesirable to leave poor quality buffered video samples in place when sufficient higher quality samples exist to replace them.

Two cases this can happen:

1. Adaptation in live playlists can leave substantial low quality data buffered, particularly in the channel change case where low bit rate initial selection facilitates rapid channel change.
2. When switching from trick-play (low frame rate) tracks to regular frame rate.

Proposed solution

Implement the existing SequenceableLoader#reevaluateBuffer() method in library-hls.

The work on this is in a pending pull request #6321

Alternatives considered

Using a separate SampleStreamWrapper and TrackGroup for the trick-play tracks. The more elegant solution of including these tracks with the balance of the adaptation set necessitates this.

[tonihei]

Thanks for filing the tracking issue. Can you let us know when #6321 is ready for review?

[stevemayhew]

Will do, thank you for the input... Saving the first sample index in HlsMediaChunk definitely looked like the simple road. Agreed HLS is much nastier with both muxed and demuxed tracks

…

On Tue, Aug 20, 2019 at 1:29 AM tonihei ***@***.***> wrote: Thanks for filing the tracking issue. Can you let us know when #6321 <#6321> is ready for review? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6322?email_source=notifications&email_token=AADBF6G6N5XKEVSLTDSWJZ3QFOTQBA5CNFSM4INJRXI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4VQAPA#issuecomment-522911804>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADBF6F66BCA7RIFDV26DHLQFOTQBANCNFSM4INJRXIQ> .

[ojw28]

If I remember correctly, it's also nastier because there's no guarantee that segments are aligned across variants, or (in the case of TS) that they start with a keyframe.

[stevemayhew]

Probably best to restrict this to playlists that indicate EXT-X-INDEPENDENT-SEGMENTS then.

[tonihei]

This is now supported with PR #7244.