-
Notifications
You must be signed in to change notification settings - Fork 48
[RSDK-9251] - Add options helpers to stream client #418
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
Conversation
|
It looks like the |
|
@seanavery I think bumping package versions should be fine provided nothing breaks when we do so. If tests start failing otherwise then we'll want to revisit of course. |
jckras
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. One thing I’m wondering is whether we should add validation for input parameters across the methods (ex: resourceName/name should be non-empty strings, width/height in setOptions should be positive numbers) other than that just left a few questions for my own understanding
| const response = await this.client.getStreamOptions(request); | ||
| return response.resolutions; | ||
| } catch { | ||
| return []; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why return an empty list when the available resolution is not available and not an error message?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah good question! I toyed around with erroring out in the failure case but thought it would be nicer to just return empty array to avoid complexity when calling it in the frontend and trying to fill a dropdown or such with the return. (This is presumptuous as I do not have that much experience with frontend stuff) Happy to change the behavior to throw if that is better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think simple is better! and would just keep how it is
| * @param height - The height of the resolution. | ||
| */ | ||
| async setOptions(name: string, width: number, height: number) { | ||
| const request = new SetStreamOptionsRequest({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need any error checking that the width/height parameters are set within a specific bound?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of the GRPC field checks happen in the server endpoint and it should hopefully error out here with the correct message. Would it be good to add additional checks here in the client before sending?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah got it. if the checks are happening elsewhere then we def don't need to duplicate it
| try { | ||
| await this.client.setStreamOptions(request); | ||
| } catch { | ||
| // Try again with just the resource name |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we try again with just the resource name? if getValidSDPTrackName(name) is false then we are just falling back to using an unformatted name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure... Was initially thrown off by this but this is the behavior from the other stream client methods so I copied it. If we want I can do a follow up PR to test this out and remove across the stream client if we dont need it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the flutter sdk only tries the sdp track name.
https://github.com/viamrobotics/viam-flutter-sdk/blob/main/lib/src/media/stream/client.dart#L88-L97
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately I don't know enough on whether one way is better than another here but I think stick with consistency here on the other stream clients?
|
@stuqdog I unsuccessfully attempted bump on Immediately getting errors from API change when trying to It appears to be an issue with how the buff binary is generating the protobuf js code. Is it ok to merge a PR with a ❌ test? Happy to create a ticket for this with results from my bump attempt. |
| npm run lint | ||
| npm run typecheck | ||
| npm run check -- --ignore=@bufbuild/protobuf | ||
| npm run check -- --reject="@bufbuild/protobuf,@connectrpc/connect,@connectrpc/connect-web" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stuqdog Added connectrpc to ignore list since they also depend on protobuf. Is this ok?
| "build:types": "tsc --project tsconfig.build.json", | ||
| "build:copy-dts": "copyfiles -u 1 \"src/gen/**/*.d.ts\" dist", | ||
| "check": "npm-check --production", | ||
| "check": "ncu --errorLevel 2 --dep prod", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had to move away from npm-check since it apparently cannot handle the scope level @ properly inside an ignore list.
Description
This PR adds a few helpers to interact with dynamic resolution stream server endpoints.
Tests
Added success and failure test cases for the new stream interface methods.