Set accurate seekMap duration in SubtitleExtractor after parsing

[onseok]

SubtitleExtractor creates its IndexSeekMap with durationUs = C.TIME_UNSET in init(), but never updates it after parsing, even though the exact duration is knowable from the parsed cues' endTimeUs values.

This causes problems for WebVTT files with long-duration cues (e.g. a cue spanning 00:00.000 --> 01:00:00.000).
Since the seekMap reports TIME_UNSET as its duration, consumers may fall back to estimating duration from sample timestamps (startTimeUs), which can be significantly shorter than the actual content end time. This can result in subtitle samples not being loaded after seeking to a position beyond the estimated duration.

This change updates the seekMap's durationUs to the maximum endTimeUs across all parsed cues, following the same pattern used by Mp3Extractor (which calls IndexSeekMap.setDurationUs() and re-emits the seekMap after reading all samples).

Also added tests to verify this behavior. Happy to adjust if anything needs to be changed :)

[icbaker]

This change makes sense - but I'm curious about this part of your explanation:

Since the seekMap reports TIME_UNSET as its duration, consumers may fall back to estimating duration from sample timestamps (startTimeUs), which can be significantly shorter than the actual content end time.

Can you give more details about these consumers? If they are handling the data after it's been transcoded to MimeTypes.APPLICATION_MEDIA3_CUES then there will be a sample representing the 'end of the last cue' (i.e. the sample's start time is the time the cues end), so it would be a correct way to estimate the track duration (and this change wouldn't be required).

[onseok]

Hi, @icbaker. The consumer I had in mind is ProgressiveMediaPeriod.onLoadCompleted(), which falls back to getLargestQueuedTimestampUs() + DEFAULT_LAST_SAMPLE_DURATION_US when the seekMap duration is TIME_UNSET.

I initially had the same thought about end-of-cue samples, but it turns out LegacySubtitleUtil.toCuesWithTiming() skips them. In outputSubtitleEvent(), when the cue list at an event time is empty, it returns early without emitting a sample:

if (cuesForThisStartTime.isEmpty()) {
  // An empty cue list has already been implicitly encoded in the duration
  // of the previous sample.
  return;
}

For example, a single WebVTT cue spanning 00:10.000 --> 05:05.000 results in two event times [10s, 305s] inside WebvttSubtitle. But getCues(305s) returns an empty list because startTime <= 305 < endTime evaluates to false, so the 305s event gets skipped entirely. Only one sample at startTimeUs = 10s is produced, and the actual end time is encoded in its durationUs field instead.

Because of this, getLargestQueuedTimestampUs() returns 10s, and the fallback duration ends up being 10.01s rather than the correct 305s.

The existing tests also confirm this behavior. For instance, SubtitleExtractorTest shows that 3 cues produce 4 samples rather than 6, since end-time-only events are not emitted as separate samples.

[icbaker]

Ah right, yes I'd misremembered how things work - thanks for clarifying.

[icbaker]

I'm going to send this for internal review now. You may see some more commits being added as I make changes in response to review feedback. Please refrain from pushing any more substantive changes as it will complicate the internal review - thanks!