Comments 77
Спасибо, как раз искал в чем причина.
Тоже долго думал в чем может быть проблема, искал узкое место и грешил на старые alight telesyn, кстати проблема не только на дешевых китайских камерах, была замечена даже на не которых d-link, хотя может их тоже можно отнести к оным)
Тоже долго думал в чем может быть проблема, искал узкое место и грешил на старые alight telesyn, кстати проблема не только на дешевых китайских камерах, была замечена даже на не которых d-link, хотя может их тоже можно отнести к оным)
очень похоже на то, что код фидера у них откуда-то из example тупо скопирован, а обработок ошибок не дописано.
посмотрим, что ответят техники — прямого выхода на разработчиков у меня нет, мучаюсь через тройной прокси из продавца-его техников-техников дальше…
а самое главное — я не считаю, что проблема в камере — проблема в софте. если выгребать всё из потока — сбоев нет.
самое смешное — «родной» китайский софт обслуживания камер всё выкачивает без проблем.
а крутые платные софтины — запинаются. но это тема отдельного поста, который в разработке.
посмотрим, что ответят техники — прямого выхода на разработчиков у меня нет, мучаюсь через тройной прокси из продавца-его техников-техников дальше…
а самое главное — я не считаю, что проблема в камере — проблема в софте. если выгребать всё из потока — сбоев нет.
самое смешное — «родной» китайский софт обслуживания камер всё выкачивает без проблем.
а крутые платные софтины — запинаются. но это тема отдельного поста, который в разработке.
Антон, есть ли у вас возможность проверить то же самое с Ivideon? Если проблемы точно такие же, то будем срочно исправлять. На всех китайских камерах, которые у нас есть — все работает. Мы сталкивались с вариантами вида: «Content-Length5323» и прочее.
Имеете ввиду запустить софт ваш, или найти вашу камеру?
Так, поставил Ivideon сервер, пытаюсьподцепить камеру.
Выбираю «Другой производитель», ожидая что это и есть ONVIF подключение — фиг там. урл при этом /axis-media/ и, разумеется, не подключается.
Просто ONVIF камер в списке не вижу.
Выставил тип «Airlink101» — подцепило её.
Начал добавлять вторую камеру — софтина молча сдохла. Сейчас еще раз пытался её добавить — стабильно помирает софтина при попытке просмотреть превью второй камеры. Вероятно дело в том, что на первой сейчас FullHD разрешение (1920*1080), а на второй 3MP (2048*1536).
Вот при попытке посмотреть превью 3MP камеры — Ivideon сервер помирает.
Выбираю «Другой производитель», ожидая что это и есть ONVIF подключение — фиг там. урл при этом /axis-media/ и, разумеется, не подключается.
Просто ONVIF камер в списке не вижу.
Выставил тип «Airlink101» — подцепило её.
Начал добавлять вторую камеру — софтина молча сдохла. Сейчас еще раз пытался её добавить — стабильно помирает софтина при попытке просмотреть превью второй камеры. Вероятно дело в том, что на первой сейчас FullHD разрешение (1920*1080), а на второй 3MP (2048*1536).
Вот при попытке посмотреть превью 3MP камеры — Ivideon сервер помирает.
Так, походу таки обрывается.
Постоянно перезапускается проигрывание.
Я оставлю пока запущенный сервер с одной камерой (с которой не падает)
Сервер «G86P4», аккаунт datacompboy.
Поглядите. Если надо какую еще информацию — предоставлю.
Постоянно перезапускается проигрывание.
Я оставлю пока запущенный сервер с одной камерой (с которой не падает)
Сервер «G86P4», аккаунт datacompboy.
Поглядите. Если надо какую еще информацию — предоставлю.
Спасибо большое! Насколько я понял, есть две проблемы.
1. Та что вы описали в статье.
2. Превью с камеры 3MP.
Есть ли у вас возможность выслать логи нам на support@ivideon.ru. При этом сначала повторить 2-. проблему, а затем отключить камеру и дождаться первой. В теле письма можно просто дать ссылку на Хабр. Постараемся поправить.
1. Та что вы описали в статье.
2. Превью с камеры 3MP.
Есть ли у вас возможность выслать логи нам на support@ivideon.ru. При этом сначала повторить 2-. проблему, а затем отключить камеру и дождаться первой. В теле письма можно просто дать ссылку на Хабр. Постараемся поправить.
письмо ушло.
правда с крешем плохо — без inspectr.exe крешлог только адрес и код и больше ничего
а с inspectr.exe, которым я обычно креши пишу на винде, он ругается на таймаут Debug Event при креше вашей софтины.
но если очень надо — поставлю отладчик, сниму креш им.
правда с крешем плохо — без inspectr.exe крешлог только адрес и код и больше ничего
а с inspectr.exe, которым я обычно креши пишу на винде, он ругается на таймаут Debug Event при креше вашей софтины.
но если очень надо — поставлю отладчик, сниму креш им.
Странно, что вы эту проблему не видели до этого. Она происходит абсолютно со всеми китайскими камерами, когда работаешь с ними по TCP.
Наш основной продукт это камеры, где наше ПО стоит на борту. Мы тщательно отлаживаем такие камеры, сообщаем о найденных проблемах их разработчику, иногда полностью переписываем весь софт на борту. Ivideon Server для Linux и Windows дает возможность подключить к нашему облаку существующие камеры. Но у нас нет возможности протестировать все имеющиеся на рынке камеры. Поэтому собираем и тщательно анализируем обратную связь от наших пользователей, чтобы сделать наш продукт лучше.
Судя по поведения — баг#2 убрали, баг#1 еще на месте.
как-либо у вас выключить ведение локального архива возможно?
не по глазам мне, хочу проверить теорию, что отвал связан именно с записью на диск.
не по глазам мне, хочу проверить теорию, что отвал связан именно с записью на диск.
Да. Можно. Нажмите на кнопку «Настройки» или «Settings» и уберите галочку «Archive».
ага, выключил. воспроизводится :(
скинул вам логи.
скинул вам логи.
Посмотрели логи. Разрыв соединения связан с тем, что от камеры приходят совершенно «левые» данные с точки зрения видео и аудио. По крайней мере плеер не может их воспроизвести.
Вы написали выше, что штатные средства показывают отлично. А они точно работают по RTSP? Дело в том, что часто у китайцев RTSP есть для галочки и на самом деле толком не работает. А собственные приложения у них работают по собственному протоколу.
А у вас есть Скайп? Можно в личку.
Вы написали выше, что штатные средства показывают отлично. А они точно работают по RTSP? Дело в том, что часто у китайцев RTSP есть для галочки и на самом деле толком не работает. А собственные приложения у них работают по собственному протоколу.
А у вас есть Скайп? Можно в личку.
крешнулся сервер еще дважды. мне это начинает нравиться :D
Интересна ваша методика написания поста- Вы, похоже, пишите его прямо в процессе поиска бага.
а можно модель D-Link'а?
Именно так выглядят управдомы в XXI веке.
Гибсон? Нильсен? Винж? Не совсем, но явно потянуло киберпанком.
Гибсон? Нильсен? Винж? Не совсем, но явно потянуло киберпанком.
Короче, наркоман напрягся.
> взорвать АЭС
Вы бы приписали, что «шутка», а то, знаете, есть такие «борцы с плохишами», вообще без чувства юмора которые… весь сайт которым не слабо заблочить за единую юморинку.
Вы бы приписали, что «шутка», а то, знаете, есть такие «борцы с плохишами», вообще без чувства юмора которые… весь сайт которым не слабо заблочить за единую юморинку.
Настоящий тоталитаризм начинается не с нелигитимной власти или фальсификаций на выборах. Он начинается с самоцензуры, которую вы и предлагаете топикастеру.
Так что все ок, АЭС взорвут только после распыления зарина в метро.
Так что все ок, АЭС взорвут только после распыления зарина в метро.
Теперь мне кажется, не только неулыбчивые «борцы с плохишами» не понимают шуток. В этом смысле интернет не только дает, но и отнимает: постоянно замечаю, что погруженные в Сеть люди юмора, если смайлик не проставлен, в упор не замечают.
Ок, пусть будет АЭС, я не против, если после зарина-то. Смайлик.
Ок, пусть будет АЭС, я не против, если после зарина-то. Смайлик.
После прочтения возник вопрос в пустоту: а есть ли такого рода сетевые камеры с открытым кодом? Можно, конечно, сочинить что-то на базе RPI, но хотелось бы что-то более компактное и экономичное.
ну как, с открытым кодом. если вы закупаете модули камеры (DSP точнее их), вам в нагрузку sdk с примером выпишут. дописывайте на здоровье в исходниках.
А готовых open hardware тушек с open software прошивками — я не видел.
А готовых open hardware тушек с open software прошивками — я не видел.
на данный момент в том виде, в каком вы хотите — нет, не существует. Даже болванки для камер продают с готовым стриминговым софтом, написанным плохо.
Тоже недавно задумался этим вопросом — хотел поставить камеру в подъезд. После осмотра доступных вариантов и достоинств/недостатков (Там поток не вытащишь, т.е. на андроиде нормально не посмотреть, там он рвется, там еще глюки какие-то) пришел к выводу, что мне возможно хватит 320x240 / 5 кадров с обычной веб-камеры, висящих на каком-либо Tp-Link TL-MR3020 и передающих через mjpeg streamer или что-то подобное. Доступнее для обычного пользователя (не оптового заказчика модулей и т.д.) судя по всему не найти :(
Присоединяюсь к вопросу, если кто-то знает варианты получше
Присоединяюсь к вопросу, если кто-то знает варианты получше
Дык! Правда, я ещё не нашёл как ONVIF сервер реализовать, пока только Виртурилка как обычная RTSP камера задействована, в HD разрешении. Если кто подскажет где посмотреть примеры ONVIF сервера (не клиента!) — киньте ссылочку, плиз. А то сервы есть, подключаются без проблем, хочу стандартный PTZ сбацать (пока без Z, правда).
Узнал из статьи, что RTP может работать поверх TCP, и этим даже кто-то пользуется…
не все DVR работают под QNX, поэтому возможны лаги на записывающей стороне. RTP/TCP позволяет без проблем писать всё без потерь используя Windows в качестве OS сервера…
А баг прост: send(somedata, somelen) возвращает <0 в случае ошибки, число байт, если отработало. И любмая ошибка всех начинающих сетевых разработчиков: send(somedata, somelen) может вернуть что-то МЕНЬШЕ, чем somelen — в буфер не влезло.
Насколько я помню, это назывется partial write, и вживую я его еще ни разу в жизни не видел. Подскажите старику, на каком сетевом стеке и с какими настройками сокета это можно воспроизвести?
с маленькими буферами и большим потоком данных. Небольшое колебание скорости прокачки данных и всё, приехали.
Я в свое время пытался подыграть на разных операционках, с разными вариантами. Например, send(мегабайт) на медленном канале и в какой-то момен времени сервер прекращал принммать. На блокирующих сокетах send() всегда блокировал до появления возможности отправить. На нелокирующих — всега либо брал на отслку весь буфер либо ничего. Вы лично видели как оно слеучается «с маленькими буферами и большим потоком данных» — или это предположение?
То есть send(мегабайт) вообще ничего не отправлял на сервер в неблокирующем режиме? Не верю.
Если window уползло в 0 и буфера забиты, то send(мегабайт) в неблокирущем режиме скажет WSAWOULDBLOCK на Windows и EWOULDBLOCK на OSX/*nix. Но я не священник, я инженер, вопросы веры в айти меня не очень интересуют. Мне очень интересно подыграть ситуацию с partial write — возможно, я не так и не там проверял.
Поставьте на сервере буфер приема в 4 килобайта, на клиенте — буфер передачи в 4 килобайта, и попробуйте отправить 12 килобайт одним вызовом.
В неблокирующем режиме обязана произойти эта самая операция partial write, независимо от платформы и используемой библиотеки.
В неблокирующем режиме обязана произойти эта самая операция partial write, независимо от платформы и используемой библиотеки.
Поставьте на сервере буфер приема в 4 килобайта, на клиенте — буфер передачи в 4 килобайта, и попробуйте отправить 12 килобайт одним вызовом. В неблокирующем режиме обязана произойти эта самая операция partial write, независимо от платформы и используемой библиотеки.
Почему обязана, если не секрет? Есть еще как минимум 64 килобайт окна, физический буфер сетевой карты, буфер драйвера сетевой карты, который неконтроллируем снаружи.
Потому что перечисленные вами буферы — глобальные, одни на все сокеты. Информация, которая относится к конкретному сокету, в котором она может (потенциально) быть забыта сервером на полчаса, не будет храниться в этих буферах.
64х же килобайт окна просто не будет. Будут 4 килобайта окна приема на сервере, потому что окно приема — это и есть оставшееся место в приемном буфере.
64х же килобайт окна просто не будет. Будут 4 килобайта окна приема на сервере, потому что окно приема — это и есть оставшееся место в приемном буфере.
В целом согласен. Увы, практика показывает обратно. Вот написанный за пару минут пример, который я запустил на доступных мне машинах. Везде отправило 12 килобайт :(. Где я ошибся?
import sys, socket, time
PORT = 1234
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_SNDBUF, 4 * 1024)
s.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 4 * 1024)
if 'server' == sys.argv[1]:
s.bind(('', PORT))
s.listen(1)
conn, _ = s.accept()
print("connected")
time.sleep(-1)
if 'client' == sys.argv[1]:
s.connect((sys.argv[2], PORT))
s.setblocking(0)
ret = s.send('*' * 12 * 1024)
print("send() returned {0}".format(ret))
Забавно. Похоже, что windows игнорирует размеры буферов и пытается выделить память динамически при вызове send.
А вот на linux все получилось сразу же:
А вот на linux все получилось сразу же:
send() returned 6144Точную модель линукса, пожалуйста?
datacompboy@nuuzerpogodible:~/work/self/chinacambug$ uname -a
Linux nuuzerpogodible.river-net 3.11-2-amd64 #1 SMP Debian 3.11.8-1 (2013-11-13) x86_64 GNU/Linux
datacompboy@nuuzerpogodible:~/work/self/chinacambug$ cat /etc/*release
PRETTY_NAME=«Debian GNU/Linux jessie/sid»
NAME=«Debian GNU/Linux»
ID=debian
ANSI_COLOR=«1;31»
HOME_URL=«www.debian.org/»
SUPPORT_URL=«www.debian.org/support/»
BUG_REPORT_URL=«bugs.debian.org/»
Linux nuuzerpogodible.river-net 3.11-2-amd64 #1 SMP Debian 3.11.8-1 (2013-11-13) x86_64 GNU/Linux
datacompboy@nuuzerpogodible:~/work/self/chinacambug$ cat /etc/*release
PRETTY_NAME=«Debian GNU/Linux jessie/sid»
NAME=«Debian GNU/Linux»
ID=debian
ANSI_COLOR=«1;31»
HOME_URL=«www.debian.org/»
SUPPORT_URL=«www.debian.org/support/»
BUG_REPORT_URL=«bugs.debian.org/»
debian stable со стандартными сетевыми настройками, разве что карточек сетевых многовато и используется как роутер
root@network-server:~# uname -a
Linux network-server 3.2.0-4-686-pae #1 SMP Debian 3.2.51-1 i686 GNU/Linux
root@network-server:~# cat /etc/*release
PRETTY_NAME="Debian GNU/Linux 7 (wheezy)"
NAME="Debian GNU/Linux"
VERSION_ID="7"
VERSION="7 (wheezy)"
ID=debian
ANSI_COLOR="1;31"
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support/"
BUG_REPORT_URL="http://bugs.debian.org/"
чуть-чуть модифицируем:
И запускаем на одной машине:
if 'server' == sys.argv[1]:
s.bind(('', PORT))
s.listen(1)
conn, _ = s.accept()
print("connected")
time.sleep(100)
if 'client' == sys.argv[1]:
s.connect((sys.argv[2], PORT))
s.setblocking(0)
ret = 1707
while True:
ret = s.send('*' * 1707)
print ret
И запускаем на одной машине:
datacompboy@nuuzerpogodible:~/work/self/chinacambug$ python tester.py client localhost
1707
1707
1707
1707
682
Traceback (most recent call last):
File "tester.py", line 17, in <module>
ret = s.send('*' * 1707)
socket.error: [Errno 11] Resource temporarily unavailable
я постараюсь PoC сервера накидать сегодня как время будет.
Кстати, а есть такие купольные камеры с приводом, чтобы можно было удаленно управлять?
Да. За PTZ примерно +100$ наценка
Странно, я покупал VGA камеру с PTZ всего за 50 баксов.
Например Wanscam работает уже больше года у меня.
Например Wanscam работает уже больше года у меня.
А все-таки, почему в приемнике заканчивается буфер, софтина из него читает настолько редко?
Можно увеличить размер буфера на приемнике.
Если же вы вообще не успеваете обрабатывать поступающие данные, придется часть их отбрасывать: в tcp это сделать будет сложно.
Какой packet loss до камер, как у вас сделана сеть? может стоит настроить QoS?
Каждый выпавший из потока пакет замораживает последующие данные в буфере, поэтому приемный буфер нужно настроить больше чем в величину емкости канала.
Можно увеличить размер буфера на приемнике.
Если же вы вообще не успеваете обрабатывать поступающие данные, придется часть их отбрасывать: в tcp это сделать будет сложно.
Какой packet loss до камер, как у вас сделана сеть? может стоит настроить QoS?
Каждый выпавший из потока пакет замораживает последующие данные в буфере, поэтому приемный буфер нужно настроить больше чем в величину емкости канала.
> А все-таки, почему в приемнике заканчивается буфер, софтина из него читает настолько редко?
Вот это самый главный вопрос, ответ на который, похоже, искать только по запаху — я пока найти не могу, но занят этим.
саппорт софтин на эти вопросы реагируют только по принципу «наша хата с краю»
> Если же вы вообще не успеваете обрабатывать поступающие данные, придется часть их отбрасывать:
> в tcp это сделать будет сложно.
Не вижу никаких сложностей — RTP пакеты идут весьма помеченными, и часть из них вполне можно выкидывать.
> Какой packet loss до камер,
0%
> как у вас сделана сеть?
Кинуты самые обычные UTP5 кабеля. Все свичи гигабит.
> может стоит настроить QoS?
свичи простые, но по сети кроме камер никто не бегает; так что QoS тут ни при чем.
Вот это самый главный вопрос, ответ на который, похоже, искать только по запаху — я пока найти не могу, но занят этим.
саппорт софтин на эти вопросы реагируют только по принципу «наша хата с краю»
> Если же вы вообще не успеваете обрабатывать поступающие данные, придется часть их отбрасывать:
> в tcp это сделать будет сложно.
Не вижу никаких сложностей — RTP пакеты идут весьма помеченными, и часть из них вполне можно выкидывать.
> Какой packet loss до камер,
0%
> как у вас сделана сеть?
Кинуты самые обычные UTP5 кабеля. Все свичи гигабит.
> может стоит настроить QoS?
свичи простые, но по сети кроме камер никто не бегает; так что QoS тут ни при чем.
Антон,
Мы хотели бы обратить внимание на то, что программное обеспечение, идущее в комплекте с камерой, в большинстве случаев подключается не по стандарту RTSP, а по протоколу собственной разработки, надстроенному над протоколом TCP. Вы можете убедиться в этом, используя сниффер. Это объясняет тот факт, что вы не замечали никаких проблем в «родной» программе. К сожалению, поддержка RTSP у китайских производителей оставляет желать лучшего и сделана, чтобы соответствовать известным стандартам ONVIF и PSIA. Из-за этого часто возникают проблемы с обрывами, причем причины могут быть самые разные.
Мы рекомендуем вам сделать следующее:
1) Изменить путь подключения к камере: :554/user=admin&password=&channel=1&stream=0.sdp?
Здесь специально опущен параметр --rtp-caching=100, который, по нашему предположению, отвечает за буферизацию rtp пакетов со стороны камеры. Чем меньше этот параметр, тем меньше будет отставать видео от реального времени, но тем более стабильным должно быть сетевое соединение. Можно попробовать этот параметр оставить, но сделать его в 5-10 раз больше.
2) Запросить последнюю прошивку у поставщика, иногда это сразу же решает проблему с обрывами.
Нам также хотелось бы узнать, как часто происходят обрывы с данной камерой? Есть ли закономерность во времени?
Мы хотели бы обратить внимание на то, что программное обеспечение, идущее в комплекте с камерой, в большинстве случаев подключается не по стандарту RTSP, а по протоколу собственной разработки, надстроенному над протоколом TCP. Вы можете убедиться в этом, используя сниффер. Это объясняет тот факт, что вы не замечали никаких проблем в «родной» программе. К сожалению, поддержка RTSP у китайских производителей оставляет желать лучшего и сделана, чтобы соответствовать известным стандартам ONVIF и PSIA. Из-за этого часто возникают проблемы с обрывами, причем причины могут быть самые разные.
Мы рекомендуем вам сделать следующее:
1) Изменить путь подключения к камере: :554/user=admin&password=&channel=1&stream=0.sdp?
Здесь специально опущен параметр --rtp-caching=100, который, по нашему предположению, отвечает за буферизацию rtp пакетов со стороны камеры. Чем меньше этот параметр, тем меньше будет отставать видео от реального времени, но тем более стабильным должно быть сетевое соединение. Можно попробовать этот параметр оставить, но сделать его в 5-10 раз больше.
2) Запросить последнюю прошивку у поставщика, иногда это сразу же решает проблему с обрывами.
Нам также хотелось бы узнать, как часто происходят обрывы с данной камерой? Есть ли закономерность во времени?
Добрый день!
Все камеры, которые сейчас у меня стоят, все работают именно по RTSP в браузере — они ставят свой плагин (что доставляет неудобств в настройке). Wireshark'ом я снимал трейс.
У той камеры, которой я ел вам мозг изначально, rtp-caching был выкинут первым делом, она подключена без него, именно для отсутствия отставания видео. (Что, впрочем, некоторым другим софтинам не мешало показывать видео с задержкой в 2-3 секунды, что как по мне, так не приемлемо для системы видеонаблюдения).
Все прошивки обновлены до последних — у одного типа камер от января прошивка, у другого от декабря.
Сейчас Macroscop выключен, да и когда включен был — визуально он никак не сообщал об обрыве.
Активно сейчас используется софт AxxonNext — в нем эта камера практически не отваливается.
Остальные 4 камеры имеют привычку отваливаться зачастую синхронно, но не всегда — иногда отваливаются не все, иногда только одна.
Частота отвала — от 3 минут до часа. Закономерности не нашел.
В принципе, мне удалось поймать свал без sleep() воткнув запись на диск f.write(rtppack) в том же потоке, вызывая write для каждого RTP пакета.
причем я поймал этот свал на ноутбуке, где пишу на SSD (так что жаловаться на нехватку IO нельзя).
Если включить буферизацию и писать на диск блоками по 128k — отвалов нет.
Я в задумчивости.
Все камеры, которые сейчас у меня стоят, все работают именно по RTSP в браузере — они ставят свой плагин (что доставляет неудобств в настройке). Wireshark'ом я снимал трейс.
У той камеры, которой я ел вам мозг изначально, rtp-caching был выкинут первым делом, она подключена без него, именно для отсутствия отставания видео. (Что, впрочем, некоторым другим софтинам не мешало показывать видео с задержкой в 2-3 секунды, что как по мне, так не приемлемо для системы видеонаблюдения).
Все прошивки обновлены до последних — у одного типа камер от января прошивка, у другого от декабря.
Сейчас Macroscop выключен, да и когда включен был — визуально он никак не сообщал об обрыве.
Активно сейчас используется софт AxxonNext — в нем эта камера практически не отваливается.
Остальные 4 камеры имеют привычку отваливаться зачастую синхронно, но не всегда — иногда отваливаются не все, иногда только одна.
Частота отвала — от 3 минут до часа. Закономерности не нашел.
В принципе, мне удалось поймать свал без sleep() воткнув запись на диск f.write(rtppack) в том же потоке, вызывая write для каждого RTP пакета.
причем я поймал этот свал на ноутбуке, где пишу на SSD (так что жаловаться на нехватку IO нельзя).
Если включить буферизацию и писать на диск блоками по 128k — отвалов нет.
Я в задумчивости.
Кстати, хочу сказать спасибо за вашу поддержку ONVIF: все камеры спокойно цепляются по ONVIF, причем цепляются оба потока — и основной и низкого разрешения.
У AxxonNext ловится только один (причем не всегда большой); ONVIF с поддержкой двух потоков просто не работает; и на всё один ответ — «эти камеры официально не поддерживаются» :D
У AxxonNext ловится только один (причем не всегда большой); ONVIF с поддержкой двух потоков просто не работает; и на всё один ответ — «эти камеры официально не поддерживаются» :D
Спасибо про вопрос про закономерность по времени. Запустил свой скрипт на чисто слив RTSP, отключив все какие бы то ни было задержки и задрав буфера. Соединение закрывается со стороны камеры спустя ровно 180 секунд.
Вот этого я никак понять уже не могу… Необходимость OPTIONS периодически нужна или нет? Надо еще тестировать-с.
Вот этого я никак понять уже не могу… Необходимость OPTIONS периодически нужна или нет? Надо еще тестировать-с.
добавил периодический пинг в канале через GET_PARAMETER. 3хминутного обрыва нет, так что отбой тревоги.
еще раз посмотрел на архив записей — абсолютно никаких тенденций по времени.
то рвётся через полторы минуты, то через 7 минут.
и очень часто синхронно на нескольких камерах — но это как раз легко объясняется каким-либо лагом компа.
еще раз посмотрел на архив записей — абсолютно никаких тенденций по времени.
то рвётся через полторы минуты, то через 7 минут.
и очень часто синхронно на нескольких камерах — но это как раз легко объясняется каким-либо лагом компа.
Это незадокументированная фича
Sign up to leave a comment.
Китайские видеокамеры и TCP: баг или фича?