ОБРАБОТКА МУЛЬТИМЕДИЙНЫХ ДАННЫХ Российский патент 2017 года по МПК H04L29/06 

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

Настоящее раскрытие относится к методикам предоставления медиа-данных пользователю, отправляемых по линии связи передачи с изменяющимися задержками передачи.

Настоящее раскрытие может быть осуществлено в сетевых решениях с использованием методик широковещательной передачи, обеспечивающих передачу медиа сегментов. В частности варианты осуществления, обсуждаемые в данном документе, могут использоваться в сценарии с использованием MBMS-передачи, eMBMS-передачи медиа сегмента или других методик широковещательной передачи, таких как Многоадресная IP-рассылка (IP-Multicast) в системе доступа DSL (IPTV) или DVB-S.

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

Методики адаптивной потоковой передачи по HTTP полагаются на выбор клиентом качества медиа-содержимого. Сервер или поставщик содержимого описывает представления со всеми доступными вариантами качества и способ их извлечения в так называемом манифест-файле, например, представления медиа-содержимого могут отличаться в зависимости от различных скоростей передачи битов медиа-содержимого и способа доступа к таким представлениям с сервера. Манифест-файл извлекается по меньшей мере однажды в начале сеанса потоковой передачи и может обновляться в течение сеанса. Динамическая Адаптивная Потоковая Передача по HTTP (DASH, Dynamic adaptive streaming over HTTP) является методикой адаптивной потоковой передачи, которая регулирует медиа поток под доступные в настоящее время скорости передачи битов в линии связи, как это раскрыто в «Динамической адаптивной потоковой передаче по HTTP (DASH) - Часть 1: Описание представления медиа контента и форматы сегментов», ISO/IEC, 23009-l:2012 (E), Версия 2.1c2 («Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats», ISO/IEC 23009-1:2012(E), Version 2.1c2.).

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

Большинству методик адаптивной потоковой передачи по HTTP требуется, чтобы клиент постоянно извлекал медиа сегменты с сервера. В медиа сегменте содержится некоторое количество времени медиа-содержимого (например, 10 секунд медиа-данных). Каждый сегмент конкретного представления медиа-содержимого становится доступным на сервере в конкретное время, указанное в манифесте. Также в манифесте описан способ создания URL-указателей на стороне клиента для загрузки сегментов представления различного качества.

На Фиг. 1 изображен принцип действия извлечения сегментов в DASH-окружении. Клиент, DASH-клиент, осуществляет связь с сервером, DASH-сервером.

Манифест-файл принимается в качестве ответа на сообщение ПОЛУЧИТЬ ПО HTTP манифест-файл (HTTP GET manifest file), 10, и обрабатывается для определения возможных вариантов качества, 11. На следующем этапе, 12, клиент запрашивает данные с самым низким качеством, ПОЛУЧИТЬ ПО HTTP Сегмент№1 Самого Низкого Качества (HTTP GET Segment#1 from Lowest Quality), и выполняется измерение скорости загрузки, 13. Клиент постоянно измеряет скорость передачи битов в линии связи во время приема медиа сегментов, 14, для определения соответствующего качества для приема данных содержимого. Клиент может перейти на представление с другим качеством в любое время, если принято решение о смене представления, 15. В варианте осуществления согласно Фиг. 1 принято решение о запросе медиа-данных со средним качеством, ПОЛУЧИТЬ ПО HTTP Сегмент№2 Среднего Качества (HTTP GET Segment#2 from Medium Quality), 16, и продолжении измерения скорости загрузки, 17.

Манифест-файл должен быть доступным для обработки медиа-содержимого, разделяемого на медиа сегменты. Манифест-файл может распространяться отдельно, в качестве дополнительной возможности внутриполосно с потоком либо посредством отдельного служебного объявления. В случае HLS компании Apple манифесту придается формат файла Списка Воспроизведения в формате m3u8. В случае 3GPP/MPEG DASH манифест является XML-структурой под названием MPD-файл (файл Описания Представления Медиа-содержимого (Media Presentation Description)). MPD содержит списки или средство для генерирования списков из URL-указателей всех медиа сегментов, которые принадлежат сеансу медиа-содержимого и которые используются для извлечения следующего медиа сегмента.

Также существует возможность доставки DASH-медиа сегментов через системы широковещательной передачи, такие как eMBMS (Служба Многоадресной и Широковещательной Передачи Мультимедийного Содержимого в LTE (LTE Multimedia Broadcast Multicast Service)). Широковещательная передача эффективна тогда, когда много пользователей в соте или любой области широковещательной передачи используют одно и тот же качество битового потока. Таким образом, возможна широковещательная передача одной и той же услуги, например, на городских территориях на более высокой скорости передачи битов и на меньшей скорости передачи битов в пригородных территориях одновременно ряду пользователей.

Таким образом, DASH-проигрыватель может принимать содержимое через широковещательную передачу или одноадресную передачу. Однако DASH-проигрыватель не имеет никакой информации о том, находится ли телефон внутри покрытия широковещательной и/или одноадресной передачи. Кодер Реального Времени (Live Encoder, LE) на стороне сервера генерирует MPD и также не знает, будет ли данный файл использован в одноадресной или широковещательной передаче, и во многих случаях одно и то же содержимое будет распространяться как в одноадресной, так и широковещательной передаче.

Кроме того, DASH функционирует посредством сегментирования потока медиа-содержимого на последовательность медиа сегментов. DASH-сегмент обычно подразделяется Кодером Реального Времени (LE) или Сегментатором на множество сегментов транспортного протокола, таких как TCP-сегменты или UDP-сегменты, причем сегменты имеют примерно постоянную продолжительность времени, так называемую продолжительность сегмента.

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

Медиа сегменты имеют размер в среднем в 100 килобайтов, однако некоторые могут быть больше, например, вплоть до 130 килобайтов, а некоторые меньше, например, вплоть до 70 килобайтов, поэтому при генерировании медиа сегментов каждый сегмент, имеющий некоторую продолжительность сегмента, может иметь различное количество TCP-сегментов или соответственно UDP-сегментов. Размер сегмента зависит также от выбранного представления. Клиент по желанию может переключаться между представлениями для адаптации скорости передачи битов. В конце концов, клиент извлекает отсортированную последовательность файлов и воссоединят файлы в сплошной поток медиа-содержимого, и происходит воспроизведение данного содержимого и постоянное запрашивание сегментов.

При задействовании DASH в Широковещательной передаче LTE (eMBMS) Кодер Реального Времени загружает медиа сегменты на Сервер Многоадресной и Широковещательной Передачи (Broadcast Multicast Server, BM-SC). Протокол FLUTE в BM-SC отвечает за разделение медиа-файла на последовательность медиа сегментов, в данном случае UDP-пакетов или UDP-сегментов. Каждому UDP-пакету однозначно присваивается порядковый номер так, чтобы клиент смог снова собрать файл.

Протокол FLUTE IETF (RFC 3926) используется для доставки файла через широковещательную передачу. Сеанс FLUTE-доставки определяется файлом SDP (Session Description Protocol (Протокола Описания Сеанса)), который содержит все параметры, такие как адрес Многоадресной IP-рассылки, UDP-порт, а также и TMGI (Temporary Mobile Group Identity (Временный Идентификатор Мобильной Группы)) для MBMS с целью позволения клиенту принимать мобильную доставку широковещательной передачи файла. Таким образом, FLUTE является протоколом, который позволяет осуществлять доставку файлов по линиям связи широковещательной передачи с использованием UDP в качестве транспортного протокола.

DASH-проигрыватель извлекает последовательность медиа сегментов в качестве независимых файлов с использованием URL, предоставленного в манифесте (называемого MPD в случае DASH). При отправке DASH по MBMS сегменты не извлекаются клиентом из удаленного сервера. Вместо этого сегментам предписывается использование FLUTE через широковещательную передачу.

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

Также в случае широковещательной передачи сегменты имеют размер в среднем в 100-килобайтов, некоторые больше, например, вплоть до 130 килобайтов, а некоторые меньше, например, вплоть до 70 килобайтов, затем при генерировании сегментов каждый сегмент может иметь различное количество UDP-сегментов. В случае широковещательной передачи присутствует однонаправленный канал с постоянной скоростью передачи битов, назначенный для широковещательной передачи. Например, выделенная скорость передачи битов может составлять 1 Мбит/с, что означает, что понадобится 0,5 секунды для передачи сегмента размером в 500 Кбит, а сегменту размером в 1500 Кбит потребуются 1,5 секунды. Различный размер медиа сегментов приводит к изменяющейся продолжительности сегмента в течение передачи сегмента, и, следовательно, временной интервал приема для полного приема медиа сегмента изменяется. Однако DASH-проигрыватель предполагает, что медиа сегменты стали доступными с фиксированным интервалом, а именно, интервалом в продолжительность сегмента.

Кроме того, сквозная задержка от BM-SC к UE отличается от одной системы к другой. Она зависит от того, как были сконфигурированы конкретные параметры в eNodeB, а также и в развертывании сети. Скорость аппаратного обеспечения BM-SC также оказывает влияние на всю систему. По этой причине сквозная задержка может в значительной степени отличаться между различными производителями и даже между двумя системами, обслуживаемыми различными BM-SC при предоставлении медиа сегментов.

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

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

Дополнительно, MPEG DASH использует фактическое время выполнения для вычисления доступности сегмента на сервере. Требуется, чтобы пользовательские оборудования (UE) должным образом синхронизировались по времени с системой так, чтобы UE мог точно рассчитать прием самого последнего медиа-содержимого. Таким образом, все упомянутые аспекты приводят к увеличению изменяющейся продолжительности передачи медиа сегментов по однонаправленному каналу с постоянной скоростью передачи битов и, следовательно, к изменению временных интервалов при приеме медиа сегментов, приводя к ситуации, при которой DASH-проигрыватель, упорядочивая последующий сегмент, может регулярно получать сообщение об ошибке, если медиа сегмент не доступен к необходимому моменту времени.

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

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

Изобретение воплощено в независимых пунктах формулы изобретения. Преимущественные варианты осуществления описаны в зависимых пунктах формулы изобретения.

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

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

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

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

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

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

На Фиг. 1 изображен вариант осуществления для извлечения сегментов в клиенте адаптивной потоковой передачи по HTTP;

На Фиг. 2 изображен вариант осуществления для использования MPD-файла;

На Фиг. 3 изображена блок-схема последовательности операций способа в пользовательском оборудовании согласно одному варианту осуществления;

На Фиг. 4 изображена блок-схема последовательности операций способа в серверном устройстве согласно одному варианту осуществления;

На Фиг. 5 схематично изображено пользовательское оборудование согласно одному варианту осуществления;

На Фиг. 6 схематично изображено серверное устройство согласно одному варианту осуществления.

Подробное описание

В последующем описании, в целях объяснения, а не ограничения, изложены конкретные подробности, такие как конкретные окружения сети и стандарты связи и т.д., для предоставления исчерпывающего понимания настоящего изобретения. Специалисту в данной области техники должно быть очевидным то, что настоящее изобретение может быть осуществлено в других вариантах осуществления, которые отклоняются от этих конкретных подробностей. Например, специалист в данной области техники поймет, что настоящее изобретение может быть осуществлено с любой беспроводной сетью, такой как, например, сеть UMTS, GSM или LTE. В качестве другого примера изобретение может также быть реализовано в беспроводных сетях ближней связи, таких как системы WLAN или Bluetooth, или в проводных сетях, например, в любых основанных на IP сетях, таких как сеть IMS.

Изобретение может быть осуществлено с помощью некоторых широковещательных сетей, например, телевидения, или с помощью гибридных сетей, содержащих широковещательную сеть и мобильную сеть, например, DVB-H (Широковещательная Передача Цифрового Видео для Портативных Устройств (Digital Video Broadcast-Handhelds)) и мобильную сеть 3GPP. В основном, изобретение может быть осуществлено внутри любого сетевого окружения, в котором может распространяться видео-содержимое.

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

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

Термины Кодер Реального Времени (Live Encoder, LE), Сегментатор Реального Времени (Live Segmenter), Транскодер Реального Времени (Live Transcoder) используется синонимично, и обозначают устройство, содержащее любое Головное Видео оборудование, необходимое для создания DASH-содержимого в реальном времени. В частности LE выполнен с возможностью генерирования медиа сегментов из непрерывного медиа-содержимого.

Когда предоставляются новые услуги или приложение или медиа-содержимое, то генерируются соответствующие файлы описания и атрибуты Служебного Объявления (Service Announcement, SA), такие как Описание Пользовательской Услуги (User Service Description, USD) или соответствующий Протокол Описания Сеанса (Session Description Protocol, SDP) или соответствующее Описание Представления Медиа-содержимого (Media Presentation Description, MPD), предоставляющие информацию для запрашивания доступного медиа-содержимого. USD-файл является родительским фрагментом для SDP и MPD, который содержит дополнительные служебные параметры для Пользовательских Служб MBMS (3GPP TS 26.346 Вер-11). Далее используется MPD манифест-файл, который, однако, не следует рассматривать в качестве ограничения настоящего изобретения.

Динамическая Адаптивная Потоковая Передача по HTTP (Dynamic adaptive streaming over HTTP, DASH) является протоколом, используемым для предоставления медиа-содержимого. Упомянутое содержимое может предоставляться по протоколу FLUTE в случае широковещательной передачи. Как уже было упомянуто, DASH-протокол предоставляет в начале сеанса MPD-файл, который содержит информацию о том, как запрашивать последующие медиа сегменты. Среди другой информации предоставляется URL-указатель (URL) медиа сегмента в медиа-содержимом, который должен быть запрошен следующим.

Проигрыватель потоковой передачи является проигрывателем на стороне клиента, выполненным с возможностью предоставления пользователю принятых данных потоковой передачи. Предпочтительно проигрыватель потоковой передачи является проигрывателем адаптивной потоковой передачи по HTTP, выполняемым с возможностью адаптации скорости приема медиа-данных или медиа-содержимого к доступной скорости в линии радиосвязи. Дополнительно проигрыватель потоковой передачи выполнен с возможностью запрашивания медиа сегментов у сервера. В одном варианте осуществления предлагается, чтобы проигрыватель потоковой передачи был DASH-проигрывателем, в частности MPEG-DASH-Проигрывательем. Также могут поддерживаться другие схемы адаптивной потоковой передачи по HTTP, такие как Потоковая Передача по HTTP в Реальном Времени от компании Apple (Apple HTTP Live Streaming).

Клиент может быть любым клиентским устройством, таким как оконечное устройство или Пользовательское Оборудование (User Equipment, UE). В одном варианте осуществления клиент содержит проигрыватель потоковой передачи, такой как DASH-проигрыватель, и процессор для осуществления изобретения. Однако также может иметь место вариант осуществления, при котором проигрыватель потоковой передачи не является частью пользовательского оборудования. Далее термины клиент и пользовательское оборудование (UE) используются в качестве синонимов. Если не упомянуто явно, то термин клиент или UE используется в смысле процессора, осуществляющего изобретение и предоставляющего результат в проигрыватель потоковой передачи.

Серверное устройство может быть любым устройством, обеспечивающим функциональность сервера в системе и выполненным с возможностью выполнения модификации времени доступности сегмента, например, посредством модифицирования MPD. В одном варианте осуществления MPD может быть модифицирован объектом, который функционирует в качестве интерфейса между LE и UE. С этой целью может также присутствовать предоставляющий данную службу выделенный объект. В дополнительном варианте осуществления, MPD модифицируется непосредственно в BM-SC, так как каждый BM-SC знает сквозную задержку системы, которой он управляет.

BM-SC является сервером широковещательной передачи, отвечающим за упаковывание DASH-медиа сегмента в подходящий формат широковещательной передачи. DASH-медиа сегменты обычно больше одного IP-пакета. В случае одноадресной передачи сегмент необходимо отправлять с использованием множества TCP-сегментов, как уже упомянуто. В случае широковещательной передачи сегмент делится на множество FLUTE/UDP-пакетов. В качестве дополнительной возможности, в качестве служебных данных к передаче сегмента рассчитывается и добавляется избыточность FEC. BM-SC повторяет данную процедуру для каждого сегмента. При задействовании DASH через Широковещательную Передачу в LTE (eMBMS) Кодер Реального Времени загружает медиа сегменты с использованием, например WebDAV, в BM-SC. WebDAV является определенным в RFC протоколом для загрузки файлов на HTTP-серверы.

В данном документе под доступностью сегмента понимается то, что «сегмент готов сейчас» быть предоставлен в проигрыватель потоковой передачи. Другое определение подразумевает то, что медиа-содержимое для медиа сегмента сейчас доступно кодеру реального времени, и сегмент становится доступным для распространения во «время доступности сегмента плюс продолжительность сегмента».

Поправочное значение может зависеть от переменности размера сегмента медиа сегментов.

Переменность размера сегмента уже внесена Кодером Реального Времени (Live Encoder, LE). Медиа сегменты, сгенерированные в LE, имеют различные размеры в том смысле, что они содержат различное количество пакетов данные, таких как UDP-пакеты данных или TCP-пакеты данных. LE зависят от производителя. Каждый производитель кодера реального времени имеет свои собственные алгоритмы для повышения эффективности сжатия, сохраняя при этом малой сквозную задержку. Дополнительно учитывается используемый профиль, такой как, например, исключенная или установленная малая сквозная задержка. Это приводит в результате к тому, что кодер реального времени вносит переменность размера сегментов. Дополнительно в случае для передачи передаваемых широковещательных данных предоставляется однонаправленный канал с постоянной скоростью передачи битов в линии связи передачи. Сегментам данных с различными размерами сегментов требуется разное время для передачи по линии связи передачи, что приводит к варьированию интервалов приема медиа сегментов. LE, на основе скорости передачи битов медиа-содержимого и закодированного Буфера Снимков (Picture Buffer), знает, как долго UE должен буферизировать содержимое до начала воспроизведения с целью исключения какой-либо недозагрузки. Таким образом, дополнительная буферизация данных на стороне клиента используется для компенсации воздействия переменных размеров сегментов.

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

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

Далее представлены некоторые наблюдения при функционировании в течение загрузки содержимого в случае одноадресной передачи (UC) и широковещательной передачи (BC).

Далее согласно Фиг. 2 представлена схема MPD. MPD состоит из трех больших компонентов, а именно, периодов, представлений и сегментов. Как изображено на Фиг. 2, компоненты-периоды являются самой внешней частью MPD. Периоды обычно являются большими порциями медиа-содержимого, которые воспроизводятся последовательно. Внутри периода может появляться множество различных кодировок содержимого. Каждый альтернативный вариант называется представлением. Такие альтернативные представления могут иметь, например, различные скорости передачи битов, частоты кадров или разрешений видео. Наконец, каждое представление описывает последовательность сегментов посредством HTTP URL-указателей. Такие URL либо явно описываются в представлении, например, в форме списка воспроизведения, либо описываются через шаблонную конструкцию, что позволяет клиенту извлекать действующий URL для каждого сегмента представления. Формат MPD гибок и может поддерживать другие контейнерные форматы медиа-содержимого, такие как MPEG-2 TS.

В шаблонной форме, как показано в третьем блоке на Фиг. 2, URL создается посредством замены некоторой части шаблона на индекс i. Шаблонная форма может иметь следующий вид в формате функции printf на языке C:

http://ex.com/path/media-segment-%d.3gs

где %d заменяется на значение i, чтобы привести в результате к использованию URL для запрашивания последующих медиа сегментов.

Если нужно запросить сегмент с индексом 10, когда i==10, то URL приобретает следующий вид:

«http://ex.com/path/media-segment-10.3gs», а когда i==11, то адрес представляет собой: http://ex.com/path/media-segment-11.3gs.

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

MPD может дополнительно содержать информацию о буферизации на стороне UE. LE на основе скорости передачи битов медиа-содержимого и закодированного Буфера Снимков знает, как долго UE следует буферизировать содержимое до начала воспроизведения с целью исключения какой-либо недозагрузки, таким образом, LE определяет так называемый minBufferTime (минВремяБуферизации). minBufferTime сообщает UE о том, что упомянутому UE предлагается буферизировать содержимое в течение продолжительности minBufferTime после приема первых битов для компенсации варьированиеа интервалов приема медиа сегментов. Предполагая, что сегменты представления непрерывно доставляются на гипотетической постоянной скорости передачи битов в битах в секунду (бит/с), то, если представление непрерывно доставляется с этой скоростью передачи битов, начиная в любой Точке Доступа к Службе (Service Access Point, SAP), которая является точкой, от которой UE может начать воспроизводить содержимое, которая указана либо посредством @startWithSAP, являющегося атрибутом MPD, либо посредством любого поля Индекс Сегмента (поле Segment Index, ‘sidx’), клиенту может быть гарантировано наличие достаточных данных для непрерывного воспроизведения, обеспечивающих воспроизведение, которое начинается после того, как было принято количество битов, равное minBufferTime * ширину полосы пропускания.

MPD может также содержать availabilityStartTime (НачальноеВремяДоступности), которое является временем, в которое первый сегмент потока становится доступным для загрузки на сервере. Клиент считывает из манифест-файла начальное время «живого» (в реальном времени) потока, в частности, availabilityStartTime. Если клиент должным образом синхронизирован по времени, то он может рассчитать самый последний доступный медиа сегмент на сервере, а именно, время каждой продолжительности медиа сегмента. Это означает, что клиент, при настраивании, может запросить i-ый медиа сегмент, который рассчитан из availabilityStartTime и продолжительности сегмента, отправляемого в MPD, таким образом, availabilityStartTime + i*продолжительность сегмента представляет собой время для запрашивания следующего медиа сегмента.

Подводя итог упрощенному сценарию, в случае одноадресной передачи сервер делает первый медиа сегмент N доступным во время t и предоставляет MPD-файл клиенту, обозначая availabilityStartTime упомянутого сегмента. Далее со времени t пользовательские оборудования (UE) могут начинать загрузку сегментов посредством запрашивания последующих сегментов, при этом клиент выбирает один (или более) подходящих представлений и запрашивает сегменты, соответствующие текущему местному времени на стороне клиента. При запрашивании до времени t сервер отвечает сообщением об ошибке (статусное сообщение HTTP 404-file-not-found (404-файл-не-найден)). Загрузка сегмента занимает некоторое время, по меньшей мере продолжительность сегмента. Поэтому, клиент буферизирует принятое содержимое по меньшей мере в течение minBufferTime до начала представления. minBufferTime предоставляет, в частности, необходимый запас для завершения клиентом загрузки. Это компенсирует продолжительность загрузки и ее варьирование, например, вследствие переменных размеров сегментов.

В случае широковещательной передачи сервер делает первый медиа сегмент N доступным для BM-SC во время t. Далее со времени t BM-SC распространяет сегменты клиенту без ожидания какого-либо запроса. После некоторого времени сегмент N становится доступным в UE, в частности в клиентской кэш-памяти. В течение загрузки данного сегмента DASH-проигрыватель получит от клиента сообщение об ошибке при запрашивании данного сегмента, так как упомянутый сегмент не доступен полностью в кэш-памяти в данное время. availabilityStartTime, обозначенное в MPD-файле и предоставленное в DASH-проигрыватель, описывает в частности время, когда первый сегмент доступен в BM-SC.

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

Предлагается, что на основе времени доступности сегмента, DASH-проигрыватель настраивает свой процесс извлечения сегментов. Для DASH через одноадресную передачу данная доступность сегмента равна времени, в которое сегменты становятся доступными на сервере для передачи. В случае DASH через широковещательную передачу доступность сегмента равна времени, в которое сегменты становятся доступными в UE для DASH-проигрывателя.

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

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

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

На этапе S21 UE принимает первый медиа сегмент. Прием первого сегмента означает, что UE настраивается на непрерывный поток широковещательной передачи. При настраивании на DASH в реальном времени по потоку широковещательной передачи клиент ожидает приема первого полного сегмента. Таким образом, принятые медиа сегменты сохраняются на стороне UE до воспроизведения упомянутых сегментов, что означает предоставление их в DASH-проигрыватель.

На следующем этапе UE определяет время полного приема первого медиа сегмента, S22.

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

На следующем этапе, S24, оцененное время доступности сигнализируется в проигрыватель, такой как, например, DASH-проигрыватель, либо посредством непосредственного обновления MPD-файла, либо посредством добавления нового HTTP-заголовка к HTTP-ответу и отправки его обратно на сервер для обновления MPD-файла.

Далее некоторые этапы с Фиг. 3 объясняются более подробно.

Этап определения времени, S22, согласно Фиг. 3, содержит определение местного времени в пользовательском оборудовании при приеме полного медиа сегмента. UE измеряет время полного приема медиа сегмента. UE фиксирует время события приема с использованием времени своего собственного устройства. Таким образом, UE принимает сигнал, например 13:05, о том, что сегмент был принят.

Этап определения времени, S22, также содержит оценку номера сегмента принятого первого сегмента. Номер сегмента определяется из шаблонной формы или из списка воспроизведения, содержащихся в принятом манифест-файле.

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

На следующем этапе S23 определяется время доступности сегмента следующих сегментов. Это осуществляется через оценивание нового availabilityStartTime посредством взятия измеренного времени приема первого медиа сегмента с поправочным значением, компенсирующим варьирование интервалов приема медиа сегментов так, чтобы проигрыватель потоковой передачи принимал медиа сегменты с постоянным временным интервалом.

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

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

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

minBufferTime считывается из DASH MPD-файла. При генерировании minBufferTime учитывается переменный размер сегмента. Таким образом, LE при установке minBufferTime обладает информацией о переменности сгенерированных медиа сегментов. minBufferTime устанавливается в значение, которое предотвращает недополнение буфера таким образом, что гарантируется, что перед воспроизведением содержимого в буфере доступно достаточно данных. Дополнительно, при генерировании MPD-файла также известна продолжительность сегмента. Продолжительность также учитывается при генерировании minBufferTime, после чего DASH-проигрыватель должен находиться в ожидании по меньшей мере в течение продолжительности сегмента прежде, чем воспроизвести данный сегмент. Поэтому предлагается в одном варианте осуществления вычитать продолжительность сегмента из minBufferTime в случае, когда продолжительность сегмента включена в minBufferTime. Дополнительно предлагается, чтобы minBufferTime модифицировалось через установление его в ноль, и чтобы при этом данное модифицированное minBufferTime предоставлялось в проигрыватель потоковой передачи.

Однако использование minBufferTime не должно рассматриваться в качестве ограничения. Альтернативно, может присутствовать явное поправочное значение переменного размера сегмента, компенсирующее изменяющийся размер сегмента медиа сегментов. Данное значение может предоставляться, например, посредством DASH MPD или даже во фрагменте Описания Пользовательской Услуги (USD). В данном документе оценка доступности сегмента касательно времени следующего сегмента осуществляется посредством поправки времени полного приема первого сегмента на предоставляемое явно поправочное значение.

Далее изображен один пример. В данном примере предлагается оценивать новое время (NewAvst) начала доступности посредством добавления minBufferTime к измеренному времени приема первого сегмента, при этом первый медиа сегмент является текущим медиа сегментом в медиа-содержимом, и вычитания из данного значения продолжительность сегмента. Данный пример должен рассматриваться в качестве примера, а не в качестве ограничения. minBufferTime и продолжительность сегмента могут быть отмасштабированы через коэффициент (α, β) для уменьшения сквозной задержки, при этом все еще удовлетворяя требованию к отсутствию какой-либо недозагрузки по приему данных.

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

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

NewAvst=time_of_first_seg_received+minBufferTime-seg-ment_duration (NewAvst=время_принятого_первого_сегмента+minBufferTime-продолжительность_сегмента)

set minBufferTime=0 (Установить minBufferTime=0)

startNumber=current_index (начальныйНомер=текущий_индекс)

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

Дополнительно предлагается модифицировать minBufferTime посредством установки его в ноль и модифицировать номер сегмента посредством установки ему номер сегмента текущего медиа сегмента в медиа-содержимом. Так как в случае широковещательной передачи сегменты воспроизводятся только тогда, когда сегменты уже приняты на стороне UE, то minBufferTime может быть установлен в ноль, после чего в случае широковещательной передачи нет необходимости ожидать полного приема сегмента при его воспроизведении, так как данный сегмент уже принят. current_index (текущий_индекс) представляет собой некоторый номер текущего сегмента, который может быть извлечен из шаблонной формы или альтернативно из списка воспроизведения, принятых с манифест-файлом. В случае списка воспроизведения все объекты списка, предшествующие текущему номеру, должны быть удалены.

Далее согласно одному примеру более подробно объясняется поправка измеренного времени.

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

availabilityStartTime=1300h (начальноеВремяДоступности=1300 ч)

startNumber=1 (НачальныйНомер =1)

Duration=10sec (Продолжительность =10 с)

minBufferTime=l5sec (минВремяБуферизации =15 с)

Таким образом, время, в которое сегмент стал доступен на сервере, составляет 1300 ч, availabil-ityStartTime. Следует заметить, что в данное время первый сегмент, startNumber 1, был доступен. Следующие сегменты генерируются каждые 10 секунд, тогда продолжительность сегмента Продолжительность составляет 10 секунд. Дополнительно minBufferTime устанавливается в 15 секунд.

Предположим, что клиент настраивается в конкретное время и измеряет, что время приема первого сегмента в клиенте составляет 13:01:10, что означает 70 секунд после начала передачи.

Клиент определяет из принятого URL, http//hhhh/seg-8.3gs, что принятый сегмент имеет индекс 8 сегмента. В случае списка воспроизведения соответственно определяется индекс URL сегмента.

На следующем этапе клиент создает новый MPD со следующими значениями

availabilityStartTime: 13:01:10+15sec-10sec=13:01:15 (НачальноеВреммяДоступности: 13:01:10+15 с-10 с=13:01:15)

startNumber=8 (начальныйНомер =8)

Duration=10sec (Продолжительность =10 с)

minBufferTime=0sec (минВремяБуферизации =0 с)

Таким образом, время полного приема первого сегмента, а именно, с номером 8 сегмента, составляет 13:01:10, к которому minBufferTime, извлеченное из исходного MPD-сообщения, добавляется для компенсации переменности сегментов и дополнительно вычитается продолжительность, так как данный сегмент уже доступен в клиентской кэш-памяти и поэтому нет никакой необходимости в учете продолжительность передачи данного сегмента. Продолжительность сегментов составляет 10 секунд, а minBufferTime устанавливается в 0, так как данное значение уже учтено в availabilityStartTime.

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

В данных примерах следующий сегмент должен быть упорядочен после гипотетической продолжительности сегмента в 10 секунд, следовательно в 13:01:25. В это время следующий сегмент становится доступным и сохраняется в буфере, затем это уже задача LE обеспечить данные таким образом, чтобы они стали доступны на стороне пользователя, например, посредством учета minBufferTime.

В дополнительном примере предлагается поправлять оцененное время доступности сегмента к availabilityStartTime первого сегмента в медиа-содержимом, подобно первому сегменту в настроенном DASH-потоке. Оценка основана на определении номера первого сегмента в медиа-содержимом, обычно имеющего номер 1.

Таким образом, прием первого сегмента полного потока медиа-содержимого используется для поправки доступности первого сегмента фактического DASH-потока. Данное решение преимущественно в случае, когда MPD содержит значение presentationTimeOffset (СмещениеВремениПредставления), которое предотвращает модифицирование startNumber в MPD-файле. presentationTimeOffset описывает положение сегмента на временной шкале медиа-содержимого.

В данном случае поправочное значение обновляется посредством вычитания продолжительности сегмента, прошедшей между первым медиа сегментом в медиа-содержимом и текущим (SegmentIndex (ИндексСегмента)) медиа сегментом в медиа-содержимом из minBufferTime. Данный пример следует рассматривать в качестве примера, а не в качестве ограничения. minBufferTime и продолжительность сегмента могут быть отмасштабированы с помощью коэффициента (α, β) для уменьшения сквозной задержки, при этом все еще удовлетворяя требованию к отсутствию какой-либо недозагрузки по приему данных.

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

NewAvst=time_of_first_seg_received+min_buffer-((SegmentIndex-startNumber)*SegDuration)(NewAvst=время_принятого_первого_сегмента+мин_буферизация-((ИндексСегмента-начальныйНомер)*ДлительностьСегмента))

set minbuffertime=0 (установить минВремяБуферизации=0)

В данном документе, NewAvst является новым рассчитанным временем доступности, time_of_first_seg_received является временем приема первого сегмента, Segmentlndex является номером первого принятого сегмента или, другими словами, текущего сегмента и startNumber является номером первого сегмента в сеансе медиа-содержимого, который предпочтительно устанавливается в 1. Таким образом, если определенный индекс сегмента составляет 8, и индекс первого сегмента составлял 1, то текущий принятый медиа сегмент имеет индекс 7.

Упомянутый расчет объясняется далее на основе одного примера. Предположим, что исходный MPD содержит следующую информацию:

availabilityStartTime=1300h (начальноеВремяДоступности=1300 ч)

startNumber=1 (НачальныйНомер =1)

Duration=10sec (Продолжительность =10 с)

minBufferTime=l5sec (минВремяБуферизации =15 с)

и время первого приема сегмента составляет 13:01:10, таким образом через 70 секунд после начала всего сеанса медиа-содержимого, такого как DASH-сеанс. Дополнительно UE выполнен с возможностью считывания номера принятого сегмента, например, из принятого сообщения с запросом URL.

Принятый HTTP-запрос первого принятого сегмента может иметь следующий формат:

http//hhhh/seg-8.3gs

Таким образом, как объяснено выше, определенный номер сегмента равен соответственно 8. На основе данного определения номера сегмента клиент вычисляет новое значение MPD следующим образом:

availabilityStartTime: 13:01:10+15sec-(8-1)*10)=13:00:15 (НачальноеВреммяДоступности: 13:01:10+15 с-(8-1)*10)=13:00:15)

startNumber=1 (начальныйНомер =1)

Duration=10sec (Продолжительность =10 с)

minBufferTime=0sec (минВремяБуферизации =0 с)

Предлагается модифицировать minBufferTime через установку его в ноль и устанавливать номеру startNumber сегмента номер сегмента первого сегмента в медиа-содержимом.

Цель определения времени доступности сегмента для первого сегмента также в данном примере заключается в определении времен доступности сегментов для всех последующих сегментов. Вследствие поправки клиент может использовать данное время доступности сегмента первого принятого сегмента для определения времен доступности сегментов для всех последующих сегментов.

Возвратимся к Фиг. 3, на этапе S23 определяется время доступности сегмента для следующего медиа сегмента посредством модифицирования времени полного приема первого медиа сегмента на поправочное значение, причем время доступности сегмента для следующего медиа сегмента может основываться либо на оценке времени доступности первого принятого сегмента (текущего медиа сегмента), либо на времени доступности, оцененном для первого сегмента в DASH-потоке. Обычно, независимое от оценки индекса сегмента значение времени полного приема первого медиа сегмента модифицируется на поправочное значение, компенсирующее варьирование интервала приема медиа сегментов, например, вследствие изменяющегося размера сегмента.

На следующем этапе Фиг. 3, S24, оцененное время доступности сигнализируется в проигрыватель, такой как, например, DASH-проигрыватель либо посредством непосредственного обновления MPD-файла, либо добавления нового HTTP-заголовка к HTTP-ответу и отправки его обратно на сервер для обновления MPD-файла.

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

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

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

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

В дополнительном варианте осуществления предлагается модифицировать доступность сегмента на стороне сервера.

Далее, согласно Фиг.4, представлен один вариант осуществления.

На первом этапе, S31, сервер берет исходное availabilityStartTime для конкретного сеанса медиа-содержимого, такого как DASH-поток. Исходное availabilityStartTime означает время, в которое сегмент доступен для передачи на сервере и которое рассчитано серверным устройством.

На следующем этапе, S32, предлагается, чтобы объект на стороне сервера модифицировал availabilityStartTime для соответствия правилу «новый сегмент становится доступным каждую продолжительность сегмента на стороне UE». Таким образом, предлагается использовать поправочное значение, которое компенсирует варьирование интервалов приема медиа сегментов так, чтобы медиа сегменты стали доступными в проигрывателе потоковой передачи с постоянным временным интервалом.

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

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

Так как сегменты могут иметь различный размер, то значение minBufferTime включено в availabilityStartTime для предотвращения запрашивания пользовательским оборудованием (UE) несуществующего сегмента. Как уже упомянуто, посредством генерирования minBufferTime Кодер Реального Времени учитывает варьирование размера сегментов и добавляет упомянутое значение к availabilityStartTime. Таким образом, размер minBufferTime компенсирует по меньшей мере варьирование размеров сегментов, которые известны кодеру реального времени. Поэтому предлагается использовать minBufferTime для обеспечения того, чтобы последующий медиа сегмент становился доступным каждую продолжительность сегмента на стороне UE.

Дополнительно предлагается, чтобы поправочное значение содержало сквозную системную задержку (max_offset (макс_смещение)).

Таким образом, предлагается, чтобы сервер добавлял к availabilityStartTime поправочное значение, учитывающее сквозную системную задержку и переменность размера сегмента. Время сквозной задержки является временем, необходимым для транспортировки сегмента от BM-SC в UE, которое известно серверу. Однако каждый кодер реального времени имеет свое собственное правило для «целевой скорости передачи битов», которое управляет различными размерами сегментов и их переменностью. Поэтому, добавленное значение зависит предпочтительно от варианта реализации Кодера Реального Времени и используемого профиля задержки, например, исключенной или установленной малой сквозной задержкой.

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

Таким образом, новое время NewAvst начала доступности вычисляется посредством взятия исходного времени avst__org начала доступности, определенного сервером и добавления MinBufTerTime, min_buffer для включения minBufferTime с целью предотвращения запрашивания несуществующего сегмента. Дополнительно также добавляется значение max_offset, которое является максимальной сквозной задержкой. Упомянутое значение также известно серверному устройству. LE может обслуживать разные системы с разными сквозными задержками, и значение max_offset обеспечивает максимальную возможную задержку доставки сегментов. Дополнительно добавляется значение maxdriftahead.

New Avst=avst__org+min_buffer+max_offset+maxdriftahead

(Новое Avst=avst__org+мин_буфер+макс_смещение+максдрейфвперед)

Дополнительно следует заметить, что поправочное значение зависит от варианта реализации Кодера Реального Времени и профиля задержки.

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

В одном варианте осуществления предлагается модифицировать availibilityStartTime в MPD-файле на стороне сервера, при этом недавно созданное MPD содержит модифицированное значение Avst. В одном варианте осуществления предлагается устанавливать то, чтобы minBufferTime можно было бы устанавливать в ноль (minbuffertime=0), в частности в случае, когда клиенту не позволено изменять упомянутый таймер. В предпочтительном варианте осуществления модифицированное minBufferTime предоставляется в проигрыватель потоковой передачи с манифест-файлом.

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

UE содержит приемник 42, выполненный с возможностью приема первого медиа сегмента. Дополнительно UE 41 содержит определительную логическую схему 44, выполненную с возможностью определения времени приема первого медиа сегмента. Дополнительно UE содержит оценочную логическую схему 45, выполненную с возможностью оценивания времени доступности медиа сегмента для запрашивания последующих медиа сегментов посредством модифицирования времени приема первого медиа сегмента на поправочное значение, компенсирующее варьирование интервалов приема медиа сегментов так, чтобы проигрыватель потоковой передачи принимал медиа сегменты с постоянным временным интервалом. Кроме того имеется отправитель 46, выполненный с возможностью сигнализации оцененного времени доступности в проигрыватель потоковой передачи.

Дополнительно UE может содержать модифицирующую логическую схему (не изображена) для модифицирования манифест-файла. Модифицирование может быть осуществлено любым предпочтительным способом, например, посредством модифицирования HTTP-заголовка или добавления нового HTTP-заголовка для отправки его в проигрыватель потоковой передачи. В предпочтительном решении манифест-файл, такой как MPD-файл, модифицируется непосредственно и предоставляется в проигрыватель потоковой передачи.

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

Функциональные блоки 42-46, описанные выше могут быть реализованы в UE 41 посредством программных модулей соответствующей компьютерной программы, содержащей кодовое средство, которое, при запуске процессором, предписывает UE 41 выполнять вышеописанные действия и процедуры. Процессор может содержать один Центральный Блок Обработки (Central Processing Unit, CPU) или может содержать два или более блоков обработки. Например, процессор может включать в себя микропроцессор общего назначения, процессор набора команд и/или связанные наборы микросхем и/или микропроцессор особого назначения, такой как Специализированная Интегральная Схема (Application Specific Integrated Circuit, ASIC). Процессор может также содержать хранилище для целей кэширования.

Каждая компьютерная программа может переноситься компьютерным программным продуктом в UE 41 в виде запоминающего устройства, имеющего считываемый компьютером носитель и соединяемого с процессором. Компьютерный программный продукт или запоминающее устройство таким образом содержат считываемый компьютером носитель, на котором хранится компьютерная программа, например, в виде модулей компьютерной программы. Например, запоминающее устройство может быть флэш-памятью, Запоминающим Устройством с Произвольным Доступом (Random-Access Memory, RAM), Постоянным Запоминающим Устройством (Read-Only Memory, ROM) или Электрически Стираемым Программируемым ROM (Electrically Erasable Programmable ROM, EEPROM), и в альтернативных вариантах осуществления программные модули могут распространяться на различных компьютерных программных продуктах в виде запоминающих устройств внутри UE 41.

На Фиг. 6 схематично изображены примерные структуры для реализации вышеописанных концепций в серверном устройстве 51, которое выполнено для предоставления медиа-содержимого, содержащего медиа сегменты, в проигрыватель потоковой передачи, причем медиа сегменты передаются через широковещательную передачу. Серверное устройство 51 содержит приемник 54, выполненный с возможностью оценивания исходного времени доступности медиа сегмента, указывающего время, в которое медиа сегмент становится доступным для загрузки в приемнике серверного устройства, таким образом исходное availibilityStartTime. Дополнительно серверное устройство 51 содержит процессор 53, выполненный с возможностью оценивания времени доступности медиа сегмента для запрашивания последующих медиа сегментов посредством модифицирования исходного времени доступности медиа сегмента, исходного availibilityStartTime, на поправочное значение, компенсирующее варьирование интервалов приема медиа сегментов так, чтобы медиа сегменты стали доступными в проигрывателе потоковой передачи с постоянным временным интервалом. Кроме того имеется отправитель 52, выполненный с возможностью сигнализации оцененного времени доступности в проигрыватель потоковой передачи.

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

Функциональные блоки 52-54, описанные выше могут быть реализованы в серверном устройстве 51 посредством программных модулей соответствующей компьютерной программы, содержащей кодовое средство, которое, при запуске процессором, предписывает серверному устройству 51 выполнять вышеописанные действия и процедуры. Процессор может содержать один Центральный Блок Обработки (Central Processing Unit, CPU) или может содержать два или более блоков обработки. Например, процессор может включать в себя микропроцессор общего назначения, процессор набора команд и/или связанные наборы микросхем и/или микропроцессор особого назначения, такой как Специализированная Интегральная Схема (Application Specific Integrated Circuit, ASIC). Процессор может также содержать хранилище для целей кэширования.

Каждая компьютерная программа может нестись компьютерным программным продуктом в серверном устройстве 51 в виде запоминающего устройства, имеющего считываемый компьютером носитель и соединяемого с процессором. Компьютерный программный продукт или запоминающее устройство таким образом содержат считываемый компьютером носитель, на котором хранится компьютерная программа, например, в виде модулей компьютерной программы. Например, запоминающее устройство может быть флэш-памятью, Запоминающим Устройством с Произвольным Доступом (Random-Access Memory, RAM), Постоянным Запоминающим Устройством (Read-Only Memory, ROM) или Электрически Стираемым Программируемым ROM (Electrically Erasable Programmable ROM, EEPROM), и в альтернативных вариантах осуществления программные модули могут распространяться на различных компьютерных программных продуктах в виде запоминающих устройств внутри серверного устройства 51.

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

Изобретение относится к способам предоставления медиасодержимого в сценарии широковещательной передачи в проигрыватель потоковой передачи, такой как DASH-проигрыватель. Техническим результатом является устранение варьирования интервалов приема медиасегментов за счет осуществления оценки времени доступности сегмента для запрашивания последующих медиасегментов. Предложен способ предоставления медиасодержимого, содержащего медиасегменты, в проигрыватель потоковой передачи. Медиасегменты передают от серверного устройства в проигрыватель потоковой передачи через широковещательную передачу. Способ содержит выполняемые в пользовательском оборудовании этапы, на которых принимают первый медиасегмент, определяют время приема первого медиасегмента. Далее согласно способу оценивают время доступности медиасегмента для запрашивания последующих медиасегментов посредством модифицирования определенного времени приема первого медиасегмента на поправочное значение, компенсирующее варьирование интервалов приема медиасегментов так, чтобы проигрыватель потоковой передачи принимал медиасегменты с постоянным временным интервалом. 4 н. и 26 з.п. ф-лы, 6 ил.

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

принимают первый медиасегмент (S21);

определяют время приема первого медиасегмента (S22);

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

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

2. Способ по п. 1,

в котором этап определения (S22) времени приема первого медиасегмента содержит этап, на котором определяют местное время в пользовательском оборудовании при полном приеме первого медиасегмента.

3. Способ по п. 1,

в котором этап определения (S22) времени приема первого медиасегмента содержит оценку номера сегмента принятого первого сегмента.

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

5. Способ по п. 1, в котором постоянный временной интервал является продолжительностью сегмента.

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

7. Способ по п. 6, в котором поправочное значение содержит minBufferTime, являющееся указанием изменяющегося размера сегмента посредством указания времени на буферизацию медиасодержимого до начала воспроизведения упомянутого медиасодержимого.

8. Способ по п. 5 или 6, в котором minBufferTime принимают в манифест-файле, принятом от серверного устройства.

9. Способ по одному из пп. 1-7, в котором этап оценивания времени (Avst) доступности медиасегмента основан на оценке времени (time_of_first_seg_received) доступности принятого первого медиасегмента, при этом первый медиасегмент является текущим медиасегментом в медиасодержимом.

10. Способ по п. 9, в котором поправочное значение обновляют посредством вычитания продолжительности сегмента из minBufferTime, NewAvst=time-_of_first_seq_received+minBufferTime-segment_duration, где segment_duration представляет собой продолжительность сегмента.

11. Способ по одному из п.п. 7, 10, в котором minBufferTime модифицируют посредством установки его в ноль, и номеру сегмента устанавливают номер сегмента текущего медиасегмента в медиасодержимом.

12. Способ по одному из пп. 1-7, в котором этап оценивания времени доступности медиасегмента основан на оценке времени (time_of_first_seg_received) доступности принятого первого медиасегмента и на первом (startNumber) медиасегменте в медиасодержимом, причем startNumber представляет собой начальный номер сегмента.

13. Способ по п. 12, в котором поправочное значение обновляют посредством вычитания продолжительности сегмента, прошедшей между первым медиасегментом в медиасодержимом и текущим (Segmentlndex) медиасегментом в медиасодержимом, из minBufferTime, NewAvst=time_of_first_seq_received+minBufferTime-((Segmentlndex-startNumber)*segment duration), где Segmentlndex представляет собой индекс сегмента.

14. Способ по п. 13, в котором minBufferTime модифицируют посредством установки его в ноль, и номер сегмента устанавливают равным номеру сегмента первого сегмента в медиасодержимом.

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

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

17. Способ по п. 1, в котором этап сигнализации оцененного времени доступности в проигрыватель потоковой передачи (S24) содержит этап, на котором модифицируют HTTP-заголовок или добавляют новый HTTP-заголовок к HTTP-ответу и отправляют его в проигрыватель потоковой передачи.

18. Способ по одному из пп. 1, 14, в котором этап сигнализации оцененного времени доступности в проигрыватель потоковой передачи (S24) содержит этап, на котором дополнительно сигнализируют модифицированное minBufferTime и номер сегмента.

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

оценивают исходное время доступности медиасегмента, указывающего время, в которое медиасегмент становится доступным для передачи в серверном устройстве (S31);

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

сигнализируют оцененное время доступности медиасегмента в проигрыватель потоковой передачи (S33).

20. Способ по п. 19, в котором поправочное значение учитывает изменяющийся размер сегмента медиасегментов.

21. Способ по п. 19 или 20, в котором поправочное значение содержит minBufferTime, являющееся указанием изменяющегося размера сегмента посредством указывания времени на буферизацию медиасодержимого до начала воспроизведения упомянутого медиасодержимого.

22. Способ по одному из пп. 19-20, в котором поправочное значение содержит сквозную системную задержку (max_offset).

23. Способ по одному из пп. 19-20, в котором поправочное значение содержит дополнительно значение (maxdriftahead) смещение вперед, указывающее максимальное смещение часов вперед.

24. Способ по одному из пп. 19-20, в котором поправочное значение зависит от варианта реализации Кодера Реального Времени и профиля задержки.

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

26. Способ по п. 24, в котором дополнительно minBufferTime модифицируют посредством установки его в ноль, и в котором модифицированное minBufferTime предоставляют в проигрыватель потоковой передачи с файлом манифеста.

27. Устройство пользовательского оборудования (41), выполненное с возможностью предоставления медиасодержимого, содержащего медиасегменты, в проигрыватель потоковой передачи, причем медиасегменты передаются от серверного устройства в проигрыватель потоковой передачи через широковещательную передачу, при этом устройство содержит:

приемник (42), выполненный с возможностью приема первого медиасегмента;

определительную логическую схему (44), выполненную с возможностью определения времени приема первого медиасегмента;

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

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

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

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

30. Серверное устройство (51), выполненное с возможностью предоставления медиасодержимого, содержащего медиасегменты, в проигрыватель потоковой передачи, причем медиасегменты передаются от серверного устройства в проигрыватель потоковой передачи через широковещательную передачу, при этом устройство содержит:

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

процессор (53), выполненный с возможностью оценивания времени доступности медиасегмента для запрашивания последующих медиасегментов посредством модифицирования исходного времени доступности медиасегмента на поправочное значение,

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

отправитель (52), выполненный с возможностью сигнализации оцененного времени доступности в проигрыватель потоковой передачи.