Видеонаблюдение.

[BigAndy]

НА праздники поставил задачу реализовать сеансовое виждеонаблюдение на кассах. Пока реализован непрерывный поток при помощи LinuxDVR и zoneminder, но для простоты хочу, чтобы создавался файл с номером чека. Программисту поставлена задача посмотреть в сторону usb камер, v4l, (vlc или mencoder)
У кого-нть может есть какие мысли?

Всего участвуют три камеры. Две запускается по датчику, расположенному в кассовой зоне, с этим проблем нет. А третяя(и, возможно, четвертая) , фиксирующая зону сканирования и взвешивания Предполагается использоватьcя слдеующим образом. Из видеопотока должен вычленяться участок записи, начинающийся за три секунды до события сканирования, и заканчивающийся через три секунды после событися сканирования. В последующем будем запихивать в postgres, но это не проблема.
Изначально не хотим ковыряться в коде, хотим использовать события postgres listen/notify при записи опредеднных транзакций с определенными кодами...

У кого-нть какой опыт в эту сторону есть?

[Alexander]

Тут либо триггеры на запрос SELECT придётся делать, либо (были у нас уже такие мысли) менять схему записи транзакций.
Поскольку сейчас все транзакции записываются в БД по закрытию чека (более того - после получения от ФР ответа об отсутствии ошибок при закрытии чека).

[BigAndy]

Мда. Надо будет поэксперементировать с List/notify при открытии транзакций
Ну, если что и в коде можно будет сделать, жаль, что тогда в дистрибутив включить как стандартное решение нельзя будет. Либо придется делать через v4l.

[BigAndy]

Мда.. Апнут тему.
1) Сегодня сделал вьюху

Код: Выделить всё

SELECT distinct tr_date_time::date , n_pc, n_kkm, seller, n_session,
      (select max(t1.tr_date_time) from "transaction" t1
      where t1.tr_type = 62 and t1.tr_date_time::date=t.tr_date_time::date) opened,
      (select max(t2.tr_date_time) from "transaction" t2
      where t2.tr_type = 61 and t2.tr_date_time::date=t.tr_date_time::date) closed

FROM "transaction" t where t.tr_type in (62,61) order by tr_date_time::date,n_session

Ужаснулся. Проблема актуализировалась.
Оказывается, что очень часто все без исключения продавцы и (или) начинают смену с опозданием и (или) заканчивают раньше. Общая CCTV не обеспечивает документирование операций у кассы. (используется avreg)

Тут либо триггеры на запрос SELECT придётся делать, либо (были у нас уже такие мысли) менять схему записи транзакций.

Я вот подумал, что хорошо было бы в transactions вводить автореккрентный -вторичный ключ и вводить протоколирование записей. При сбое в кассовой программе/получении статуса ошибки торгового оборудования можно было бы вводить стоп-запись (обнуления чека). Такой порядок, почти OLTP, был бы полезен для выработки сигналов по некоторым ключевым событиям техпроцесса продажи товаров...
Выборка последовательности операций очень удобно было бы делать при помощи with recursive, что упростило бы работу в мультитерминальном режиме.
Собственно и сейчас можно сделать, даже быстро на бейсике, при помощи Listen/notify, но детализировать можно, только внедрившись в код программы, что неизбежно повлечёт трудности с апгрейдом и увеличения порога администрирования системы.