Каждый раз, запуская Skype, Zoom или Hangouts, я с интересом жду свежую порцию косяков с видео и звуком. Технологии редко меня разочаровывают: квакание, фоновые шумы, пропадание голоса, распадение видео на «квадратики», замороженные кадры и другие радости видеоконференций преследуют видеозвонки сколько я себя помню. Интерес во многом профессиональный: кроме программируемой телефонии для обычных телефонов, веб-страниц и мобильных приложений, мы в Voximplant отгружаем разработчикам видео. Хочется Full HD, в реальном времени, без фризов, в любом браузере и конференция человек на 50. Что интересно, в лабораторных условиях оно именно так и работает. А вот в каком-нибудь парке на 3G видеоконсультация с доктором может превратиться в пошаговую стратегию: пакеты-то теряются! Современный стек технологий пока не позволяет на равных бороться с «мигающим» интернетом, но исследования постоянно ведутся. Под катом — адаптированный для Хабра перевод про Salsify: сплава видеокодека и сетевого протокола, минимизирующего проблемы при передаче видео в реальном времени.
Команда из Стенфорда провела эксперимент: заменила всё лоскутное одеяло современных технологий видеоконференций на один протокол сжатия и передачи по сети.
Видеоконференции: лллллаги, ффффффризы и дерганье
Через некоторое время проблемы проходят сами собой. Иногда — вместе с изображением, оставляя вместо него черный экран. Доставляемые неприятности живут в диапазоне от «подождем пару минут, сетка мигает» до «телеоперацию можно завершать, пациент умер». Ученые из Стенфорда подошли к проблема кардинально, разработав с нуля и сетевой стек, и кодек, и способ передачи данных с единственной целью: сделать лучше чем у Skype, FaceTime, Hangouts и Chrome+WebRTC.
Возглавляющий исследование аспирант из Стенфорда Саджад Фолади представил результаты на профильной конференции NSDI'18. Идеи, лежащие в основе решения «с чистого листа», доступны всем желающим и могут быть использованы в коммерческих решениях. Конечно, если кто-нибудь захочет заменить весь стек.
«Передача видео через интернет эволюционировала десятки лет. Сейчас стек технологий больше напоминает лоскутное одеяло», — говорит доцент компьютерных наук Кит Уинстейн. «Саджад показал, как можно собрать эти кусочки другим способом, чтобы получить видео лучшего качества и с меньшими задержками».
А вот насчет сроков внедрения Уинстейн более осторожен. «Сейчас мы думаем над изменениями, чтобы в один прекрасный день передача видео в реальном времени стала более надежной. Будет очень кстати в телемедицине и роботизированных операциях», — говорит он. «Но в тот софт, что используется сейчас, все эти изменения внести сложно».
Новый подход, новое имя
Стенфордская команда назвала свой фреймворк «Salsify» (Козлобородник, такой «цветок», отдаленно напоминающий одуванчик в юности — примечание переводчика). Фреймворк решает проблему, вызванную тем, что «передача видео в реальном времени» сейчас сшита из двух разных технологий. Это «кодек», который сжимает видео и «сетевой протокол», который передает по сети небольшие кусочки данных и пытается угадать, когда нужно отправить следующие кусочки, чтобы его нигде по пути не выкинули, потому что сеть перегружена и вообще все плохо. Проблема в том, что эти два компонента эволюционировали отдельно друг от друга, часто разными компаниями, а затем были совмещены в таких продуктах как Skype или FaceTime.
Фолади уверен: чтобы решить проблему с фризами и лагами, кодек и сетевой стек должны работать вместе. Ведь важно не просто вовремя отправить пакет по сети. Нужно, чтобы в этом пакете были правильные данные! А не кусок видео 3-секундной давности, который все равно будет выкинут на принимающей стороне как «слишком старый». Как говорит руководитель проекта, «когда транспортный протокол и кодек теряют синхронизацию – начинаются проблемы». Поэтому команда сделала новый кодек, который максимально интегрирован с транспортным протоколом. Один алгоритм управляет сжатием кадров видео, формированием сетевых пакетов и их отправкой. Таким образом, видеопоток «знает» о состоянии сети в реальном времени и пытается в нее «вписаться» по мере возможности.
Даже один отправленный невовремя кадр может привести к рывкам и фризам. Salsify никогда не отправит кадр, если он может привести к проблемам с сетью
Увидеть и поверить
Исследователи провели множество тестов, сравнив Salsify с Microsoft Skype, Google Hangouts, Apple FaceTime и Google Chrome+WebRTC. В среднем Salsify уменьшает задержку в четыре раза (!!!), а качество изображения становится на 60% лучше (по методике изменения structural similarity, SSIM). Готовы side-by-side сравнение с Chrome 65 WebRTC и сделан отдельный веб-сайт, посвященный проекту. Проект open source: можно скачивать, изучать, использовать наработки.
У всех случаются проблемы с видеоконференциями. Очень круто работать над проектом, который призван изменить ситуацию.
Комментарии (107)
Quiensabe
06.08.2018 18:03+1Это очень круто!
Интересно, насколько сложно сделать некий «плагин» к тому же скайпу, который бы эмулировал звонок, но уже через эту технологию? Т.е. скайп используется в режиме обмена сообщениями, только для пересылки информации о клиентах, для установки соединения, чтобы исключить необходимость в стороннем сервере. А в дальнейшем звонок идет напрямую, полностью через новый протокол, не используя сервера микрософт. Сразу решаем и проблему качества, и записи разговора никуда не утекают…
Насколько это вообще реально/сложно реализовать?eyeofhell
06.08.2018 18:35Скайп не поддерживает плагины и у него закрытый протокол. Но команда разработки скайпа или зума вполне могут воспользоваться этими наработками, о чем однозначно пишут авторы — «берите, пользуйтесь»
Quiensabe
06.08.2018 20:33Я потому и взял «плагин» в кавычки. Но полагаю так или иначе связать функционал возможно, есть ведь программы записи звонков с интеграцией кнопки записи прямо в скайп. Да и не суть. Даже если для установки соединения будут отправляться видимые сообщения с кодом — не страшно. И если это будет надстройка не над скайпом, а на телеграм или любым другим популярным мессенджером — тоже не проблема. Для многих, вопрос качества связи весьма актуален. Любые подвижки в этом направлении — это отличные новости.
firedragon
07.08.2018 17:53
Этот хомяк смотрит на вас с осуждением.
dev.skype.com/hipmunk-case-studyeyeofhell
08.08.2018 09:29Я на него тоже смотрю с осуждением. Потому что он — бот. А бот и плагин — это очень, очень разные штуки.
firedragon
08.08.2018 10:56Сейчас у меня нет времени, но API существует, в частности по нему работают мои наушники Plantronics. А если копаться глубоко то вот вам начальная точка docs.microsoft.com/en-us/skype-sdk/skypedeveloperplatform
eyeofhell
08.08.2018 11:12Мои соболезнования, со временем сейчас оч тяжело :( Апи, увы, не существует:
reversecode
06.08.2018 19:22ничего крутого для тех кто разбирается
можно так же кучу статей на эту тему накидать
взять тот же srt www.srtalliance.org
там видео тоже с примером
ValdikSS
07.08.2018 00:00+1А меня видео не впечатлило. Добиться быстрого восстановления картинки можно вообще без изменений технологии, просто уменьшив GOP, посылая ключевые кадры раз в 100мс, например, а адаптивный битрейт можно нормально сделать и на любых текущих энкодерах, если «научить» энкодер быстро понимать, когда происходит потеря пакетов, и моментально реагировать (а не как сейчас, основываясь на косвенных признаках потери пакета). Получать соответствующую информацию можно от алгоритма управления TCP-окном, например (но готовые API для этого мне неизвестны, может, amarao подскажет).
В общем, всё изображенное на видео можно внедрить в обычный WebRTC, и он останется совместимым с другими реализациями WebRTC.reversecode
07.08.2018 07:00+2Оно там уже внедрено, просто авторы видео не знают webrtc
поэтому создали что то свое и сравнили с дефолтным webrtceyeofhell
07.08.2018 07:39«Оно» — это что? Если я правильно помню текущую реализацию WebRTC в хроме, то связь между RTP и кодеком довольно примитивная: если пакеты не теряются то увеличиваем битрейт и разрешение до лимитов, если теряются — то уменьшаем. Довольно медленный процесс, кстати. Если во время видеозвонка на непродолжительное время начать дропать пакеты для одной из сторон, то видео о-о-о-о-о-очень нескоро восстановится.
reversecode
07.08.2018 08:24-1наберите в гугле webrtc bbr
этот вывод про медленное восстановление вы сделали после прочтения статьи?
все потому что у вас много специалистов по js и почти нет специалистов по voip и webrtcaylarov
07.08.2018 08:56+1очень смешной комментарий :) иногда вопрос далеко не в количестве, а в качестве. У нас есть разные специалисты, поэтому мы умеем и записывать видео и делать видео конференции, скоро еще будет много новых функций, включая стримминг.
reversecode
07.08.2018 09:10-1Если у ваших специалистов «видео медленно восстанавливается» — то пора их обновить :)
Либо отправьте их на переквалификацию
eyeofhell
07.08.2018 09:44Congestion control он, увы, больше про среднюю скорость передачи данных, а не про реалтайм. Очень слабо влияет именно на восстановление видео после сетевых проблем. А статья именно об этом — как убрать фризы и лаги. Чтобы видео надолго не замирало нужно взаимодействие между кодеком и сетевым протоколом чуть более плотное, чем сейчас делает WebRTC.
reversecode
07.08.2018 10:22-1Мне противно такую чушь читать
Топик отлично показал сколько непрофессионалов в технологии webrtc присутствует на хабреeyeofhell
07.08.2018 11:03В этом прелесть Хабра — можно обсудить интересное. Я тут пообщался с коллегами. Если не углубляться в кишки, то традиционная версия WebRTC принимает решение о пропускной способности канала на основании bandwidth estimator с RTCP/REMB наперевес и еще ряда параметров, например потери пакетов (пакеты в видео зависят друг от друга, и 10% потерь пакетов это не как «интерполировали и норм» в голосе, а «не смогли восстановить картинку вообще и все зафризилось). Традиционный congestion control, например из TCP, известен тем, что очень любит делить окно/bandwidth напополам. А потом медленно его увеличивать. WebRTC делает что-то похожее — оно довольно быстро, в течении 1-5 секунд дропает качество/разрешение/частоту, а потом медленно их восстанавливает. Но это СЕКУНДЫ. См. ролик в начале статьи. BBR призван бороться как раз с медленным восстановлением, но в сумме скорость реакции даже с BBR очень медленна и фризы будут. У ребят в статье чутка другой подход.
ValdikSS
07.08.2018 14:53+1Если не углубляться в кишки, то традиционная версия WebRTC принимает решение о пропускной способности канала на основании bandwidth estimator с RTCP/REMB
В этом и проблема, что о потери пакетов узнают на L7, а не от алгоритма, который этим занимается.
tools.ietf.org/html/draft-ietf-rmcat-gcc-02 — это уже в каких-либо браузерах реализовано?eyeofhell
07.08.2018 15:43У меня нет информации, чтобы эта штука продвинулась дальше Proposal. Но, как я уже писал выше, мое личное мнение — что congestion control это история про максимизацию наполнения трубы, история о пропускной способности. Если мы хотим real-time и бороться с фризами то нам нужен flow control: то, что делают ребята. В современном сетевом стеке congestion, flow и ряд других механик работают вместе. Мой поинт в том, что изменением только congestion control на другой general-purpose congestion control вроде BBR не приведет к тем же результатам, как в видеоролике до ката. Просто потому, что технология создана для другого.
ValdikSS
07.08.2018 15:51В современном сетевом стеке congestion, flow и ряд других механик работают вместе.
Не совсем. Алгоритмы управления очередями, как минимум в Linux, работают на уровне IP (но умеют понимать, откуда и куда передаются пакеты, одно ли это соединение, или разные), и не зависят от протоколов уровнем выше.
В современных версиях Linux по умолчанию используется fq_codel — www.bufferbloat.net/projects/codel/wiki
With the “fq_codel” variant (Fair/Flow Queueing + Codel) it is possible to reduce bottleneck delays by several orders of magnitude, and provide accurate RTT estimates to elephant TCP flows, while allowing shorter (sparser) flows like DNS, ARP, SYN, routing, etc packets priority access.
Если WebRTC мог бы получать информацию о состоянии сети из алгоритма управления очередью, и, например, моментально уменьшать битрейт и насильно отправлять следующим кадром ключевой кадр, то было бы сильно лучше.
eyeofhell
07.08.2018 07:43Сейчас реал-тайм видеосвязь в основном по UDP, так что управление TCP окном мало поможет. Sad, but true.
«Быстро понимать, когда происходит потеря пакетов» — это одна из фундаментальных трудностей современного сетестроения. По сути каждый из endpoint'ов отправляет пакеты «в трубу» и вообще не представляет, что в этой трубе происходит и что появится на другом ее конце. Единственный способ как-то понять, что пакет потерян — это слать ACK'и с противоположной стороны. А это дополнительные задержки и проблемы вида «пакеты от нас ходят хорошо, пакеты к нам ходят хуже, на том конце видео выключили и ожидают видеть наше видео, а мы ждем ACK'ов, которые не приходят, и не понимаем, что наши пакеты на самом деле не теряются».reversecode
07.08.2018 08:11-3BBR в webrtc применяется не для tcp, изучите внутренности webrtc для начала
ValdikSS
07.08.2018 14:54+1BBR есть только в Chromium, как я полагаю. Другие реализации используют другие алгоритмы управления потоком.
reversecode
06.08.2018 18:42В Стенфорде больше нечем заняться?
Так же не верю что вебртц гугл хром у них глючил, явно по дефолту и никто никаких параметров не подкручивал
Скайп глупо было сравнивать, он уже давно никак не развиваетсяRegis
06.08.2018 22:59+2Вы что, серьёзно предлагаете каждому пользователю каждого браузера заниматься тюнингом параметров браузера?
reversecode
07.08.2018 07:02-1Что такое параметры броузера? это настройки webrtc
Вы за то что в броузеры внедрили webrtc с кучей опций решили на мне отыграться минусами?
Да идите гуглу пишите свои недовольстаWhuthering
07.08.2018 09:37+2Вы за эту самую вакханалию с опциями webrtc в браузерах здесь пламенно топите и утверждаете, что так и надо, попутно оскорбляя всех тех, кто недоволен сложившейся ситуацией. Так что логично, что минусуют не гугл, а лично вас.
reversecode
07.08.2018 10:26-1Они не в опциях броузера они в настройке sdp в webrtc
И я нигде не утверждаю что так и надо, я утверждаю что это стандарт
И если он есть, то его либо учат как использовать, либо не используют
А минусующие это молодежь которая психует за то что не может освоить voip
И когда минусы достигнут апогея я с удовольствием удалюсь, уже не раз об этом дискутировал с администрацией ресурса
Нет ничего хуже чем находиться среди непрофессионаловwiwrel
07.08.2018 10:53Ну так поведайте нам — неблагоразумным и глупым, о тайном знании настроек webrtc, что даст нам контент без задержек и лагов
Whuthering
07.08.2018 11:49+3А минусующие это молодежь которая психует за то что не может освоить voip
Ставить диагнозы по интернету — детский сад.
Нет ничего хуже чем находиться среди непрофессионалов
Профессионализм/непрофессионализм здесь вообще не причем. Просто вам стоит поучиться вести дискуссии в приличном обществе.reversecode
07.08.2018 12:30Диагнозы или характеристики?
Я так вижу вы в теме просто поговорить и к webrtc никак
Ну ка ну ка в чем не корректная дискуссия?
В том что я сначала начал утверждать очевидное?
SanekPlus
07.08.2018 12:11>>Нет ничего хуже чем находиться среди непрофессионалов
Ну так вали отсюда. :)reversecode
07.08.2018 12:27Ляпнул тот у кого ноль статей и минусовой рейтинг, явно старались в этом последние 7 лет
QuickJoey
07.08.2018 09:28Скажите, а сколько вы ещё напишите комментариев про «дефолтные настройки WebRTC», а? Уже понятно, спасибо, сверху прочитали три раза.
abyrkov
07.08.2018 10:39Вместо того, что бы намекать, что мы все идиоты и вообще вам известны «секретные» знания, может соизволите написать об этом статью?
Whuthering
07.08.2018 11:49+2Подозреваю, что никаких «секретов» ему неизвестно, а всё это здесь расписывается просто для поднятия самооценки и чувства собственной важности. Как оно обычно и бывает.
reversecode
07.08.2018 12:26Что тут подозревать если вы далеки от темы webrtc и передачи av over networks
reversecode
07.08.2018 12:25-2Вы эти намеки сами придумали?
Сакральные знания в том что сначала надо изучить webrtc а потом использовать?
Londoner
06.08.2018 18:56А пока это будущее не наступило, кто может посоветовать апп, чтоб общаться голосом (хотя бы голосом, Карл!) по IP с абонентом с подмосковным 3G от МТС? WhatsApp каждые пять секунд реконнектится, остальное время лагает, вычёркиваем. Если нет ничего, чтоб прокричаться через отечественный мобильный интернет, то есть ли хотя бы полудуплексные решения? Чтобы сказал фразу и нажал кнопку приём, на той стороне абонент ждёт, когда пока фраза скачается полностью, слушает и так же отправляет голосовой ответ.
APXEOLOG
06.08.2018 19:12Чтобы сказал фразу и нажал кнопку приём, на той стороне абонент ждёт, когда пока фраза скачается полностью, слушает и так же отправляет голосовой ответ.
Голосовые сообщения в ВК? :)
Londoner
06.08.2018 19:14Ну нет, надо чтоб был апп с одной кнопкой «приём», как на старых радиостанциях.
reversecode
06.08.2018 19:16play.google.com/store/apps/details?id=com.rebelvox.voxer&hl=ru
play.google.com/store/apps/details?id=com.loudtalks
итд наберите слово РАЦИЯ и проверяйтеLondoner
06.08.2018 19:32Искал, но в основном попадались странные или глючные поделия. Если вы пользовались сами чем-то, что подходит под моё описание, порекомендуйте.
Mobile1
06.08.2018 22:27Если вы пользовались сами чем-то, что подходит под моё описание, порекомендуйте.
Попробуйте наш M1 Messenger — там реализован этот режим (Push-To-Talk или режим рации). Работает как в одиночных, так и в групповых чатах:
Скриншот режима РТТ в М1 Мессенджер
reversecode
06.08.2018 19:13если от 3G там только название то никак
а так любая звонилка которая умеет g729 или opus кодекиLondoner
06.08.2018 19:151. А полудуплекс, как я описал, почему нет?
1. А тогда как настроить тот же WhatsApp на другой кодек?reversecode
06.08.2018 19:17Где нет? где вы искали и что находили?
А причем здесь вотсап?Londoner
06.08.2018 19:28Переформулирую вопрос. Есть ли звонилки, специально заточенные под плохой канал вроде подмосковного 3G от МТС, работающие лучше чем WhatsApp (он, как раз, пользует opus)?
reversecode
06.08.2018 19:32канал может быть насколько хреновый что никакая звонилка не поможет
а так, любая звонилка которая умеет выбрать кодек
их в гугле несколько вагонов
в апсторе я вам выше пару показалLondoner
06.08.2018 19:36+1Вот представьте, что я спрашиваю у Вас, какой трактор обладает самой лучшей проходимостью, а Вы мне в ответ — «дорога может быть настолько хреновая, что любой трактор застрянет». Не спорю, может. Но это не означает, что можно ездить только по асфальту на легковушке. Так какие «3G-трактора» Вы знаете?
reversecode
06.08.2018 19:42-3Я понимаю что вы спрашиваете не понимая сути проблемы.
При хреновом качестве канала, никакой кодек итд вам не поможет передать реалтайм данные
А если вам не реалтайм нужны, ну пользуйтесь социальными сетями или стикерами в смс сообщениях, где записывается голосовое сообщение и отправляется…
И оно потом когда нибудь дойдет до адресата
nikolayv81
06.08.2018 20:50+2Да skype это, звук работает с модемом 2g (проверено) при этом даже какую-то картинку показывает (связь с деревней через модем принудительно переведённый в 2g), проблема 3g в том что он менее стабилен чем 2g.
Лучше скайпа ничего не работало.
Goodkat
06.08.2018 21:53Если нет ничего, чтоб прокричаться через отечественный мобильный интернет, то есть ли хотя бы полудуплексные решения? Чтобы сказал фразу и нажал кнопку приём, на той стороне абонент ждёт, когда пока фраза скачается полностью, слушает и так же отправляет голосовой ответ.
Видел, подростки именно так и общаются в этом вашем воцапе через голосовые сообщения.
belyvoron
06.08.2018 19:46+3я надеюсь, про телеоперацию и умершего пациента было для красного словца? потому что уже много лет существуют профессиональные ВКС системы, сертифицированные для применения в медицинских учреждениях, которые включают через выделенные каналы (MPLS VPN) и получают гарантированное и стабильно FullHD качество, без квадратиков и рассыпаний картинки.
Надо чётко понимать, что никакой кодек и никакой протокол не дадут гарантированного качества картинки на негарантированном канале, которым является интернет. Поэтому не надо мешать в одну кучу профессиональное применение (от которого в том числе могут зависеть жизни), для которого решения существуют, с любительским применением.nikolayv81
06.08.2018 20:55И там в коробке ровно тоже самое, основное это канал, а от экскаватора никто не застрахован увы.
Другое дело сертификация позволяет переложить расходы в случае чего, с конкретной больницы на крупную/страховую компанию.
rub_ak
06.08.2018 22:30+1Когда я работал в больнице и как раз немного с ВКС, никаких выделенных MPLS VPN в помине не было, было или ISDN или обычный ethernet, оборудование было или Polycom (ещё раньше) или Tanberg (ныне Cisco), правда это давно уже было 7лет назад и тогда только закупили c60 кодеки с камерами 1080p, а при мне только 720p были 3000 и 6000mpx.
Интересно а, что сейчас используется? Потому как в то времена софтовые решения вообще нормально не работали.
PS А у нас разве телеоперации разрешили, да даже не у нас? В первый раз про такое слышу.aram_pakhchanian
07.08.2018 09:01Я так понимаю, речь идёт о телемедицина в целом. Там тоже могут быть ситуации, когда надо принимать быстрое решение.
OnelaW
07.08.2018 10:29+1в бюджетном исполнении грандстрим юзают.
В более масштабных поликом с тенбергом.
Для полевых работ танберг с сумматором.
У буржуев есть вариант бюджетных сумматоров для дома где плохая связь.
Dessloch
07.08.2018 03:01+1ИМХО пропадание пакетов и качество видео это вообще перпендикулярные проблемы. На свежей(да и на 16 тоже можно) Ubuntu поставили bbr congestion и прекрасно общаемся голосом. Если падает канал никаким программным образом ту проблему не решить, чудес не бывает. Разумеется я имею в виду не разработку новых протоколов маршрутизации.
eyeofhell
07.08.2018 07:33Если падает — да. Если «мигает», то разница в восстановлении между 500мс и 2-3 секундами очень-очень большая
orcy
07.08.2018 10:09+1«Весь стек» — это включая IP/Ethernet/WiFI?
eyeofhell
07.08.2018 11:06Нет, достаточно UDP пакетов. Основная сложность в congestion, а оно проявляется на всем пути между нами и другой стороной звонка. Так что тайные знания ethernet или wifi о состоянии канала от нас до точки доступа мало помогут :)
BugM
Нативная поддержка в основных браузерах ожидается примерно никогда?
APXEOLOG
И даже позже
reversecode
А зачем? в броузерах и так все нормально, только настраивать надо уметь
reversecode
О… отлично, будем по минусам считать количество не умеющих настраивать
а потом удивляемся откуда столько вакансий пустующих по webrtc
YetAnotherSlava
Я бы тоже минус поставил, но у меня кармы не хватает.
reversecode
Кто бы сомневался что количество тех кто ничего не умеет и не хочет само обучиться всегда превышает количество тех кто молча берет учится разбирается
DracoL1ch
Добрая часть товаров созданы для тех, кто чего-то не умеет и не хочет учиться. Это абсолютно нормально не заниматься изобретением колеса, а платить тому, кто этому уже обучен, в данном случае — основным производителям браузеров за внедрение поддержки.
reversecode
Так не используйте броузеры в которые внедрен webrtc
Потому что как оказывается webrtc еще надо настраивать атрибутами, а еще как миниум владеть знаниями voip
Это тоже самое что для вождения авто надо сдать на права, а не просто научится крутить руль и жать на пидальки
Так что минус сходите влепите тому кто придумал webrtc
aikixd
Я как понимаю, дом свой вы тоже построили, а не купили?
reversecode
ОО а дом то вы сюда какой логикой прилепили?
Вам не нравится что webrtc такой? пишите свои недовольства в гугл
Или правда глаза колит в том что в voip надо разбираться что бы использовать webrtc?
aikixd
Да мне вообще наплевать на видео звонки, я раз 10 за жизнь их использовал. Меня раздражает что вы считаете что я должен это знать. Можно подумать, что кроме войп технологий больше нет.
reversecode
В этой теме обсуждается именно voip, если вас это раздражает значит удались с этой темы
А иначе вы тролль
Hardcoin
Вот разработчикам не понравилось, что webrtc такой. Они написали свое недовольство на гитхаб. А вы ничего дельного пока не написали, кроме "в браузерах и так всё нормально". При этом ясно — в браузерах нормально не всё.
vaizmanai
Простите, а где сдают на права управлением браузера?
reversecode
Там же где и самостоятельно строят дома
vaizmanai
Так это Вы теплое с мягким путаете, а не aikixd
Сдают на водительское удостоверение не потому, что автомобилем сложно управлять, а из-за опасности этого управления. А вот по Вашей теории нужно обучаться пользоваться браузером, причем я так понимаю, для разных направлений отдельно, ещё и вероятно кофемолкой, для телевизора пару уровней аттестации вводить и т.п.
reversecode
Вы хотите использовать webrtc неразбираясь в том как он работает?
Напишите свое возмущение разработчикам webrtc
А я высказал очевидную истину, что для того что бы использовать webrtc нужно разбираться в том как работает voip
t_kanstantsin
я пользуюсь брауезром не разбираясь, как он внутри работает. Мне безразлично, что передо мной: gif или mp4 — я хочу посмотреть котиков. Если бы мне приходилось это настраивать, то я, возможно, забил бы и не смотрел котиков на таком ресурсе/через такой браузер.
Т.е. если технология работает из коробки — ей будут разные люди, в т.ч не просвещённые в детали. Иначе — только те, кому это очень надо.
max1muz
Почему вы не обучитесь правильно писать по-русски?
reversecode
А почему вы не обучаетесь технологиям передачи аудио и видео по сети?
Hardcoin
Так он может не пользуется? А вы-то русским явно пользуетесь. Могли бы и аттестацию пройти, по вашему же совету.
reversecode
14 криворуких за сутки которые не смогли осилить webrtc, не так уж и плохо на большую аудиторию хабра
MikeTolkachev
Минус за едкость и колкость. Умеешь webrts настраивать — молодец. А мультикаст через паблик на другой континент можешь? Или файл без ошибок по UDP без обратного канала передать? У каждого есть свои набор умений. А ответы типа всё уже придумали, научитесь настраивать вызывают только минусы. Nvidia в своё время придумали алгоритмы и их считали эталоном. А что сделал Джон Кармак? Переписал драйвер Nvidia, получил прирост производительности в 1000 раз. В вашей реальности — настроил.
reversecode
Давно известная истинна что правда глаза колит
Но мои изначальные комментарии были не о том, но каждый понял как понял а по результату понял не верно
И пытаться сейчас бороться с троллями смысла нет
MikeTolkachev
НЛО сделал своё дело. Но, отвечу на выпад с точки зрения руководителя.
У Вас есть сакральное значение, но я никогда не обращусь к Вам за помощью.
В любой момент Вы можете повести себя так, как сейчас. Мне нет смысла зависеть от ваших знаний, когда речь идёт о профессиональном контенте. Каждая секунда «провала» — это деньги, большие деньги. Гораздо эффективнее использовать несколько потоков или несколько способов доставки. Это дешевле чем полная потеря контракта из-за одного звена. И, как результат, Ваше знание останется при Вас. Вы не получите выгоды, как финансовой, так и профессиональной. И пока вы говорите, что можно дешевле, нужно только правильно настроить, утвердят новый стандарт SMPTE.
Hardcoin
Вы настаивать умеете, а исследователи из Стенфорда — нет? Можете тогда посмотреть их работу (ссылки в посте) и показать, что они неверно настроили, раз у них chrome 65 хуже отрабатывает, чем их протокол?
reversecode
Через сутки после статьи и минусов появился разумный вопрос
Но мой интерес уже пропал, жду когда администрация удалит акк
Hardcoin
Реакция людей понятна — вы не стали описывать интересные детали, а сразу заявили — в браузерах всё норм, кому не нравится — не умеют настраивать. При таком настрое разумные вопросы появляются намного реже. Мы же не на ЛОР.
Regis
Я программист, а не «специалист по настройке броузеров». Я не хочу этим заниматься.
Не хватало еще каждую используемую программу вручную настраивать под все нюансы окружения.
reversecode
Да какой вы еще программист, если прибежали жаловаться на то что webrtc оказывается надо тюнить
Сходите лучше книгу по voip какую нибудь почитайте
Ну и адрес разработчиков webrtc я надеюсь сами найдете, туда им и минус свой пришлите а не мне
Regis
Зачем? Я не работаю с VoIP и не собираюсь им заниматься. Есть большое множество интересных для меня направлений для разработки, но VoIP сейчас в их число не входит. Почему я вдруг должен бежать заниматься именно VoIP? Только из-за того что он фигово работает "из коробки"? Мне проще не пользоваться, чем тратить на это время.
reversecode
Что ВЫ все не относящиеся к webrtc и данной статьи здесь делаете?
Просто за компанию?
Wesha
Whuthering
Если для того чтобы «было все нормально» для технологии рассчитанной на домохозяек, нужно читать книги и специально настраивать — значит это уже ненормально.
reversecode
Почему вы еще не написали ни одной жалобы в гугл и разработчикам стандарта webrtc?
aaalllsss
Вы, как знающий, расскажите мне, незнающему, что нужно настроить в браузере для работы WebRTC?