2665270 - Способ и устройство для обработки информации

Способ и устройство для обработки информации

Иллюстрации

Показать все

Изобретение относится к технологиям сетевой связи. Технический результат заключается в повышении скорости обработки информации. Способ содержит: проверку получения от равноправного устройства через соединение для передачи данных по беспроводной сети запроса на дистанционное отображение экрана; получение адреса интернет-протокола (IP-адреса) и номера порта равноправного устройства в случае получения от равноправного устройства запроса на дистанционное отображение экрана; формирование единого указателя ресурса (URL), соответствующего медиа-данным, предназначенным для воспроизведения на экране равноправного устройства, в соответствии с IP-адресом и номером порта; определение стандартного проигрывателя, соответствующего URL; и воспроизведение медиа-данных, соответствующих URL. 3 н. и 4 з.п. ф-лы, 13 ил.

Реферат

Ссылки на родственные заявки

Настоящая заявка основана на китайской патентной заявке № 2015107182895, поданной 29 октября 2015 г., все содержание которой включено в настоящую заявку посредством ссылки, и притязает на приоритет по ней.

Область техники, к которой относится изобретение

Варианты осуществления настоящего изобретения относятся к общей технической области связи, а более конкретно касаются способа и устройства для обработки информации.

Уровень техники

Технология отображения по WiFi представляет собой распространения ресурсов (например, изображений, видеозаписей и музыки) между двумя элементами пользовательского оборудования ПО (User Equipment, UE) в режиме реального времени на основе протокола WiFi Direct.Такое распространение может включать в себя передачу материалов через соединение WiFi от передающей стороны (так называемой стороны источника) принимающей стороне (так называемой стороне приемника) для воспроизведения без использования какого-либо аппаратного соединения. Например, технология воспроизведения по WiFi обеспечивает возможность синхронного воспроизведения видеозаписей, воспроизводимых на мобильном телефоне, на крупноэкранном телевизионном приемнике.

Однако в соответствии с известными технологиями после передачи данных, предназначенных для воспроизведения на стороне приемника, такие данные немедленно воспроизводят на стороне приемника; поскольку процедуры передачи и воспроизведения данных не независимы одна от другой, в случае изменения протокола связи, установленного между стороной источника и стороной приемника, нормальное воспроизведение данных, переданных от стороны источника стороне приемника, может быть нарушено.

Раскрытие изобретения

Для устранения недостатков известных технологий в соответствии с настоящим изобретением предлагаются способ и устройство для обработки информации.

В соответствии с первым аспектом вариантов осуществления настоящего изобретения предлагается способ обработки информации, включающий в себя:

проверку получения от равноправного устройства через соединение для передачи данных по беспроводной сети запроса на дистанционное отображение экрана;

получение адреса интернет-протокола (Internet Protocol, IP) и номера порта равноправного устройства в случае получения от равноправного устройства запроса на дистанционное отображение экрана;

формирование единого указателя ресурса (Uniform Resource Locator, URL), соответствующего медиа-данным, предназначенным для воспроизведения на экране равноправного устройства, в соответствии с IP-адресом и номером порта;

определение стандартного проигрывателя, соответствующего URL; и

воспроизведение медиа-данных, соответствующих URL, при помощи стандартного проигрывателя.

В случае получения запроса на дистанционное отображение экрана, переданного передающей стороной, принимающая сторона получает IP-адрес и номер порта передающей стороны и генерирует URL, причем принимающая сторона определяет стандартный проигрыватель, соответствующий URL, и воспроизводит медиа-данные при помощи полученного стандартного проигрывателя. Поскольку стандартный проигрыватель на принимающей стороне в соответствии данным вариантом осуществления настоящего изобретения представляет собой независимый стандартный проигрыватель, такой стандартный проигрыватель на принимающей стороне может обеспечить нормальное воспроизведение медиа-данных, переданных передающей стороной, даже в случае изменения протокола, принятого при обмене данными между передающей стороной и принимающей стороной.

Определение стандартного проигрывателя, соответствующего URL, может дополнительно включать в себя:

получение заранее установленного проигрывателя;

проверку поддержки заранее установленным проигрывателем типа формата, соответствующего URL;

назначение заранее установленного проигрывателя стандартным проигрывателем, соответствующим URL, если заранее установленный проигрыватель поддерживает тип формата, соответствующий URL; и

настройку заранее установленного проигрывателя в качестве проигрывателя, поддерживающего тип формата, соответствующий URL, и назначение проигрывателя, поддерживающего тип формата, соответствующий URL, стандартным проигрывателем, соответствующим URL, если заранее установленный проигрыватель не поддерживает тип формата, соответствующий URL.

Преобразование существующего проигрывателя, не поддерживающего тип формата, соответствующий URL, для получения из него стандартного проигрывателя, поддерживающего тип формата, соответствующий URL, позволяет исключить влияние на воспроизведение переданных медиа-данных стандартным проигрывателем в реальном времени даже в случае изменения протокола передачи данных между стороной источника и стороной приемника.

Определение стандартного проигрывателя, соответствующего URL, может дополнительно включать в себя:

создание стандартного проигрывателя;

проверку поддержки стандартным проигрывателем типа формата, соответствующего URL; и

назначение стандартного проигрывателя стандартным проигрывателем, соответствующим URL, если стандартный проигрыватель поддерживает тип формата, соответствующий URL.

Создание стандартного проигрывателя, поддерживающего тип формата, соответствующий URL, и проверка поддержки стандартным проигрывателем типа формата, соответствующего URL, после его создания позволяют устранить влияние на воспроизведение переданных медиа-данных в реальном времени в стандартном проигрывателе в случае изменения протокола передачи данных между стороной источника и стороной приемника при наличии поддержки стандартным проигрывателем формата, соответствующего URL.

Проверка получения от равноправного устройства запроса на дистанционное отображение экрана может дополнительно включать в себя:

обмен с равноправным устройством информацией о заранее установленных параметрах в случае установления с равноправным устройством связи для обмена данными с использованием сетевого протокола Wireless Fidelity Peer-to-Peer (WiFi P2P);

проверку успешности согласования с равноправным устройством в соответствии с информацией о заранее установленных параметрах;

определение получения от равноправного устройства запроса на дистанционное отображение экрана в случае успешного согласования с равноправным устройством; и

определение неполучения от равноправного устройства запроса на дистанционное отображение экрана в случае безуспешного согласования с равноправным устройством.

Стороны производят согласование, чтобы определить, выполнены ли для условия передачи данных, тем самым предотвращая ситуацию, в которой по получении медиа-данных, переданных стороной источника, сторона приемника не может нормально воспроизвести такие медиа-данные в связи с несовместимостью их формата или другими причинами.

Воспроизведение медиа-данных, соответствующих URL, при помощи стандартного проигрывателя может дополнительно включать в себя:

получение медиа-данных, соответствующих URL, на равноправном устройстве в соответствии с URL;

декодирование медиа-данных;

обработку декодированных медиа-данных для получения медиа-данных воспроизведения; и

воспроизведение медиа-данных воспроизведения в стандартном проигрывателе.

После получения URL производят анализ такого URL, а затем производят получение соответствующих медиа-данных в соответствии с проанализированным URL. Например, после осуществления анализа URL сторона источника передает стороне приемника медиапоток в реальном времени (или зафиксированный интерфейс) в формате транспортного потока ТП (Transport Stream, TS) через установленный канал связи, сторона приемника кодирует и демультиплексирует данные медиапотока (например, аудио и видео данные), а затем передает данные медиапотока стандартному проигрывателю для декодирования, обработки и воспроизведения.

В соответствии со вторым аспектом вариантов осуществления настоящего изобретения предлагается устройство для обработки информации, содержащее:

модуль оценки запросов, выполненный с возможностью проверки получения запроса на дистанционное отображение экрана от равноправного устройства через соединение беспроводной сети для передачи данных;

модуль получения информации, выполненный с возможностью получения IP-адреса и номера порта равноправного устройства в случае получения запроса на дистанционное отображение экрана от равноправного устройства;

модуль формирования URL, выполненный с возможностью формирования URL, соответствующего медиа-данным, предназначенным для воспроизведения на экране равноправного устройства, на основе IP-адреса и номера порта;

модуль определения проигрывателя, выполненный с возможностью определения стандартного проигрывателя, соответствующего URL; и

модуль воспроизведения медиа-данных, выполненный с возможностью воспроизведения медиа-данных, соответствующих URL, при помощи стандартного проигрывателя.

Модуль получения проигрывателя может быть выполнен с возможностью получения заранее установленного проигрывателя;

первый модуль оценки типа формата может быть выполнен с возможностью проверки наличия поддержки заранее установленным проигрывателем типа формата, соответствующего URL;

первый модуль определения стандартного проигрывателя может быть выполнен с возможностью назначения заранее установленного проигрывателя стандартным проигрывателем, соответствующим URL, в случае наличия поддержки заранее установленным проигрывателем типа формата, соответствующего URL;

модуль настройки стандартного проигрывателя может быть выполнен с возможностью настройки заранее установленного проигрывателя в качестве проигрывателя, поддерживающего тип формата, соответствующий URL, в случае отсутствия поддержки заранее установленным проигрывателем типа формата, соответствующего URL; и

второй модуль определения стандартного проигрывателя может быть выполнен с возможностью назначения проигрывателя, поддерживающего тип формата, соответствующий URL, стандартным проигрывателем, соответствующим URL.

Модуль создания стандартного проигрывателя может быть выполнен с возможностью создания стандартного проигрывателя;

второй модуль оценки типа формата может быть выполнен с возможностью проверки наличия поддержки стандартным проигрывателем типа формата, соответствующего URL; и

третий модуль определения стандартного проигрывателя может быть выполнен с возможностью назначения стандартного проигрывателя стандартным проигрывателем, соответствующим URL, в случае наличия поддержки стандартным проигрывателем типа формата, соответствующего URL.

Модуль оценки запросов может дополнительно содержать:

модуль обмена информацией о параметрах, выполненный с возможностью осуществления обмена информацией о заранее установленных параметрах с равноправным устройством в случае установления с равноправным устройством соединения для обмена данными с использованием сетевого протокола WiFi P2P;

модуль оценки согласования, выполненный с возможностью проверки успешности согласования с равноправным устройством по информации о заранее установленных параметрах;

модуль определения успешного запроса, выполненный с возможностью определения получения запроса на дистанционное отображение экрана в случае успешного согласования с равноправным устройством; и

модуль определения безуспешного запроса, выполненный с возможностью определения неполучения запроса на дистанционное отображение экрана в случае безуспешного согласования с равноправным устройством.

Модуль воспроизведения медиа-данных может дополнительно содержать:

модуль получения медиа-данных, выполненный с возможностью получения в соответствии с URL медиа-данных, соответствующих URL равноправного устройства;

модуль декодирования, выполненный с возможностью декодирования медиа-данных;

модуль обработки, выполненный с возможностью обработки декодированных медиа-данных для получения медиа-данных воспроизведения; и

модуль воспроизведения, выполненный с возможностью воспроизведения медиа-данных воспроизведения в стандартном проигрывателе.

В соответствии с третьим аспектом вариантов осуществления настоящего изобретения предлагается терминал, содержащий:

процессор; и

память, выполненную с возможностью сохранения инструкций, исполнимых процессором,

причем процессор выполнен с возможностью:

проверки получения от равноправного устройства через соединение для передачи данных по беспроводной сети запроса на дистанционное отображение экрана;

получения IP-адреса и номера порта равноправного устройства в случае получения от равноправного устройства запроса на дистанционное отображение экрана;

формирования URL, соответствующего медиа-данным, предназначенным для воспроизведения на экране равноправного устройства, в соответствии с IP-адресом и номером порта;

определения стандартного проигрывателя, соответствующего URL; и

воспроизведения медиа-данных, соответствующих URL, при помощи стандартного проигрывателя.

Технические решения по вариантам осуществления настоящего изобретения могут обладать, в частности, следующими преимуществами:

при использовании способа и устройства для обработки информации, предлагаемых в соответствии с вариантами осуществления настоящего изобретения, в случае обнаружения передающей стороной принимающей стороны принимающая сторона и передающая сторона устанавливают соединение для обмена данными; при наличии соединения для обмена данными принимающая сторона и передающая сторона производят обмен некоторой информацией с целью согласования; в случае успешного согласования определяют, что от передающей стороны получен запрос на дистанционное отображение экрана, и принимающая сторона получает IP-адрес и номер порта передающей стороны и формирует URL; принимающая сторона определяет стандартный проигрыватель, соответствующий URL, и осуществляет воспроизведение медиа-данных при помощи полученного таким образом стандартного проигрывателя. Стандартный проигрыватель принимающей стороны по настоящему изобретению представляет собой независимый стандартный проигрыватель, вследствие чего стандартный проигрыватель принимающей стороны обеспечивает возможность нормального воспроизведения медиа-данных, переданных передающей стороной, даже в случае изменения протокола, принятого при обмене данными между передающей стороной и принимающей стороной.

Следует понимать, что приведенное выше общее раскрытие и нижеследующее подробное описание осуществления изобретения представлены исключительно в качестве примера и в целях пояснения и не налагают на настоящее изобретение каких-либо ограничений.

Краткое описание чертежей

Прилагаемые чертежи, включенные в настоящее описание и составляющие его часть, иллюстрируют варианты осуществления, соответствующие настоящему изобретению, и предназначены для разъяснения принципов изобретения в сочетании с настоящим описанием.

На фиг. 1 представлена схема иерархии протоколов в соответствии с одним из примеров осуществления изобретения;

На фиг. 2 представлена схема, иллюстрирующая передачу данных между стороной источника и стороной приемника;

На фиг. 3 представлена блок-схема, иллюстрирующая способ обработки информации в соответствии с одним из примеров осуществления изобретения;

На фиг. 4 представлена блок-схема этапа S340 по фиг. 3;

На фиг. 5 представлена другая блок-схема этапа S340 по фиг. 3;

На фиг. 6 представлена блок-схема этапа S310 по фиг. 3;

На фиг. 7 представлена блок-схема этапа S350 по фиг. 3;

На фиг. 8 представлена схема, иллюстрирующая устройство для обработки информации в соответствии с одним из примеров осуществления изобретения;

На фиг. 9 представлена схема, иллюстрирующая модуль определения проигрывателя по фиг. 8;

На фиг. 10 представлена другая схема, иллюстрирующая модуль определения проигрывателя по фиг. 8;

На фиг. 11 представлена схема, иллюстрирующая модуль оценки запросов по фиг. 8;

На фиг. 12 представлена схема, иллюстрирующая модуль воспроизведения медиа-данных по фиг. 8; и

На фиг. 13 представлена структурная схема терминала в соответствии с одним из примеров осуществления изобретения.

Осуществление изобретения

Ниже следует подробное описание вариантов осуществления изобретения, примеры которых проиллюстрированы прилагаемыми чертежами. Нижеследующее описание содержит ссылки на прилагаемые чертежи, причем одни и те же ссылочные номера обозначают на разных чертежах одни и те же или сходные элементы, если иное не следует из описания. Решения, раскрытые в нижеследующем описании примеров вариантов осуществления изобретения, не представляют все решения, соответствующие настоящему изобретению. Они лишь представляют собой примеры устройства и способов по аспектам настоящего изобретения, определенным в прилагаемых пунктах формулы изобретения.

В версии 4.2 операционной системы Android, разработанной компанией Google, была добавлена поддержка функции отображения по WiFi (WiFi Display, WFD), что привело к значительному изменению всей архитектуры отображения ОС Android. Альянс WiFi создал для устройств, поддерживающих функцию WFD, сертификацию под названием Miracast. Устройства, соответствующие требованиям сертификации Miracast, обеспечивают максимальную поддержку функции WFD и совместимость с нею.

Основная функция Miracast состоит в обеспечении распространения видео и аудио данных между устройствами через сеть WiFi. Например, в соответствии с простым сценарием применения Miracast может быть обеспечена возможность передачи видеозаписей с мобильного телефона на телевизор через соединение WiFi без проводного соединения (например, интерфейса мультимедиа высокой четкости, High Definition Multimedia Interface (HDMI)). С учетом современных тенденций развития интеллектуальной аппаратуры функция WFD с высокой вероятностью должна способствовать осуществлению подлинного многоэкранного взаимодействия в течение сравнительно короткого времени. Протокол WFD расширен по сравнению с протоколом WiFi и потоковым протоколом реального времени (Real Time Streaming Protocol, RTSP), определяет набор параметров и типов сообщений на основе RTSP и осуществляет базовую передачу данных через специализированную функцию информационного элемента (Information Element) WiFi. Иерархия этого протокола представлена на фиг. 1.

Как показано на фиг. 2, протокол WFD требует наличия по меньшей мере одного устройства-источника (стороны источника) и устройства-приемника (стороны приемника), которые называют источником WFD и приемником WFD, причем сторона источника представляет собой передающую сторону, а сторона приемника представляет собой принимающую сторону. Взаимодействие между стороной источника и стороной приемника для передачи данных кратко описано ниже. Стандарт Miracast управляет взаимодействие между двумя устройствами в рамках каждого сеанса связи, причем предусмотрены следующие основные этапы (выполняемые в указанном порядке):

обнаружение устройств: поиск близлежащих устройств, поддерживающих WiFi P2P, производимый при помощи WiFi P2P;

выбор устройства: после обнаружения устройством А устройства В устройство А должно выдать пользователю запрос, и пользователь может решить, следует ли производить согласование с устройством В;

установление соединения: установление соединения между стороной источника и средствами отображения стороны приемника при помощи WiFi P2P; в соответствии с технической спецификацией WiFi Direct данный этап включает в себя определение владельца группы и клиента; затем между данными двумя устройствами устанавливают соединение в соответствии с протоколом управления передачей (Transmission Control Protocol, TCP), причем для последующего управления и контроля сеанса связи настраивают порт RTSP; и

согласование технических возможностей: перед началом передачи видео- и аудиоданных устройство-источник и средства отображения должны произвести обмен информацией о некоторых параметрах Miracast, например, о поддерживаемых обеими сторонами форматах видео и аудио информации; дальнейшие этапы могут быть выполнены только после успешного согласования;

установление сеанса связи и потоковая передача: по завершении предыдущего этапа между устройством-источником и средствами отображения устанавливают сеанс связи Miracast, после чего может быть осуществлена передача видео- и аудиоданных; видео- и аудиоданные стороны источника передают на средства отображения с использованием протокола передачи реального времени (Real-time Transport Protocol, RTP) после кодирования транспортным потоком Экспертной группы по движущемуся изображению (Moving Picture Experts Group Transport Stream, MPEG2TS); средства отображения декодируют полученные данные и производят их отображение.

Однако в вышеописанном решении уровень упаковки приложений Android (Android Package, APK) помещен в раздел настройки, а средний уровень смешан с WiFi P2P, что создает неясности с точки зрения логического потока и затрудняет развязывание и поддержку. Поскольку вышеописанное решение может быть разделено на соединение и отображение в масштабах целого потока, изменение части соединения оказывает влияние на нормальную работу части воспроизведения. Например, в случае замены существующего протокола обнаружения стороны источника WiFi P2P и использования для обнаружения устройства универсального протокола автоматической настройки (Universal Plug and Play, UPnP) сети разработчиков Microsoft (Microsoft Developer Network, MSDN) или частного протокола обнаружения нормальная работа части воспроизведения может быть нарушена в связи с отсутствием изменений в базовом протоколе RTSP.

Поскольку решение Miracast смешивает серверное соединение RTSP с процедурой соединения WiFi P2P, поток воспроизведения запускают немедленно после получения IP-адреса и номера порта источника; с учетом того, что непосредственная связь между воспроизведением и установлением соединения ограничена только IP-адресом и номером порта, для обеспечения независимости между воспроизведением и установлением соединения может быть предусмотрена передача IP-адреса и номера порта приложениям при помощи средств Intent для осуществления последующих операций. Таким образом, способ обработки информации, предлагаемый в соответствии с вариантами осуществления настоящего изобретения, обеспечивает возможность разделения части установления соединения и части воспроизведения и обеспечения независимости части воспроизведения от части установления соединения с устранением влияния изменений части установления соединения на воспроизведение; конкретная последовательность операций подробно описана ниже.

Для устранения недостатков, присущих известным технологиям, в соответствии с одним из вариантов осуществления настоящего изобретения предлагается способ обработки информации, применяемый к стороне приемника; как показано на фиг. 3, данный способ может включать в себя следующие этапы.

На этапе 310 определяют, получен ли от равноправного устройства через соединение беспроводной связи запрос на удаленное отображение экрана.

Сторона источника может использовать WiFi P2P для поиска близлежащего устройства, поддерживающего WiFi P2P, а также может использовать для поиска равноправного устройства другие протоколы, например, частный протокол обнаружения. При обнаружении стороной источника стороны приемника сторона источника и сторона приемника используют протокол сетевой передачи, поддерживаемый ими обеими, для установления соединения для передачи данных; если для отображения экрана стороне источника необходимо осуществить воспроизведение медиа-данных на стороне приемника в реальном времени, сторона источника передает стороне приемника запрос на дистанционное отображение экрана через установленное ранее соединение для обмена данными.

После получения от равноправного устройства запроса на дистанционное отображение экрана на этапе S320 получают IP-адрес и номер порта данного равноправного устройства.

IP-адрес и номер порта равноправного устройства представляют собой IP-адрес и номер порта стороны источника.

На этапе S330 производят формирование URL, соответствующего медиа-данным, предназначенным для воспроизведения на экране равноправного устройства, в соответствии с IP-адресом и номером порта.

URL формируют в соответствии с IP-адресом и номером порта стороны источника, причем URL может иметь формат типа wfd.

На этапе S340 определяют стандартный проигрыватель, соответствующий URL.

Определение стандартного проигрывателя, соответствующего URL, может быть произведено двумя методами, один из которых состоит в преобразовании существующего проигрывателя в стандартный проигрыватель для обеспечения поддержки им типа формата, соответствующего URL, а второй состоит в создании стандартного проигрывателя, поддерживающего тип формата, соответствующий URL, для обеспечения возможности воспроизведения медиа-данных, соответствующих URL, таким стандартным проигрывателем.

На этапе S350 производят воспроизведение медиа-данных, соответствующих URL, при помощи стандартного проигрывателя.

После определения стандартного проигрывателя медиа-данные, соответствующие URL, могут быть воспроизведены при помощи стандартного проигрывателя, то есть сторона приемника может осуществить воспроизведение медиа-данных, переданных стороной источника, в реальном времени.

В соответствии со способом обработки информации, предлагаемым по данному варианту осуществления настоящего изобретения, в случае получения запроса на дистанционное отображение экрана, переданного передающей стороной, принимающая сторона получает IP-адрес и номер порта передающей стороны и генерирует URL, причем принимающая сторона определяет стандартный проигрыватель, соответствующий URL, и воспроизводит медиа-данные при помощи полученного стандартного проигрывателя. Поскольку стандартный проигрыватель на принимающей стороне в соответствии данным вариантом осуществления настоящего изобретения представляет собой независимый стандартный проигрыватель, такой стандартный проигрыватель на принимающей стороне может обеспечить нормальное воспроизведение медиа-данных, переданных передающей стороной, даже в случае изменения протокола, принятого при обмене данными между передающей стороной и принимающей стороной.

В соответствии с другим вариантом осуществления настоящего изобретения этап S340 по фиг. 3 также может включать в себя следующие этапы, представленные на фиг. 4, для определения стандартного проигрывателя, соответствующего URL, и преобразования существующего проигрывателя.

На этапе S341 получают заранее установленный проигрыватель

Такой проигрыватель может быть уже существующим проигрывателем, и может быть обеспечена возможность немедленного вызова заранее установленного проигрывателя.

На этапе S342 определяют, поддерживает ли заранее установленный проигрыватель тип формата, соответствующий URL.

После получения заранее установленного проигрывателя прежде всего необходимо определить, поддерживает ли данный проигрыватель формат, соответствующий URL. URL может иметь формат типа wfd, например, представлять собой URL типа wfd://xxx.

В случае поддержки заранее установленным проигрывателем типа формата, соответствующего URL, на этапе S343 заранее установленный проигрыватель назначают стандартным проигрывателем, соответствующим URL.

Если заранее установленный проигрыватель поддерживает тип формата, соответствующий URL, заранее установленный проигрыватель может быть использован непосредственно, без его преобразования. Поскольку в настоящее время существующий проигрыватель в общем случае не поддерживает тип формата wfd://xxx URL, то на данном этапе, если заранее установленный проигрыватель поддерживает тип формата, соответствующий URL, можно считать, что заранее установленный проигрыватель был преобразован или представляет собой стандартный проигрыватель, созданный заранее. Заранее установленный проигрыватель назначают стандартным проигрывателем.

В случае отсутствия поддержки заранее установленным проигрывателем типа формата, соответствующего URL, на этапе S344 в качестве заранее установленного проигрывателя устанавливают проигрыватель, поддерживающий тип формата, соответствующий URL, причем проигрыватель, поддерживающий тип формата, соответствующий URL, назначают стандартным проигрывателем, соответствующим URL.

Если заранее установленный проигрыватель не поддерживает тип формата, соответствующий URL, необходимо преобразовать существующий проигрыватель так, чтобы обеспечить поддержку им типа формата, соответствующего URL, и назначить преобразованный заранее установленный проигрыватель стандартным проигрывателем.

На данном этапе может быть использован метод получения видео- и аудиоданных с использованием приемника RTP и последующего запуска их воспроизведения проигрывателем в TunnelRender; поскольку данный метод использует модуль и интерфейс стандартного проигрывателя, необходимо только распространить настройки и параметры поверхности и т. п. по соответствующим интерфейсам в архитектуре MediaPlayerService в соответствии с равномерным процессом. Кроме того, поскольку в данном методе воспроизведение осуществляют через процесс WiFiDisplaySink->RTPReceiver->TunnelRenderer, инициализация реального проигрывателя оболочки была произведена в объекте TunnelRenderer, и поток воспроизведения запускают вызовом setDataSource (), setVideoSurfaceTexture (), start () и других интерфейсов функций.

Однако недостаток вышеописанного варианта состоит в том, что установление соединения и воспроизведение не могут быть разделены, часть воспроизведения не независима, и предполагается, что приложения верхнего уровня автоматически распознают тип воспроизведения через URL для создания потока воспроизведения, в связи с чем процесс инициализации проигрывателя должен быть включен в класс MediaPlayerService с конкретным преобразованием функции setDataSource члена класса MediaPlayerService для обеспечения возможности распознавания URL Miracast; при этом Miracast определяет тип воспроизведения как wfd://xxx, чтобы обеспечить отличие от других протоколов для обеспечения возможности создания корректного потока воспроизведения нижним уровнем; setVideoSurfaceTexture (), start () и т. п. других потоков те же, что и в стандартном потоке вызова воспроизведения.

В соответствии с другим вариантом осуществления настоящего изобретения этап S340 по фиг. 3 также может включать в себя следующие этапы, представленные на фиг. 5, для определения стандартного проигрывателя, соответствующего URL, и преобразования существующего проигрывателя.

На этапе S345 создают стандартный проигрыватель.

Поскольку в общем случае проигрыватель, поддерживающий тип формата, соответствующий URL, в данный момент отсутствует, необходимо создать стандартный проигрыватель. Стандартный проигрыватель имеет стандартный интерфейс и поддерживает обычный стандартный поток вызова проигрывателя. Стандартный проигрыватель поддерживает тип формата, соответствующий URL, например, тип формата URL wfd://xxx.

На этапе S346 определяют, поддерживает ли стандартный проигрыватель тип формата, соответствующий URL.

После создания стандартного проигрывателя также необходимо проверить созданный стандартный проигрыватель, чтобы определить, поддерживает ли стандартный проигрыватель тип формата, соответствующий URL, для обеспечения возможности точного воспроизведения стандартным проигрывателем медиа-данных, соответствующих URL.

В случае поддержки стандартным проигрывателем типа формата, соответствующего на этапе S347 стандартный проигрыватель назначают стандартным проигрывателем, соответствующим URL.

В случае поддержки стандартным проигрывателем типа формата, соответствующего URL, такой стандартный проигрыватель может быть назначен стандартным проигрывателем, соответствующим URL.

Стандартный проигрыватель может быть создан на основе метода непосредственного декодирования видео- и аудиоданных для воспроизведения из Mediareceiver в Directrender, а именно, WiFiDisplaySink->MediaReceiver->DirectRenderer; хотя данный метод содержит поток воспроизведения, такой поток не однороден с потоком стандартного проигрывателя ОС Android; наиболее существенный недостаток данного метода состоит в отсутствии реализации стандартных интерфейсов, таких как setDataSource and setVideoSurfaceTexture, для базового класса MediaPlayerInterface проигрывателя, а также в отсутствии возможности своевременного извещения приложений WiDi об изменении разрешения при изменении разрешения стороной источника, в результате чего перемещения мыши не соответствуют видео изображению; для устранения этих недостатков может быть предусмотрено создание нового класса проигрывателя, называемого FakeMiracastPlayer, причем такой новый класс проигрывателя прозрачен для уровня приложений, уровень приложений может вызывать поток стандартного MediaPlayer, базовая реализация использует исходную оболочку, выполняющую функцию моста, верхний уровень запускает ее с типом формата wfd://xxx URL, а нижний уровень извещает уровень приложений о событии.

Кроме того, FakeMiracastPlayer вызвает исходный WiFiDisplay через стандартный интерфейс setDataSource, передает объект проигрывателя верхнего уровня в WiFiDisplay через интерфейс setListener, что позволяет получить в WiFiDisplay сообщение обратной связи, и передает через setWfdSurface стандартную поверхность в WiFiDisplay для кодирования, декодирования и отображения; таким образом осуществляют согласование интерфейсов.

В соответствии с другим вариантом осуществления настоящего изобретения этап S310 по фиг. 3 также может включать в себя следующие этапы, представленные на фиг. 6, для проверки получения стороной приемника запроса на дистанционное отображение экрана, переданного стороной источника.

На этапе S311 в случае установления соединения для обмена данными с равноправным устройством с использованием сетевого протокола WiFi P2P производят обмен с равноправным устройством информацией о заранее установленных параметрах.

Информация о заранее установленных параметрах может представлять собой информацию о параметрах Miracast, например, о видео/аудио формате, поддерживаемом стороной источника и стороной приемника.

На этапе S312 определяют по информации о заранее установленных параметрах, произведено ли успешное согласование с равноправным устройством.

После обмена информацией о заранее установленных параметрах между стороной источника и стороной приемника обе стороны проверяют полученную в результате такого обмена информацию о заранее установленных параметрах и определяют, обеспечена ли поддержка данного формата их устройствами, т. е. произведено ли успешное согласование.

В случае успешного проведения согласования с равноправным устройством на этапе S313 определяют, что запрос на дистанционное отображение экрана от равноправного устройства получен.

В случае безуспешного проведения согласования с равноправным устройством на этапе S314 определяют, что запрос на дистанционное отображение экрана от равноправного устройства не получен.

Способ и устройство для обработки информации

Патент 2665270