Skip to content

feat(youtube): support live streams through SABR#87

Open
Priveetee wants to merge 5 commits into
InfinityLoop1308:mainfrom
Priveetee:feat/youtube-live-sabr
Open

feat(youtube): support live streams through SABR#87
Priveetee wants to merge 5 commits into
InfinityLoop1308:mainfrom
Priveetee:feat/youtube-live-sabr

Conversation

@Priveetee

Copy link
Copy Markdown
Contributor

Depends on #86

Part of TypeType-Video/TypeType#145

Summary

While working on live SABR support in TypeType, I found that PipePipeExtractor already decodes most of the required live protocol data, but live streams are still excluded from the normal SABR stream and session path.

YouTube live responses also behave differently from VOD responses: the live window evolves through LIVE_METADATA, segment numbers are absolute within the broadcast timeline, and MP4/WebM media responses can include initialization data again with each media fragment.

This adds the missing extractor-side handling for those cases.

Problem

The current stream extractor only builds WEB/MWEB SABR streams for VOD. Live and post-live streams are routed through the existing HLS path instead.

Even when a SABR session is opened manually, the session still has several VOD assumptions:

  • live metadata is only applied after the streaming response has already been consumed
  • reaching the current live head can be interpreted as the end of the stream
  • absolute live segment sequences can be treated like a finite VOD timeline
  • self-initializing live fragments are exposed as regular media segments even though callers expect initialization and media data separately

This prevents a downstream client from driving a complete live SABR session through the normal extractor API.

Changes

  • Allow WEB/MWEB SABR stream extraction for live and post-live streams.
  • Process LIVE_METADATA while the UMP response is still being streamed.
  • Track the absolute live head sequence, head time and seekable window.
  • Distinguish an active live stream from a post-live DVR stream.
  • Keep an active live session open when it reaches the current live head.
  • Preserve absolute live segment sequence numbers.
  • Split self-initializing MP4 live fragments into ftyp / moov initialization data and moof / mdat media data.
  • Split self-initializing WebM fragments before the first Cluster.
  • Cache synthesized initialization segments through the existing SABR session API.
  • Keep every audio and video format advertised by YouTube available, including H.264, VP9 and AV1.
  • Skip the HLS extraction path when a usable SABR response is available.

Validation

Build:

  • ./gradlew :extractor:compileJava
  • ./gradlew :extractor:build
  • git diff --check

Live SABR probe:

video: Lt1KH3D_Pe8

H.264: itag 298
VP9: itag 302
AV1: itag 398
audio: itag 140

Observed behavior:

  • live metadata arrived before the media segments
  • the live head and seekable window advanced correctly
  • follow-up requests used absolute broadcast segment sequences
  • MP4 and WebM initialization data were separated from media data
  • all three tested video codecs and the audio format returned usable segments

Notes

This PR is extractor-only.

It does not switch PipePipe Client live playback from its current DASH/HLS path to SABR. It makes the existing extractor SABR API capable of supporting live playback when a client chooses to use it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant