Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Allow configuring asset-list prefetch timing per HLS interstitial

Aperta
  • Qualcosa non va?
#3,494 2 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 4 giorni

@marcbaechinger ci sta già lavorando.

Dal 28/10/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

enhancement
Use case description

We would like to control when HlsInterstitialsAdsLoader resolves the X-ASSET-LIST for each interstitial, allowing resolution both earlier and later than the current default.

In our implementation, asset-list resolution triggers an ad-decision request. Its timing affects both the time available to cache the returned ads before playback and which assets we request. (We can handle media caching ourselves through existing APIs.)

For live streams, we check whether the content position at which playback should resume after the break is already available:

resumePosition = breakStartPosition + plannedBreakDuration

If the known live edge has not reached that position, we request an additional filler audio asset. Resolving later may avoid requesting that asset while still leaving enough time to prepare the ads before playback reaches the break.

Whether this is possible depends on the listener’s distance behind the live edge, the break duration, and the resolution lead time.

Conversely, other breaks may benefit from earlier resolution to accommodate ad-service latency and allow more time for caching.

Currently, maybeExecuteOrSetNextAssetListResolutionMessage() in HlsInterstitialsAdsLoader.java:1432 calculates resolution timing using a fixed heuristic:

resolutionStartTimeUs =
    max(
        currentPeriodPositionUs,
        resolutionStartTimeUs
            - (TARGET_DURATION_MULTIPLIER * nextAssetResolution.targetDurationUs));

TARGET_DURATION_MULTIPLIER is a constant set to 3, so a ten-second playlist target duration causes resolution approximately 30 seconds before the break.

This ties ad-decision timing to segment duration rather than application requirements. Configurable timing would let us balance preparation time against content availability, which can favor either earlier or later resolution. Our manifests provide custom prefetch markers that specify the resolution timing for each break.

The requested capability would concern asset-list resolution timing. Media caching could remain application-managed.

Proposed solution

Would it be possible to expose an API for configuring asset-list resolution timing per interstitial, retaining the existing heuristic when no override is provided?

One possible API would be:

public void setAssetListResolutionLeadTimeMs(
    Object adsId,
    String interstitialId,
    long leadTimeMs);

The lead time would specify how long before the break’s start resolution should become eligible:

// Resolve 60 seconds before this break.
adsLoader.setAssetListResolutionLeadTimeMs(
    adsId,
    "break-123",
    60_000L,
)

// Resolve only 5 seconds before another break.
adsLoader.setAssetListResolutionLeadTimeMs(
    adsId,
    "break-456",
    5_000L,
)

A lead time relative to the break would avoid ambiguity as the live window moves. An application with an explicit prefetch marker could calculate:

val leadTimeMs = breakStartPositionMs - prefetchPositionMs

The configured timing would replace the default for that interstitial, allowing earlier or later resolution while preserving Media3’s handling of seeks and live-window updates. A per-interstitial scheduling callback would also meet our needs.

Alternatives considered
  • A global configurable lead time: Allows earlier or later resolution globally, but cannot express different requirements for individual breaks.
  • Delaying resolution inside a custom DataSource: Could postpone the ad-decision request, but would keep Media3’s load in flight while waiting and could block other asset-list requests.
  • A timing callback: Media3 could ask the application when to resolve each break’s asset list, then schedule the request itself. This would also work for our use case.
Lingua principale
Java
Stelle
3.1k
Fork
998
Merge medio
6g 8h
PR unite (30g)
2

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di androidx/media

Tutte le issue di androidx/media

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.