Difference between revisions of "Talk:Nc3x3"
| Line 20: | Line 20: | ||
2 - Streamer is running (and the sensor - too). In that case only the stream frames will be available for other requests (if the stream is not aborted by the authorized user) | 2 - Streamer is running (and the sensor - too). In that case only the stream frames will be available for other requests (if the stream is not aborted by the authorized user) | ||
| + | |||
| + | --[[User:Andrey.filippov|Andrey.filippov]] 22:04, 17 September 2005 (MDT) | ||
Revision as of 20:04, 17 September 2005
formatting
It is convenient to use some Wiki formatting - i.e. sections. Then it is easier to edit just a selected section, not the whole page
continuously running streamer
В целом согласен. Нужно детализировать набор ioctl. Я так понял stream будет вкючен постоянно? Надо подумать как можно будет приостановить съёмку, чтобы потом пустить её в точное время - для синхронизации. Т.е. два кадра от разных камер должны быть засняты в одно и то же время (по сети они всё равно не смогут быть приняты одновременно, тут уж пусть клиент разбирается). Устройство "frame" может не передавать jpeg-заголовок, который можно генерить в user-space по необходимости.
Сергей
two different modes
No, I don't think stream should be always running. It will be difficult to change frame size, and - why waste network bandwidth when it is not needed?
So I believe - there should be two different cases.
1 - Single image mode - streamer is not running. Request for the static image (small clip also?) is received and queued by the camera, including all the individual acquisition settings (gains, exposure, image size, etc. Then processed one at a time - similar to printer jobs. There should be some provision to control the queued jobs (i.e. view/cancel them).
2 - Streamer is running (and the sensor - too). In that case only the stream frames will be available for other requests (if the stream is not aborted by the authorized user)
--Andrey.filippov 22:04, 17 September 2005 (MDT)
