Правило астериска
берите только опенсурс решения под ваш астериск. Там тоже всё мышкой управляется
Нужно больше доп фич? Допишите 20 строк в диалплан. Забудьте на 5 лет.
Ездите в отпуска, делайте что хотите. Если вы не продаете телефонию, а используете для внутренних целей — любой фрилансер-админ решит все ваши проблемы.
Мы 5 лет продаем телефонию. Построена на астериске. Продаем в малых количествах.
Обновлялись 1 раз за 5 лет. Обновлялись когда вышел хороший фикс T38.
На самом деле астериск используется у нас не по назначению — Sip router с авторизацей.
В то время знал астериск, opensip не знал. За запуск получил немного денег. Потом процент с продаж. Вот вам вся поддержка.
Основные проблемы Fax, Nat, зависшая оконечка.
Боитесь. Воткните в офисе proxmox. Сделайте себе 1 рабочий и 9 резервных астерисков. Прикрутите к ним опенсорсную статистику. Уезжайте хоть на год. Один сломался — запустил второй и т.д.
Попробуйте искать их сами без эйчаров + добавьте обучение у себя в организации. Многое для себя откроете.
В России я всё чаще и чаще встречаю людей — мастеров на все руки.
Отсюда начинает хромать некоторая область.
2 года в одном направлении работаешь, два в другом и т.д. Рынок меняется очень быстро. А если (не дай бог) стал не IT специалистом, а руководителем отдела, то тут вообще может начаться каша в знаниях, так как под тобой человек 40 разной специализации, а тебе с этим нужно разбираться и ставить правильные сроки, зачастую это происходит с некоторой потерей знаний (не всегда так, но бывает). Потом организация грохается.
Знаю таких людей, сам попал в такой переплет.
Знаю организацию, которая набирает инженеров по телефонии (работа на телефоне). SIP. В Москве нет столько людей с оооочень хорошим знанием SIP протокола. По этому приходится их учить за свой счет.
Сам уже ищу работу полтора месяца. За это время видел совершенно разные подходы. Очень разный рынок, хотя задачи одни и те же, нужно приспосабливаться, а это потеря времени и изменение знаний.
Очень часто не специалисты ищут специалистов. Всего 1 раз встретил специалиста-начальника, прообщались полтора часа на собеседовании. Но вакансия покрывает всего 15%-30% моих знаний и мне требуется обучение (восстановление знаний). То о чем общались я делал 3 года назад, а потом просто поддерживал в виде HelpDesk (телефония). У меня в профайле на брейн сторейдже указано где то 50% того чем я занимался в своей профессиональной карьере. «Столько знать не возможно» — с этим я согласен, но была задача, было решение, коммерческое решение подтвержденное временем.
Всегда хотел стать программистом (еще лет с 13), но до сих пор судьба так не сложилась. Поддержка, администратор, хелпдеск, инженер по телефонии, аналитик, начальник подразделения/нескольких отделов, автоматизация и т.д, но не все уходят работать в большую организацию с многомиллионными доходами, отсюда и получается набор бесполезного опыта и знаний (в нынешней перспективе)
Проблема в поисках работы и рынке.
Он у нас уж очень странный.
Есть 2 типа людей
1) узкой специализации
2) широкой специализации
Первые, если хорошие профессионалы, то они быстро найдут работу. Но за частую на их плечи ложится написание некоторых модулей, т.е. не полного ПО. И за ними нет решения «выложить в open-source». Так как продукт не в их ведении.
Вторым искать работу сложнее, но и решают они больший круг вопросов. И частенько начиная от эникея и заканчивая полным проектированием и ведением какого либо продукта. Так вот скрытие некоторых технологий/кода дает конкурентное преимущество на Российском рынке труда.
А ситуация тут простая. Если кругозор такого специалиста на 80% шире узкоспециализинованного специалиста, то знания по некоторым направлениям могут страдать, либо устаревать со временем. А при наличии уникальных уже готовых решений шанс найти работу явно выше.
Если подходить со стороны вопроса из статьи, то это уменьшает шансы человека познакомиться с тем же гитхабом.
Почему на хабре обычные IT специалисты воспринимаются одностаночниками без саморазвития?
Как будто дома ни кто не ведет свои проекты, ни кто ни чего не изучает, не общается с людьми.
REST легче AGI?
а вообще, скрипт который я привел работает на всех версиях астериска, начиная от 1.4. Скрипту больше 6ти лет.
и в agi общение происходит через stdio
при использовании не PHP можно сделать свое ядро с «ручками» и дергать его по agi.
Причем AGI позволяет выполнять скрипт при уже мертвом канале.
При некоторой сноровке в скрипт (на любом языке) помещаются все необходимые проверки. AGI позволяет сделать доп функционал астериску без перегрузки диалплана. Например: Автозвонилка с автоинформатором по sql базе. Не буду объяснять почему работу sql в астериске лучше выносить за диалплан.
Есть две задачи
1) отображение зоопарка кодеков h264 в онлайн видео.
2) отображение записей.
Записи полностью по html5 работают. Записи работали на тех устройствах, которые держат html5
Онлайн видео из-за зоопарка кодеков работает во флеше, hls, в vlc плагине, в разных плеерах.
Вывод mjpeg с детектора движения. (работает во всех браузерах кроме ie)
Зоопарка устройств для теста не было, айфон, андройд, нокия с5-00.
Тут пример кода для локального развертывания: github.com/Calc86/dvr/tree/master/bin/system2/classes/tv
6 камер вполне хорошо будут работать.
Ну желательно делать snmp по паролю (snmp v3?) и только на тех портах на которых можно его делать (ACL)
плюс там есть настройка для кого какие oid выдавать (для public одни, для private другие)
Ivideon Server 3.5.0 Build 95
onvif discovery не сработал у меня.
Да и как я говорил напрямую нельзя «скормить» ссылку на onvif камеры.
Мне просто попадались IP камеры где есть ссылка на onvif, но для ссылки на rtsp приходилось рыться в интернете, даже поставщик не мог сказать их.
Может в будущем вы реализуете что нибудь подобное alpha.hstor.org/files/2f7/8e1/7f1/2f78e17f107742fb8ab445bb85149f7f.png
IP camera Name DCS-2103
Time & Date Wed Jan 16 07:32:58 2013
Firmware Version 1.20.00
MAC Address F0:7D:68:09:E4:F4
IP Address 10.112.28.231
IP Subnet Mask 255.255.255.0
Default Gateway 10.112.28.253
Primary DNS 10.112.1.1
Secondary DNS 10.112.2.1
PPPoE Disable
DDNS Disable
у меня 10.112.28.33, воткнуты в один свич, udp не режется.
А что писать то)
В сентябре новая работа будет искаться. Буду заниматься видео — что нибудь напишу, а так пока мысли только о том как себя ведет TCP при большой нагрузке (window size и etc)
В сторону SIP может быть занесет и гоняние видео по нему, но кто знает.
У меня «облако» это был Core-i5 с Proxmox на борту, 3 машины (DVR, Mysql, Web) и второй гроб FreeNAS. Для нас было «накладно» перекодировать на нашем железе, по этому искались решения как можно проще и «в лоб». 30 камер 720p держал влет с онлайн просмотром архива и детектором движения. Онлайн просмотр был страшным монстром. Иногда h264 елся, иногда тупо mjpeg отдалавли (4 кдра в секунду, что позволяло смотреть даже на nokia c5-00). Ну и тайплапсы видео за день (1 секунда = 3 минуты), что позволяло за 5-8 минут проверить работу целой толпы людей. Кто был, кто не был и кто когда пришел. Так как проект потонул, вот и описываю «опыт».
Доходило до изобретения «железяки» на openwrt, которая напрямую поток с камеры кладет на хард, который воткнут в эту «железяку». Это был любой роутер TP-link и OpenWRT прошивка. Идея была в том, чтобы через OpenWRT хоть как то стандартизировать получение потока, стопкадра и безопасности.
Можно конечно и всё это описать, но там велосипед на велосипеде.
Также я не рассказал о том как «собирать» udp поток.
RTCP для сохранения потока не столь важен :)
Кадры есть в SDP (SPS, PPS), для поддержки связи используется GET_PARAMETER, OSD есть в кадре. Минимум соблюден. При желании через onvif можно поставить правильное время.
Ссылка на RFC: tools.ietf.org/html/rfc3550#page-19
Камеры шлют RTCP senders report (200), мы должны слать Receiver Report (201)
До реализации RTCP не дошло, так как не было в этом надобности (точнее она была только при прошивке 1.00 у Dlink DCS-2103, на прошивке 1.20 надобность отпала)
/**
* Created by calc on 17.07.14.
* http://tools.ietf.org/html/rfc3550#page-19
*
* From wireshark:
* RTCP senders report (200)
* 01234567 01234567 01234567 01234567
* +--------+--------+--------+--------+
* |V P RC | type201| length (octets) |
* v-2bit
* p-1bit
* 01234567 01234567 01234567 01234567
* +--------+--------+--------+--------+
* SSRC
* NTP timestamp MSW
* NTP timestamp LSW
* RTPWrapper timestamp
* senders packet count
* senders octet count
*
* RTCP source description (202)
* +--------+--------+--------+--------+
* |V P SC | type202| length |
* chunks:
* Chunk 1:
* +--------+--------+--------+--------+
* Identifier (SSRC?)
* SDES:
* +--------+--------+
* type length Text... End(0)
*
*
* +--------+--------+--------+--------+
* |V P RC | type201| length (octets) |
* ssrc
* Sources:
* +-Source1:
* +-Identifier (4bytes)
* +-SSRC content
* + fraction lost 1byte
* + Cumulative number of packets lost: -1 (3 bytes)
* + extended highest sequence number received
* + cycle 2b
* + number 2b
* + jitter 4b
* + LSR (middle of NTP timestamp)
* + Delay since last SR 4b
*
*
*
*/
public static byte[] response201(RTCP rtcp, int loop, int seq, int channel, long last, int jitter){
byte[] buffer = new byte[32];
int i = 0;
//header
buffer[i++] = (byte)0x81; //1000 0001
buffer[i++] = (byte)RTCP.TYPE_RECEIVER_REPORT;
buffer[i++] = 0; buffer[i++] = 7; // 32/4-1
//my ssrc
System.arraycopy(ssrc, 0, buffer, i, ssrc.length);
i += ssrc.length;
buffer[i-1] = (byte)channel;
//source 1
System.arraycopy(rtcp.getBuffer(), rtcp.getSSRCStart(), buffer, i, 4);
i += 4;
//fraction lost
buffer[i++] = (byte)0x00;
//Cumulative number of packets lost: -1
/*buffer[i++] = (byte)0xff;
buffer[i++] = (byte)0xff;
buffer[i++] = (byte)0xff;*/
buffer[i++] = 0;
buffer[i++] = 0;
buffer[i++] = 0;
//Extended highest sequence number received:
buffer[i++] = BIT.HiByte(BIT.LoWord(loop));
buffer[i++] = BIT.LoByte(BIT.LoWord(loop));
buffer[i++] = BIT.HiByte(BIT.LoWord(seq));
buffer[i++] = BIT.LoByte(BIT.LoWord(seq));
//Interarrival jitter:
buffer[i++] = BIT.HiByte(BIT.HiWord(jitter));
buffer[i++] = BIT.LoByte(BIT.HiWord(jitter));
buffer[i++] = BIT.HiByte(BIT.LoWord(jitter));
buffer[i++] = BIT.LoByte(BIT.LoWord(jitter));
//Last SR timestamp: 3810671619 (0xe3223c03)
buffer[i++] = BIT.HiByte(BIT.LoWord(rtcp.getHiNTPTimestamp()));
buffer[i++] = BIT.LoByte(BIT.LoWord(rtcp.getHiNTPTimestamp()));
buffer[i++] = BIT.HiByte(BIT.HiWord(rtcp.getLowNTPTimestamp()));
buffer[i++] = BIT.LoByte(BIT.HiWord(rtcp.getLowNTPTimestamp()));
//Delay since last SR timestamp: 71531 (1091 milliseconds)
//1/65536
long now = System.currentTimeMillis();
int range = (int)(((double)(now - last)/1000) * 65536);
buffer[i++] = BIT.HiByte(BIT.HiWord(range));
buffer[i++] = BIT.LoByte(BIT.HiWord(range));
buffer[i++] = BIT.HiByte(BIT.LoWord(range));
buffer[i++] = BIT.LoByte(BIT.LoWord(range));
/*buffer[i++] = 0;
buffer[i++] = 0;
buffer[i++] = 0x06;
buffer[i++] = 0x68;*/
return buffer;
}
Рекомендованный интервал между RTCP пакетами — 5 (секунд)
Задача в том, чтобы сохранить последний RTCP (200) и спустя некоторое время ответить.
Также нужно понимать о существовании RTCP source description (202)
Каждый Source у камеры имеет уникальное число (32 бита, SSRC)
Аудио и видео это разные Source.
Алгоритмы вычисления lost и jitter можно посмотреть в приложениях RFC 3550, или вольная интерпретация тут: github.com/Calc86/camRecorder/tree/master/src/com/net/rtp/rfc — но его надо тестить.
Такого класса вполне достаточно для ответа на RTCP 200
private class Source{
public int ch;
public int controlCh;
public int SSRC;
public RTCP lastRTCP;
public long lastRTCPTime;
public long jitter;
public long transit;
public int loop;
public int sequence;
//Перевезти в эти переменные массив os[]
private OutputStream dataOut;
private OutputStream controlOut;
public void calculate(RTPWrapper rtp){
long ts = uInt.get(rtp.getTimestamp());
long arrival = System.currentTimeMillis() / 1000L;
long transit = arrival - ts;
long d = transit - this.transit;
this.transit = transit;
if(d < 0) d = -d;
jitter += (1./16.) * ((double)d - jitter);
int oldSeq = sequence;
int newSeq = rtp.getSequence();
if(newSeq < oldSeq) loop++;
sequence = newSeq;
}
}
Ну а вот что делать со всеми этими Timestamp — хрен его знает. Если пакеты потерялись, то не будем же мы нули писать в поток. По этому берем поток, отправляем в OutputStream и всё.
Спасибо, поправил. Видимо у вас идет поиск по камерам для которых включено обнаружение по onvif, но если я хочу добавить свою, у которой выключено обнаружение, то не могу найти в вашем сервере подобную настройку (3.4.5 build 78).
Архаичное решение как «сервер» нужен для архаичных камер, которые имеют совершенно разный h264 кодек с совершенно разными звуковыми дорожками и хочешь-не хочешь для вещания в web нужно всё декодировать.
А статьи про видео наблюдение обычно заканчиваются комментариями «Откройте для себя Ivideon».
Тема от IT обособлена по одной причине. Проще поставить коробку (DVR) и воткнуть туда камеры. Это обкатанный вариант, но не совсем бюджетный. Рынок довольно насыщенный и забит системами безопасности. И «пока оно работает» люди не особо хотят что то трогать.
А статей мало потому что есть либо zoneminder, либо скриптовый монстр на VLC (У меня такой есть), либо вы :)
Пока все производители камер не перейдут на «православный» web h264 ситуация особо не изменится. А как показывает практика и общение с разными организациями и безопасниками лучше иметь обособленную медиа среду для безопасности, нежели гнать по общему lan с его узлами. Сразу скажу что общение происходило в тех организациях, которые экономят на всём и штат в них до 20 человек. Т.е. им дешевле обслуживать путь Камера-провод-DVR, нежели всю инфраструктуру lan (которая строится на каком нибудь asus rt-n66)
Опыт используемый в этой статье был взят из проекта который «не выстрелил».
А сервер нужен для стандартизации потоков с камер. После этого можно и в web, и в файлы, и в космос.
Кстати, как у вас обстоят дела с собственной системой видео наблюдения? Текущие реалии позволяют брать h264 камеры со стоп кадром (почти все камеры с onvif имеют его, либо собственный датчик движения, можно подписаться на эвенты onvif). И по схеме 10 минут записи в ram диск и миграция через ffmpeg на любой NAS на core i5 дает возможность держать больше 30ти камер. У меня 20-25 потоков h264 грузят одно ядро процессора на 80-180% (ядер 4 — 400%) с детектором движения на motion.
берите только опенсурс решения под ваш астериск. Там тоже всё мышкой управляется
Нужно больше доп фич? Допишите 20 строк в диалплан. Забудьте на 5 лет.
Ездите в отпуска, делайте что хотите. Если вы не продаете телефонию, а используете для внутренних целей — любой фрилансер-админ решит все ваши проблемы.
Мы 5 лет продаем телефонию. Построена на астериске. Продаем в малых количествах.
Обновлялись 1 раз за 5 лет. Обновлялись когда вышел хороший фикс T38.
На самом деле астериск используется у нас не по назначению — Sip router с авторизацей.
В то время знал астериск, opensip не знал. За запуск получил немного денег. Потом процент с продаж. Вот вам вся поддержка.
Основные проблемы Fax, Nat, зависшая оконечка.
Боитесь. Воткните в офисе proxmox. Сделайте себе 1 рабочий и 9 резервных астерисков. Прикрутите к ним опенсорсную статистику. Уезжайте хоть на год. Один сломался — запустил второй и т.д.
В России я всё чаще и чаще встречаю людей — мастеров на все руки.
Отсюда начинает хромать некоторая область.
2 года в одном направлении работаешь, два в другом и т.д. Рынок меняется очень быстро. А если (не дай бог) стал не IT специалистом, а руководителем отдела, то тут вообще может начаться каша в знаниях, так как под тобой человек 40 разной специализации, а тебе с этим нужно разбираться и ставить правильные сроки, зачастую это происходит с некоторой потерей знаний (не всегда так, но бывает). Потом организация грохается.
Знаю таких людей, сам попал в такой переплет.
Знаю организацию, которая набирает инженеров по телефонии (работа на телефоне). SIP. В Москве нет столько людей с оооочень хорошим знанием SIP протокола. По этому приходится их учить за свой счет.
Сам уже ищу работу полтора месяца. За это время видел совершенно разные подходы. Очень разный рынок, хотя задачи одни и те же, нужно приспосабливаться, а это потеря времени и изменение знаний.
Очень часто не специалисты ищут специалистов. Всего 1 раз встретил специалиста-начальника, прообщались полтора часа на собеседовании. Но вакансия покрывает всего 15%-30% моих знаний и мне требуется обучение (восстановление знаний). То о чем общались я делал 3 года назад, а потом просто поддерживал в виде HelpDesk (телефония). У меня в профайле на брейн сторейдже указано где то 50% того чем я занимался в своей профессиональной карьере. «Столько знать не возможно» — с этим я согласен, но была задача, было решение, коммерческое решение подтвержденное временем.
Всегда хотел стать программистом (еще лет с 13), но до сих пор судьба так не сложилась. Поддержка, администратор, хелпдеск, инженер по телефонии, аналитик, начальник подразделения/нескольких отделов, автоматизация и т.д, но не все уходят работать в большую организацию с многомиллионными доходами, отсюда и получается набор бесполезного опыта и знаний (в нынешней перспективе)
Он у нас уж очень странный.
Есть 2 типа людей
1) узкой специализации
2) широкой специализации
Первые, если хорошие профессионалы, то они быстро найдут работу. Но за частую на их плечи ложится написание некоторых модулей, т.е. не полного ПО. И за ними нет решения «выложить в open-source». Так как продукт не в их ведении.
Вторым искать работу сложнее, но и решают они больший круг вопросов. И частенько начиная от эникея и заканчивая полным проектированием и ведением какого либо продукта. Так вот скрытие некоторых технологий/кода дает конкурентное преимущество на Российском рынке труда.
А ситуация тут простая. Если кругозор такого специалиста на 80% шире узкоспециализинованного специалиста, то знания по некоторым направлениям могут страдать, либо устаревать со временем. А при наличии уникальных уже готовых решений шанс найти работу явно выше.
Почему на хабре обычные IT специалисты воспринимаются одностаночниками без саморазвития?
Как будто дома ни кто не ведет свои проекты, ни кто ни чего не изучает, не общается с людьми.
вступает следующая ситуация
«я платил, а он бесплатно!»
по всем показателям должно получиться (-1.4, 0.1)
ARI появился этим летом (точной информации не нашел)
а вообще, скрипт который я привел работает на всех версиях астериска, начиная от 1.4. Скрипту больше 6ти лет.
и в agi общение происходит через stdio
при использовании не PHP можно сделать свое ядро с «ручками» и дергать его по agi.
Причем AGI позволяет выполнять скрипт при уже мертвом канале.
При некоторой сноровке в скрипт (на любом языке) помещаются все необходимые проверки. AGI позволяет сделать доп функционал астериску без перегрузки диалплана. Например: Автозвонилка с автоинформатором по sql базе. Не буду объяснять почему работу sql в астериске лучше выносить за диалплан.
call-back-mont.php:
call-back.php
ну а дальше только ваша фантазия.
1) отображение зоопарка кодеков h264 в онлайн видео.
2) отображение записей.
Записи полностью по html5 работают. Записи работали на тех устройствах, которые держат html5
Онлайн видео из-за зоопарка кодеков работает во флеше, hls, в vlc плагине, в разных плеерах.
Вывод mjpeg с детектора движения. (работает во всех браузерах кроме ie)
Зоопарка устройств для теста не было, айфон, андройд, нокия с5-00.
Тут пример кода для локального развертывания: github.com/Calc86/dvr/tree/master/bin/system2/classes/tv
6 камер вполне хорошо будут работать.
ну так, 10 лет опыта работы в организациях с нулевым финансированием… :)
Это жалюзи: habrastorage.org/files/414/12a/c4d/41412ac4d584437da0cf6ec0ba1c56f3.jpg
Должны были повисеть дней 5, повесили в апреле)
В этом году нервы сдали, «уйду я от них»
У меня даже где то аналог ivi умер )
www.youtube.com/channel/UCqNO2PNJYx9G5yepVEm09bg
плюс там есть настройка для кого какие oid выдавать (для public одни, для private другие)
onvif discovery не сработал у меня.
Да и как я говорил напрямую нельзя «скормить» ссылку на onvif камеры.
Мне просто попадались IP камеры где есть ссылка на onvif, но для ссылки на rtsp приходилось рыться в интернете, даже поставщик не мог сказать их.
Может в будущем вы реализуете что нибудь подобное
alpha.hstor.org/files/2f7/8e1/7f1/2f78e17f107742fb8ab445bb85149f7f.png
у меня 10.112.28.33, воткнуты в один свич, udp не режется.
А что писать то)
В сентябре новая работа будет искаться. Буду заниматься видео — что нибудь напишу, а так пока мысли только о том как себя ведет TCP при большой нагрузке (window size и etc)
В сторону SIP может быть занесет и гоняние видео по нему, но кто знает.
У меня «облако» это был Core-i5 с Proxmox на борту, 3 машины (DVR, Mysql, Web) и второй гроб FreeNAS. Для нас было «накладно» перекодировать на нашем железе, по этому искались решения как можно проще и «в лоб». 30 камер 720p держал влет с онлайн просмотром архива и детектором движения. Онлайн просмотр был страшным монстром. Иногда h264 елся, иногда тупо mjpeg отдалавли (4 кдра в секунду, что позволяло смотреть даже на nokia c5-00). Ну и тайплапсы видео за день (1 секунда = 3 минуты), что позволяло за 5-8 минут проверить работу целой толпы людей. Кто был, кто не был и кто когда пришел. Так как проект потонул, вот и описываю «опыт».
Доходило до изобретения «железяки» на openwrt, которая напрямую поток с камеры кладет на хард, который воткнут в эту «железяку». Это был любой роутер TP-link и OpenWRT прошивка. Идея была в том, чтобы через OpenWRT хоть как то стандартизировать получение потока, стопкадра и безопасности.
Можно конечно и всё это описать, но там велосипед на велосипеде.
RTCP для сохранения потока не столь важен :)
Кадры есть в SDP (SPS, PPS), для поддержки связи используется GET_PARAMETER, OSD есть в кадре. Минимум соблюден. При желании через onvif можно поставить правильное время.
Ссылка на RFC: tools.ietf.org/html/rfc3550#page-19
Камеры шлют RTCP senders report (200), мы должны слать Receiver Report (201)
До реализации RTCP не дошло, так как не было в этом надобности (точнее она была только при прошивке 1.00 у Dlink DCS-2103, на прошивке 1.20 надобность отпала)
Рекомендованный интервал между RTCP пакетами — 5 (секунд)
Задача в том, чтобы сохранить последний RTCP (200) и спустя некоторое время ответить.
github.com/Calc86/camRecorder/blob/master/src/com/net/rtp/RTCP.java
Также нужно понимать о существовании RTCP source description (202)
Каждый Source у камеры имеет уникальное число (32 бита, SSRC)
Аудио и видео это разные Source.
Алгоритмы вычисления lost и jitter можно посмотреть в приложениях RFC 3550, или вольная интерпретация тут: github.com/Calc86/camRecorder/tree/master/src/com/net/rtp/rfc — но его надо тестить.
Такого класса вполне достаточно для ответа на RTCP 200
Ну а вот что делать со всеми этими Timestamp — хрен его знает. Если пакеты потерялись, то не будем же мы нули писать в поток. По этому берем поток, отправляем в OutputStream и всё.
Архаичное решение как «сервер» нужен для архаичных камер, которые имеют совершенно разный h264 кодек с совершенно разными звуковыми дорожками и хочешь-не хочешь для вещания в web нужно всё декодировать.
А статьи про видео наблюдение обычно заканчиваются комментариями «Откройте для себя Ivideon».
Тема от IT обособлена по одной причине. Проще поставить коробку (DVR) и воткнуть туда камеры. Это обкатанный вариант, но не совсем бюджетный. Рынок довольно насыщенный и забит системами безопасности. И «пока оно работает» люди не особо хотят что то трогать.
А статей мало потому что есть либо zoneminder, либо скриптовый монстр на VLC (У меня такой есть), либо вы :)
Пока все производители камер не перейдут на «православный» web h264 ситуация особо не изменится. А как показывает практика и общение с разными организациями и безопасниками лучше иметь обособленную медиа среду для безопасности, нежели гнать по общему lan с его узлами. Сразу скажу что общение происходило в тех организациях, которые экономят на всём и штат в них до 20 человек. Т.е. им дешевле обслуживать путь Камера-провод-DVR, нежели всю инфраструктуру lan (которая строится на каком нибудь asus rt-n66)
Опыт используемый в этой статье был взят из проекта который «не выстрелил».
А сервер нужен для стандартизации потоков с камер. После этого можно и в web, и в файлы, и в космос.
ru.lostpedia.wikia.com/wiki/%D0%A7%D0%B8%D1%81%D0%BB%D0%B0
Железо ни когда не купят, ну либо спустя год после заказа этого железа (в идеале)