-
Notifications
You must be signed in to change notification settings - Fork 150
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
Camera source docs #530
base: master
Are you sure you want to change the base?
Camera source docs #530
Conversation
The payloads I've dealt with that have multiple sources and a single stream are mostly independent. More specifically, for the various fields in
|
The other problem with mavlink/mavlink#2079 is that there is no way for a GCS to determine the number of sources available. Either need a new field in |
@nexton-winjeel So you're saying that generally you can change the source and the stream URL stays the same. In which case we have no problem with the stream still being where GCS expects it to be, but the resolution etc might not be set up correctly? Perhaps we should require that any source-change that affects a stream should force the affected VIDEO_STREAM_INFORMATION to re-emit? W.r.t advertising the source I was thinking you'd try to set one that didn't exist it would error. But yes, you could have this information, and potentially in both CAMERA_INFORMATION and VIDEO_STREAM_INFORMATION. Thoughts? |
Yeah, generally the URL and encoding stays the same, so GCS will still receive.
That would help.
The problem is, with the current implementation, I can't dynamically build a UI that will only show the valid choices for the
Preferably not both -- single source of truth please. |
Kind of for different purposes. It should go in |
FYI @auturgy was suggesting in dev call that he has seen cameras with multiple sensors that can stream from those simultaneously. So you could have video streams for IR and for Visible light at the same time from one camera, and presumably also picture in picture. Also that you could have the camera allowing photo capture from those sensors and not affecting the video. I said "but didn't we say for that case you need to implement different cameras"? Probably not if you want to allow the PIP case. I am somewhat sure that what we have done will not work well for all these cases, but I have no idea how to resolve it. |
Actually, you're right:
|
In that case, you just report multiple streams, yeah? And per the above, add a field to However, this also implies that |
Yes to "VIDEO_STREAM_INFORMATION should report which source is being used in the stream." Not so sure on "CAMERA_INFORMATION should report how many sources are available.".
Maybe, but I'd be tempted to add those to the video start/stop capture commands and also add source fields to VIDEO_STREAM_STATUS. Then (my concern about using |
The way I understand it is that a stream doesn't change when a source changes but what's transmitted on the stream might change, and with it maybe the resolution, etc., depending on the implementation. Cameras with multiple streams would probably not implement various sources because they don't have to as they can always stream both. |
This adds docs for setting camera source. Follows on from mavlink/mavlink#2079
@rmackay9 , @nexton-winjeel, @julianoes
We may have run into a snag unless we can assume that streams are independent of the source - can we make that assumption? I mean if I have a particular stream id, can I assume that the same URL and resolution will be published if the source is changed - albeit with data from a different sensor.
If the assumption is that they can be dependent then we're in trouble, because changing the source would make the current stream invalid. You'd lose video because the ground station will be expecting data at the URL with given resolution etc. It wouldn't know your intent to switch to some other stream.
If they can be dependent I think we'd have to use the stream ID option for setting the source.
This will need modifications based on responses.