По поводу аутентификации на ИП-камере

[Anthi]

А есть ли какой-нибудь способ забирать RTSP с камеры, которая требует аутентификации?
Ну, то есть что-то типа http://server.tld/index.html?id=rtsp://ip.camera&user=user&password=notsecret

 

[Max]

Да, для этого нужно прописать логин и пароль в конфиге rtsp.auth и перезапустить сервер.
Если в вашей версии этого конфига нет, попробуйте последнюю доступную здесь. Или установите WCS4 Beta - там точно есть поддержка RTSP аутентификации.

 

[Max]

Кстати в WCS4 были исправлены некоторые ошибки, относящиеся к RTSP, поэтому лучше использовать ее.

 

[Anthi]

поставил WCS4
Забирать получается, наблюдаю между ИП камерой и сервером устойчивый трафик, похожий на rtsp, но вижу черный молчащий квадрат
в логах клиента имеет место быть

12:27:19,743 ERROR  RtpVideoPlayer - New I/O  worker #41 Codec not found; pt - 8; current pt - 96
java.lang.IllegalArgumentException: Codec not found; pt - 8; current pt - 96

На камере выставлен кодек H.264 звук G.711A

 

[Max]

Последняя версия WCS4 на текущий момент:
Client: 566
Server: 1048
Проверьте, что именно эти версии установлены.
Если все еще черный экран, пришлите нам на почту логи (server_logs/flashphoner.log) и дамп трафика tcpdump -s 4096 -w log.pcap.
Или лучше просто скиньте URL камеры и доступ к ней если есть такая возможность. Проверим.

 

[Anthi]

Версии последние (ещё бы - час назад переставлял )
Логи скинул.

 

[Max]

В логах явные ошибки. Систему 64-бинтую используете? Что выдает uname -a?
Сервер должен быть Linux x86_64.

 

[Anthi]

Система 32 бита, сервер когда ставился - правильно определился как 32битный

Linux ext-gw-backup 3.1.4 #3 SMP Mon Dec 12 17:15:24 EET 2011 i686 Intel(R) Core(TM)2 Quad CPU  Q6600  @ 2.40GHz GenuineIntel GNU/Linux

 

[Alex]

В данный момент сервер работает корректно только на 64-битной системе, поэтому в требованиях везде пишем Linux x86_64.
В вашем случае можно поднять виртуалку с Linux x86_64, тогда должно заработать.

 

[Anthi]

Что-то я не пойму...
Связка клиент-сервер-камера превосходно отрабатывает, если поток берется с моей локальной вебкамеры и транслируется другим клиентам без проблем, но светит "чёрный квадрат" если поток берется по RTSP а проблема кроется в разрядности?
ЗЫ: На серве 4Г ОЗУ физикой и достаточно плотная нагрузка, куда ж я туда засуну виртуалку, да еще и 64 бита...

 

[Max]

Да, проблема в разрядности. Когда вы тестируете WebRTC-потоки между браузерами, все работает потому что у всех одинаковые кодеки и не требуется транскодирования.
В случае RTSP подключается транскодинг H.264 (IP cam) -> VP8 (WebRTC). В вашем случае не подключается, т.к. нативные библиотеки транскодинга скомпилированы под x86_64 и не работают под 32 бит, отсюда и черный экран.

Кстати, если на сервере плотная загрузка, лучше RTSP оттуда не забирать, т.к. транскодинг даст сильную доп. нагрузку на CPU.

 

[Anthi]

Я понял... но понимание мне помогло не сильно
Нашел я внутри локалки 64-битный серв

Linux ext-web 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

CentOS release 6.5 (Final)
Поставил на него WCS-4.0.1048. Настроил. Перенес на него лицензию.
Перенастроил на клиенте адреса в flashphoner.xml указав на новый серв
И получаю тот же самый чёрный молчаливый квадрат, но теперь без единого ERROR в логах WCS

 

[Max]

Лог с дампом еще раз на почту отправьте

 

[Anthi]

Отправил

 

[Max]

Проверьте первым делом firewall. Пакеты приходят на ваш сервер (113), но firewall их может сбрасывать.
Убедитесь что порты 31000-32000 открыты.

Попробуйте в flashphoner.properties выставить в

enable_candidate_harvester=false

добавьте в log4j.properties

log4j.logger._com.flashphoner.media.rtp.RtpVideoPlayer=DEBUG

и перезагрузите WCS-сервер.
Если не поможет,
пришлите логи с дампом снова.

 

[Anthi]

Фаервол таки был закрыт. Открыл, не помогло
Логи отправил.

 

[Max]

Логи старые. Отправьте новые.
И еще попробуйте в flashphoner.properties
ip=
прописать внешний IP адрес сервера и тестировать с внешней сети.

 

[Anthi]

Переотправил. Простите, запутался уже в логах
Схема такая:
browser-client<->client-WCS-javascript-API-1.0.56<->WCS-4.0.1048<->IP-camera-RTSP

т.е. тестирую как раз через инет
между браузером и клиентомWCS - инет, между клиентомWCS-серверомWCS-ИПкамерой - локалка
У клиентаWCS в настройках указан серверWCS, у сервераWCS оба ИП - локальные, т.к. он через NAT
Шлюз с НАТом для локалки в этой цепочке не указан, т.к. это еще один хост.
Я правильно понимаю, что мне нужно пронатить WCS-4.0.1048 и в его настройках поставить внешним адресом ИП маршрутизатора с NAT?

 

[Max]

По логам видно, что браузерное подключение приходит с той же локальной сети 192.168, так что выглядит что у вас все внутри этой сети и браузер и WCS и IP камера.
Если вы настроили DEBUG логи (log4j.logger._com.flashphoner.media.rtp.RtpVideoPlayer=DEBUG), то в логи должно быть много информации, а ее нет.
Самый простой способ, это пробросить RTSP порт на вашу IP-камеру и нам попробовать воспроизвести видео из-за NAT с внешнего WCS-сервера. Если картинка появится, то проблема внутри вашей сети.

Я правильно понимаю, что мне нужно пронатить WCS-4.0.1048 и в его настройках поставить внешним адресом ИП маршрутизатора с NAT?

Да правильно, но судя по логам вы цепляетесь с локальной сети.

 

[Anthi]

Да, может это и есть ключ к решению проблемы... Потому что та машина, с которой проверяется соединение (моя воркстейшен) находится еще за одним НАТом, а сервера, на которых настроен НАТ соединены между собой не только через инет, а еще и туннелем с внутренней адресацией. Внутренняя VPN объединяет несколько городов и много локалок. С адресами, включающими 192.168.0.0/16 10.0.0.0/8 и 172.16.0.0/12
Т.е. вполне возможно что соединение моей воркстейшен с камерой ныряет в туннель, вместо того, чтобы идти снаружи.
Хотя, с другой стороны, внутриVPNовские соединения не должны нигде и ничем резаться...
То есть сейчас я пробую пронатить WCS4 и указать в его настройках внешний ИП...

Кстати, DEBUG в логах я таки вписывал и WCS4 после него рестартовал...