Re: [webrtc-rtptransport] Add batch interfaces for reading RtpSents and RtpAcks (#42)

> 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 won't need any Events. For either of these cases, needing both 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?

-- 
GitHub Notification of comment by tonyherre
Please view or discuss this issue at https://github.com/w3c/webrtc-rtptransport/pull/42#issuecomment-2142520360 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 31 May 2024 15:38:46 UTC