Обработка мультимедийных данных

Обработка мультимедийных данных

Иллюстрации

Показать все

Реферат

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

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

Настоящее раскрытие может быть осуществлено в сетевых решениях с использованием методик широковещательной передачи, обеспечивающих передачу медиа сегментов. В частности варианты осуществления, обсуждаемые в данном документе, могут использоваться в сценарии с использованием 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 до воспроизведения упомянутых сегментов, что означа