RU2606064C2

RU2606064C2 - Потоковая передача с управлением качеством

Info

Publication number: RU2606064C2
Application number: RU2015104261A
Authority: RU
Inventors: Юрий РЕЗНИК; Эдуардо АСБАН; Чжифэн ЧЕН; Рахул ВАНАМ
Original assignee: Вид Скейл, Инк.
Priority date: 2012-07-10
Filing date: 2013-07-10
Publication date: 2017-01-10
Also published as: KR20190026965A; RU2015104261A; KR102283241B1; JP7072592B2; KR20200037463A; CN104488246A; TW201424314A; KR20170083641A; HK1204513A1; US10178140B2; EP2873212B1; US10880349B2; JP6697879B2; JP2015531186A; EP2873212A1; US20140019593A1; CN104488246B; CN109618185A; TWI610554B; WO2014011720A1

Abstract

Изобретение относится к области связи. Технический результат – достижение эффективности при использовании полосы пропускания сети путем адаптации к сложности и качеству кодированного видеосигнала. Для этого, чтобы обеспечивать коммутацию на основе качества в клиенте потоковой передачи, клиент может иметь доступ к информации относительно качества кодированного сегмента и/или субсегмента. Связанная с качеством информация может включать в себя любое число дополнительных показателей качества, связанных с кодированным сегментом и/или субсегментом кодированного видеопотока. Добавление связанной с качеством информации может быть выполнено посредством включения связанной с качеством информации в файл манифеста, включающий в себя связанную с качеством информацию, в индексы сегментов, сохраненные в индексном файле сегментов, и/или предоставления дополнительных файлов со связанной с качеством информации сегментов и предоставления ссылки на информацию из MPD-файла. После приема связанной с качеством информации клиент может запрашивать и принимать поток, который имеет более низкую скорость передачи битов, за счет этого экономя полосу пропускания при одновременном поддержании качества потокового контента. 2 н. и 15 з.п. ф-лы, 22 ил., 2 табл.

Description

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

[0001] Данная заявка испрашивает приоритет по предварительной заявке на патент США № 61/669983, поданной 10 июля 2012 года, и предварительной заявке на патент США № 61/835105, поданной 14 июня 2013 года, содержимое которых в силу этого содержится по ссылке в данном документе.

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

[0002] Стандарт динамической адаптивной потоковой HTTP-передачи (DASH) MPEG/3GPP может задавать инфраструктуру для проектирования доставки с адаптацией полосы пропускания потокового контента по беспроводным и проводным сетям. Тем не менее, MPEG/3GPP DASH-стандарт может не предоставлять механизм для считывания и адаптации к сложности и качеству кодированного видеоконтента. Это может вводить определенную неэффективность при использовании ресурсов полосы пропускания сети и может приводить к субоптимальным возможностям работы пользователей.

Сущность изобретения

[0003] Раскрыты системы, способы и инструментарий для того, чтобы обеспечивать оптимизации на основе качества для процесса доставки потокового контента. Оптимизация может принимать форму коммутации на основе качества (например, которая также может упоминаться как "управление качеством" или "с учетом качества" и т.п.). Коммутация на основе качества может обеспечиваться в инфраструктуре адаптивной потоковой HTTP-передачи. Если клиент имеет информацию, связанную с качеством каждого из кодированных сегментов, которые он принимает, то клиент может обеспечивать коммутацию на основе качества. Могут быть предусмотрены различные способы, посредством которых информация относительно качества сегмента может передаваться клиенту. Эта связь позволяет предоставлять адаптацию на основе качества в клиенте.

[0004] Чтобы обеспечивать решения на основе качества в клиенте потоковой передачи, клиент может иметь доступ к информации относительно качества каждого кодированного сегмента. Связанная с качеством информация может включать в себя один или более показателей качества, связанных с кодированным сегментом и/или кодированным субсегментом. Добавление связанной с качеством информации может быть выполнено посредством включения связанной с качеством информации в файл манифеста (например, в файл .mdp). Например, связанная с качеством информация может быть включена в индексы сегментов, сохраненные в индексном файле сегментов (например, в MP4- или M4S-файлах), и/или дополнительные файлы со связанной с качеством информацией сегментов могут предоставляться, например, посредством предоставления ссылки на информацию из файла манифеста. После приема связанной с качеством информации клиент может запрашивать и/или принимать поток, который имеет более низкую скорость передачи битов, за счет этого экономя полосу пропускания при одновременном поддержании качества потокового контента. Например, клиент может запрашивать и/или принимать поток с более низкой скоростью передачи битов, который имеет качество, которое является приемлемым для клиента для потока.

[0005] Способ коммутации контента в беспроводном приемо-передающем модуле (WTRU) может заключать в себе прием информации качества, связанной с сегментом контента, который кодирован как множество потоков. Сегмент контента может формировать часть периода контента. Поток сегмента контента может выбираться в качестве функции от соответствующей информации скоростей передачи битов и качества, ассоциированной с потоками. Выбранный поток может запрашиваться и/или приниматься посредством WTRU.

[0006] Способ коммутации контента в беспроводном приемо-передающем модуле (WTRU) может заключать в себе прием информации качества, связанной с сегментом контента, который кодирован как множество потоков. Субсегмент контента может формировать часть сегмента контента, который может формировать часть периода контента. Поток сегмента контента может выбираться в качестве функции от соответствующей информации скоростей передачи битов и качества, ассоциированной с потоками. Выбранный поток может запрашиваться и/или приниматься посредством WTRU.

[0007] Способ коммутации с управлением качеством в беспроводном приемо-передающем модуле (WTRU), способ может заключать в себе прием первого потока контента на первой скорости передачи битов. Первый поток контента может иметь, по меньшей мере, пороговый уровень качества. Может приниматься информация качества, связанная с сегментом периода первого потока контента. Второй поток контента на второй скорости передачи битов может определяться на основе информации качества приема. Вторая скорость передачи битов может быть ниже первой скорости передачи битов, и второй поток контента может иметь, по меньшей мере, пороговый уровень качества. Второй поток контента может запрашиваться и/или приниматься на второй скорости передачи битов.

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

[0008] Фиг. 1A является схемой системы для примерной системы связи, в которой могут быть реализованы один или более раскрытых вариантов осуществления.

[0009] Фиг. 1B является схемой системы примерного беспроводного приемо-передающего модуля (WTRU), который может использоваться в системе связи, проиллюстрированной на фиг. 1A.

[0010] Фиг. 1C является схемой системы примерной сети радиодоступа и примерной базовой сети, которые могут использоваться в системе связи, проиллюстрированной на фиг. 1A.

[0011] Фиг. 1D является схемой системы примерной сети радиодоступа и другой примерной базовой сети, которые могут использоваться в системе связи, проиллюстрированной на фиг. 1A.

[0012] Фиг. 1E является схемой системы примерной сети радиодоступа и другой примерной базовой сети, которые могут использоваться в системе связи, проиллюстрированной на фиг. 1A.

[0013] Фиг. 2 является графиком, иллюстрирующим пример MOS-колебаний при кодировании на основе скорости передачи битов и кодировании на основе качества.

[0014] Фиг. 3 является графиком, иллюстрирующим примерные распределения MOS-оценок для кодирования на основе скорости передачи битов и кодирования на основе качества.

[0015] Фиг. 4 является схемой, иллюстрирующей пример архитектуры системы адаптивной потоковой HTTP-передачи.

[0016] Фиг. 5 является схемой, иллюстрирующей пример потенциала для уменьшения скорости передачи битов посредством использования адаптации на основе качества.

[0017] Фиг. 6 является схемой, иллюстрирующей пример состояний заполненности клиентского буфера.

[0018] Фиг. 7 является схемой, иллюстрирующей представление модели работы DASH-клиента потоковой передачи, когда не предоставляется информация качества.

[0019] Фиг. 8 является схемой, иллюстрирующей представление модели работы DASH-клиента потоковой передачи с использованием информации качества.

[0020] Фиг. 9 является схемой, иллюстрирующей пример дорожки информации качества, добавленной к DASH-представлению.

[0021] Фиг. 10 является схемой, иллюстрирующей пример информации качества, сохраненной в поле mdat в DASH-сегменте.

[0022] Фиг. 11 является схемой, иллюстрирующей пример информации качества, сохраненной в поле free или skip в DASH-сегменте.

[0023] Фиг. 12 является схемой, иллюстрирующей пример высокоуровневой архитектуры DASH-системы.

[0024] Фиг. 13 является схемой, иллюстрирующей пример логических компонентов клиентской DASH-модели.

[0025] Фиг. 14 является схемой, иллюстрирующей пример высокоуровневой модели данных мультимедийного DASH-представления.

[0026] Фиг. 15 является схемой, иллюстрирующей пример кодированного видеопотока с тремя различными типами кадров.

[0027] Фиг. 16 является схемой примера шести различных DASH-профилей.

[0028] Фиг. 17 является блок-схемой, иллюстрирующей пример видеокодера на основе блоков.

[0029] Фиг. 18 является блок-схемой, иллюстрирующей пример видеодекодера на основе блоков.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

[0031] Фиг. 1A является схемой примерной системы 100 связи, в которой могут быть реализованы один или более раскрытых вариантов осуществления. Система 100 связи может представлять собой систему с множественным доступом, которая предоставляет такое содержимое, как речь, данные, видео, обмен сообщениями, широковещательная передача и т.д., нескольким беспроводным пользователям. Система 100 связи может предоставлять возможность нескольким беспроводным пользователям осуществлять доступ к такому содержимому посредством совместного использования системных ресурсов, включающих в себя беспроводную полосу пропускания. Например, системы 100 связи могут использовать один или более способов доступа к каналу, таких как множественный доступ с кодовым разделением каналов (CDMA), множественный доступ с временным разделением каналов (TDMA), множественный доступ с частотным разделением каналов (FDMA), ортогональный FDMA (OFDMA), FDMA с одной несущей (SC-FDMA) и т.п.

[0032] Как показано на фиг. 1A, система 100 связи может включать в себя беспроводные приемо-передающие модули 102a, 102b, 102c и/или 102d (WTRU) (которые в общем или совместно могут упоминаться как WTRU 102), сеть 103/104/105 радиодоступа (RAN), базовую сеть 106/107/109, коммутируемую телефонную сеть 108 общего пользования (PSTN), Интернет 110 и другие сети 112, хотя следует принимать во внимание, что раскрытые варианты осуществления рассматривают любое число WTRU, базовых станций, сетей и/или сетевых элементов. Каждый из WTRU 102a, 102b, 102c, 102d может представлять собой любой тип устройства, выполненного с возможностью работать и/или обмениваться данными в беспроводном окружении. В качестве примера, WTRU 102a, 102b, 102c, 102d могут быть выполнены с возможностью передавать и/или принимать беспроводные сигналы и могут включать в себя пользовательское оборудование (UE), мобильную станцию, стационарное или мобильное абонентское устройство, устройство поискового вызова, сотовый телефон, персональное цифровое устройство (PDA), смартфон, переносной компьютер, нетбук, персональный компьютер, беспроводной датчик, бытовую электронную аппаратуру и т.п.

[0033] Системы 100 связи также могут включать в себя базовую станцию 114a и базовую станцию 114b. Каждая из базовых станций 114a, 114b может представлять собой любой тип устройства, выполненного с возможностью взаимодействовать в беспроводном режиме, по меньшей мере, с одним из WTRU 102a, 102b, 102c, 102d, чтобы упрощать доступ к одной или более сетей связи, таких как базовая сеть 106/107/109, Интернет 110 и/или сети 112. В качестве примера, базовые станции 114a, 114b могут представлять собой базовую приемо-передающую станцию (BTS), узел B, усовершенствованный узел B, домашний узел B, домашний усовершенствованный узел B, узловой контроллер, точку доступа (AP), беспроводной маршрутизатор и т.п. Хотя базовые станции 114a, 114b проиллюстрированы как один элемент, следует принимать во внимание, что базовые станции 114a, 114b могут включать в себя любое число соединенных базовых станций и/или сетевых элементов.

[0034] Базовая станция 114a может быть частью RAN 103/104/105, которая также может включать в себя другие базовые станции и/или сетевые элементы (не показаны), такие как контроллер базовой станции (BSC), контроллер радиосети (RNC), ретрансляционные узлы и т.д. Базовая станция 114a и/или базовая станция 114b могут быть выполнены с возможностью передавать и/или принимать беспроводные сигналы в конкретной географической области, которая может упоминаться как сота (не показана). Сота дополнительно может быть разделена на секторы соты. Например, сота, ассоциированная с базовой станцией 114a, может быть разделена на три сектора. Таким образом, в одном варианте осуществления, базовая станция 114a может включать в себя три приемо-передающих устройства, к примеру, по одному для каждого сектора соты. В другом варианте осуществления, базовая станция 114a может использовать технологию со многими входами и многими выходами (MIMO) и, следовательно, может использовать несколько приемо-передающих устройств для каждого сектора соты.

[0035] Базовые станции 114a, 114b могут обмениваться данными с одним или более WTRU 102a, 102b, 102c, 102d по радиоинтерфейсу 115/116/117, который может представлять собой любую подходящую линию беспроводной связи (например, радиочастотную (RF), микроволновую, на основе инфракрасного излучения (IR), ультрафиолетовую (UV), на основе видимого света и т.д.). Радиоинтерфейс 115/116/117 может устанавливаться с использованием любой подходящей технологии радиодоступа (RAT).

[0036] Более конкретно, как отмечено выше, система 100 связи может представлять собой систему с множественным доступом и может использовать одну или более схем доступа к каналу, таких как CDMA, TDMA, FDMA, OFDMA, SC-FDMA и т.п. Например, базовая станция 114a в RAN 103/104/105 и WTRU 102a, 102b, 102c могут реализовывать такую технологию радиосвязи, как наземный радиодоступ для универсальной системы мобильной связи (UMTS) (UTRA), которая позволяет устанавливать радиоинтерфейс 115/116/117 с использованием широкополосного CDMA (WCDMA). WCDMA может включать в себя такие протоколы связи, как высокоскоростной пакетный доступ (HSPA) и/или усовершенствованный HSPA (HSPA+). HSPA может включать в себя высокоскоростной пакетный доступ по нисходящей линии связи (HSDPA) и/или высокоскоростной пакетный доступ по восходящей линии связи (HSUPA).

[0037] В другом варианте осуществления базовая станция 114a и WTRU 102a, 102b, 102c могут реализовывать такую технологию радиосвязи, как усовершенствованный наземный радиодоступ UMTS (E-UTRA), которая может устанавливать радиоинтерфейс 115/116/117 с использованием стандарта долгосрочного развития (LTE) и/или усовершенствованного стандарта LTE (LTE-A).

[0038] В других вариантах осуществления базовая станция 114a и WTRU 102a, 102b, 102c могут реализовывать такие технологии радиосвязи, как IEEE 802.16 (к примеру, стандарт общемировой совместимости широкополосного беспроводного доступа (WIMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, промежуточный стандарт 2000 (IS-2000), промежуточный стандарт 95 (IS-95), промежуточный стандарт 856 (IS-856), глобальная система мобильной связи (GSM), развитие стандарта GSM с увеличенной скоростью передачи данных (EDGE), GSM EDGE (GERAN) и т.п.

[0039] Базовая станция 114b на фиг. 1A может представлять собой, например, беспроводной маршрутизатор, домашний узел B, домашний усовершенствованный узел B или точку доступа и может использовать любую подходящую RAT для упрощения беспроводных подключений в локализованной области, к примеру, в офисе, дома, в транспорте, в университетском городке т.п. В одном варианте осуществления, базовая станция 114b и WTRU 102c, 102d могут реализовывать такую технологию радиосвязи, как IEEE 802.11, для того чтобы устанавливать беспроводную локальную вычислительную сеть (WLAN). В другом варианте осуществления, базовая станция 114b и WTRU 102c, 102d могут реализовывать такую технологию радиосвязи, как IEEE 802.15, для того чтобы устанавливать беспроводную персональную вычислительную сеть (WPAN). В еще одном другом варианте осуществления, базовая станция 114b и WTRU 102c, 102d могут использовать сотовую RAT (например, WCDMA, CDMA2000, GSM, LTE, LTE-A и т.д.), для того чтобы устанавливать пикосоту или фемтосоту. Как показано на фиг. 1A, базовая станция 114b может иметь прямое подключение к Интернету 110. Таким образом, базовая станция 114b, возможно, не обязательно должна осуществлять доступ в Интернет 110 через базовую сеть 106/107/109.

[0040] RAN 103/104/105 может поддерживать связь с базовой сетью 106/107/109, которая может представлять собой любой тип сети, выполненной с возможностью предоставлять услуги передачи речи, данных, приложений и/или услуги по протоколу "речь-по-IP" (VoIP) в один или более WTRU 102a, 102b, 102c, 102d. Например, базовая сеть 106/107/109 может предоставлять услуги управления вызовами, биллинга, услуги на основе местоположения мобильных устройств, предоплатные вызовы, Интернет-подключения, распространение видео и т.д. и/или выполнять высокоуровневые функции обеспечения безопасности, такие как аутентификация пользователей. Хотя не показано на фиг. 1A, следует принимать во внимание, что RAN 103/104/105 и/или базовая сеть 106/107/109 могут поддерживать прямую или косвенную связь с другими RAN, которые используют RAT, идентичную с RAN 103/104/105, или другую RAT. Например, помимо подключения к RAN 103/104/105, которая может использовать E-UTRA-технологию радиосвязи, базовая сеть 106/107/109 также может поддерживать связь с другой RAN (не показана) с использованием GSM-технологию радиосвязи.

[0041] Базовая сеть 106/107/109 также может выступать в качестве шлюза для WTRU 102a, 102b, 102c, 102d, чтобы осуществлять доступ к PSTN 108, Интернету 110 и/или другим сетям 112. PSTN 108 может включать в себя телефонные сети с коммутацией каналов, которые предоставляют обычную телефонную связь (POTS). Интернет 110 может включать в себя глобальную систему соединенных компьютерных сетей и устройств, которые используют такие стандартные протоколы связи, как протокол управления передачей (TCP), протокол пользовательских датаграмм (UDP) и Интернет-протокол (IP) в комплекте Интернет-протоколов TCP/IP. Сети 112 могут включать в себя сети проводной или беспроводной связи, принадлежащие и/или управляемые посредством других поставщиков услуг. Например, сети 112 могут включать в себя другую базовую сеть, подключенную к одной или более RAN, которые могут использовать RAT, идентичную с RAN 103/104/105, или другую RAT.

[0042] Некоторые или все WTRU 102a, 102b, 102c, 102d в системе 100 связи могут включать в себя многорежимные характеристики, к примеру, WTRU 102a, 102b, 102c, 102d могут включать в себя несколько приемо-передающих устройств для обмена данными с различными беспроводными сетями по различным линиям беспроводной связи. Например, WTRU 102c, показанный на фиг. 1A, может быть выполнен с возможностью обмениваться данными с базовой станцией 114a, которая может использовать технологию сотовой радиосвязи, и с базовой станцией 114b, которая может использовать IEEE 802-технологию радиосвязи.

[0043] Фиг. 1B является схемой системы примерного WTRU 102. Как показано на фиг. 1B, WTRU 102 может включать в себя процессор 118, приемо-передающее устройство 120, приемо-передающий элемент 122, динамик/микрофон 124, клавиатуру 126, дисплей/сенсорную панель 128, стационарное запоминающее устройство 130, съемное запоминающее устройство 132, источник 134 питания, набор 136 микросхем глобальной системы определения местоположения (GPS) и другие периферийные устройства 138. Следует принимать во внимание, что WTRU 102 может включать в себя любую субкомбинацию вышеприведенных элементов без потери согласованности с вариантом осуществления. Кроме того, варианты осуществления предполагают, что базовые станции 114a и 114b и/или узлы, которые могут представлять базовые станции 114a и 114b, такие как, но не только, приемо-передающая станция (BTS), узел B, узловой контроллер, точка доступа (AP), домашний узел B, усовершенствованный домашний узел B (усовершенствованный узел B), домашний усовершенствованный узел B (HeNB), шлюз домашнего усовершенствованного узла B и прокси-узлы, в числе других, могут включать в себя часть или все элементы, проиллюстрированные на фиг. 1B и описанные в данном документе.

[0044] Процессор 118 может представлять собой процессор общего назначения, процессор специального назначения, традиционный процессор, процессор цифровых сигналов (DSP), множество микропроцессоров, один или более микропроцессоров в ассоциации с DSP-ядром, контроллер, микроконтроллер, специализированные интегральные схемы (ASIC), схемы на основе программируемой пользователем вентильной матрицы (FPGA), любой другой тип интегральной схемы (IC), конечный автомат и т.п. Процессор 118 может выполнять кодирование сигналов, обработку данных, управление питанием, обработку ввода-вывода и/или любую другую функциональность, которая предоставляет возможность WTRU 102 работать в беспроводном окружении. Процессор 118 может соединяться с приемо-передающим устройством 120, которое может соединяться с приемо-передающим элементом 122. Хотя фиг. 1B иллюстрирует процессор 118 и приемо-передающее устройство 120 в качестве отдельных компонентов, следует принимать во внимание, что процессор 118 и приемо-передающее устройство 120 могут быть интегрированы в электронном блоке или микросхеме.

[0045] Приемо-передающий элемент 122 может быть выполнен с возможностью передавать сигналы или принимать сигналы из базовой станции (например, базовой станции 114a) по радиоинтерфейсу 115/116/117. Например, в одном варианте осуществления, приемо-передающий элемент 122 может представлять собой антенну, выполненную с возможностью передавать и/или принимать RF-сигналы. В другом варианте осуществления, приемо-передающий элемент 122 может представлять собой излучатель/детектор, выполненный с возможностью передавать и/или принимать, например, IR-, UV-сигналы или сигналы в диапазоне видимого света. В еще одном другом варианте осуществления, приемо-передающий элемент 122 может быть выполнен с возможностью передавать и принимать как RF-, так и световые сигналы. Следует принимать во внимание, что приемо-передающий элемент 122 может быть выполнен с возможностью передавать и/или принимать любую комбинацию беспроводных сигналов.

[0046] Помимо этого, хотя приемо-передающий элемент 122 проиллюстрирован на фиг. 1B как один элемент, WTRU 102 может включать в себя любое число приемо-передающих элементов 122. Более конкретно, WTRU 102 может использовать MIMO-технологию. Таким образом, в одном варианте осуществления, WTRU 102 может включать в себя два или более приемо-передающих элемента 122 (например, несколько антенн) для передачи и приема беспроводных сигналов по радиоинтерфейсу 115/116/117.

[0047] Приемо-передающее устройство 120 может быть выполнено с возможностью модулировать сигналы, которые должны быть переданы посредством приемо-передающего элемента 122, и демодулировать сигналы, которые принимаются посредством приемо-передающего элемента 122. Как отмечено выше, WTRU 102 может иметь многорежимные характеристики. Таким образом, приемо-передающее устройство 120 может включать в себя, например, несколько приемо-передающих устройств для предоставления возможности WTRU 102 обмениваться данными через несколько RAT, к примеру, UTRA и IEEE 802.11.

[0048] Процессор 118 WTRU 102 могут соединяться и могут принимать пользовательские входные данные из динамика/микрофона 124, клавишной панели 126 и/или дисплея/сенсорной панели 128 (например, модуля отображения на основе жидкокристаллического дисплея (LCD) или модуля отображения на органических светодиодах (OLED)). Процессор 118 также может выводить пользовательские данные в динамик/микрофон 124, клавишную панель 126 и/или дисплей/сенсорную панель 128. Помимо этого, процессор 118 может осуществлять доступ к информации и сохранять данные на любом типе подходящего запоминающего устройства, таком как стационарное запоминающее устройство 130 и/или съемное запоминающее устройство 132. Стационарное запоминающее устройство 130 может включать в себя оперативное запоминающее устройство (RAM), постоянное запоминающее устройство (ROM), жесткий диск или любой другой тип запоминающего устройства. Съемное запоминающее устройство 132 может включать в себя карту модуля идентификации абонента (SIM), карту памяти, карту памяти по стандарту Secure Digital (SD) и т.п. В других вариантах осуществления, процессор 118 может осуществлять доступ к информации и сохранять данные в запоминающем устройстве, которое физически не находится на WTRU 102, к примеру, на сервере или домашнем компьютере (не показаны).

[0049] Процессор 118 может принимать питание из источника 134 питания и может быть выполнен с возможностью распределять и/или управлять питанием в другие компоненты в WTRU 102. Источник 134 питания может представлять собой любое подходящее устройство для питания WTRU 102. Например, источник 134 питания может включать в себя один или более аккумуляторов на сухих элементах (например, никель-кадмиевые (NiCd), никель-цинковые (NiZn), никель-металлогидридные (NiMH), ионно-литиевые (Li-ion) и т.д.), солнечных элементов, топливных элементов и т.п.

[0050] Процессор 118 также может соединяться с набором 136 GPS-микросхем, который может быть выполнен с возможностью предоставлять информацию местоположения (например, долготу и широту) касательно текущего местоположения WTRU 102. Помимо или вместо информации из набора 136 GPS-микросхем, WTRU 102 может принимать информацию местоположения по радиоинтерфейсу 115/116/117 из базовой станции (например, базовых станций 114a, 114b) и/или определять свое местоположение на основе синхронизации сигналов, принимаемых из двух или более близлежащих базовых станций. Следует принимать во внимание, что WTRU 102 может обнаруживать информацию местоположения посредством любого подходящего способа определения местоположения без потери согласованности с вариантом осуществления.

[0051] Процессор 118 дополнительно может соединяться с другими периферийными устройствами 138, которые могут включать в себя один или более программных и/или аппаратных модулей, которые предоставляют дополнительные признаки, функциональность и/или проводные или беспроводные подключения. Например, периферийные устройства 138 могут включать в себя акселерометр, электронный компас, спутниковое приемо-передающее устройство, цифровую камеру (для фотографий или видео), порт универсальной последовательной шины (USB), вибрационное устройство, телевизионное приемо-передающее устройство, гарнитуру громкой связи, модуль Bluetooth®, частотно-модулированный (FM) радиомодуль, цифровой музыкальный проигрыватель, мультимедийный проигрыватель, модуль устройства видеоигр, Интернет-обозреватель и т.п.

[0052] Фиг. 1C является схемой системы RAN 103 и базовой сети 106 согласно варианту осуществления. Как отмечено выше, RAN 103 может использовать UTRA-технологию радиосвязи для того, чтобы обмениваться данными с WTRU 102a, 102b, 102c по радиоинтерфейсу 115. RAN 103 также может поддерживать связь с базовой сетью 106. Как показано на фиг. 1C, RAN 103 может включать в себя узлы B 140a, 140b, 140c, которые могут включать в себя одно или более приемо-передающих устройств для обмена данными с WTRU 102a, 102b, 102c по радиоинтерфейсу 115. Узлы B 140a, 140b, 140c могут быть ассоциированы с конкретной сотой (не показана) в RAN 103. RAN 103 также может включать в себя RNC 142a, 142b. Следует принимать во внимание, что RAN 103 может включать в себя любое число узлов B и RNC без потери согласованности с вариантом осуществления.

[0053] Как показано на фиг. 1C, узлы B 140a, 140b могут поддерживать связь с RNC 142a. Дополнительно, узел B 140c может поддерживать связь с RNC 142b. Узлы B 140a, 140b, 140c могут обмениваться данными с соответствующими RNC 142a, 142b через Iub-интерфейс. RNC 142a, 142b могут поддерживать связь друг с другом через Iur-интерфейс. Каждый из RNC 142a, 142b может быть выполнен с возможностью управлять соответствующими узлами B 140a, 140b, 140c, с которыми он соединяется. Помимо этого, каждый из RNC 142a, 142b может быть выполнен с возможностью осуществлять или поддерживать другую функциональность, такую как управление питанием с внешним контуром, управление нагрузкой, управление доступом, пакетная диспетчеризация, управление передачей обслуживания, макроразнесение, функции обеспечения безопасности, шифрование данных и т.п.

[0054] Базовая сеть 106, показанная на фиг. 1C, может включать в себя медиашлюз 144 (MGW), центр 146 коммутации мобильной связи (MSC), обслуживающий узел 148 поддержки GPRS (SGSN) и/или шлюзовой узел 150 поддержки GPRS (GGSN). Хотя каждый из вышеприведенных элементов проиллюстрирован как часть базовой сети 106, следует принимать во внимание, что любой из этих элементов может принадлежать и/или управляться посредством объекта, отличного от оператора базовой сети.

[0055] RNC 142a в RAN 103 может подключаться к MSC 146 в базовой сети 106 через IuCS-интерфейс. MSC 146 может подключаться к MGW 144. MSC 146 и MGW 144 могут предоставлять для WTRU 102a, 102b, 102c доступ к сетям с коммутацией каналов, таким как PSTN 108, чтобы упрощать связь между WTRU 102a, 102b, 102c и традиционными устройствами наземной связи.

[0056] RNC 142a в RAN 103 также может подключаться к SGSN 148 в базовой сети 106 через IuPS-интерфейс. SGSN 148 может подключаться к GGSN 150. SGSN 148 и GGSN 150 могут предоставлять для WTRU 102a, 102b, 102c доступ к сетям с коммутацией пакетов, таким как Интернет 110, чтобы упрощать связь между и WTRU 102a, 102b, 102c и устройства с поддержкой IP.

[0057] Как отмечено выше, базовая сеть 106 также может подключаться к сетям 112, которые могут включать в себя другие проводные или беспроводные сети, которые принадлежат и/или управляются посредством других поставщиков услуг.

[0058] Фиг. 1D является схемой системы RAN 104 и базовой сети 107 согласно варианту осуществления. Как отмечено выше, RAN 104 может использовать E-UTRA-технологию радиосвязи для того, чтобы обмениваться данными с WTRU 102a, 102b, 102c по радиоинтерфейсу 116. RAN 104 также может поддерживать связь с базовой сетью 107.

[0059] RAN 104 может включать в себя усовершенствованные узлы B 160a, 160b, 160c, хотя следует принимать во внимание, что RAN 104 может включать в себя любое число усовершенствованных узлов B без потери согласованности с вариантом осуществления. Усовершенствованные узлы B 160a, 160b, 160c могут включать в себя одно или более приемо-передающих устройств для обмена данными с WTRU 102a, 102b, 102c по радиоинтерфейсу 116. В одном варианте осуществления, усовершенствованные узлы B 160a, 160b, 160c могут реализовывать MIMO-технологию. Таким образом, усовершенствованный узел B 160a, например, может использовать несколько антенн для того, чтобы передавать беспроводные сигналы и принимать беспроводные сигналы из WTRU 102a.

[0060] Каждый из усовершенствованных узлов B 160a, 160b, 160c может быть ассоциирован с конкретной сотой (не показана) и может быть выполнен с возможностью обрабатывать решения по управлению радиоресурсами, решения по передаче обслуживания, диспетчеризацию пользователей в восходящей и/или нисходящей линии связи и т.п. Как показано на фиг. 1D, усовершенствованные узлы B 160a, 160b, 160c могут обмениваться данными друг с другом по X2-интерфейсу.

[0061] Базовая сеть 107, показанная на фиг. 1D, может включать в себя шлюз 162 управления мобильностью (MME), обслуживающий шлюз 164 и шлюз 166 сети пакетной передачи данных (PDN). Хотя каждый из вышеприведенных элементов проиллюстрирован как часть базовой сети 107, следует принимать во внимание, что любой из этих элементов может принадлежать и/или управляться посредством объекта, отличного от оператора базовой сети.

[0062] MME 162 может подключаться к каждому из усовершенствованных узлов B 160a, 160b, 160c в RAN 104 через S1-интерфейс и может служить в качестве управляющего узла. Например, MME 162 может отвечать за аутентификацию пользователей WTRU 102a, 102b, 102c, активацию/деактивацию однонаправленных каналов, выбор конкретного обслуживающего шлюза во время начального присоединения WTRU 102a, 102b, 102c и т.п. MME 162 также может предоставлять функцию плоскости управления для коммутации между RAN 104 и другими RAN (не показаны), которые используют другие технологии радиосвязи, такие как GSM или WCDMA.

[0063] Обслуживающий шлюз 164 может подключаться к каждому из усовершенствованных узлов B 160a, 160b, 160c в RAN 104 через S1-интерфейс. Обслуживающий шлюз 164 может, в общем, маршрутизировать и перенаправлять пакеты пользовательских данных в/из WTRU 102a, 102b, 102c. Обслуживающий шлюз 164 также может выполнять другие функции, такие как привязка пользовательских плоскостей во время передач обслуживания между усовершенствованными узлами B, инициирование поисковых вызовов, когда данные нисходящей линии связи доступны для WTRU 102a, 102b, 102c, управление и сохранение контекстов WTRU 102a, 102b, 102c и т.п.

[0064] Обслуживающий шлюз 164 также может подключаться к PDN-шлюзу 166, который может предоставлять для WTRU 102a, 102b, 102c доступ к сетям с коммутацией пакетов, таким как Интернет 110, чтобы упрощать обмен данными между WTRU 102a, 102b, 102c и устройствами с поддержкой IP.

[0065] Базовая сеть 107 может упрощать обмен данными с другими сетями. Например, базовая сеть 107 может предоставлять для WTRU 102a, 102b, 102c доступ к сетям с коммутацией каналов, таким как PSTN 108, чтобы упрощать обмен данными между WTRU 102a, 102b, 102c и традиционными устройствами наземной связи. Например, базовая сеть 107 может включать в себя или может обмениваться данными с IP-шлюзом (например, сервером мультимедийной подсистемы на базе IP-протокола (IMS)), который выступает в качестве интерфейса между базовой сетью 107 и PSTN 108. Помимо этого, базовая сеть 107 может предоставлять для WTRU 102a, 102b, 102c доступ к сетям 112, которые могут включать в себя другие проводные или беспроводные сети, которые принадлежат и/или управляются посредством других поставщиков услуг.

[0066] Фиг. 1E является схемой системы RAN 105 и базовой сети 109 согласно варианту осуществления. RAN 105 может представлять собой сеть предоставления услуг доступа (ASN), которая использует IEEE 802.16-технологию радиосвязи для того, чтобы обмениваться данными с WTRU 102a, 102b, 102c по радиоинтерфейсу 117. Как подробнее поясняется ниже, линии связи между различными функциональными объектами WTRU 102a, 102b, 102c, RAN 105 и базовой сети 109 могут задаваться как опорные точки.

[0067] Как показано на фиг. 1E, RAN 105 может включать в себя базовые станции 180a, 180b, 180c и ASN-шлюз 182, хотя следует принимать во внимание, что RAN 105 может включать в себя любое число базовых станций и ASN-шлюзов без потери согласованности с вариантом осуществления. Базовые станции 180a, 180b, 180c могут быть ассоциированы с конкретной сотой (не показана) в RAN 105 и могут включать в себя одно или более приемо-передающих устройств для обмена данными с WTRU 102a, 102b, 102c по радиоинтерфейсу 117. В одном варианте осуществления, базовые станции 180a, 180b, 180c могут реализовывать MIMO-технологию. Таким образом, базовая станция 180a, например, может использовать несколько антенн для того, чтобы передавать беспроводные сигналы и принимать беспроводные сигналы в/из WTRU 102a. Базовые станции 180a, 180b, 180c также могут предоставлять функции управления мобильностью, такие как инициирование передачи обслуживания, установление туннеля, управление радиоресурсами, классификация трафика, активация политики качества обслуживания (QoS) и т.п. ASN-шлюз 182 может служить в качестве точки агрегирования трафика и может отвечать за поисковые вызовы, кэширование профилей абонентов, маршрутизацию в базовую сеть 109 и т.п.

[0068] Радиоинтерфейс 117 между WTRU 102a, 102b, 102c и RAN 105 может задаваться как опорная R1-точка, которая реализует технические требования IEEE 802.16, помимо этого, каждый из WTRU 102a, 102b, 102c может устанавливать логический интерфейс (не показан) с базовой сетью 109. Логический интерфейс между WTRU 102a, 102b, 102c и базовой сетью 109 может задаваться как опорная R2-точка, которая может использоваться для аутентификации, авторизации, управления конфигурацией IP-хостов и/или управления мобильностью.

[0069] Линия связи между каждой из базовых станций 180a, 180b, 180c может задаваться как опорная R8-точка, которая включает в себя протоколы для упрощения передач обслуживания WTRU и передачи данных между базовыми станциями. Линия связи между базовыми станциями 180a, 180b, 180c и ASN-шлюзом 182 может задаваться как опорная R6-точка. Опорная R6-точка может включать в себя протоколы для упрощения управления мобильностью на основе связанных с мобильностью событий, ассоциированных с каждым из WTRU 102a, 102b, 102c.

[0070] Как показано на фиг. 1E, RAN 105 может подключаться к базовой сети 109. Линия связи между RAN 105 и базовой сетью 109 может задаваться в качестве опорной R3-точки, которая включает в себя, например, протоколы для упрощения характеристик передачи данных и управления мобильностью. Базовая сеть 109 может включать в себя домашний агент 184 на основе мобильного IP-протокола (MIP-HA), сервер 186 аутентификации, авторизации и учета (AAA) и шлюз 188. Хотя каждый из вышеприведенных элементов проиллюстрирован как часть базовой сети 109, следует принимать во внимание, что любой из этих элементов может принадлежать и/или управляться посредством объекта, отличного от оператора базовой сети.

[0071] MIP-HA может отвечать за управление IP-адресом и может предоставлять возможность WTRU 102a, 102b, 102c входить в зону роуминга между различными ASN и/или различными базовыми сетями. MIP-HA 184 может предоставлять для WTRU 102a, 102b, 102c доступ к сетям с коммутацией пакетов, таким как Интернет 110, чтобы упрощать связь между WTRU 102a, 102b, 102c и устройствами с поддержкой IP. AAA-сервер 186 может отвечать за аутентификацию пользователя и за поддержку пользовательских услуг. Шлюз 188 может упрощать межсетевое взаимодействие с другими сетями. Например, шлюз 188 может предоставлять для WTRU 102a, 102b, 102c доступ к сетям с коммутацией каналов, таким как PSTN 108, чтобы упрощать обмен данными между WTRU 102a, 102b, 102c и традиционными устройствами наземной связи. Помимо этого, шлюз 188 может предоставлять для WTRU 102a, 102b, 102c доступ к сетям 112, которые могут включать в себя другие проводные или беспроводные сети, которые принадлежат и/или управляются посредством других поставщиков услуг.

[0072] Хотя не показано на фиг. 1E, следует принимать во внимание, что RAN 105 может подключаться к другим ASN, и базовая сеть 109 может подключаться к другим базовым сетям. Линия связи между RAN 105 и другими ASN может задаваться как опорная R4-точка, которая может включать в себя протоколы для координации мобильности WTRU 102a, 102b, 102c между RAN 105 и другими ASN. Линия связи между базовой сетью 109 и другими базовыми сетями может задаваться как опорная R5-точка, которая может включать в себя протоколы для упрощения межсетевого взаимодействия между домашними базовыми сетями и гостевыми базовыми сетями.

[0073] Технологии, поясненные в данном документе, могут выполняться частично или полностью посредством WTRU 102a, 102b, 102c, 102d, RAN 104, базовой сети 106, Интернета 110 и/или других сетей 112. Например, потоковая передача видео, выполняемая посредством WTRU 102a, 102b, 102c, 102d, может активировать различную обработку, как пояснено в данном документе.

[0074] Раскрыты системы, способы и инструментарий для того, чтобы обеспечивать оптимизации на основе качества для доставки видео. Раскрытые технологии могут быть проиллюстрированы в отношении MPEG/3GPP DASH-стандарта, но не ограничены этим. Например, в данном документе описываются способы, посредством которых информация относительно качества сегмента может передаваться в DASH-клиент. Эта связь позволяет предоставлять адаптацию на основе качества в клиенте. Технологии, описанные в данном документе, могут быть реализованы как расширения в MPEG DASH-стандарт.

[0075] Эффективность сжатия изображений может оцениваться, например, с использованием скорости передачи битов и/или полосы пропускания для того, чтобы передавать сигнал, и/или качества восстановленного изображения. Если рассматриваются время и/или последовательность изображений/кадров или видео, то может быть множество характеристик скорости передачи битов и/или качества, которые могут достигаться посредством видеокодеков для каждого кадра.

[0076] Чтобы сообщать параметры скорости и/или качества (например, PSNR, SSIM и/или MOS) для последовательности, могут использоваться средние значения параметров скоростей передачи битов и/или качества через один или более кадров. Средние значения могут не быть надежными, например, поскольку могут быть предусмотрены различные способы достигать идентичных средних оценок, которые, например, могут оказывать различное влияние на общее качество работы. Например, кодеры могут использовать различные стратегии для балансирования мгновенных компромиссов между качеством и скоростью для отдельных кадров в видеопоследовательности. Скорость передачи битов может поддерживаться максимально близкой к заданной цели при достижении самого лучшего качества изображений/кадров с учетом такой скорости. Эта стратегия может упоминаться в качестве кодирования с постоянной скоростью передачи битов (CBR). Качество может поддерживаться близко к заданной цели при использовании минимального возможного числа битов, требуемых для того, чтобы достигать такого качества для каждого кадра. Эта стратегия может упоминаться в качестве кодирования с постоянным качеством.

[0077] Чтобы учитывать изменяющуюся сложность видеоконтента, кодеры могут реализовывать версии кодирования с постоянной скоростью и/или постоянным качеством, в которых кодеры разрешают скорости и/или качеству колебаться между кадрами. Например, кодеры могут пытаться уменьшать или минимизировать такие колебания. Такие стратегии кодирования могут упоминаться в качестве кодирования на основе скорости передачи битов и на основе качества, соответственно.

[0078] Фиг. 2 является графиком, иллюстрирующим пример MOS-колебаний при кодировании на основе скорости передачи битов и кодировании на основе качества идентичной последовательности. Фиг. 2 иллюстрирует пример MOS-оценок, сформированных посредством кодирования на основе скорости передачи битов и кодирования на основе качества видеопоследовательности. В этом примере, кодирование на основе качества может использовать более высокую пиковую скорость передачи битов (2,7 Мбит/с), но может достигать примерно идентичной средней скорости передачи битов (1,8 Мбит/с), что и кодирование на основе скорости передачи битов. Кодирование на основе качества может отличаться посредством более стабильного качества. Кодирование на основе качества позволяет иметь меньше экземпляров кадров/сегментов, в которых качество опускается ниже определенного уровня приемлемости (например, посредственного).

[0079] Фиг. 3 является примером из предшествующего уровня техники для распределений MOS-оценок для кодирования на основе скорости передачи битов и кодирования на основе качества. Отсутствие падения качества ниже допустимого уровня может приводить к лучшему общему качеству работы. Это может иметь место для множества различных типов настроек видеоконтента и воспроизведения.

[0080] Фиг. 4 является схемой, иллюстрирующей пример работы системы 400 адаптивной потоковой HTTP-передачи. Системы потоковой передачи могут использовать кодирования видео на основе скорости, например, посредством подготовки нескольких потоков, кодированных на различных целевых скоростях. Клиентское приложение может использоваться для того, чтобы динамично выбирать между одним или более кодированных потоков. Коммутации потоков, реализованные посредством клиента, могут иметь определенную гранулярность, которая, например, может составлять приблизительно 2-10 секунд на практике. Точки, в которых клиент может коммутироваться между кодированными потоками, могут упоминаться в качестве точек коммутации. Части кодированного контента между кодированными потоками могут упоминаться в качестве сегментов.

[0081] Во время сеанса потоковой передачи клиент потоковой передачи может вычислять скорость доставки одного или более сегментов. Скорость доставки сегмента может давать клиенту оценку полосы пропускания сети, которая может быть доступной для приема следующего сегмента. На основе этой оценки клиент может решать то, какое следующее кодирование/скорость необходимо использовать для следующего сегмента. Это может давать возможность клиенту адаптироваться к изменяющимся характеристикам сети. Например, высокоуровневая информация относительно каждого кодированного потока, включающая в себя, но не только, их скорости, может сохраняться в файле манифеста или файле описания мультимедийного представления (MPD). Например, информация смещений и синхронизации для кодированного сегмента в потоке может сохраняться в одном или более индексных файлов сегментов.

[0082] Файлы манифеста и/или индексные файлы могут не включать в себя информацию относительно качества каждого из кодированных сегментов. Клиент потоковой передачи может не иметь сведений относительно качества каждого сегмента. Без этих сведений клиент потоковой передачи может не иметь возможность реализовывать адаптацию с управлением качеством. Это может создавать определенную неэффективность в системе доставки потоковой передачи. Например, могут возникать ситуации, в которых затруднительно кодировать контент, что может приводить к посредственному качеству на текущей скорости. Например, могут возникать ситуации, когда контент просто кодировать, и когда целесообразно понижать скорость без влияния на качество. Один пример этого проиллюстрирован на фиг. 5.

[0083] Фиг. 5 является схемой, иллюстрирующей пример потенциала для уменьшения скорости передачи битов посредством использования адаптации на основе качества. Как показано на фиг. 5, видео может содержать один или более сегментов, которые могут быть просто кодированы. В таких случаях, коммутация на более низкую скорость позволяет экономить полосу пропускания при одновременном поддержании качества на определенном предельном уровне. В данном документе описывается то, как может обеспечиваться такая коммутация с учетом качества (например, с управлением качеством) в инфраструктуре адаптивной потоковой HTTP-передачи и, в частности, в MPEG/3GPP DASH-стандарте.

[0084] Клиент потоковой передачи может налагать некоторый лимит по качеству, например, как показано на фиг. 5. Клиент может знать одно или более значений качества (например, PSNR), достигаемых для сегмента. Клиент может выбирать кодирование на более низкой скорости, которая является достаточной для того, чтобы достигать данного целевого показателя качества, например, если клиент определяет то, что следующий сегмент достигает одного или более значений качества, которые равны или превышают данный целевой показатель качества (например, 48 дБ вместо целевых 38 дБ). Клиент позволяет экономить полосу пропускания и/или позволяет повышать стабильность качества видеоконтента, который доставляется.

[0085] Информация качества может использоваться посредством DASH-клиента потоковой передачи для того, чтобы улучшать доставку видео. Ниже описывается модель клиентского буфера. Фиг. 6 является схемой, иллюстрирующей пример определенного числа состояний заполненности клиентского буфера. Клиент может управлять буфером отката определенной длины (например, 10-30 секунд). Клиент может использовать одно или более пороговых значений заполненности буфера, таких как, например, Low_buf 602 и High_buf 604. Low_buf 602 может означать пороговое значение, при котором клиент может иметь риск попадания в ситуацию повторной буферизации. При пороговом значении 602 Low_buf, клиент может выполнять измерения для того, чтобы пополнять буфер. High_buf 604 может означать пороговое значение, при котором клиент, возможно, накапливает объем информации, чтобы рассматривать коммутацию и/или регулирование нагрузки (например, если уже достигнута самая высокая скорость).

[0086] Фиг. 7 является схемой, иллюстрирующей представление 700 модели работы DASH-клиента потоковой передачи, когда не предоставляется информация качества. Ниже описывается модель работы DASH-клиента. Ссылаясь на фиг, 7, как показано на 702, когда уровень Buf заполненности буфера меньше порогового значения Low_buf, клиент может выбирать представление с самой низкой скоростью, чтобы не допускать повторной буферизации. Как показано на 704, когда уровень Buf заполненности буфера между пороговыми значениями Low_buf и High_buf, клиент, например, может выбирать представление с самой высокой скоростью, которое ниже доступной полосы пропускания. Как показано на 706, когда уровень Buf заполненности буфера превышает пороговое значение High_buf, клиент может проверять то, достигнуто или нет представление с самой высокой скоростью, и если да, то клиент может вводить одну или более пауз между загрузками сегментов (например, в качестве регулирования нагрузки), поскольку он может иметь уже достаточно данных для воспроизведения в реальном времени.

[0087] Может предоставляться клиентская адаптивная модель с использованием информации качества и скорости в расчете на сегмент. Фиг. 8 является схемой, иллюстрирующей представление 800 модели работы DASH-клиента потоковой передачи с использованием информации качества, которая, например, может предотвращать выбор потоков/сегментов, качество которых превышает пороговое значение quality_cap, например, независимо от скорости передачи битов. Такой выбор может приводить к более умеренному использованию полосы пропускания и/или более стабильному качеству работы конечного пользователя. Эта информация качества может использоваться, например, в дополнение к информации заполненности буфера. Как показано на фиг. 8 на 802, когда уровень Buf заполненности буфера меньше порогового значения Low_buf, клиент может выбирать представление с самой низкой скоростью, чтобы не допускать повторной буферизации. Как показано на 804, когда уровень Buf заполненности буфера между пороговыми значениями Low_buf и High_buf, клиент, например, может выбирать представление с самой высокой скоростью, которое ниже доступной полосы пропускания, и которое имеет качество, которое не превышает пороговое значение quality_cap лимита по качеству. Как показано на 806, когда уровень Buf заполненности буфера превышает пороговое значение High_buf, клиент может проверять то, достигнуто или нет представление с самой высокой скоростью. Если да, клиент может вводить одну или более пауз между загрузками сегментов (например, в качестве регулирования нагрузки), поскольку он может иметь уже достаточно данных для воспроизведения в реальном времени.

[0088] Чтобы обеспечивать решения на основе качества в клиенте потоковой передачи, клиент может иметь доступ к информации относительно качества одного или более кодированных сегментов. Может быть предусмотрено множество мест и множество способов, связанных с тем, как эта информация может вводиться в MPEG DASH-стандарте. Например, одно или более из PSNR, SSIM, VQM, VIF, J.341, MOS (например, в любой допустимой комбинации) и/или другого объективного и/или субъективного показателя может использоваться в качестве дополнительного показателя качества.

[0089] Показатели качества могут использовать шкалу в дБ, такую как, например, PSNR. Показатели качества могут преобразовываться в интервал, например, в интервал [1…5], который может быть ассоциирован с 5-уровневой MOS-шкалой. Передача в служебных сигналах значений качества может быть гибкой, например, посредством предоставления возможности добавлений и расширений. Передача в служебных сигналах значений качества может обеспечивать возможность обмена показателями, которые могут масштабироваться согласно диапазону значений. Например, показатели могут масштабироваться согласно диапазону значений MOS-оценок, такому как от 1 (наименьшее) до 5 (наибольшее). Передача в служебных сигналах значений качества может обеспечивать возможность обмена PSNR.

[0090] Информация качества может быть гранулированной. Например, информация качества может быть задана на уровне сегментов и/или субсегментов, что может давать возможность DASH-клиентам принимать решения. Информация качества может быть доступной. Например, информация качества может быть доступной для сегментов и/или представлений в адаптивном наборе, например, так что DASH-клиент может извлекать (например, независимо извлекать) информацию качества заранее и перед загрузкой фактических сегментов данных. Информация качества может быть компактной. Например, информация качества может быть компактной, так что загрузка информации качества не создает существенный дополнительный объем с точки зрения данных, который загружает клиент потоковой передачи.

[0091] Один способ добавления информации относительно качества кодированных сегментов может заключаться в использовании тегов (например, дополнительных тегов) в частях списка сегментов MPD-файла. Адаптивный набор может содержать теги, указывающие присутствие значений качества в списке сегментов. Пример таких объявлений представлен ниже:

[0092] В данном документе описывается независимый дескриптор последовательности значений качества. Информация качества может быть включена в качестве отдельного дескриптора, например, на уровне представления. Этот дескриптор может задавать показатель качества, может задавать точность представления качества (например, приблизительное представление может использоваться для того, чтобы делать его более компактным) и/или может задавать последовательность значений качества, ассоциированных с сегментами в представлении.

[0093] Дескриптор информации качества на уровне представления может содержать информацию относительно фактической сжатой длины каждого сегмента, например, в случаях, если MPD может использовать шаблоны сегментов и/или URL-адреса для отдельных файлов сегментов. Дескриптор информации качества на уровне представления может задаваться как случай дескриптора SupplementalProperty и, например, может содержать универсальное имя ресурса (URN) схемы, которое может предоставлять уникальный идентификатор, ассоциированный со служебной информацией по качеству.

[0094] Примерная реализация дескриптора последовательности значений качества предоставляется в таблице 1.

Таблица 1
Название элемента или атрибута	Использование	Описание
QualitySequence
@qualityMetric	Значение по умолчанию OD: PSNR	Может указывать то, какой показатель может использоваться для того, чтобы выражать качество, который, например, может представлять собой PSNR, MOS и/или SSIM. Он может быть передан в служебных сигналах в качестве URN с отдельными схемами, зарегистрированными для PSNR, SSIM и т.д.
@Accuracy	Значение по умолчанию OD: 1	Коэффициент масштабирования по умолчанию для значения @q в Q элементов
Q	0…N
@s	O	Номер сегмента для первого сегмента, включенного в элемент
@n	Значение по умолчанию OD: 1	Число сегментов, включенных в элемент, совместно использующий идентичные значения качества и полосы пропускания
@q	M	Масштабированное значение показателя качества как целое число
@b	O	Полоса пропускания для доставки в реальном времени сегмента, например, в Кбит/с

Условные обозначения: M = обязательный, O = необязательный, OD = необязательный со значением по умолчанию, C-M = условно обязательный.
Для элементов: <minOccurs>…<maxOccurs>(N=unbounded)

[0095] Способ добавления информации относительно качества кодированных сегментов может состоять в том, чтобы использовать индексные файлы сегментов (или индексных сегментов). Индексные файлы сегментов могут содержать файлы (например, специализированные файлы), могут содержать информацию индексов сегментов и/или могут сохраняться вместе с .mpd и файлами сегментов на HTTP-сервере. Индексные файлы сегментов могут содержать версии (например, специализированные версии) mp4 файлов. Индексные файлы сегментов могут содержать поля STYP-, SIDX- и/или SSIX-типа, например, с информацией индексов сегментов для кодированных представлений. Индексы сегментов могут встраиваться в кодированный мультимедийный файл (например, файл fall.mp4), когда связанные с индексом поля могут быть расположены в начале файла.

[0096] К индексным файлам сегментов можно обращаться из MPD-файлов, например, посредством присутствия элемента RepresentationIndex, предоставляющего индекс сегмента для представления. К индексным файлам сегментов можно обращаться из MPD-файлов, например, посредством присутствия, по меньшей мере, одного из двух атрибутов @index или @indexRange в элементе SegmentList.SegmentURL. К индексным файлам сегментов можно обращаться из MPD-файлов, например, посредством присутствия атрибута SegmentTemplate@index.

[0097] Атрибут @indexRange может использоваться для того, чтобы предоставлять байтовый диапазон для индекса в мультимедийном сегменте. Это может осуществляться, когда разрешено посредством формата мультимедийного сегмента. Например, атрибут @index может не присутствовать, и указываемый диапазон может частично или полностью находиться в байтовом диапазоне, указываемом для мультимедийного сегмента.

[0098] Индексные файлы сегментов, используемые для передачи в служебных сигналах относительно качества, могут содержать индикатор того, что информация качества может присутствовать в индексных файлах (например, посредством дескриптора или атрибута в MPD-файле), спецификацию типа показателя качества (например, включенного в MPD и/или в полях индексов сегментов) и/или список значений качества для сегмента и/или субсегмента в представлении. Список значений качества может сжиматься, например, посредством кодирования по длинам серий.

[0099] Индексные файлы сегментов, используемые для передачи в служебных сигналах относительно качества, могут содержать определенное число дескриптивных элементов. Например, индексный файл сегментов может указывать то, что информация качества присутствует в индексном файле, например, с использованием дескриптора или атрибута в MPD-файле. Индексный файл сегментов может содержать спецификацию типа показателя качества, например, в MPD-файле или в поле индексов сегментов. Индексный файл сегментов может содержать список значений качества для одного или более сегментов или субсегментов в представлении. Этот список может сжиматься, например, с использованием кодирования по длинам серий.

[0100] Чтобы сохранять параметры качества в контейнере файлов на основе ISOBMFF, могут задаваться поля. Например, нижеупомянутая таблица 2 может добавляться в конце таблицы 1 ISO/IEC 14496-12.

Таблица 2
qtyp	опорный	тип показателя качества
sqls	опорный	список параметров качества сегмента
ssql	опорный	список параметров качества субсегмента

[0101] Могут применяться следующие определения: qtyp может обозначать поле, которое описывает тип показателя качества, такой как, но не только, PSNR, SSIM, MS-SSIM и/или VQM; sqls может обозначать поле, включающее в себя список показателей качества для сегментов в представлении. Примерный синтаксис проиллюстрирован ниже.

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

[0103] Чтобы указывать клиенту то, что информация качества присутствует в индексных файлах, синтаксис MPD-файла может быть расширен с тем, чтобы обеспечивать дополнительный флаг qualityInfoPresentInIndexFiles. Пример использования этого файла показан ниже:

[0104] Информация относительно качества кодированных сегментов может добавляться посредством использования и/или сохранения отдельных файлов с их собственным синтаксисом. Такие файлы могут быть ассоциированы с соответствующим адаптивным набором в MPD-файле, например, посредством дескриптора. Пример такого дескриптора показан ниже.

[0105] Это может обеспечивать путь для развертывания в системах (например, в существующих системах) и кодированный контент.

[0106] Фиг. 9 является схемой, иллюстрирующей пример дорожки 900 информации качества, добавленной к DASH-представлению. Информация качества может встраиваться в поле 902 контейнера мультимедийных данных (mdat). Информация качества может сохраняться в поле 902 контейнера мультимедийных данных (mdat) в качестве дорожки 900 информации качества вместе с видеодорожкой 904 в представлении. Чтобы добавлять дорожку 900 информации качества, DASH-сегмент инициализации может перечислять добавленную дорожку, например, как показано на фиг. 9.

[0107] В контейнере 906 для мультимедийной информации в дорожке (поле trak) контейнер 908 для мультимедийной информации в дорожке (например, поле mdia) может содержать контейнер 910 мультимедийной информации (например, поле minf). Для дорожки 900 информации качества контейнер 910 мультимедийной информации (например, поле minf) может использовать тип нулевого заголовка мультимедиа (например, поле 912 nmhd). В поле 912 nmhd информация качества может предоставляться и может содержать, например, тип показателя качества (например, PSNR, SSIM и т.д.). Пример синтаксиса для поля 912 nmhd, которое может включать в себя информацию качества, предоставляется ниже:

[0108] quality_metric_type может быть перечислением. Например, 0 может указывать PSNR, 1 может указывать SSIM и т.д. Присутствие дорожки 900 информации качества может быть передано в служебных сигналах в файле описания, например, как предусмотрено ниже:

[0109] Как показано на фиг. 10, поле 1002 sidx (индексов сегментов) может включать в себя список указателей в пары полей 1004 moof и полей 1006 mdat. Каждая пара может представлять субсегмент, например, как показано на фиг. 10, поле 1004 moof может перечислять дорожки, присутствующие в поле 1006 mdat.

[0110] Фиг. 10 является схемой, иллюстрирующей пример информации качества, сохраненной в поле mdat в DASH-сегменте 1008. Информация качества может добавляться на уровне субсегментов. Например, дорожка 1010 качества может добавляться в поле 1006 mdat, которое, например, может обобщать информацию качества видеодорожки на уровне субсегментов. Информация качества может появляться в начале поля 1006 mdat, например, так что она может быть легко извлечена посредством клиента. Поле 1004 moof может содержать перечень 1012, который может указывать присутствие дорожки 1010 качества. Примерный синтаксис для получения информации качества в поле 1006 mdat может предоставляться ниже:

[0111] Информация качества может предоставляться в свободном (например, free или skip) поле. Информация относительно качества может сохраняться в свободном (например, free или skip) поле в MPEG DASH-сегменте. Например, контент свободного поля может быть нерелевантным и/или может игнорироваться без влияния на представление. Поля free или skip могут быть полями верхнего уровня (например, равноправными по отношению к полю mbox (поле фильма) и/или к полю mdat мультимедийных данных). Как показано на фиг. 11, поля free или skip могут быть размещены, например, после поля 1100 sidx индексов сегментов в MPEG DASH-сегменте 1102, к примеру, около начала сегмента. Пара из поля 1104 moof и/или поля 1106 mdat может представлять субсегмент и/или может соответствовать паре moov и/или mdat в MP4-файле. Поле 1108 free и/или skip может добавляться около начала сегмента, например, так что к нему может осуществляться доступ до выборки всего сегмента.

[0112] Присутствие поля 1108 free и/или skip может быть передано в служебных сигналах в файле описания, например, как предусмотрено ниже:

[0113] Фиг. 11 является схемой, иллюстрирующей пример информации качества, сохраненной в поле 1108 free или skip в DASH-сегменте 1102. Например, поле 1108 free и/или skip может добавляться в то время, когда создается сегмент. Если поля 1108 free и/или skip добавляются после того, как созданы сегменты (например, в ранее созданном DASH-контенте), могут пересчитываться смещения, используемые в таблице выборок sidx.

[0114] Может задаваться формат поля 1108 free и/или skip. Например, может использоваться синтаксис, аналогичный синтаксису, предложенному для использования с индексными файлами сегментов. Примерный синтаксис предоставляется ниже:

[0115] Признаки и элементы, описанные в данном документе, могут применяться к потоковой HTTP-передаче в реальном времени (HLS) и/или к другим системам потоковой передачи. Передача в служебных сигналах информации качества для сегмента может добавляться заранее. Эта информация может использоваться посредством клиента при выборе потока, для которого можно выполнять запросы и/или на который можно подписываться.

[0116] Добавление связанной с качеством информации может быть выполнено посредством включения связанной с качеством информации в файл манифеста (например, в файл .mdp), включающий в себя связанную с качеством информацию, в индексы сегментов, сохраненные в индексном файле сегментов (например, в MP4- или M4S-файлах), и/или предоставления дополнительных файлов с информацией качества/сегментов и предоставления ссылки на нее из MPD-файла.

[0117] Динамическая адаптивная потоковая HTTP-передача (DASH) представляет собой стандарт, который позволяет консолидировать несколько подходов для потоковой HTTP-передачи. MPEG DASH может быть расширением "3GP DASH". DASH может использоваться для того, чтобы справляться с переменной полосой пропускания в беспроводных и проводных сетях и может поддерживаться посредством поставщиков контента и устройств. DASH может предоставлять услуги потоковой передачи мультимедиа по любой сети доступа к любому устройству.

[0118] Фиг. 12 является схемой, иллюстрирующей пример высокоуровневой архитектуры DASH-системы 1200. DASH-система может быть развернута в качестве набора HTTP-серверов 1202, которые могут распределять передаваемый в реальном времени контент и/или контент по запросу, который подготовлен в подходящем формате. Клиенты могут осуществлять доступ к контенту непосредственно из этих HTTP-серверов и/или из сетей 1204 распространения контента (GDI), или CDN. CDN могут использоваться для развертывания, в котором ожидается большое число клиентов, поскольку они могут кэшировать содержимое и могут быть расположены около клиентов на границе сети.

[0119] В DASH, сеанс потоковой передачи может управляться посредством клиента 1206 посредством запроса сегментов с использованием HTTP и их объединения по мере того, как они принимаются от поставщика контента и/или CDN 1204. Клиенты могут отслеживать, например, постоянно отслеживать и регулировать скорость передачи мультимедиа на основе характеристик сети (например, частоты ошибок по пакетам, дрожания времени задержки) и их собственного состояния (например, заполненности буфера, режима работы, предпочтений пользователя), что фактически перекладывает интеллектуальность с сети на клиентов.

[0120] DASH-стандарт может быть аналогичным информативным моделям клиента. Фиг. 13 является примером логических компонентов концептуальной клиентской DASH-модели 1300. DASH-механизм доступа может принимать файл описания мультимедийного представления (MPD). DASH-механизм 1302 доступа может конструировать и выдавать запросы и принимать сегменты или части сегментов. Вывод DASH-механизма 1302 доступа может содержать мультимедиа в форматах MPEG-контейнеров (например, формат MP4-файла и/или транспортный MPEG-2-поток) и/или информацию синхронизации, которая может преобразовывать внутреннюю синхронизацию мультимедиа во временную шкалу представления. Комбинация кодированных порций мультимедиа и/или информации синхронизации может быть достаточной для корректного рендеринга контента.

[0121] Некоторые ограничения, которые DASH налагает на кодированные мультимедийные сегменты, основаны на таком допущении, что декодирование, постобработка и/или воспроизведение может выполняться посредством механизма 1304 обработки мультимедиа, который может не иметь информации, связанной с характером кодированных мультимедийных сегментов и/или тем, как доставлены кодированные мультимедийные сегменты. Механизм 1304 обработки мультимедиа может декодировать и воспроизводить непрерывный мультимедийный файл, подаваемый в порциях посредством DASH-механизма доступа.

[0122] Например, DASH-механизм 1302 доступа может использовать JavaScript, в то время как механизм 1304 обработки мультимедиа может предоставляться посредством обозревателя, подключаемого модуля обозревателя (к примеру, но не только, Flash или Silverlight) и/или операционной системы.

[0123] Фиг. 14 является схемой, иллюстрирующей пример высокоуровневой модели 1400 данных мультимедийного DASH-представления. В DASH, организация мультимедийного представления 1402 может быть основана на иерархической модели данных. Описание мультимедийного представления (MPD) позволяет описывать последовательность периодов 1404, которые составляют мультимедийное DASH-представление (например, мультимедийный контент). Период 1404 может представлять период доступности мультимедийного контента, в течение которого доступен набор кодированных версий мультимедийного контента. Например, набор доступных скоростей передачи битов, языков и/или заголовков может не изменяться в течение периода 1404.

[0124] Адаптивный набор 1406 может представлять набор взаимозаменяемых кодированных версий одного или более компонентов мультимедийного контента. Например, может быть предусмотрен адаптивный набор 1406 для видео, адаптивный набор для первичного аудио, один для вторичного аудио и/или адаптивный набор для заголовков. Адаптивные наборы 1406 могут быть мультиплексированы, и при этом взаимозаменяемые версии мультиплексирования могут описываться как один адаптивный набор 1406. Например, адаптивный набор 1406 может включать в себя видео и/или аудио для периода 1404.

[0125] Представление 1408 позволяет описывать доставляемую кодированную версию одного или более компонентов мультимедийного контента. Представление 1408 может содержать один или более мультимедийных потоков (например, по одному для каждого компонента мультимедийного контента при мультиплексировании). Одно представление 1408 в адаптивном наборе 1406 может быть достаточным для того, чтобы подготавливать посредством рендеринга включенные компоненты мультимедийного контента. Клиенты могут коммутироваться с одного представления 1408 на другое представление 1408 в адаптивном наборе 1406, с тем чтобы адаптироваться к характеристикам сети или другим факторам. Клиент может игнорировать представления 1408, которые используют кодеки, профили и/или параметры, которые не поддерживает клиент. Контент в представлении 1408 может быть разделен во времени на сегменты 1410 фиксированной или переменной длины. URL-адрес может предоставляться для каждого сегмента 1410. Сегмент 1410 может быть наибольшей единицей данных, которая может быть извлечена с одним HTTP-запросом.

[0126] Описание мультимедийного представления (MPD) может представлять собой XML-документ, который может содержать метаданные, которые могут использоваться посредством DASH-клиента, чтобы конструировать надлежащие HTTP URL-адреса для сегментов доступа и/или предоставлять услугу потоковой передачи пользователю. Базовый URL-адрес в MPD может использоваться посредством клиента для того, чтобы формировать HTTP GET-запросы на сегменты и другие ресурсы в мультимедийном представлении. Частичные HTTP GET-запросы могут использоваться для того, чтобы осуществлять доступ к ограниченной части сегмента посредством использования байтового диапазона (например, через HTTP-заголовок Range). Альтернативный базовые URL-адреса могут указываться для того, чтобы предоставлять доступ к представлению в случае, если местоположение недоступно, предоставляя избыточность для доставки мультимедийных потоков, обеспечивая возможность балансировки нагрузки на стороне клиента и/или параллельной загрузки.

[0127] MPD может иметь статический или динамический тип. Статический тип MPD может изменяться или не изменяться во время мультимедийного представления и может использоваться для представлений по запросу. Динамический тип MPD может обновляться во время мультимедийного представления и может использоваться для передаваемых в реальном времени представлений. MPD может обновляться с тем, чтобы расширять список сегментов для каждого представления, вводить новый период и/или завершать мультимедийное представление.

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

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

[0130] Временная шкала доступности сегментов может использоваться для того, чтобы передавать в служебных сигналах в клиент время доступности сегментов в указанных HTTP URL-адресах. Например, эти времена могут предоставляться в физических временах. Перед осуществлением доступа к сегментам в указанном HTTP URL-адресе, клиенты могут сравнивать физическое время с временами доступности сегментов. Для контента по запросу времена доступности сегментов могут быть идентичными. Сегменты мультимедийного представления могут быть доступными на сервере, как только доступен сегмент. MPD может представлять собой статический документ.

[0131] Для передаваемого в реальном времени контента времена доступности сегментов могут зависеть от позиции сегмента на временной шкале мультимедийного представления. Сегменты могут становиться доступными со временем по мере того, как формируется контент. MPD может периодически обновляться для того, чтобы отражать изменения в представлении во времени. Например, URL-адреса сегментов для новых сегментов могут добавляться в MPD. Старые сегменты, которые больше не доступны, могут удаляться из MPD. Обновление MPD может опускаться, если URL-адреса сегментов описываются с использованием шаблона.

[0132] Длительность сегмента может представлять длительность мультимедиа, включенного в сегмент, при представлении на нормальной скорости. Сегменты в представлении могут иметь идентичную или примерно аналогичную длительность. Длительность сегмента может отличаться между представлениями. DASH-представление может иметь структуру с относительно короткими сегментами (например, в несколько секунд) или более длинными сегментами, включающими в себя один сегмент для целого представления.

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

[0134] Сегменты дополнительно могут подразделяться на субсегменты. Каждый субсегмент может содержать общее число полных единиц доступа. Единица доступа может представлять собой единицу мультимедийного потока с назначенным временем мультимедийного представления. Если сегмент разделен на субсегменты, они могут быть описаны посредством индекса сегмента. Индекс сегмента может предоставлять диапазон времени представления в представлении и соответствующий байтовый диапазон в сегменте, занимаемом посредством каждого субсегмента. Клиент может загружать этот индекс заранее и выдавать запросы на отдельные субсегменты с использованием, например, частичных HTTP GET-запросов. Индекс сегмента может быть включен в мультимедийный сегмент, например, в начале файла. Информация индексов сегментов может предоставляться в отдельных индексных сегментах.

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

[0136] Мультимедийный сегмент может содержать и может инкапсулировать мультимедийные потоки, которые либо описаны в мультимедийном сегменте и/или описаны посредством сегмента инициализации представления. Мультимедийные сегменты могут содержать определенное число полных единиц доступа и могут содержать, по меньшей мере, одну точку доступа к потоку (SAP) для каждого включенного мультимедийного потока.

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

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

[0139] Клиенты могут коммутироваться между представлениями в адаптивном наборе в любой точке в мультимедиа. Коммутация в произвольных позициях может усложняться вследствие зависимостей кодирования в представлениях и других факторов. Может не допускаться загрузка перекрывающихся данных (например, мультимедиа для идентичного периода времени из нескольких представлений). Коммутация может быть более простой в точке произвольного доступа в новом потоке. DASH может задавать независимый от кодека принцип точки доступа к потоку (SAP) и идентифицировать различные типы точек доступа к потоку. Тип точки доступа к потоку может передаваться в качестве одного из свойств адаптивного набора (например, при условии, что все сегменты в адаптивном наборе имеют идентичные типы SAP).

[0140] Точка доступа к потоку (SAP) может предоставлять произвольный доступ в контейнер файлов одного или более мультимедийных потоков. SAP может представлять собой позицию в контейнере, обеспечивающую возможность начала воспроизведения идентифицированного мультимедийного потока с использованием информации, включенной в контейнер, начиная с этой позиции и далее, и/или возможных данных инициализации из другой части или других частей контейнера. Данные инициализации могут быть доступными внешне.

[0141] Может задаваться определенное число свойств контейнера файлов. T_SAP может быть временем представления, например, самым ранним временем представления единицы доступа мультимедийного потока, так что все единицы доступа мультимедийного потока со временем представления, превышающим или равным T_SAP, могут корректно декодироваться с использованием данных в потоке битов, начинающемся в I_SAP и без данных до I_SAP.

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

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

[0144] T_DEC может представлять собой самое раннее время представления единицы доступа мультимедийного потока, который может корректно декодироваться с использованием данных в потоке битов, начинающемся в I_SAU и с или без данных, начинающихся до I_SAU. T_EPT может быть самым ранним временем представления единицы доступа мультимедийного потока, начинающегося в I_SAU в потоке битов. T_PTF может быть временем представления первой единицы доступа мультимедийного потока в порядке декодирования в потоке битов, начинающемся в I_SAU.

[0145] Фиг. 15 является примером точки доступа к потоку с параметрами. Фиг. 15 иллюстрирует кодированный видеопоток 1500 с тремя различными типами кадров: I, P и B. P-кадры могут использовать (например, использовать только) предшествующие I- или P-кадры для декодирования, в то время как B-кадры могут использовать предшествующие и последующие I- и/или P-кадры. Могут возникать различия в порядках передачи, декодирования и/или представления в I-, P- и/или B-кадрах.

[0146] Тип SAP может зависеть от того, какие единицы доступа являются корректно декодируемыми, и/или их компоновки в порядке представления. Примеры шести типов SAP описываются в данном документе. Один тип, в котором T_EPT=T_DEC=T_SAP=T_PFT, может соответствовать тому, что известно как "точка произвольного доступа в форме закрытой GoP". Единицы доступа (в порядке декодирования), начинающиеся с I_SAP, могут корректно декодироваться. Результат может представлять собой непрерывную временную последовательность корректно декодированных единиц доступа без разрывов. Первая единица доступа в порядке декодирования может представлять собой первую единицу доступа в порядке представления.

[0147] В другом типе SAP, T_EPT=T_DEC=T_SAP<T_PFT. Этот тип SAP может соответствовать тому, что известно как "точка произвольного доступа в форме закрытой GoP", для которой первая единица доступа в порядке декодирования в мультимедийном потоке, начинающемся с I_SAU, может не представлять собой первую единицу доступа в порядке представления. Например, первые два кадра могут представлять собой обратно предсказанные P-кадры (которые синтаксически могут быть кодированы в качестве B-кадров только для перенаправления в H.264 и в некоторых других кодеках), и/или им может требоваться или не требоваться третий кадр для декодирования.

[0148] В другом типе SAP, T_EPT<T_DEC=T_SAP<=T_PTF. Этот тип SAP может соответствовать тому, что известно как "точка произвольного доступа в форме открытой GoP", в которой могут быть некоторые единицы доступа в порядке декодирования после I_SAU, которые не могут корректно декодироваться и/или могут иметь времена представления меньше T_SAP.

[0149] В другом типе SAP, T_EPT<=T_PFT<T_DEC=T_SAP. Этот тип SAP может соответствовать тому, что известно как "точка произвольного доступа на основе постепенного обновления при декодировании (GDR)" или "грязный" произвольный доступ, в котором могут быть некоторые единицы доступа в порядке декодирования, начинающемся с и после I_SAU, которые не могут корректно декодироваться и/или могут иметь времена представления меньше T_SAP. Один примерный случай GDR может представлять собой процесс внутреннего обновления, который может охватывать N кадров с частью кадра, кодированного с помощью внутренних MB. Неперекрывающиеся части могут интра-кодироваться через N кадров. Этот процесс может повторяться до тех пор, пока не будет обновлен весь кадр.

[0150] В другом типе SAP, T_EPT=T_DEC<T_SAP. Этот тип SAP может соответствовать случаю, для которого предусмотрена, по меньшей мере, одна единица доступа в порядке декодирования, начинающемся с I_SAP, которая не может корректно декодироваться, может иметь время представления, превышающее T_DEC, и при этом T_DEC может быть самым ранним временем представления единицы доступа, начинающейся с I_SAU.

[0151] В другом типе SAP, T_EPT<T_DEC<T_SAP. Этот тип SAP может соответствовать случаю, для которого может быть, по меньшей мере, одна единица доступа в порядке декодирования, начинающемся с I_SAP, которая не может корректно декодироваться, может иметь время представления, превышающее T_DEC, и при этом T_DEC может не быть самым ранним временем представления единицы доступа, заканчивающейся на I_SAU.

[0152] Профили DASH могут быть заданы для того, чтобы обеспечивать функциональную совместимость и передачу в служебных сигналах относительно использования признаков. Профиль может налагать набор ограничений. Эти ограничения могут налагаться на признаки документа описания мультимедийного представления (MPD) и/или на форматы сегментов. Ограничение может налагаться на контент, доставляемый в сегментах, к примеру, но не только, на типы мультимедийного контента, формат(ы) мультимедиа, кодек(и) и/или форматы защиты и/или на количественные показатели, к примеру, но не только, на скорости передачи битов. Длительности и размеры сегментов и/или горизонтальный и вертикальный визуальный размер представления.

[0153] Например, DASH может задавать определенное число профилей, показанных на фиг. 16. Профили могут быть организованы в двух категориях на основе типа контейнера файлов, используемого для сегментов. Три профиля 1600, 1602, 1604 могут использовать контейнеры мультимедийных файлов по стандарту ISO Base, два профиля 1606, 1608 могут использовать контейнеры файлов на основе стандарта транспортных потоков (TS) MPEG-2, и один профиль 1610 может поддерживать оба типов контейнеров файлов. Любой тип контейнера может быть независимым от кодека.

[0154] Формат мультимедийного файла по стандарту ISO Base профиля 1602 передач по запросу может предоставлять базовую поддержку для контента по запросу. Ограничения профиля 1602 передач по запросу могут заключаться в том, что каждое представление может предоставляться в качестве одного сегмента, субсегменты могут совмещаться через представления в адаптивном наборе, и/или субсегменты могут начинаться с точек доступа к потоку. Профиль 1602 передач по запросу может использоваться для того, чтобы поддерживать большие библиотеки видео по запросу (VoD) с относительно нестрогим управлением контентом. Профиль 1602 передач по запросу может разрешать масштабируемое и эффективное использование HTTP-серверов и может упрощать прозрачную коммутацию.

[0155] Профиль 1604 передач в реальном времени в формате мультимедийного файла по стандарту ISO Base может быть оптимизирован для кодирования в реальном времени и/или доставки с небольшим временем задержки сегментов, состоящих из одного фрагмента фильма ISO-формата файла с относительно небольшой длительностью. Каждый фрагмент фильма может запрашиваться при доступности. Это может быть выполнено, например, с использованием сформированного по шаблону URL-адреса. Запросы на MPD-обновления могут опускаться для некоторых запросов сегментов. Сегменты могут ограничиваться таким образом, что они могут конкатенироваться на границах сегментов и дешифроваться без разрывов и/или перекрытий в мультимедийных данных. Это может быть независимо от адаптивной коммутации представлений в адаптивном наборе. Этот профиль 1604 может использоваться для того, чтобы распределять передаваемый не в реальном времени контент. Например, профиль 1604 передач в реальном времени может использоваться, когда передаваемое в реальном времени мультимедийное представление завершено, но поддерживается доступным в качестве услуги по запросу. Основной профиль 1600 в формате мультимедийного файла по стандарту ISO Base может представлять собой расширенный набор профиля 1602 передач по запросу и профиля 1604 передач в реальном времени в формате мультимедийного файла по стандарту ISO Base.

[0156] Основной профиль 1606 в формате MPEG-2 TS может налагать нестрогие ограничения на формат мультимедийного сегмента для контента на основе стандарта транспортных потоков (TS) MPEG-2. Например, представления могут быть мультиплексированы, так что может не требоваться привязка мультимедийных потоков (аудио, видео) в клиенте. Например, сегменты могут включать в себя целое число MPEG-2 TS-пакетов. Например, может рекомендоваться индексация и совмещение сегментов. Контент потоковой HTTP-передачи в реальном времени (HLS) может быть интегрирован с этим профилем 1606 посредством преобразования описания мультимедийного HLS-представления (.m3u8) в DASH MPD.

[0157] Простой профиль 1608 в формате MPEG-2 TS может представлять собой поднабор основного профиля 1606 в формате MPEG-2 TS. Это может налагать дополнительные ограничения на кодирование и мультиплексирование контента, чтобы обеспечивать простую реализацию прозрачной коммутации. Прозрачная коммутация может достигаться посредством гарантирования того, что механизм обработки мультимедиа, соответствующий ISO/IEC 13818-1 (MPEG-2-системы), может воспроизводить любой поток битов, сформированный посредством конкатенации последовательных сегментов из любого представления в идентичном адаптивном наборе. Полный профиль 1610 может представлять собой расширенный набор основного профиля 1600 в формате мультимедийного файла по стандарту ISO Base и основного профиля 1606 в формате MPEG-2 TS.

[0158] Фиг. 17 является блок-схемой, иллюстрирующей пример видеокодера на основе блоков, например, гибридной системы кодирования видео. Входной видеосигнал 1702 может обрабатываться поблочно. Единица видеоблока может включать в себя 16x16 пикселов. Такая единица блока может упоминаться в качестве макроблока (MB). В стандарте высокоэффективного кодирования видео (HEVC) увеличенные размеры блоков (например, которые могут упоминаться в качестве "единицы кодирования" или CU) могут использоваться для того, чтобы эффективно сжимать видеосигналы высокого разрешения (например, 1080p и выше). В HEVC, CU может составлять вплоть до 64x64 пикселов. CU может быть сегментирована на единицы предсказания (PU), для которых могут применяться отдельные способы предсказания.

[0159] Для входного видеоблока (например, MB или CU), может выполняться пространственное предсказание 1760 и/или временное предсказание 1762. Пространственное предсказание (например, "интра-предсказание") может использовать пикселы из уже кодированных соседних блоков в идентичном видеоизображении/серии последовательных макроблоков для того, чтобы предсказывать текущий видеоблок. Пространственное предсказание позволяет уменьшать пространственную избыточность, внутренне присущую в видеосигнале. Временное предсказание (например, "интер-предсказание" или "предсказание с компенсацией движения") может использовать пикселы из уже кодированных видеоизображений (например, которые могут упоминаться в качестве "опорных изображений") для того, чтобы предсказывать текущий видеоблок. Временное предсказание позволяет уменьшать временную избыточность, внутренне присущую в видеосигнале. Сигнал временного предсказания для видеоблока может быть передан в служебных сигналах посредством одного или более векторов движения, которые могут указывать величину и/или направление движения между текущим блоком и его блоком предсказания в опорном изображении. Если поддерживаются несколько опорных изображений (например, что может иметь место для H.264/AVC и/или HEVC), то для каждого видеоблока, может дополнительно отправляться его индекс опорного изображения. Опорный индекс может использоваться для того, чтобы идентифицировать то, из какого опорного изображения в хранилище 1764 опорных изображений (например, которое может упоминаться в качестве "буфера декодированных изображений", или DPB) поступает сигнал временного предсказания.

[0160] После пространственного и/или временного предсказания блок 1780 решения по выбору режима в кодере может выбирать режим предсказания. Блок предсказания может вычитаться из текущего видеоблока 1716. Остаток предсказания может преобразовываться 1704 и/или квантоваться 1706. Квантованные остаточные коэффициенты могут обратно квантоваться 1710 и/или обратно преобразоваться 1712 для того, чтобы формировать восстановленный остаток, который может добавляться обратно в блок 1726 предсказания для того, чтобы формировать восстановленный видеоблок.

[0161] Внутриконтурная фильтрация, к примеру, но не только, фильтр удаления блочности, контурные фильтры на основе дискретизированного адаптивного смещения и/или адаптивные контурные фильтры, может применяться 1766 к восстановленному видеоблоку до того, как он помещается в хранилище 1764 опорных изображений и/или используется для того, чтобы кодировать будущие видеоблоки. Чтобы формировать выходной поток 1720 видеобитов, режим кодирования (например, режим интер-предсказания или режим интра-предсказания), информация режима предсказания, информация движения и/или квантованные остаточные коэффициенты могут отправляться в модуль 1708 энтропийного кодирования для сжатия и/или пакетирования с тем, чтобы формировать поток битов.

[0162] Фиг. 18 является блок-схемой, иллюстрирующей пример видеодекодера на основе блоков. Поток 1802 видеобитов может распаковываться и/или энтропийно декодироваться в модуле 1808 энтропийного декодирования. Информация режима кодирования и/или предсказания может отправляться в модуль 1860 пространственного предсказания (например, если интра-кодируется) и/или модуль 1862 временного предсказания (например, если интер-кодируется) для того, чтобы формировать блок предсказания. Если интер-кодируется, информация предсказания может содержать размеры блоков предсказания, один или более векторов движения (например, которые могут указывать направление и величину движения) и/или один или более опорных индексов (например, которые могут указывать то, из какого опорного изображения должен быть получен сигнал предсказания).

[0163] Предсказание с компенсацией движения может применяться посредством модуля 1862 временного предсказания, чтобы формировать блок временного предсказания. Остаточные коэффициенты преобразования могут отправляться в модуль 1810 обратного квантования и модуль 1812 обратного преобразования, чтобы восстанавливать остаточный блок. Блок предсказания и остаточный блок могут суммироваться в 1826. Восстановленный блок может проходить через внутриконтурную фильтрацию до того, как он сохраняется в хранилище 1864 опорных изображений. Восстановленное видео в хранилище 1864 опорных изображений может использоваться для того, чтобы активировать устройство отображения, и/или использоваться для того, чтобы предсказывать будущие видеоблоки.

[0164] Однослойный видеокодер может принимать один ввод видеопоследовательности и формировать один сжатый поток битов, передаваемый в однослойный декодер. Видеокодек может быть спроектирован для услуг передачи цифрового видео (например, таких как, но не только, отправку телевизионных сигналов по спутниковым, кабельным и наземным каналам передачи). В видео-ориентированных приложениях, развернутых в гетерогенных окружениях, технологии многослойного кодирования видео могут быть разработаны в качестве расширения стандартов кодирования видео для того, чтобы обеспечивать различные приложения. Например, технологии масштабируемого кодирования видео могут быть спроектированы с возможностью обрабатывать более одного видеослоя, при этом каждый слой может декодироваться для того, чтобы восстанавливать видеосигнал с конкретным пространственным разрешением, временным разрешением, точностью воспроизведения и/или видом. Любой из принципов, описанных в данном документе, может выполняться посредством кодера и/или декодера, например, посредством кодера и/или декодера, описанных со ссылкой на фиг. 17 и фиг. 18. Дополнительно, хотя однослойный кодер и декодер описывается со ссылкой на фиг. 17 и фиг. 18, принципы, описанные в данном документе, могут использовать многослойный кодер и декодер, например, для технологий многослойного или масштабируемого кодирования.

[0165] Процессы, описанные выше, могут быть реализованы в компьютерной программе, программном обеспечении и/или микропрограммном обеспечении, включенном в компьютерно-читаемый носитель для выполнения посредством компьютера и/или процессора. Примеры компьютерно-читаемых носителей включают в себя, но не только, электронные сигналы (передаваемые по проводным и/или беспроводным подключениям) и/или компьютерно-читаемые запоминающие носители. Примеры компьютерно-читаемых запоминающих носителей включают в себя, но не только, постоянное запоминающее устройство (ROM), оперативное запоминающее устройство (RAM), регистры, кэш-память, полупроводниковые запоминающие устройства, магнитные носители, такие как, но не только, внутренние жесткие диски и съемные диски, магнитооптические носители и/или оптические носители, такие как CD-ROM-диски и цифровые универсальные диски (DVD). Процессор в ассоциации с программным обеспечением может использоваться для того, чтобы реализовывать радиочастотное приемо-передающее устройство для использования в WTRU, пользовательском оборудовании (UE), терминале, базовой станции, RNC и/или любом хост-компьютере.

Claims

1. Способ коммутации контента в беспроводном модуле приема/передачи (WTRU), при этом способ содержит этапы, на которых:

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

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

- запрашивают выбранный поток; и

- принимают выбранный поток.

2. Способ по п. 1, в котором объективный показатель качества видео сегмента контента содержит пиковое отношение сигнал-шум (PSNR), структурное подобие (SSIM), показатель качества видео (VQM), точность воспроизведения визуальной информации (VIF), J.341 или средняя экспертная оценка (MOS).

3. Способ по п. 1, в котором информация качества видео сохраняется в файле манифеста.

4. Способ по п. 3, в котором файл манифеста содержит файл описания мультимедийного представления (MPD), и информация качества видео включена в один или более тегов MPD-файла.

5. Способ по п. 1, в котором информация качества видео сохраняется в индексном файле сегментов.

6. Способ по п. 5, в котором индексный файл сегментов содержит, по меньшей мере, один из МР4-файла или M4S-файла.

7. Способ по п. 5, в котором индексный файл сегментов содержит контейнер файлов на основе ISOBMFF, содержащий, по меньшей мере, одно поле, и при этом параметр качества сегмента включен, по меньшей мере, в одно поле контейнера файлов на основе ISOBMFF.

8. Способ по п. 5, в котором в WTRU передается в служебных сигналах наличие информации качества видео через флаг в файле описания мультимедийного представления (MPD).

9. Способ по п. 1, в котором информация качества видео включена в файл, который ассоциирован с файлом описания мультимедийного представления (MPD).

10. Способ по п. 9, в котором файл ассоциирован с адаптивным набором в MPD-файле.

11. Способ коммутации контента в беспроводном модуле приема/передачи (WTRU), при этом способ содержит этапы, на которых:

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

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

- запрашивают выбранный поток; и

- принимают выбранный поток.

12. Способ по п. 11, в котором информация качества видео сохраняется в файле манифеста.

13. Способ по п. 12, в котором файл манифеста содержит файл описания мультимедийного представления (MPD), и информация качества видео включена в один или более тегов MPD-файла.

14. Способ по п. 11, в котором информация качества видео сохраняется в индексном файле сегментов.

15. Способ по п. 11, в котором в WTRU передается в служебных сигналах наличие информации качества видео через флаг в файле описания мультимедийного представления (MPD).

16. Способ по п. 11, в котором информация качества видео включена в файл, который ассоциирован с файлом описания мультимедийного представления (MPD).

17. Способ по п. 16, в котором файл ассоциирован с адаптивным набором в MPD-файле.