Использование Intel Wireless Display (WiDi) в Ubuntu
Он не хочет запускаться, потому что файл блокировки существует.
Убедитесь, что каждый процесс google-chrome убит: sudo killall google-chrome Удалить lockFile или даже папку .config / google-chrome , Он будет воссоздан, когда приложение запустится. rm /home/subham/.config/google-chrome/SingletonLock Запустить google-chrome
3 ответа
Корпорация Intel выпустила «Программное обеспечение с открытым исходным кодом для встроенного ПО беспроводного дисплея Intel®» Программное обеспечение с открытым исходным кодом для встроенного ПО беспроводного дисплея Intel® для телевизора Это должно заставить компьютер общаться с телевизором через Wi-Fi от Intel. [ 112]
РЕДАКТИРОВАТЬ: имейте в виду, что эта ссылка предназначена для исходного кода, выпущенного в соответствии с GNU GENERAL PUBLIC LICENSE Version 2, June 1991, и потребуется компиляция.
РЕДАКТИРОВАТЬ 2: Пререквизиты:
WiDi и Miracast изначально были двумя разными, несовместимыми форматами; более поздние версии WiDi также поддерживают miracast (v3.5 +). Я не знаю, поддерживается ли какой-либо из вариантов Linux (за исключением miracast на Android.
Версия WiDi на моем телевизоре LG также не работает с miracast.
Больше информации здесь:
Это старый вопрос, но он все равно может кому-то помочь: 2 Проекты на Github:
Программное обеспечение беспроводного дисплея для ОС Linux (WDS) , источник на связанном Github, содержит примеры реализаций Miracast (WiDi) Sink и Source.
WDS — это набор компонентов, используемых для построения стека отображения для Linux. Он состоит из:
- libwds: Первичная библиотека, которая реализует Miracast-диалект RTSP, который включает в себя синтаксический анализатор, логику согласования для приемника и источника и связанные структуры данных. Он не привязан к какому-либо конкретному диспетчеру соединений, средам мультимедиа или главному циклу
- wds / network: поддерживает интеграцию с главным циклом GLib и GStreamer
- wds / p2p: поддерживает интеграцию с функциями ConnMan Wifi P2P
Инструкции по сборке из github: cmake ; make
Источник
Ubuntu как Miracast Отправитель / получатель
Я ничего не мог найти в Ubuntu, действующем как получатель или отправитель Miracast.
- Это может работать вообще?
- Есть ли аппаратные предпосылки?
- Требуется ли WiFi или он может работать через локальную сеть или другое сетевое соединение?
- Wi-Fi Direct, кажется, является необходимым требованием, достаточно ли это? (т.е. если система поддерживает WiFi direct, значит ли это, что она поддерживает Miracast?)
- Есть ли различия в поддержке между получением / отправкой?
- Как задержка? (по сравнению с конкурентами, то есть VNC, коммерческими устройствами Miracast и т. д.)
- Как мне на самом деле использовать это, если это сложно?
В частности, я планирую использовать его вместе с телефоном Android (4.x Jelly Bean).
7 ответов
OpenWFD мертв и теперь заменен MiracleCast:
MiracleCast — это реализация технологии Miracast с открытым исходным кодом (также: Wifi-Display (WFD)). Он основан на исследовательском проекте OpenWFD и заменит его. Мы ориентируемся на правильную и тесную интеграцию в существующие системы Linux-Desktop по сравнению с OpenWFD, который задумывался как площадка для быстрого прототипирования.
Несмотря на свое название и происхождение, сам проект не ограничивается Miracast. Мы можем поддерживать любой вид потоковой передачи с минимальным объемом дополнительной работы. Тем не менее, Miracast останется главной целью развития благодаря уровню осведомленности.
Это все еще в начале своего цикла разработки. В настоящее время кажется, что он может выполнять связывание, но не выполняет реальное потоковое видео.
Демонстрация OpenWFD на FOSDEM 2014 также выполнила потоковую передачу, но, насколько я понимаю, MiracleCast — это проект » сделай все правильно «, тогда как код, который он показал в FOSDEM, «вероятно, будет работать только на этой машине».
Miracast основан на WiFi Direct, который, насколько я могу судить, требует беспроводной карты с аппаратной поддержкой стандарта.
отправитель
Я думаю, что Intel Wireless Display — это способ отправить экран ноутбука на приемник Miracast.
Однако, насколько я могу судить, Ubuntu в настоящее время не поддерживает карты Wireless Display.
Получатель
Для получения контента от передатчика Miracast (например, от вашего телефона) вы можете приобрести адаптеры приемника Miracast, которые будут выводиться на любой вход HDMI: Rocketfish ™ — видеоприемник Miracast
Я не знаю, есть ли на любом устройстве драйверы Ubuntu. Если кто-то может подтвердить или предложить другое устройство с драйверами Ubuntu, это было бы здорово.
Источник
Стандарт Miracast — старые протоколы в новой обёртке
Не так давно (начиная с JellyBean 4.2) Google добавила в Android поддержку технологии Miracast.
Практическому исследованию этой технологии методами reverse engineering и посвящена статья.
Что такое Miracast в двух словах? Это очередное детище Wi-Fi альянса — стандарт для передачи мультимедийного контента по сети Wi-Fi в peer-to-peer режиме. Для пользователя это означает прежде всего то, что для соединения с телевизором (к примеру) ему не понадобится Wi-Fi маршрутизатор. Два устройства по задумке альянса должны связываться друг с другом напрямую. Это обеспечивается использованием стандарта Wi-Fi Direct за авторством той же организации. Иными словами, новый стандарт решает задачи очень похожие на AirPlay от Apple, WiDi от Intel, или старое-доброе DLNA.
Зачем было городить огород — спросите вы. Почему было не воспользоваться уже существующим решением? Тут мне будет трудно ответить. Понятно, что лицензировать решения от прямых конкурентов или даже от Intel — не кошерный вариант имеющий к тому же фатальный недостаток, но почему не взять то же DLNA, возможно, чуть доработав рашпилем. Быть может, хотелось чего-то новенького, с модными нонче словами peer-to-peer? Не буду гадать. Так или иначе, технология была реализована в Android, и свежие телефоны типа Nexus 4 и Samsung Galaxy S3 имеют ее на борту.
Хуже обстоит дело с производителями телевизоров. Если поддержка DLNА уже есть практически в каждом современном телевизоре достаточно высокого уровня, то с Miracast дела обстоят хуже. Несмотря на существование чипов, модели телевизоров и проекторов умеющие принимать Miracast можно пересчитать по пальцам. Впрочем, ситуация наверняка изменится в 2014 году, а пока — пользователь может довольствоваться многочисленными гаджетами, принимающими сигнал по Wi-Fi и преобразующими его в HDMI. Такая штука втыкается в HDMI-разъем телевизора, и вот уже у вас есть Miracast-enabled устройство!
Один из инженерных образцов с чипом Broadcom попал в мои цепкие руки:
Убедившись, что с Android-смартфоном все работает на ура, я задумался над вопросом — нельзя ли наладить вещание через Miracast прямо из под Linux? Ведь что такое Android внутри? Тот же Linux…
Для начала, хотелось понять как вообще выглядит стек протоколов Miracast? Что стоит за красивым названием? Гонится ли видео-сигнал напрямую в Ethernet-фреймах или используется IP и еще более высокоуровневые протоколы. К сожалению, сам стандарт, хоть и открытый, но далеко не бесплатный, так что пришлось изыскивать иные, более традиционные пути исследования. В какой-то презентации я ухватил ключевые слова — MPEG-TS и RTSP, и это дало возможность раскрутить клубок дальше. Если я хоть что-то в чем-то смыслю, то RTSP — это TCP, а TCP — это IP. А IP — это подходящий протокол, который можно послушать tcpdump-ом! Сказано-сделано, запустив на Nexus-е tcpdump и включив Wireless display в настройках, через 5 минут я имел дамп пакетов, приемлемый для дальнейшего анализа.
Временно отложив трудности с соединением через Wi-Fi я взялся сразу за анализ TCP-потока. И вот что увидел:
Неправда ли, напоминает обычный RTSP. Итак, часть дела сделана. Остается понять чем отличается Miracast-овская реализация RTSP от стандартной. Для тех, кто никогда не сталкивался с RTSP (Real Time Streaming Protocol) напомню, что он используется для управления мультимедийным потоком с сервера на клиенте. Сиречь — позволяет выдать такие команды как PLAY, PAUSE, TEARDOWN и т.п. Также имеется возможность обменяться опциями и настроить параметры. Именно
Поскольку из анализа фреймов MPEG-TS я понял, что использовалось стандартное разрешение 720×480, и кодек H.264 (AVC), то было неплохой идеей создать видеофайл с ровно такими же параметрами, и тогда поля типа wfd_video_formats можно оставить без изменения! Порывшись в DVD-дисках я перекодировал небольшой VOB из телесериала «Cracker», в нужный мне формат посредством ffmpeg. Теперь оставалось только скормить файл серверу. Но для этого нужно найти сервер!
Чтобы не писать RTSP-сервер самостоятельно (что никак не входило в мои планы) я начал просматривать Open Source варианты, которые было бы легко доработать до состояния совместимого с Miracast. Если вы внимательно смотрели на логи из tcpdump-а, то могли заметить несколько странностей. Традиционная клиент-серверная модель RTSP заменена «peer-to-peer» взаимодействием. Это значит, что активность в запросах может исходить не только от клиента (им в данном случае выступает телевизор или проектор), а и от «сервера» (то бишь телефона или компьютера). Зачем понадобилось так делать — непонятно, но факт остается фактом — и «клиент» и «сервер» могут слать запросы когда им вздумается, что сводит на нет их традиционные роли. Тем не менее, сторону которая шлет видеосигнал я буду продолжать именовать сервером (в нашем случае это Linix-PC), а сторону, принимающую и декодирующую видео — клиентом (в нашем случае — это будет проектор).
Итак, после нескольких часов поисков я остановился на live555. Этот сервер написан на С++, распространяется под лицензией LGPL и поддерживает как RTSP, так и вещание в MPEG-TS. Поглядев на обработчик RTSP я понял, что его вполне реально переработать под peer-to-peer специфику Miracast. Но, оставалось еще заставить клиента (т.е. Мiracast-гаджет) соединяться с Linux!
Эта задача была посложней «Фауста» Гёте. Прежде я никогда не настраивал в Linux-е даже обычный Wi-Fi, справедливо полагая, что провода как-то понадежнее. Что уж говорить про Wi-Fi Direct. Однако, прочитав стопку manual-ов, я понял, что надо рыть в направлении загадочного WPA supplicant. Для чего нужен этот supplicant? Именно он обеспечивает аутентификацию при подключении по Wi-Fi к точке доступа или к другому узлу. Как я уже писал выше, Miracast работает в режиме p2p, т.е. устройства связываются напрямую, минуя маршрутизаторы. Эта возможность, к счастью, поддержана в последних версиях wpa_supplicant. Не знаю точно, с какого момента была добавлена поддержка p2p, но в версии 2.1-devel она уже есть.
Однако, обновить supplicant мало! Надо еще иметь конфигурационные файлы для него. С грехом пополам я написал конфигурацию приемлемую для моего устройства (NetGear, WNA1100 Wireless-N 150 [Atheros AR9271]), возможно, она подойдет и вам.
Итак, в файле /etc/wpa_p2p.conf пишем:
Далее, нужен shell-скрип для запуска supplicant:
Вот вроде и все (уточню, что данная конфигурация работает в Ubuntu-based дистрибутиве Linux Mint 13 Maya, версия ядра — 3.2.0-57-generic).
Дальше нужно овладеть такой утилитой как wpa_cli, именно она позволяет управлять соединением «вручную».
После запуска wpa_supplicant через скрипт, нужно открыть отдельную консоль и выдать что-то вроде:
Это командный интерфейс к supplicant-у. Включив гаджет мы можем командой p2p_find найти все устройства в округе, готовые подключиться к нам в режиме p2p. Далее, используя команду p2p_connect мы производим само подключение.
Вот пример лога для моего устройства:
В принципе, из лога все понятно, кроме разве что загадочного слова ‘pbc’ в команде p2p_connect после адреса устройства. Что же оно значит? Это один из вариантов аутентификации при подключении по Wi-Fi direct. Означает он — Push Button Control. Это упрощенная аутентификация, не требующая от пользователя ввода пароля или даже pin-кода. Просто в момент соединения нужно нажать кнопку на устройстве, и аутентификаця будет считаться успешной.
Итак, из лога мы видим, что соединение успешно произошло. И теперь мы имеем возможность получить IP-адрес для интерфейса wlan0.
DHCP-сервером в данном случае будет выступать телевизор или проектор. Введем в отдельном терминале:
Если после этого запустить tcpdump, то мы обнаружим попытки посылки SYN-пакета на порт 7236. Этот порт отличается от стандартного порта для RTSP (554), но пугать это нас не должно. Самое главное, что гаджет хочет с нами договориться! Запустив уже слегка доработанный livemedia сервер на этом порту (7236) мы получаем возможность отлаживать собственно «клиент-серверное» взаимодействие.
Я не буду утомлять читателя подробностями отладки протокола, скажу лишь, что все проблемы так или иначе были решены. И вот, наконец, результат налицо — я смог смотреть видео со своего PC через новомодный Miracast!
Нужно ли это вам? Не знаю. Во всяком случае, разобраться в новом стандарте всегда интересно (если конечно это не ASN.1).
Для тех, кому было лень вникать в технические подробности тезисно обрисую процедуру соединения для Miracast-based устройств:
- Используя Wi-Fi direct, устройства находят друг друга (обычно — источник видео-данных находит устройство отображения)
- Используя ту или иную форму аутентификации (в нашем случае — pbc) устройства объединяются в P2P-группу
- Одно из устройств получает IP-адрес по DHCP (в нашем случае — это источник видео-данных)
- На источнике данных на порту 7236 запускается RTSP-сервер
- Клиент подключается к RTSP-серверу, и запрашивает некий предопределенный URL (/wfd1.0/streamid=0)
- RTSP-сервер начинает передавать видео (и, возможно, аудио) данные в форме MPEG-TS упакованных в RTP-пакеты.
- Клиент распаковывает данные и отображает их на устройстве вывода.
Из явных недостатков Miracast (не упомянутых в Wiki) я бы отметил следующие:
- Если вы подключаетесь к Miracast-устройству то теряете возможность работы через обычный (не P2P) Wi-Fi. Чтобы одновременно пользоваться традиционным Wi-Fi и Wi-Fi direct нужен специальный двух-канальный Wi-Fi адаптер. Он имеется далеко не во всех телефонах!
- Качество картинки на динамичных сценах страдает даже при разрешении 720×480, 30 FPS. Я уж не говорю про Full HD. Разумеется, с появлением более мощных процессоров картина будет меняться, но пока все печально.
Вот собственно и все. Если у вас остались вопросы — задавайте в комментариях.
Источник
