- From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
- Date: Fri, 05 Apr 2019 16:08:43 +0000
- To: public-webrtc-logs@w3.org
First of all: I agree that WebRTC compatible endpoints (but **not** browsers) must be able to announce less than 64k streams. Definitely needed when talking to a small embedded device. But that's covered by the spec as it is today. > The problem with implementing a dynamic allocation is that you can't handle memory allocation failures, since you already negotiated that you support 65535 streams. Realistically, if a browser encounters such a scenario where ~6 MiB more would result in OOM, it's probably already doomed. :slightly_smiling_face: > One could use an late allocation scheme where you only use sizeof(void *) for an unused incoming or outgoing stream. However, without impacting the performance too hard, one would always allocate the array of pointers for stream 0...N. Hrm, I can't quite follow here. Enlarging an array should be easy enough? Sure, it needs an additional size variable, but other than that? > So using small stream IDs would be beneficial. Using a stream ID of 65535, would require the pointer array to be maximal. A hash table based lookup may also be something feasible to keep the memory impact low with high stream ids. Generally I don't consider it an issue. Applications who use stream ids in the area of 64k will be extremely rare. Even if it's a pointer array implementation it's only ~512 KiB on 64-bit machines to enlarge the stream array to 65535 void pointers. (Side note: Yeah, renegotiation of the number of streams is still implemented in Firefox... although AFAIK it's still a bit buggy here and there, so the complexity argument isn't that far off.) -- GitHub Notification of comment by lgrahl Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2158#issuecomment-480332653 using your GitHub account
Received on Friday, 5 April 2019 16:08:47 UTC