Add batch interfaces for reading RtpSents and RtpAcks

[tonyherre]

Add batch methods as discussed in #20.

Currently leaving the Events unchanged, as an alternative.

[Philipel-WebRTC]

Looks good, I would even prefer if we only had the batched getters instead of the EventHandlers

Another thing I think would be nice to have is a signal that only gets triggered when some receive buffer goes from empty to not empty.

Also, what should happen if the application doesn't call the getters fast enough? Do we just silently drop packets?

[tonyherre]

Looks good, I would even prefer if we only had the batched getters instead of the EventHandlers

I don't feel super strongly, but came to the thought that one either has ~low frequency packets so just event-per-packet is best and easiest, or one has ~high frequency packets (paced to something smooth-ish) so calling readSentNotifications() will always return stuff so one won't need any Events. For either of these cases, needing to use both an Event + getBatch() is extra code & complexity for no benefit.
What scenarios did I missed which would benefit for event+getBatch? Something with lots of bursty packets, like high res, low framerate screenshare maybe? Is that what you were thinking about, Philip?

Also, what should happen if the application doesn't call the getters fast enough? Do we just silently drop packets?

Very good Q... I think we really should do this (and this is an advantage over raw Events which could just clog up the Event Loop ~forever potentially preventing the JS from recovering, as discussed). But do we need to expose that fact to the app, so it knows to speed up if it's not keeping up?
Maybe as a dictionary SentRtpBatchRead { sequence<SentRtp> sentNotifications, short missedSentNotificationCount} dict returned by readSentNotifications() etc?

[aboba]

@tonyherre In WebTransport, we have incomingMaxAge, outgoingMaxAge to enable dropping of incoming and outgoing packets that spend too long in the queue. Also, there are stats.

[tonyherre]

Problem: without the clear signal of attaching event handlers, how does the browser know the app will eventually call readSentNotifications() etc so that it should store RtpSent and RtpAcks objects?
Even the RtpTransport object might not be created before JS makes the first read() call, expecting to hear about what's been going on up to that point:

const pcWithCustomBWE = new RTCPeerConnection();
// negotiate, add tracks etc.
setTimeout(() => {
  // What's been sent?
  processSends(pcWithCustomBWE.rtpTransport.readSentNotifications(100));
}, 1000);

We might need a field in RTCConfiguration to start this tracking...

[Philipel-WebRTC]

This is another reason why I think having only batched getters is better. It makes the API clearer.

[youennf]

I tend to agree we should have only one API here.

Normally, setting event listeners should have no real side effects.
If we think there is a potential big power effects here, it might be better to have a clear signal from the web app that they are interested in this data, like calling getReader for instance.

[pthatcher]

I think we should keep the new example from #42 and the updated example from #51 (with the event payloads removed). I'm fine with either naming scheme.

[pthatcher]

We can deal with the "is the max number optional?" either in this PR or in a separate one

[tonyherre]

@tonyherre In WebTransport, we have incomingMaxAge, outgoingMaxAge to enable dropping of incoming and outgoing packets that spend too long in the queue. Also, there are stats.

These are great ideas, thanks! - forked out into #54 & #55.

[tonyherre]

I think we should keep the new example from #42 and the updated example from #51 (with the event payloads removed). I'm fine with either naming scheme.

Done, I think. Adopted the naming scheme from #51. Also removed the comment and examples which had data in the events themselves.

We can deal with the "is the max number optional?" either in this PR or in a separate one

I wasn't sure which way to go with this - what's the default if the app doesn't provide a max, it just gets the entire queue of many (thousands?) of packets in one chunk? Forcing the JS to specify some number feels like it might be good for avoiding surprises and doesn't add too much complexity, or?
Don't feel that strongly though, so happy to add it and discuss removing it in an issue or meeting etc.

PTAL all!

[tonyherre]

Ping @pthatcher - Are you happy with how this has taken the updated example from #51?