Функциональность подразумевает размытие только на основе окантовки некоторой толщины с целью виртуально "расширить" экран. Обработка всего кадра целиком это не только увеличение нагрузки на CPU, но и ухудшение точности итогового результата.
А ещё нужно учитывать, что когда участники конференции не активны, им достаточно передавать пониженное разрешение для демонстрации thumbnail. И что, как правило, активный участник в конференции только один.
В таком случае P2P связность уже не кажется такой громоздкой.
Люди забывают, что количество данных туда-сюда одинакого в обоих сценариях. Но в случае с централльным сервером он берет на себя всю нагрузку и является точкой отказа. В случае p2p точки отказа нет и нагрузка размазывается между пирами.
Я считаю что есть смысл добавить это в стаью. Собствено, ради этого и я вступил в дискуссию, пытаясь хоть как-то указать на неконструктивность подхода "because I can" и недостаточно глубокое изучение вопроса.
Три момента заслуживающих внимания читателей:
1) В серсии 1.1 данная вункциональность уже реализована из коробки.
2) Методы аутентификации в версии 1.1 более безопасны, но обратно не совместимы с 1.0 и бэкпортированы не будут никогда.
3) Исходя из официальной документации 1.0 версия считается legacy, хотя для нее и выходят корректирующие релизы (прямо как gnupg, правда?) и тем кто заботится о безопасности следовало бы присмотреться к механизму инвайтов и новой версии Tinc.
Вопрос. Будет ли это выложено в OpenSource?))
Тогда стоит это уточнить в заголовке.
Потому что для обработки звука повышенная частота дискретизации и расширенный динамический диапазон приходятся очень даже кстати.
Пустяк или нет, но сама логика перебора целого кадра выглядит странно.
А есть более быстрые методы захвата изображения?
Тогда вопрос, зачем перебирать весь экран?
Функциональность подразумевает размытие только на основе окантовки некоторой толщины с целью виртуально "расширить" экран. Обработка всего кадра целиком это не только увеличение нагрузки на CPU, но и ухудшение точности итогового результата.
Судя по видео задержка ощущается как пара сотен мс и для фильмов такое явно не пойдет.
Максим, спасибо за статью и упоминание)))
Надо будет повторить))
Потому что ICMP RTT, он же пинг, нужно тестировать под нагрузкой.
Это называется RRUL.
К сожалению, это самый частый случай планировки в современных офисах.
На самом деле, тратятся.
Дак может это и был эмулятор, просто вы сами участвовали в учениях и не знали об этом?
Кому сегодня нужно это старьё?
В таком случае P2P связность уже не кажется такой громоздкой.
В реальности существуют разные схемы. Ну, например вот тут можно почитать.
www.akamai.com/uk/en/multimedia/documents/technical-publication/multi-rate-peer-to-peer-video-conferencing-a-distributed-approach-using-scalable-coding-technical-publication.pdf
Люди забывают, что количество данных туда-сюда одинакого в обоих сценариях. Но в случае с централльным сервером он берет на себя всю нагрузку и является точкой отказа. В случае p2p точки отказа нет и нагрузка размазывается между пирами.
Зашёл написать этот комментарий.
wikidevi.wi-cat.ru/Main_Page
Я буду смотреть дату статьи перед комментарием!
Я буду смотреть дату статьи перед комментарием!
Зачем в 2019 году использовать iwconfig когда есть iw?
Что дальше? Статьи о том как правильно пользоваться ifconfig?
Проблема WireGuard в том что это исключительно TUN (L3). В то время как TINC умеет и TUN (L3) и TAP (L2).
Работает в пространстве ядра (модуль).
Проблема Tinc в том что он прибит гвоздями к OpenSSL.
Работает в пространстве пользователя (демон).
То есть, чисто менеджерским взглядом будет казаться что это отличная перспектива. Но на деле это два абсолютно разных проекта.
Вы не поверите.
https://www.tinc-vpn.org/pipermail/tinc/2017-February/004755.html
Я считаю что есть смысл добавить это в стаью. Собствено, ради этого и я вступил в дискуссию, пытаясь хоть как-то указать на неконструктивность подхода "because I can" и недостаточно глубокое изучение вопроса.
Три момента заслуживающих внимания читателей:
1) В серсии 1.1 данная вункциональность уже реализована из коробки.
2) Методы аутентификации в версии 1.1 более безопасны, но обратно не совместимы с 1.0 и бэкпортированы не будут никогда.
3) Исходя из официальной документации 1.0 версия считается legacy, хотя для нее и выходят корректирующие релизы (прямо как gnupg, правда?) и тем кто заботится о безопасности следовало бы присмотреться к механизму инвайтов и новой версии Tinc.