Page History

...

1. Протоколы на основе TCP.
   Данный протокол является надежным, при его использовании сохранность и надежность доставки данных обеспечивается на сетевом уровне операционной системой. С другой стороны, это же является его недостатком: при потерях пакетов будет производиться повторная посылка данных. Для этого нужны существенные дополнительные ресурсы, а также время для того, чтобы определить потерю и послать данные заново.
   Рекомендуется применять:
   
   1. В нагруженных сетях, где возможны серьезные потери пакетов (из-за оборудования, среды передачи и т.д.).
   2. Когда более важна целостность картинки, чем скорость ее получения (например, при записи в архив).
   Не рекомендуется применять:
   
   1. На потоке с высоким битрейтом (высокие fps и разрешение, низкая компрессия).
   2. Для ситуаций, когда задержка между реальностью и наблюдаемой картинкой более важна, чем пропадание картинки (например, в живом видео).
   Некоторые камеры (к примеру, ArecontVision) имеют серьезные ограничения по FPS при работе по протоколу TCP.
2. Протоколы на основе UDP.
   Данные протоколы являются ненадежными, т.е. для них транспортным уровнем не обеспечивается сохранность данных. С другой стороны, данный протокол обеспечивает более быструю передачу данных и низкую задержку. Также, в случае небольших потерь и высокого fps картинка более плавная.
   Кроме того, некоторые UDP-протоколы, в частности, RTP, имеют обработку потерь пакетов на прикладном уровне (т.е. средствами приложения, а не ОС). Это позволяет использовать более приспособленные для передачи мультимедиа данных алгоритмы регулирования ширины потока и обработку потерь пакетов. Поэтому иногда такие протоколы лучше решают проблему передачи данных в плохих сетях.
   Рекомендуется применять:
   
   1. В сетях с низкими потерями пакетов (in-door, офисные сети).
   2. Для ситуаций, когда задержка между реальностью и наблюдаемой картинкой более важна, чем пропадание картинки (например, в живом видео).
   3. На потоке с высоким битрейтом (высокие fps и разрешение, низкая компрессия).
   Не рекомендуется применять:
   
   1. В нагруженных сетях, где возможны серьезные потери пакетов (из-за оборудования, среды передачи и т.д.).
   2. Когда более важна целостность картинки, чем скорость ее получения (например, при записи в архив).

Для того, чтобы Чтобы переключать протоколы передачи для IP-устройств, необходимо добавить следующий ключ в реестр:

1. Путь: HKEY_LOCAL_MACHINE \SOFTWARE\ITV\Intellect\Video\TransportProtocols TransportProtocols (для 6432-битной системы путь HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ITV\Intellect\Video\TransportProtocols). Если путь не существует, то нужно создать соответствующий раздел.

2. Название ключа: <Имя драйвера>. В качестве названия ключа используется именно имя драйвера, а не название производителя IP-устройства. Имя драйвера входит в название соответствующего ему ipd-файла, который находится в директории установки Drivers Pack (например, файл C:\Program Files\Common Files\Axxon\Ipint.DriverPack\3.0.0\Ipint.Axis.ipd для устройств Axis). В большинстве случаев имя драйвера совпадает с названием производителя IP-устройства. Уточнить имя драйвера для требуемого производителя можно при обращении в техническую поддержку компании ITV.

   Info
   title Примечание
   Если IP-устройство подключается по протоколу RTSP, необходимо использовать название ключа "RTSP" без кавычек с сохранением регистра.

3. Значение: <протокол>. Например, "http" (на основе TCP) или "tftp" (на основе UDP) для ArecontVision, "tcp" или "udp" для Axis. Значение ключа вводится с сохранением регистра.

   Info
   title Примечание
   Для некоторых устройств Axis имеется возможность включения мультикаста, реализованного в самом устройстве. Источником трансляции при этом будет являться ip-устройство. Для включения мультикаста необходимо задать значение multicast параметру Axis. На момент написания документации данная возможность поддерживается для следующих моделей камер Axis: 243SA, 243Q, 241Q, 232D+, 225FD, 221, 216FD, 211A.

4. Тип ключа: строковый.