-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify why the writable stream backpressure should be disabled #188
Comments
We can do this. As of why it is disabled, the principle is that the pipeline is a realtime pipeline where buffering should be very limited. |
…hm returning zero. This makes it clearer backpressure is disabled. Mention reducing buffering as the reason behind this choice. Fixes w3c#188.
…hm returning zero. This makes it clearer backpressure is disabled. Mention reducing buffering as the reason behind this choice. Fixes w3c#188.
…hm returning zero. This makes it clearer backpressure is disabled. Mention reducing buffering as the reason behind this choice. Fixes w3c#188.
This is the wrong direction to go in. The right way of approaching this is to make the feedback channel explicit as outlined in https://github.com/alvestrand/hackathon-encoded-media EDIT: It seems that we have already disabled backpressure in the specified API, so we have no defense against buffer overruns. This seems dangerous, but it is a previously accepted danger. |
This issue was discussed in WebRTC July 2023 meeting – (Issue #188: Clarify why backpressure should be disabled) |
https://w3c.github.io/webrtc-encoded-transform/#stream-creation
#108 disabled it and added some notes, but the intention is not clear why it should be disabled. The note only says it's disables by letting sizeAlgorithm to return 0 (which I think it should set highWaterMark to Infinity instead).
The text was updated successfully, but these errors were encountered: