Use most recent ll-hls part for window start position

[uvjustin]

This PR uses the most recent independent part for the window default start position.

[uvjustin]

Actually from looking at the RFC, whether we start at the segment start also should depend on whether we get have an #EXT-X-START and whether it has the PRECISE field set.
Basically it looks like:
missing EXT-X-START -> start at nearest preceding independent part
EXT-X-START && missing PRECISE -> start at nearest preceding independent part
EXT-X-START && PRECISE==NO -> start at nearest preceding segment
EXT-X-START && PRECISE==YES -> start at the exact time without looking for part/segment

Does this seem correct?

[uvjustin]

I mocked something up according to the above, but since PRECISE will be parsed as a boolean with a default, it is hard to differentiate between the second case and the third or fourth ones. It is easier if we collapse the second case into either the third or the fourth one.
I will push a commit that collapses the second case into the third one (haven't tested it yet).

[uvjustin]

I'll leave this in draft pending comments and #8764 .

[christosts]

Hi. Thanks for the PR. Let's finish-up #8764 first before getting this one.

[uvjustin]

@christosts
Now that #8764 is finished up we can discuss this one.

The existing behavior of getWindowDefaultStartPosition seems to return the start time of the segment that contains the liveEdgeOffsetUs (minStartPositionUs). From section 4.4.2.2 of the RFC, it looks like this matches the intended behavior (case 1) when EXT-X-START is specified and PRECISE is either NO or omitted.
There are two other cases to consider:
(case 2) When PRECISE is YES, it looks like the player should actually just start from liveEdgeOffsetUs (minStartPositionUs).
(case 3) It seems that when EXT-X-START is not specified, the exact start location (segment start, part start, or exact time) is not well specified.
Currently the PR does the below:
(case 1) EXT-X-START && PRECISE==NO (or missing PRECISE) -> start at beginning of segment
(case 2) EXT-X-START && PRECISE==YES -> start at the exact time
(case 3) missing EXT-X-START -> start at nearest preceding independent part

I'm not familiar enough with the rest of Exoplayer to know if there's actually any advantage in starting from an independent part vs a non-independent part. Also, since starting at a part doesn't seem to be specified anywhere, maybe case 3) should be dropped altogether and just handled as is (ie as case 1). Looking forward to hearing your thoughts on the matter. Thanks!

[christosts]

Hmm. How about this:

• when EXT-X-START is specified and PRECISE=YES: the player should start from liveEdgeOffsetUs (minStartPositionUs)
• when EXT-X-START is specified and (PRECISE=NO or PRECISE is omitted): the player starts from nearest preceding segment or independent part. This was Case 1 above and the difference is that it considers the closest preceding independent part too. Am I right to assume that you left the independent part out because the RFC does not explicitly mention parts in the EXT-X-START definition?
• when EXT-X-START is not present, the liveEdgeOffsetUs was picked up from EXT-X-SERVER-CONTROL (or fallback to 3*TARGETDURATION). This is a minimum, as we clarified in Calculate HLS target live offset from #EXT-START-TIME if available #8764 :). Then, if we jump to the closest preceding segment or independent part, we should still respect minimum constraint.

Aside: I'll need to check the behavior change for non-live since we now parse PRECISE. Looks like we pass EXT-X-START directly at the moment, maybe we need to tune it as well.

[uvjustin]

Hmm. How about this:

• when EXT-X-START is specified and PRECISE=YES: the player should start from liveEdgeOffsetUs (minStartPositionUs)

Sounds good.

• when EXT-X-START is specified and (PRECISE=NO or PRECISE is omitted): the player starts from nearest preceding segment or independent part. This was Case 1 above and the difference is that it considers the closest preceding independent part too. Am I right to assume that you left the independent part out because the RFC does not explicitly mention parts in the EXT-X-START definition?

Yes, I had this interpretation as well, and I still think that it makes the most sense. However I later noticed that the current draft RFC seems to imply that when PRECISE=NO, the player should start from the beginning of the segment:

PRECISE

  The value is an enumerated-string; valid strings are YES and NO.
  If the value is YES, clients SHOULD start playback at the Media
  Segment containing the TIME-OFFSET, but SHOULD NOT render media
  samples in that segment whose presentation times are prior to the
  TIME-OFFSET.  **If the value is NO, clients SHOULD attempt to render
  every media sample in that segment.**  This attribute is OPTIONAL.
  If it is missing, its value should be treated as NO.

• when EXT-X-START is not present, the liveEdgeOffsetUs was picked up from EXT-X-SERVER-CONTROL (or fallback to 3*TARGETDURATION). This is a minimum, as we clarified in Calculate HLS target live offset from #EXT-START-TIME if available #8764 :). Then, if we jump to the closest preceding segment or independent part, we should still respect minimum constraint.

This makes sense, and we can add a check to enforce good behavior, but wouldn't the constraint only be violated if the media playlist provided an invalid EXT-X-START/PART-HOLD-BACK combination?

[christosts]

@uvjustin we reshaped the code a bit and added some unit tests. It worked fine with our testing LL-HLS streams, would you be able to test too?

[uvjustin]

@christosts Thanks - I will give it a try and report back.
Edit:
It doesn't seem to be working for me. The start time seems to be getting set correctly but the media buffers for the duration of several segments before starting. I will have to dig into this a bit - some of this may be from my server implementation. However, this behavior did not happen with the previous version of Exoplayer + the PR.
From a quick profiling session, HlsSampleStreamWrapper seems to be requesting segments prior to the requested start location (e.g. if I'm starting from the 3rd segment, it's still requesting the 1st and the 2nd segments before requesting the 3rd segment). Also, for some reason the 1st and 2nd segments are loading really slowly - at approximately the playing time (a n second segment is taking n seconds to load) - even though they are already available as full segments when they are requested.
Edit 2:
Seems to be working fine. Not sure what happened above.
Edit 3:
There is still some odd behavior - I will update when I track it down.
Edit 4:
Works well on my end. Turns out the loading behavior (loading segments prior to the start position even though they are unused) exposed a bug on my server implementation. Thanks for this.