Difference between revisions of "Nc3x3 multiuser mode"
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | {{Manual legacy_pages}} | ||
| + | |||
I think we need to implement 2 distinct modes - "master" and "slave" (or however we call them). It is OK to switch sensor/compressor modes for individual JPEG images but that will not work if the streamer is running without severe interruptions of the stream. | I think we need to implement 2 distinct modes - "master" and "slave" (or however we call them). It is OK to switch sensor/compressor modes for individual JPEG images but that will not work if the streamer is running without severe interruptions of the stream. | ||
| − | So there should be a separate protocol for gaining control of the sensor operation mode. I.e. if the camera is in idle mode anybody (with enough permissions) can acquire image, several parallel requests might queued and served in sequence with sensor reprogramminmg. But if the streamer is running the other request should only use the stream (or images from it) without any interruption of the stream. Maybe (if the streamer uses all the CPU/network resources) request may be denied completely to avoid any frame drops (if some QoS was requested). | + | So there should be a separate protocol for gaining control of the sensor operation mode. I.e. if the camera is in idle mode anybody (with enough permissions) can acquire image, several parallel requests might be queued and served in sequence with sensor reprogramminmg. But if the streamer is running the other request should only use the stream (or images from it) without any interruption of the stream. Maybe (if the streamer uses all the CPU/network resources) request may be denied completely to avoid any frame drops (if some QoS was requested). |
User should be notified about the reasons fro denial of service and have the possibility (with relevant permissions) to gain the control of the camera, reset the streamer and reprogram camera to the different mode. | User should be notified about the reasons fro denial of service and have the possibility (with relevant permissions) to gain the control of the camera, reset the streamer and reprogram camera to the different mode. | ||
Andrey Filippov | Andrey Filippov | ||
| + | |||
| + | ---- | ||
| + | |||
| + | Да, это надо реалиизовывать через <i>ctrl</i> интерфейс, с разделением полномочий, и выбор базового профиля для конкретной ситуации - вместе с разделением прав на три группы - как в Axis - этот момент надо будет проработать с AlexLP. | ||
| + | |||
| + | Spectr | ||
Latest revision as of 15:37, 24 August 2008
This is a legacy page. The information bellow is not compatible with Elphel 393 or 353/363 series cameras.
I think we need to implement 2 distinct modes - "master" and "slave" (or however we call them). It is OK to switch sensor/compressor modes for individual JPEG images but that will not work if the streamer is running without severe interruptions of the stream.
So there should be a separate protocol for gaining control of the sensor operation mode. I.e. if the camera is in idle mode anybody (with enough permissions) can acquire image, several parallel requests might be queued and served in sequence with sensor reprogramminmg. But if the streamer is running the other request should only use the stream (or images from it) without any interruption of the stream. Maybe (if the streamer uses all the CPU/network resources) request may be denied completely to avoid any frame drops (if some QoS was requested).
User should be notified about the reasons fro denial of service and have the possibility (with relevant permissions) to gain the control of the camera, reset the streamer and reprogram camera to the different mode.
Andrey Filippov
Да, это надо реалиизовывать через ctrl интерфейс, с разделением полномочий, и выбор базового профиля для конкретной ситуации - вместе с разделением прав на три группы - как в Axis - этот момент надо будет проработать с AlexLP.
Spectr
