Цитата: Вот мне как раз это интересно, как определить ухудшение связи?
Сделал у себя так: При подключении к серверу определяем пропускную способность сети путем скачивания файла с сервера на скорость. Если она выше минимально допустимой, тут же фиксируем уровень вайфай соединения. Далее каждую секунду проверяем уровень вайфая и если он ниже начального, производим сопоставление с пропускной способностью (её только один раз в начале проверяем, чтобы не забивать трафик) и если она ниже минимально допустимой - отключаемся от сервера.
Цитата: Кстати, надо будет добавить алерт какой-нибудь на экране для индикации ухудшения коннекта.
Вот мне как раз это интересно, как определить ухудшение связи? У меня такая же телега, только на ноде. Когда я заежжаю в слабую зону связи, она перестает реагировать на команды или реагирует с большой задержкой. Если это дело проверять дополнительной отсылкой пакетов, то будет забиватся канал. Должен же быть какой нибудь правильный способ сделать это.
Цитата: Только вот не надо эти девайсы "роботами" называть :-)
Почему? Как по мне это вполне себе робот телеприсутствия, ну или, по крайней мере, прототип. Есть же задачи, которые он выполняет самостоятельно, пусть небольшие, но есть.
А как проверяете ширину канала? И есть ли какая-нибудь защита, если пропускная способность ниже необходимой? Например, подали команду на робота - вперед и заехали в место, где нет связи, что тогда?
Вообщем, оно ресамплит, но слать с виртурилки частотой 8khz не умеет нормально. Это касается не только alaw, но и других кодеков. Пока остановился на opus с минимальным качеством. А там придется конвертер писать скорее всего.
У меня динамический ip на виртурилке. Написал простой bash скрипт, который определяет свой ip с помощью wpa_cli и выводит espeak'ом или google воисом на динамик.
Спасибо. Пересобрал, залил. Уже шлет нормально, но сама виртурилка проигрывает плохо, ужасно:( Не подходит такой вариант. Хм... че ж оно не ресамплит...?
2 Gol: А не подскажете еще, какими командами собираете? Пробуюу так (предварительно включив в .config опцию SND_DM365_VOICE_CODEC_8KHZ): cd kernel make oldconfig Не идет... И еще такой вопрос - при сборке, все остальное будет нормально работать?
2 Gol: Спасибо, opus поставился. Нужно еще где нибудь вот эту либу взять к гстримеру: libgstopus.so Цитата: Вроде вот так ресемплить надо audioconvert ! audioresample ! 'audio/x-raw-int,rate=8000,width=16,channels=1'
Я так и делал, пробовал и другие варианты. Уже и на форуме гстримера спрашивал... Он вроде ресемплит и показывает, что 8000 частота, но на принимающей стороне все равно нужно 16000 указывать, иначе медленно проигрывает.
По смене опции FS - это пересобирать надо или где нибудь на виртурилке можно заменить?
<strong>2 Gol:</strong> А как отдельно opus собрать? Пробовал так: cd /opt/virt2real-sdk/fs sudo make opus-xpkg
Ругается: checking for arm-buildroot-linux-gnueabi-gcc... /opt/virt2real-sdk/fs/output/host/usr/bin/arm-none-linux-gnueabi-gcc checking whether the C compiler works... no configure: error: in `/opt/virt2real-sdk/fs/output/build/opus-1.0.2': configure: error: C compiler cannot create executables See `config.log' for more details make: *** [/opt/virt2real-sdk/fs/output/build/opus-1.0.2/.stamp_configured] Error 77
2 Gol: Средствами gstreamer так и не удалось понизить частоту:( Как его назад отпатчить до 8kHz?:) Блин столько прошел уже, а тут на такой мелочи застряг:/
Есть еще один вариант по WebRTC - использовать OpenWebRtc от Ericsson. Они недавно поставили его на Raspberry pi. Надеюсь, скоро выложат доку какую нибуть, как это сделать. Можно будет с виртурилкой попробовать.
Крутяк. Немного оттюнил цепочку, никаких проблем уже не наблюдаю, за исключением лагов плагина, когда темно. Звук тоже пошел, но 16кГц. В итоге он замедленный в 2 раза, т.к. вебу нужно 8кГц. Есть возможность гстримером понизить его до 8 на стороне виртурилки? Пробовал так: gst-launch alsasrc ! audioconvert ! audio/x-raw-int,channels=1,depth=16,width=16,rate=8000 ! alawenc ! rtppcmapay ! udpsink host=192.168.1.16 port=3001 Шлет 16.Если так: gst-launch alsasrc ! audioconvert ! audio/x-raw-int,channels=1,depth=8,width=8,rate=8000 ! alawenc ! rtppcmapay ! udpsink host=192.168.1.16 port=3001 То ругается: WARNING: erroneous pipeline: could not link audioconvert0 to alawenc0
2 Gol: Отписался. По темноте - да, в том то и дело, что при обычном все хорошо. И вообще этот плагин очень уж капризный. Еле подобрал цепочку на v2r, с которой он более менее нормально работает. Параметр idrinterval должен быть всегда 1, иначе задержка видео постоянно увеличивается в арифметической прогрессии. Также, если поставить слишком высокий или слишком низкий targetbitrate, получится та же проблема. Также заметил, что если переключаться между вкладками при стримминге, видео замедляется. Вроде с компа, когда библиотекой x264 шлю ему h264 нет подобных проблем. Чего ж он так к виртурилке неровно дышит... Ребята из RTCWeb решили недавно, что h264 будет обязательным для WebRTC. Надеюсь это произойдет чем поскорее. Все надежды на родные возможности, ато с этими плагинами...
<strong>2 Gol:</strong> Спасибо большое за библиотеки! Теперь работает. По загрузке проца на 10%-20% больше грузится, чем с AAC. Качество звука хорошое, вроде. Но видео сразу замедлилось. Правда, почему-то частота звука в 2 раза выше. Вроде должна быть 8000 по умолчанию для g711, а не 16000. Щас подзаряжу аккум и продолжу испытания...
Форум спамят, по этому спрошу здесь. Есть у меня некоторые наработки по WebRTC. Не хватает передачи звука с V2R. Вроде как виртурилка умеет жать звук с микрофона кодеком G.711, являющимся одним из двух, которые поддерживает WebRTC. В gstreamer за G.711 отвечает команда alawenc или mulawenc, которая должна входить в состав plugins-good. Но на виртурилке ее нет(!). Как я могу это исправить?
А как по RTMP видео со звуком? При штатной частоте, даже при минимальном качестве, задержка была около 0,5сек (что не годится для удаленного управления). При этом, при обратной передаче звука с микрофона на виртурилку, ей было сложно его обрабатывать, то есть явно процессор не тянул. Как сейчас с задержкой, не замечали?
