Difference between revisions of "Talk:Nc3x3"
| (4 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | It is | + | == 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. | Нужно детализировать набор ioctl. | ||
| Line 9: | Line 9: | ||
Т.е. два кадра от разных камер должны быть засняты в одно и то же время (по сети они всё равно не смогут быть приняты одновременно, тут уж пусть клиент разбирается). | Т.е. два кадра от разных камер должны быть засняты в одно и то же время (по сети они всё равно не смогут быть приняты одновременно, тут уж пусть клиент разбирается). | ||
Устройство "frame" может не передавать jpeg-заголовок, который можно генерить в user-space по необходимости. | Устройство "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) | ||
| + | |||
| + | --[[User:Andrey.filippov|Andrey.filippov]] 22:04, 17 September 2005 (MDT) | ||
| + | |||
| + | == continously running sensor == | ||
| + | I mean what sensor should run continously and will be interrupted in only for change of some modes which can not be changed on fly. | ||
| + | If the queue contain a job, streaming interrupts and sensor reprogramming for the job. After this sensor reprogrammed again for the stream. | ||
Latest revision as of 21:08, 17 September 2005
Contents
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)
continously running sensor
I mean what sensor should run continously and will be interrupted in only for change of some modes which can not be changed on fly. If the queue contain a job, streaming interrupts and sensor reprogramming for the job. After this sensor reprogrammed again for the stream.
