Improved data tracks depacketizer to support mutliple in flight packets

[1egoman]

• Updates the depacketizer to take a maxPartialFrames which controls how many frames are being stored at once.
• Exposes this as a RemoteDataTrack level setting - there is one pipeline per track, not one pipeline per subscription, so this is where it makes most sense (also given that you won't really need to configure it differently by subscription since this is fully dependant on the data being received from the sender).

Code example:

const remoteDataTrack: RemoteDataTrack = /* ... */;

// The new bit:
remoteDataTrack.setMaxPartialFrames(10); // Defaults to 1 to maintain backwards compatibility.

for await (const frame of remoteDataTrack.subscribe()) {
  // ...
}

Todo

• Add changeset

[changeset-bot]

⚠️ No Changeset found

Latest commit: 64daceb

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

size-limit report 📦

Path	Size
dist/livekit-client.esm.mjs	97.13 KB (+0.2% 🔺)
dist/livekit-client.umd.js	105.99 KB (+0.1% 🔺)

[ladvoc]

question: What are your thoughts on adding this to DataTrackSubscribeOptions instead? This would still have the caveat that "the value applies to all current and future subscribers of this track," but this is the case for bufferSize anyway. Also keeps API surface cleaner.

[1egoman]

I had brought up in our 1:1 that this needs to be configured at the track level, and not the subscription level, since there is one IncomingDataTrackPipeline per RemoteDataTrack. Given this, I'm curious what you have in mind here - are you suggesting this be changed so there's aIncomingDataTrackPipeline per subscription instead?

I will say that just generally, I am not really a big fan of this method approach, and would like to find a better place to put this, so if there's something I'm missing here I'm definitely open to changing this.

[ladvoc]

I'm proposing putting it on DataTrackSubscribeOptions but this updates the track-level value under-the-hood. One disadvantage I can think of is there is no way to change max partial frames once you have a subscription (without obtaining a second one)—but not sure if this is something you would want to do anyway.

[1egoman]

I'm confused - if it was done this way, wouldn't that mean that if a user did .subscribe({ maxPartialFrames: 5 }) first, then .subscribe({ maxPartialFrames: 10 }) second, the last value would "win" and apply to both subscriptions since there is one pipeline for all subscriptions of a given track? The only way to work around this would be one pipeline per subscription rather than one pipeline per track?

[ladvoc]

Yes, the latest value would win. This behavior would have to be documented at the option level similar to this disclaimer in Rust for buffer size.

[ladvoc]

praise: Nice test coverage!

[ladvoc]

Just the one question about exposing the new option, but looks good otherwise! I will port this to Rust so these can be merged at the same time.