СПОСОБ АДАПТИВНОЙ ПОТОКОВОЙ ПЕРЕДАЧИ ДАННЫХ С УПРАВЛЕНИЕМ СООБЩЕНИЯМИ АКТИВНОЙ ДОСТАВКИ Российский патент 2019 года по МПК H04N21/472 H04N21/262 

Данная заявка испрашивает приоритет по следующим патентным заявкам Великобритании: № 1312547.1 и № 1312561.2, поданным 12 июля 2013 г., и № 1410540.7, поданной 12 июня 2014 г., которые все включены в данное описание в порядке ссылки.

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

Настоящее изобретение относится к сетям связи на основе потоковой передачи данных по HTTP.

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

DASH (динамическая адаптивная потоковая передача по HTTP) - это стандарт связи, обеспечивающий потоковую передачу медиаконтента (обычно аудио/видеоконтент) по HTTP. Согласно DASH, медиапрезентации описываются как файлы XML, именуемые файлами “описания медиапрезентации" (в дальнейшем MPD). Файлы MPD обеспечивают клиентские устройства информацией, позволяющей им запрашивать и управлять доставкой медиаконтента.

УРОВЕНЬ ТЕХНИКИ

Общий принцип передачи медиапотока по HTTP проиллюстрирован на фиг. 3. Большинство новых протоколов и стандартов для адаптивной передачи медиапотока по HTTP базируются на этом принципе.

Медиасервер 300 осуществляет потоковую передачу данных на клиент 310. На медиасервере хранятся медиапрезентации. Например, медиапрезентация 301 содержит аудио- и видеоданные. Аудио и видео могут перемежаться в одном и том же файле. Способ построения медиапрезентации описан в дальнейшем со ссылкой на фиг. 4a. Медиапрезентация разделяется во времени на малые независимые и последовательные временные сегменты 302a, 302b и 302c, например сегменты MP4, которые можно независимо адресовать и загружать. Адреса загрузки (URL HTTP) медиаконтента для каждого из этих временных сегментов устанавливаются сервером для клиента. Каждый временной сегмент аудио/видео медиаконтента связан с одним адресом HTTP.

На медиасервере также хранится документ 304 файла манифеста (описанный в дальнейшем со ссылкой на фиг. 5), который описывает контент медиапрезентации, включающий в себя характеристики медиаконтента (например тип медиаданных: аудио, видео, аудио-видео, текст и т.д.), формат кодирования (например битовую скорость, информацию хронирования и т.д.), список временных медиасегментов и соответствующих URL. Альтернативно, документ содержит информацию шаблона, которая позволяет повторно построить явный список временных медиасегментов и соответствующих URL. Этот документ может быть записан с использованием расширяемого языка разметки (XML).

Файл манифеста отправляется на клиент. После приема файла манифеста на этапе 305, клиент информируется о связи между временными сегментами медиаконтента и адресами HTTP. Кроме того, файл манифеста снабжает клиента информацией, касающейся контента медиапрезентации (перемежающегося аудио/видео в настоящем примере). Информация может включать в себя разрешение, битовую скорость и т.д.

На основании принятой информации, модуль 311 клиента HTTP клиента может выдавать запросы 306 HTTP для загрузки временных сегментов медиаконтента, описанных в файле манифеста. Ответы 307 HTTP сервера переносят запрашиваемые временные сегменты. Модуль 311 клиента HTTP извлекает из ответов временные медиасегменты и переносит их во входной буфер 307 машины 312 медиаданных. Наконец, медиасегменты могут декодироваться и отображаться на соответствующие этапы 308 и 309.

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

Генерация медиапрезентации и файла манифеста описана со ссылкой на фиг. 4a. На этапах 400 и 401 получаются аудио- и видеоданные. Затем аудиоданные сжимаются на этапе 402. Например, может использоваться стандарт MP3. Также видеоданные сжимаются параллельно на этапе 403. Например, могут использоваться алгоритмы сжатия видеосигнала MPEG4, MPEG/AVC, SVC, HEVC или масштабируемого HEVC. После осуществления сжатия аудио- и видеоданных, доступны элементарные потоки 404, 405 аудио и видео. Элементарные потоки инкапсулируются на этапе 406 в глобальную медиапрезентацию. Например, стандарт BMFF ISO (или расширение стандарта BMFF ISO до AVC, SVC, HEVC, масштабируемое расширение HEVC и т.д.) может использоваться для описания контента кодированных элементарных потоков аудио и видео как глобальной медиапрезентации. Полученная таким образом инкапсулированная медиапрезентация 407 используется для генерации, на этапе 408, XML-файла 409 манифеста. В медиапрезентации 407 может быть получено, сжато, инкапсулировано и описано несколько представлений видеоданных 401 и аудиоданных 400.

Для конкретного случая протокола потоковой передачи MPEG/DASH, проиллюстрированного на фиг. 4b, файл манифеста именуется “описанием медиапрезентации" (или файлом “MPD”). Корневым элементом файла является элемент MPD который содержит атрибуты, применяющиеся ко всей презентации плюс информация DASH, например, профиль или схема. Медиапрезентация разделяется на периоды времени, представляемые элементом Period. Файл MPD 410 содержит все данные, связанные с каждым периодом времени. Благодаря приему этой информации, клиент знает контент для каждого периода времени. Для каждого периода 411 задаются элементы AdaptationSet.

Возможная организация предусматривает наличие одного или более AdaptationSet для каждого типа медиаданных, содержащегося в презентации. AdaptationSet 412, связанный с видео, содержит информацию о различных возможных представлениях кодированных видеозаписей, доступных на сервере. Каждое представление описано в элементе Representation. Например, первое представление может представлять собой видео, кодированное с пространственным разрешением 640×480 и сжатое с битовой скоростью 500 кбит/с. Второе представление может представлять собой то же самое видео, но сжатое с битовой скоростью 250 кбит/с.

Затем каждая видеозапись может загружаться по запросам HTTP, если клиент знает адреса HTTP, связанные с видеозаписью. Связь между контентом каждого представления и адресами HTTP устанавливается с использованием дополнительного уровня описания: временные сегменты. Каждое представление видео разделяется на временные сегменты 413 (обычно несколько секунд). Каждый временной сегмент содержит контент, хранящийся на сервере, который доступен по адресу HTTP (URL или URL с одним байтовым диапазоном). Для описания временных сегментов в файле MPD может использоваться несколько элементов: SegmentList, SegmentBase или SegmentTemplate.

Кроме того, доступен конкретный сегмент: сегмент инициализации. Сегмент инициализации содержит информацию инициализации MP4 (если видео инкапсулировано с использованием BMFF ISO или его расширений), которая описывает инкапсулированный видеопоток. Например, это помогает клиенту иллюстрировать примерами алгоритмы декодирования, связанные с видео.

В файле MPD указаны адреса HTTP сегмента инициализации и медиасегментов.

На фиг. 5 показан иллюстративный файл MPD. В показанном файле MPD описаны два медиа материала. Первым является аудиопоток на английском языке, и вторым является видеопоток. Аудиопоток на английском языке вводится с использованием тега 500 AdaptationSet. Для этого аудиопотока доступны два альтернативных представления:

- первым представлением 501 является инкапсулированный элементарный аудиопоток MP4 с битовой скоростью 64000 бит/с. Кодек, подлежащий использованию для обработки этого элементарного потока (после разбора (синтаксического анализа) MP4) задан в стандарте атрибутом кодека, имеющим значение: 'mp4a.0x40'. Он доступен по запросу по адресу, сформированному сцеплением элементов BaseURL в иерархии сегментов: <BaseURL>7657412348.mp4</BaseURL>, который является относительным URI. <BaseURL>, заданный на верхнем уровне в элементе MPD в виде ‘http://cdn1.example.com/’ или в виде ‘http://cdn2.example.com/’ (два сервера доступны для потоковой передачи одного и того же контента), является абсолютным URI. Затем клиент может запрашивать аудиопоток на английском языке из запроса по адресу ‘http://cdn1.example.com/7657412348.mp4’ или по адресу 'http://cdn2.example.com/7657412348.mp4’.

- вторым представлением 502 является инкапсулированный элементарный аудиопоток MP4 с битовой скоростью 32000 бит/с. Можно привести те же объяснения, что и для первого представления 501, и, таким образом, клиентское устройство может запрашивать это второе представление 502 посредством запроса по любому из следующих адресов:

‘http://cdn1.example.com/3463646346.mp4’ или ‘http://cdn2.example.com/3463646346.mp4’.

Адаптационный набор 503, связанный с видео, содержит шесть представлений. Эти представления содержат видеозаписи с разными пространственными разрешениями (320×240, 640×480, 1280×720) и с разными битовыми скоростями (от 256000 до 2048000 битов в секунду). Для каждого из этих представлений соответствующий URL связывается через элемент BaseURL. Таким образом, клиент может выбирать между этими альтернативными представлениями одного и того же видео согласно различным критериям, например, оцененной полосе, разрешению экрана и т.д. (заметим, что, согласно фиг. 5, разложение представления на временные сегменты для наглядности не проиллюстрировано.)

Фиг. 5a демонстрирует стандартное поведение клиента DASH. Фиг. 5b демонстрирует древовидное представление иллюстративного файла манифеста (файла описания или MPD), используемого в способе, показанном на фиг. 4a.

В начале сеанса потоковой передачи, клиент DASH начинает с запрашивания файла манифеста (этап 550). После ожидания ответа сервера и приема файла манифеста (этап 551), клиент анализирует файл манифеста (этап 552), выбирает набор ASij из AdaptationSet, пригодных для его окружения (этап 553), затем выбирает, в каждом ASij AdaptationSet, представление в MPD, пригодном, например, для этой полосы, возможности декодирования и рендеризации (этап 554).

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

Затем клиент запрашивает сегмент инициализации (этап 556). После приема сегмента инициализации (этап 557), декодеры инициируются (этап 558).

Затем клиент посегментно запрашивает первые медиаданные (этап 560) и буферизует минимальный объем данных (согласно условию на этапе 559) прежде, чем фактически начать декодирование и отображение (этап 563). Эти множественные запросы/ответы между загрузкой MPD и первыми отображаемыми кадрами вносят задержку запуска в сеанс потоковой передачи. После этих начальных этапов, сеанс потоковой передачи DASH продолжается стандартным образом, т.е. клиент DASH адаптирует и запрашивает медиасегменты один за другим.

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

В частности, компоненты медиаконтента можно описать с использованием элементов SubRepresentation. Эти элементы описывают свойства одного или нескольких компонентов, вложенных в представление. На фиг. 6 показан пример файла манифеста DASH, описывающего дорожки фрагментов как компоненты видео. Для краткости и наглядности представлен один-единственный период 600. Однако последующие элементы периода будут организованы таким же образом. В части 601, элемент первый адаптационный набор используется для описания базового уровня масштабируемого видео. Например, видео кодируется согласно SVC или масштабируемому HEVC. В части 602, второй адаптационный набор используется для описания уровня наивысшего разрешения масштабируемого видео. Для немасштабируемого видео будет присутствовать только второй адаптационный набор 602, без зависимости от базового уровня, т.е. атрибута dependencyId. В этом втором адаптационном наборе 602 описано единичное представление 603, а именно, то, которое соответствует отображаемому видео. Представление описано как список сегментов 610 с соответствующими URL для запросов клиента.

Таким образом, представление зависит от другого представления, идентифицированного посредством ‘R1’ (атрибута dependencyId), фактически, представления базового уровня из первого адаптационного набора 601. Зависимость предписывает клиенту потоковой передачи сначала запрашивать текущий сегмент для базового уровня до получения текущего сегмента для уровня улучшения. Это нельзя использовать для выражения зависимостей в отношении дорожек фрагментов, поскольку дорожки, указываемые таким образом, будут автоматически загружаться клиентом. Этого следует избегать, поскольку пользователь способен выбирать интересные ему фрагменты в любой момент в ходе медиапрезентации. Таким образом, для указания зависимостей между составной дорожкой и дорожками фрагментов используется элемент SubRepresentation. Отображаемое видео описано как список подпредставлений 604-608. Каждое подпредставление фактически представляет дорожку в инкапсулированном файле MP4. Таким образом, существует по одному подпредставлению для каждого фрагмента (четыре фрагмента в настоящем примере) плюс одно подпредставление для составной дорожки 608. Каждое подпредставление описано элементом 614-618 "компонент контента" для указания, соответствует ли оно дорожке 614, 615, 616 и 617 фрагментов или составной дорожке 618. Тип описателя Role, доступный DASH/MPD, используется с конкретной схемой разбиения на фрагменты. Описатель Role также указывает позицию фрагмента в полноэкранном видео. Например, компонент 614 описывает фрагмент, расположенный в верхнем левом углу видео (1:1 для первого в строке и первого в столбце). Размеры фрагментов, ширина и высота, задаются как атрибуты подпредставления, возможные для MPD. Здесь также может быть задана информация полосы для помощи клиенту DASH при определении количества фрагментов и выборе фрагментов согласно его полосе. Что касается составной дорожки, ее нужно сигнализировать иначе, чем дорожки фрагментов, поскольку в конце загрузки обязательно нужно иметь возможность построения видеопотока, который можно декодировать. С этой целью, в описание добавляются два элемента. Во-первых, описатель в соответствующем компоненте 618 контента указывает, что он является главным компонентом из всех компонентов. Во-вторых, в подпредставлении, добавляется новый атрибут ‘необходимый’ для указания клиенту, что соответствующие данные подлежат запрашиванию. Все запросы составной дорожки или одной или более из дорожек фрагментов вычисляются из URL, обеспеченного в списке 610 сегментов (по одному для каждого интервала времени). В примере, “URL_X" объединенный с “BaseURL" в начале MPD обеспечивает полный URL, который клиент может использовать для осуществления запроса GET HTTP. С помощью этого запроса, клиент будет получать данные для составной дорожки и все данные для всех дорожек фрагментов. Для оптимизации передачи, вместо запроса, клиент может сначала запрашивать информацию индекса сегмента (обычно информацию “ssix" и/или “sidx” в BMFF ISO, хорошо известную специалисту в данной области техники), с использованием данных, доступных из атрибута 620 index_range. Эта информация индекса позволяет определять байтовые диапазоны для каждого из компонентов. Затем клиент DASH может отправлять столько же запросов GET HTTP с надлежащим байтовым диапазоном, сколько выбрано дорожек (включая необходимую составную дорожку).

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

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

Активная доставка (push, доставка без запроса) сервером является полезной функцией для уменьшения времени загрузки веб-ресурса. Такие серверы рассматриваются со ссылкой на фиг. 1a - 1e.

На фиг. 1b показано, что при обменах данными HTTP/2, запрос нужно отправлять для каждого необходимого ресурса: ресурсов с R1 по R4 и подресурсов с A по I (как показано на фиг. 1a). Однако, при использовании функции активной доставки серверами, как показано на фиг. 1c, количество запросов ограничивается элементами с R1 по R4. Элементы с A по I “активно доставляются” сервером на клиент на основании зависимостей, показанных на фиг. 1a, что избавляет от необходимости в соответствующих запросах.

Таким образом, как показано на фиг. 1b и 1c, когда серверы используют функцию активной доставки, количество прохождений в двух направлениях HTTP (запрос+ответ), необходимое для загрузки ресурса с его подресурсами, уменьшается. Это особенно интересно для сетей высокой латентности, например, сетей мобильной связи.

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

• клиент отправляет запрос на сервер;

• сервер отвечает на запрос клиента ответом, который содержит представление веб-ресурса.

Запросы и ответы представляют собой сообщения, содержащие различные части, в особенности, заголовки HTTP. Заголовок HTTP содержит имя совместно со значением. Например, в заголовке “Host:en.wikipedia.org” “Host” это имя, и “en.wikipedia.org” - его значение. Он используется для указания хоста запрашиваемого ресурса (например, страница Wikipedia, описывающая HTTP, доступна по адресу http://en.wikipedia.org/wiki/HTTP). Заголовки HTTP возникают в запросах клиента и ответах сервера.

HTTP/2 позволяет обмениваться запросами/ответами через потоки. Поток создается внутри соединения HTTP/2 для каждого запроса и ответа HTTP. Обмен кадрами осуществляется в потоке для переноса содержимого и заголовков запросов и ответов.

HTTP/2 задает ограниченный набор кадров с разные смысловыми значениями, например:

- HEADERS: который обеспечивается для передачи заголовков HTTP

- DATA: который обеспечивается для передачи содержимого сообщения HTTP

- PUSH_PROMISE: который обеспечивается для объявления активно доставляемого контента

- PRIORITY: который обеспечивается для установления приоритета потока

- WINDOW_UPDATE: который обеспечивается для обновления значения окна потока управления

- SETTINGS: который обеспечивается для переноса параметров конфигурации

- CONTINUATION: который обеспечивается для продолжения последовательности блочных фрагментов заголовка

- RST_STREAM: который обеспечивается для окончания или отмены потока.

Активная доставка серверами была введена в HTTP/2 для того, чтобы серверы могли отправлять представления незатребованных веб-ресурсов на клиенты. Веб-ресурсы, например веб-страницы, в общем случае содержат ссылки на другие ресурсы, которые, в свою очередь, могут содержать ссылки на другие ресурсы. Для полного отображения веб-страницы клиенту, в общем случае, необходимо извлекать все связанные и подсвязанные ресурсы. Это возрастающее выявление может приводить к медленному отображению веб-страницы, в особенности в сетях высокой латентности, например, сетях мобильной связи.

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

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

На этапе 100 сервер принимает начальный запрос. Затем сервер идентифицирует на этапе 101 ресурсы для активной доставки как часть ответа и начинает отправлять ответ контента на этапе 102. Параллельно, сервер отправляет сообщения обещания активной доставки на клиент на этапе 103. Эти сообщения идентифицируют другие ресурсы, которые сервер планирует активно доставлять, например, на основании зависимостей, показанных на фиг. 1a. Эти сообщения отправляются для того, чтобы клиент мог заранее знать, какие активно доставляемые ресурсы будут отправляться. В частности, это снижает опасность отправки клиентом запроса на ресурс, который в настоящее время активно доставляется или подлежит активной доставке. Для дополнительного снижения этой опасности, сервер должен отправлять сообщение обещания активной доставки до отправки какой-либо части ответа согласно ресурсу, описанному в обещании активной доставки. Это также позволяет клиентам запрашивать отмену активной доставки обещанных ресурсов, если клиентам не нужны эти ресурсы. Затем сервер отправляет ответ и все обещанные ресурсы на этапе 104. Процесс заканчивается на этапе 105.

Блок-схема операций на фиг. 1d демонстрирует процесс на стороне клиента.

После того, как клиент идентифицирует ресурс для извлечения с сервера, он сначала проверяет на этапе 106, находятся ли уже соответствующие данные в его кэш-памяти. В случае, когда ресурс уже находится в кэш-памяти (Да), он извлекается из нее на этапе 107. Кэшированные данные могут представлять собой либо данные, извлеченные из предыдущих запросов, либо данные, ранее активно доставленные сервером. В случае, когда он не находится в кэш-памяти (Нет), клиент отправляет запрос на этапе 108 и ожидает ответа сервера. После приема кадра от сервера, клиент проверяет на этапе 109, соответствует ли кадр обещанию активной доставки. Если кадр данных соответствует обещанию активной доставки (Да), то на этапе 110 клиент обрабатывает обещание активной доставки. Клиент идентифицирует ресурс, подлежащий активной доставке. Если клиент не желает принимать ресурс, клиент может отправлять сообщение ошибки на сервер, чтобы сервер не выполнял активную доставку этого ресурса. В противном случае, клиент сохраняет обещание активной доставки, пока не примет соответствующий активно доставляемый контент. Обещание активной доставки используется таким образом, что клиент не запрашивает обещанный ресурс, пока сервер активно доставляет его. В случае, когда кадр данных не соответствуют обещанию активной доставки (Нет), на этапе 111 проверяется, является ли кадр кадром данных, относящимся к активно доставляемым данным. В случае, когда он относится к активно доставляемым данным (Да), клиент обрабатывает активно доставляемые данные на этапе 112. Активно доставляемые данные сохраняются в кэш-памяти клиента. В случае, когда кадр не является кадром данных, относящимся к активно доставляемым данным (Нет), на этапе 113 проверяется, соответствует ли он к ответу, принятому от сервера. В случае, когда кадр соответствует ответу от сервера (Да), ответ обрабатывается на этапе 114 (например, отправляется на приложение). В противном случае (Нет), на этапе 115 проверяется, идентифицирует ли кадр конец ответа (Да). В этом случае, процесс заканчивается на этапе 116. В противном случае, процесс возвращается к этапу 109.

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

Хранение активно доставляемых ресурсов в кэш-памяти управляется с использованием директив управления кэш-памятью. Директивы управления кэш-памятью также используются для управления ответами. Эти директивы, в частности, применимы к узлам-посредникам (proxy-узлам): любой ресурс, активно доставленный или нет, может храниться узлами-посредниками или только клиентом.

На фиг. 1a показан граф набора ресурсов, находящихся в собственности сервера, с их соотношениями. Набор ресурсов переплетен: R1, R2, R3 и R4 являются ресурсами, которые необходимо загружать совместно для правильной обработки клиентом. Кроме того, задаются подресурсы с A по H. Эти подресурсы связаны с ресурсами 1, 2 или 3. Например, A связан с R1, и C связан с R1, R2 и R4.

Фиг. 1b, рассмотренная выше, демонстрирует обмен данными HTTP без использования функции активной доставки сервером: клиент запрашивает R1, затем он выявляет R2, A, B, C и D и запрашивает их. Приняв их, клиент запрашивает R3, R4, F и G. Наконец, клиент запрашивает подресурсы H и I. Для извлечения всего набора ресурсов требуется четыре прохождения в двух направлениях.

Фиг. 1c, рассмотренная выше, демонстрирует обмен данными HTTP с использованием функции активной доставки непосредственно соединенных подресурсов сервером. Запросив R1, сервер отправляет R1 и активно доставляет A, B, C и D. Клиент идентифицирует R2 и запрашивает его. Сервер отправляет R2 и активно доставляет F и G. Наконец, клиент идентифицирует R3, R4 и запрашивает эти ресурсы. Сервер отправляет R3, R4 и активно доставляет H и I. Этот процесс требует трех прохождений в двух направлениях для извлечения всего набора ресурсов.

Для уменьшения времени загрузки набора ресурсов, обычно, веб-страницы и ее подресурсов, HTTP/2 позволяет параллельно осуществлять обмен множественными приоритетами запроса и ответа. Как показано на фиг. 2, веб-страница может требовать загрузки нескольких ресурсов, например JavaScript, изображений и т.д. В ходе начального обмена данными 200 HTTP, клиент извлекает файл HTML. Этот файл HTML содержит ссылки на два файла JavaScript (JS1, JS2), два изображения (IMG1, IMG2), один файл CSS и один файл HTML. В ходе обмена данными 201, клиент отправляет запрос для каждого файла. Порядок, заданный на схеме обмена данными 201 на фиг. 2, базируется на порядке веб-страниц: клиент отправляет запрос, как только найдена ссылка. Затем сервер принимает запросы на JS1, CSS, IMG1, HTML, IMG2 и JS2 и обрабатывает эти запросы согласно этому порядку. Затем клиент извлекает эти ресурсы в этом порядке.

Приоритеты HTTP позволяют клиенту указывать, какие запросы более важны и должны обрабатываться до других запросов. Конкретное использование приоритетов проиллюстрировано на схеме обмена данными 202. Файлам JavaScript назначаются наивысший приоритет. Файлам CSS и HTML назначаются средний приоритет, и изображения назначаются низкий приоритет. Этот подход позволяет принимать блокирующие файлы или файлы, которые могут содержать ссылки на другие ресурсы, прежде чем другие файлы. В ответ, предполагается, что сервер старается отправлять в первую очередь файлы JavaScript, затем файлы CSS и HTML и, в конце концов, изображения, как описано на схеме обмена данными 202. Серверы не обязаны следовать приоритетам клиента.

Помимо приоритетов, HTTP/2 предусматривает, что можно управлять объемом одновременно обмениваемых данных. Клиент и сервер могут указывать, какой объем данных они могут буферизовать для каждого соединения и для каждого потока. Это аналогично управлению перегрузкой TCP: размер окна, который указывает доступный размер буфера, инициализируется на данное значение; каждый раз, когда отправитель отправляет данные, размер окна уменьшается; отправитель должен останавливать отправку данных, чтобы размер окна никогда не становился меньше нуля. Получатель принимает данные и отправляет сообщения для подтверждения, что данные были приняты и удалены из буфера; сообщение содержит объем данных, удаленных из буфера; затем размер окна увеличивается от данного значения, и отправитель может вновь начать отправку данных.

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

Потоковая передача на серверной основе обычно осуществляется с использованием RTP. В отличие от DASH, RTP не использует HTTP и не может непосредственно пользоваться веб-инфраструктурами, в частности узлами-посредниками и блоками кэш-памяти. Передача медиапотока на основе веб-сокетов страдает теми же недостатками. Согласно HTTP/1.1, потоковую передачу на серверной основе нелегко осуществлять, поскольку сервер, в общем случае, может только отвечать на запросы клиента. Согласно HTTP/2, в частности, благодаря введению функции активной доставки, серверы на основе DASH могут руководить потоковой передачей. Таким образом, серверы может использовать свое знание характеристик контента, который они передают в потоке, для оптимизации ощущений пользователя. Например, сервер может активно доставлять фильм в SD-качестве (в силу ограниченной полосы), но рекламные материалы в HD-качестве, поскольку рекламные материалы занимают дополнительную ограниченную величину полосы. Другим примером является случай сервера, который начинает делать быстрый запуск с видео низкого разрешения и переключается на наилучшее возможное представление после хорошего оценивания полосы.

Чтобы сервер мог руководить потоковой передачей, согласно одному подходу, серверу разрешается активно доставлять данные (в частности, данные DASH) как предпочтительные. Затем клиент использует любые доступные данные для отображения видео. Обычно сервер объявляет активную доставку сразу нескольких сегментов. Затем сервер отправляет сегменты параллельно или последовательно.

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

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

Таким образом, требуется усовершенствовать потоковую передачу данных, в особенности, в контексте связи на основе DASH.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

В данном контексте настоящее изобретение относится к нижеследующему.

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

- прием, от клиентского устройства, запроса, относящегося к первым медиаданным,

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

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

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

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

- передачу, на серверное устройство, запроса, относящегося к первым медиаданным,

- прием от упомянутого серверного устройства, в ответ на упомянутый запрос, данных, относящихся к упомянутым первым медиаданным,

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

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

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

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

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

Запрос, относящийся к первым медиаданным, может касаться первых медиаданных и/или других данных, связанных с этими первыми медиаданными.

Вторые медиаданные могут связываться с упомянутыми первыми медиаданными, например, серверным устройством.

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

Серверные устройства могут давать рекомендации по контенту клиентским устройствам. Также, они могут оптимизировать использование сети.

Варианты осуществления изобретения совместимы с существующими признаками HTTP/2. Эти признаки можно успешно использовать для реализации вариантов осуществления изобретения.

Сетевые характеристики, в общем случае, повышаются.

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

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

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

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

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

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

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

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

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

Серверные и клиентские устройства имеют такие же преимущества, как соответствующие вышеописанные способы.

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

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

определение серверным устройством политики активной доставки, и

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

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

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

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

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

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

Соответственно, способ может дополнительно содержать, на клиентском устройстве, отправку информации обновления политики активной доставки, вложенной в заголовок кадра HTTP, на серверное устройство.

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

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

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

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

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

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

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

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

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

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

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

Альтернативно, первый атрибут активной доставки является идентификатором конкретных медиаданных в файле описания.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- прием, от клиентского устройства, запроса, относящегося к первым медиаданным,

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

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

причем способ дополнительно содержит следующие этапы:

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

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

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

Упомянутые значения приоритета могут задаваться согласно протоколу HTTP/2.

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

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

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

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

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

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

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

Например, запрашиваемые первые медиаданные являются видеосегментами.

Потоковая передача может осуществляться согласно стандарту DASH.

Например, способ дополнительно содержит следующие этапы:

- прием, от клиентского устройства, запроса обновления упорядочения,

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

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

Способ может дополнительно содержать передачу на клиентское устройство сообщения подтверждения обновления упорядочения.

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

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

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

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

Согласно вариантам осуществления:

- упомянутые вторые медиаданные содержат данные улучшения для улучшения качества первых медиаданных, и

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

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

Например, упомянутая информация, относящаяся к видеоконтенту первых медиаданных, сохраняется в упомянутом файле описания.

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

Например, упомянутый порядок передачи базируется, по меньшей мере, на статистических популярностях медиаданных.

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

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

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

Способ может дополнительно содержать следующие этапы:

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

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

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

Способ может дополнительно содержать этап передачи на клиентское устройство сообщения подтверждения обновления упорядочения.

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

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

Например, упомянутая информация порядка передачи передается в упомянутых уведомительных сообщениях.

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

На стороне клиента, способ осуществления доступа клиентским устройством, к медиаданным, передаваемым в потоке серверным устройством, может содержать следующие этапы:

- передачу, на серверное устройство, запроса, относящегося к первым медиаданным,

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

причем способ дополнительно содержит следующий этап:

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

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

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

Например, упомянутые значения приоритета задаются согласно протоколу HTTP/2.

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

- прием от серверного устройства вторых медиаданных со значением приоритета, связанным с упомянутым механизмом,

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

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

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

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

Например, запрашиваемые первые медиаданные являются видеосегментами.

Например, упомянутая потоковая передача осуществляется согласно стандарту DASH.

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

Способ может дополнительно содержать этап приема от серверного устройства сообщения подтверждения обновления упорядочения.

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

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

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

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

Согласно вариантам осуществления:

- упомянутые вторые медиаданные содержат данные улучшения для улучшения качества первых медиаданных, и

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

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

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

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

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

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

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

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

Способ может содержать следующие этапы:

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

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

Способ может содержать этап приема от серверного устройства сообщения подтверждения обновления упорядочения.

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

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

Например, упомянутая информация порядка передачи принимается в упомянутых уведомительных сообщениях.

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

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

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

- определение, на основании порядка передачи медиаданных, приоритета повторной передачи для медиаданных, и

- осуществление повторной передачи принятых медиаданных на клиентское устройство, на основании упомянутого определенного приоритета передачи.

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

Способ может дополнительно содержать следующие этапы:

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

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

- осуществление повторной передачи медиаданных согласно обновленному приоритету повторной передачи.

Способ может дополнительно содержать следующие этапы:

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

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

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

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

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

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

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

- осуществление способа согласно первому аспекту серверным устройством, и

- осуществление способа согласно второму аспекту клиентским устройством.

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

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

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

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

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

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

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

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

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

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

- выбор данных из наборов данных, указанных в файле описания;

- отправку файла описания на клиентское устройство;

- активную доставку выбранных данных на клиентское устройство.

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

Медиаматериал может представлять собой, например, видео- или аудио-элемент, например аудио-дорожку.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как объяснено выше, может быть предусмотрен этап приема обещания активной доставки, связанного с этапом приема незатребованных данных и до него. Этот этап приема обещания активной доставки может осуществляться до этапа приема файла описания.

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

Можно предусмотреть следующие этапы на клиентском устройстве:

- определение принятия или отклонения обещания активной доставки на основании данных, включенных в обещание активной доставки;

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

Также можно использовать следующие этапы:

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

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

Может использоваться этап буферизации упомянутых незатребованных данных после приема, до декодирования этих данных.

Поскольку активно доставляемые данные призваны соответствовать только данным инициализации и/или начальным медиаданным, могут осуществляться следующие этапы:

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

- отправку запроса определенных данных на сервер.

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

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

- сервер принимает запрос от клиентского устройства;

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

- сервер отправляет файл описания на клиентское устройство;

- сервер активно доставляет выбранные данные на клиентское устройство;

- клиентское устройство принимает файл описания от сервера;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

- фиг. 7a и 7b демонстрируют переупорядочение медиасегментов согласно вариантам осуществления;

- фиг. 8 – блок-схема операций иллюстративных этапов, осуществляемых серверами согласно вариантам осуществления;

- фиг. 9 – блок-схема операций иллюстративных этапов, осуществляемых клиентами согласно вариантам осуществления;

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

- фиг. 11 демонстрирует измерение полосы согласно вариантам осуществления;

- фиг. 12 демонстрирует инициализацию воспроизведения видео согласно вариантам осуществления;

- фиг. 13 – схема устройств согласно вариантам осуществления;

- фиг. 14a демонстрирует, с использованием блок-схемы операций, общие этапы изобретения на стороне клиента;

- фиг. 14b демонстрирует, с использованием блок-схемы операций, общие этапы изобретения на стороне сервера;

- фиг. 15a демонстрирует, с использованием блок-схемы операций, этапы определения совместно используемой политики активной доставки на стороне клиента на основе явного подхода;

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

- фиг. 16 демонстрирует документ MPD, в котором узел PushPolicy используется для указания политики активной доставки, применяемой сервером;

- фиг. 17 демонстрирует, с использованием блок-схемы операций, этапы идентификации и помечания некоторых сегментов как готовых к активной доставке, согласно совместно используемой политике активной доставки “PushPolicy ”;

- фиг. 18a демонстрирует пример связи между сервером и клиентом, когда политика активной доставки передается в заголовке “политика активной доставки” HTTP;

фиг. 18b демонстрирует тот же пример с запросом клиента для изменения политики активной доставки;

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

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

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

- фиг. 23 демонстрирует документ MPD, в котором элемент SupplementalProperty используется для указания политики активной доставки, применяемой сервером на иерархическом уровне документа;

- фиг. 24 демонстрирует документ MPD, используемый в качестве примера политики активной доставки на основе XPath;

- фиг. 25 демонстрирует переупорядочение элементов в дереве приоритетов, например, в веб-странице, до применения политики активной доставки;

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

- фиг. 27 описывает иллюстративный способ, осуществляемый сервером для быстрого запуска DASH; и

- фиг. 28 описывает возможный способ, осуществляемый клиентским устройством для быстрого запуска DASH.

ПОДРОБНОЕ ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

Полное переупорядочение описано со ссылкой на фиг. 7a. На этапе 700 клиент запрашивает у сервера описание медиапрезентации (далее MPD). На этапе 701 сервер извлекает MPD для отправки обратно на клиент и идентифицирует соответствующие элементы данных для активной доставки. В примере, приведенном на фиг. 7a, сервер идентифицирует “Data 1.1”, “Data 1.2” и “Data 1.3” как элементы данных для активной доставки. Эти элементы представляют собой, например, сегменты данные. Элемент “Data X.1” представляет базовый уровень для данных X, элемент “Data X.2” представляет уровень улучшения для данных X, и “Data X.3” представляет дополнительный уровень улучшения для данных X. Сервер задает конкретный порядок передачи для элементов данных. Сервер связывает соответствующие значения приоритета с кадрами PUSH_PROMISE, подлежащими отправке на клиент, для объявления элементов данных, которые предстоит активно доставлять. Затем, на этапе 702, сервер отправляет кадры PUSH_PROMISE “P1.1”, “P1.2” и “P1.3” с соответствующими приоритетами и MPD. Затем, вскоре после отправки MPD и обещания активной доставки, на этапе 703, сервер отправляет на клиент кадр данных, соответствующий элементу “Data 1.1”, и сообщения PUSH_PROMISE “P2.1”, “P2.2” и “P2.3”, соответственно, соответствующие элементам “Data 2.1”, “Data 2.2” и “Data 2.3”, которые являются сегментами, следующими за “Data 1.1”, “Data 1.2” и “Data 1.3” в заданном порядке передачи. Параллельно приему кадра данных и обещания активной доставки на этапе 703, клиент принимает решение, после приема MPD и кадров PUSH_PROMISE “P1.1”, “P1.2” и “P1.3”, что уровень улучшения “Data 1.2” имеет более низкий приоритет по сравнению с дополнительным уровнем улучшения “Data 1.3”. Таким образом, на этапе 704 клиент отправляет кадр обновления приоритета для снижения приоритета “Data 1.2”. Приняв запрос обновления приоритет, сервер изменяет расписание передачи на этапе 705. Следовательно, передача “Data 1.2” откладывается после передачи “Data 1.3”. Кроме того, сервер использует MPD для связывания сегментов, связанных с “Data 1.2”. Он идентифицирует “Data 2.2” и также снижает его приоритет.

Частичное переупорядочение описано со ссылкой на фиг. 7b. Этапы 710-714 на фиг. 7b, по существу, такие же, как этапы 700-704 на фиг. 7a. После приема кадра обновления приоритета, поведение сервера отличается по сравнению с описанным ранее этапом 705. На этапе 715, сервер уже начал передачу “Data 1.2” и продолжает передачу далее. Для этого сегмента не происходит изменения приоритета. Тем не менее, сервер, обновляет приоритет соединенных сегментов, а именно, “Data 2.2” в настоящем примере. Для объявления того факта, что изменение приоритета учтено, сервер может отправлять сообщение обновления приоритета для “Data 2.2”. Таким образом, клиенту можно сообщать об изменении.

Варианты осуществления изобретения могут осуществляться в случаях использования, когда серверы могут активно доставлять части видео высокого качества с достаточным запасом по времени, благодаря чему всю часть видео можно воспроизводить с высоким качеством. Например, видео можно разделить на часть 1, воспроизводимую с низким качеством, часть 2, воспроизводимую с высоким качеством, и часть 3, воспроизводимую с низким качеством. Полоса между клиентом и сервером допускает потоковую передачу в реальном времени низкого качества, но не высокого качества. В этом случае, сервер может перемежать часть 1 с улучшением части 2. После воспроизведения части 1, улучшенная часть 2 также доступна, и сервер отправляет базовый уровень части 2 для воспроизведения с высоким качеством совместно с улучшением той же части 2. Таким образом, сервер гарантирует, что вся часть 2 воспроизводится с высоким качеством. После этого отправляется часть 3. Мерцание качества, которое нарушает ощущения пользователя, можно ослабить, и переключение качества происходит только в ограниченное количество моментов. Сервер находится в наилучшей позиции, чтобы знать, когда переключаться на другой уровень качества, поскольку он знает видеоконтент.

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

На этапе 800, сервер принимает запрос R от клиента. Этот запрос идентифицирует конкретные медиа материалы, обычно на основании файла MPD. Затем сервер осуществляет итерационный процесс, содержащий этапы 801-810. Процесс содержит отправку данных согласно заданному порядку. Порядок передачи обновляется согласно обратной связи с клиентом. После отправки данных, они принимаются и воспроизводятся клиентом. Затем сервер идентифицирует новые данные для отправки, и процесс продолжается.

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

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

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

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

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

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

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

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

Вычислив приоритеты, сервер отправляет кадры PUSH_PROMISE, содержащие значения приоритета, на этапе 803. Чтобы начать передачу кадров PUSH_PROMISE не требуется идентифицировать все сегменты. В случае необходимости отправки MPD для сегментов, подлежащих активной доставке (этап 804), MPD отправляется (этап 805). Параллельно, на этапе 806 начинается передача сегмента.

После того, как клиент примет кадры PUSH_PROMISE, сервер может принимать изменения обновления приоритета и затем внести соответствующее изменение в свое расписание передачи (этапы 807-808 и этапы 820-828). Отправляя сегменты, сервер ожидает приема сообщений изменения приоритета. В случае приема сообщения изменения приоритета (этап 807), сервер соответственно переупорядочивает сегменты и продолжает передачу сегмента (этап 808). После отправки всех сегментов (этап 809-1), сервер перезапускает процесс итерации для продолжения потоковой передачи медиаматериала до конца медиаматериала. По достижении конца медиаматериала (этап 809-2), сервер проверяет, нужно ли автоматически начинать потоковую передачу другого медиаматериала (этап 810). В случае, когда другой медиаматериал нужно передавать в потоке (Да), сервер идентифицирует новый медиаматериал, подлежащий потоковой передаче (этап 811), и перезапускает процесс с этапа 801. В отсутствие необходимости передавать в потоке новые данные, процесс останавливается (этап 812).

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

После приема сообщения изменения обновления приоритета, сервер идентифицирует связанный сегмент на этапе 821. Затем сервер переходит к переупорядочению передачи сегмента (этапы 822, 823). Если сегмент уже передан, процесс заканчивается. Если сегмент передается, в зависимости от своей реализации, сервер может отклонить изменение передачи (например, поскольку это слишком сложно) или может фактически перепланировать отправку оставшихся данных.

Перепланирование данных может осуществляться следующим образом. На сервере хранится список видеосегментов для активной доставки (и/или активно доставляемых видеосегментов). Этот список упорядочивается согласно приоритетам, установленным сервером. Затем сервер устанавливает новое значение приоритета для сегмента. Затем список переупорядочивается, и передача соответствующего видеосегмента осуществляется раньше или позже соответственно.

После переупорядочения видеосегмента, сервер может фактически принимать решение применять это изменение приоритета к другим связанным видеосегментам. Если клиент поднял приоритет видеосегмента, который составляет часть уровня улучшения, сервер может поднять приоритет всех сегментов этого уровня улучшения. Напротив, если клиент снижает приоритет видеосегмента базового уровня, приоритет всех сегментов связанных во времени с этим сегментом, может снижаться. Этот процесс описан на этапах 824-827. На основании MPD и перепланированного видеосегмента, сервер идентифицирует список связанных сегментов (этап 824). Соотношение может быть временным, пространственным, на основе качества и т.д. MPD можно улучшать, чтобы лучше показывать потенциальные соотношения. В частности, когда приоритет сегмента инициализации (который требуется для воспроизведения более чем одного видеосегмента) снижается или повышается, все связанные сегменты можно перепланировать. Это также может быть справедливо для сегментов базового уровня и сегментов улучшения. Для каждого идентифицированного связанного сегмента, сервер проверяет, нужно ли изменять передачу связанного сегмента (этап 825). В случае необходимости изменения, сервер вычисляет новое значение приоритета для каждого сегмента (этап 826) и соответственно перепланирует передачу сегмента (этап 827). Новое значение приоритета можно вычислить, прибавляя к старому значению разность между новым значением приоритета, принятым на этапе 820, и начальным значением приоритета сегмента, идентифицированным на этапе 821. Процесс останавливается, когда проверен каждый связанный сегмент (этап 828).

Сервер также может принимать сообщения потока управления, например кадры WINDOW_SIZE. Эти сообщения могут предоставлять возможность серверу идентифицировать, что воспроизводит в данный момент клиент. Когда на стороне клиента доступно некоторое дополнительное свободное место в буфере, можно заключить, что некоторые данные были удалены из буфера, обычно самые старые данные. Если на сервере хранится история отправленных данных, сервер способен идентифицировать, какие данные были удалены. Таким образом, при условии, что сервер знает упорядочение кэш-памяти клиента, сервер может знать, какие видеосегменты в данный момент воспроизводит клиент. Это упорядочение может базироваться на MPD, которое позволяет упорядочить кэшированные данные согласно временной шкале. Затем сервер может обнаруживать, например, пропуск времени клиента. Сервер может реагировать, заранее быстро отправляя начало следующей главы, чтобы клиент мог продолжать пропуск глав видео.

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

Согласно другим вариантам осуществления, сообщение приоритета отправляется совместно с PUSH_PROMISE. Согласно первому варианту, оно отправляется как заголовок в кадре PUSH_PROMISE. Согласно другому варианту, отправляется кадр PRIORITY, где ID потока зарезервирован соответствующим кадром PUSH_PROMISE. Согласно третьему варианту отправляется кадр PUSH_PROMISE, затем заголовки соответствующих кадров (для открытия потока) и затем кадр PRIORITY на этом вновь открытом потоке.

Для дополнительного управления буфером клиента, сервер может отправлять новое представление сегмента, кэшированного клиентом. В заголовках, отправленных как часть этого нового представления, директивы кэширования HTTP могут использоваться для запрашивания клиента фактически удалить сегмент, например, помечая его как не кэшируемый. Это позволяет освобождать свободное место в буфере на стороне клиента. Может использоваться поток управления HTTP/2. Затем сервер может активно доставлять дополнительные данные.

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

Процесс на стороне клиента описан со ссылкой на фиг. 9.

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

На первом этапе 900 клиент подключается к серверу и запрашивает файл MPD. Затем клиент извлекает файл MPD на этапе 901 и ожидает (этап 902) приема данных. Когда данные приняты, клиент проверяет (этап 903), являются ли данные обещанием активной доставки. В случае приема обещания активной доставки, это означает, что сервер отправляет новый видеосегмент. Клиент обрабатывает обещание активной доставки. В частности, на этапе 904, клиент может удостоверять значения приоритета, предложенные сервером. В случае, когда клиент желает изменить значения приоритета (этап 905) для текущего сегмента или другого обещанного сегмента, клиент вычисляет новое значение приоритета и отправляет его на сервер (этап 906).

В случае, когда клиент принимает видеоданные (этап 907), клиент связывает видеосегмент с файлом MPD (этап 908) и сохраняет видеоданные (этап 909). Связывание видеоданных с файлом MPD позволяет клиенту извлекать видеосегмент, когда он будет дополнительно использоваться для декодирования видео (этап 911). Это также может обеспечивать эффективное хранение видеоданных (этап 909), например, в случае группирования смежных видеосегментов.

Ограничения на хранение в буфере могут дополнительно изменять приоритет. Таким образом, клиент может снова проверять, нужно ли изменять значение приоритета, и при необходимости может осуществлять связь с сервером (этапы 905, 906).

Когда клиент готов начать или продолжить воспроизведение видео (этап 910), клиент извлекает из своей кэш-памяти видеосегменты следующего временного интервала (этап 911) и декодирует и воспроизводит видео (этап 912). На этапе 911 клиент может опрашивать свою кэш-память, чтобы узнать, какие видеосегменты доступны. По умолчанию, клиент может использовать все доступные видеосегменты, в частности, все сегменты улучшения, при наличии. Клиент может позволять серверу выбрать контент: вообще говоря, клиенту следует использовать все сегменты. Если некоторые сегменты нельзя использовать совместно (например, аудиодорожки на английском и французском языке), клиент, в первую очередь, должен отбрасывать неиспользуемые сегменты. Следует отметить, что не все клиенты могут получать доступ к состоянию кэш-памяти: веб-приложения, в частности, обычно не имеют доступа к кэш-памяти веб-браузера. В таком случае, сервер может непосредственно отправлять список активно доставляемых сегментов на клиент веб-приложения. Например, эта информация может передаваться с сервера на клиент с использованием соединения через веб-сокеты.

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

Далее более подробно описан этап 904.

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

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

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

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

В случае автоматизированного переключения видео, блок-схему операций на фиг. 9 можно расширить путем обнаружения активной доставки нового MPD как часть проверки обещания активной доставки (этап 903). При обнаружении активной доставки MPD, клиент может начинать прием сегментов нового видео на этапе 908. Таким образом, клиент должен идентифицировать MPD, связанный с видеоданными. Когда воспроизведение видео заканчивается для данного MPD (этап 902), новый MPD может использоваться для продолжения воспроизведения видео. Клиент может фактически отбрасывать все видеосегменты, связанные с предыдущим MPD.

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

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

Сервер может активно доставлять видеосегмент по нескольким причинам. Например, видеосегмент можно активно доставлять в случае, когда это предполагается полезным для концевого клиента. Видеосегмент также можно активно доставлять в случае, когда предполагается, что видеосегмент может использоваться несколько раз, и что хуже активно доставлять его узлам-посредникам.

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

Фиг. 10 содержит три блок-схемы операций. Одна блок-схема операций относится к процессу фильтрации активно доставляемых сегментов (этапы 1000-1008). Другая блок-схема операций относится к процессу, осуществляемому, когда сегмент запрашивается клиентом, хотя он уже обещан другому клиенту (этапы 1010-1015). Еще одна блок-схема операций относится к управлению изменениями приоритета (этапы 1020-1026).

Процесс фильтрации активно доставляемых сегментов начинается с приема (этап 1000) события активно доставляемых данных, обычно в случае приема кадра PUSH_PROMISE или связанного кадра DATA. Узел-посредник проверяет, имеют ли данные высокий приоритет (этап 1001). Данные можно рассматривать как высокоприоритетные, если их значение приоритета гораздо больше, чем значения приоритета других передаваемых сегментов. Данные также можно рассматривать как высокоприоритетные, если их значение приоритета имеет особый смысл, например, быстрый запуск или оценивание полосы. Если данные имеют высокий приоритет, они отправляются как можно быстрее на клиент (этап 1002). Затем узел-посредник принимает решение, сохранять ли данные (этапы 1003, 1004). Это решение может быть принято один раз в случае приема соответствующего кадра PUSH_PROMISE или заголовков соответствующих кадров, который открывает активно доставляемый поток данных. Это решение также может базироваться на состоянии кэш-памяти узла-посредника, предполагаемом использовании видео, популярности источника видеосигнала или других критериях. Узел-посредник сохраняет видеосегмент, если сегмент активно доставляется, будучи запрашиваемым одновременно одним или более клиентами. Видеосегменты также могут сохраняться, если сегменты идентифицируются как быстрый запуск.

Если данные не имеют высокий приоритет, узел-посредник проверяет, имеют ли они низкий приоритет (этап 1005). Данные низкого приоритета могут быть данными, передачу которых на клиент можно пропустить, но которые сервер считает интересными для сетевых посредников, например узлов-посредников. Узел-посредник сначала принимает решение, отправлять ли данные на клиент (этап 1006). Это решение может быть принято один раз в случае приема соответствующего кадра PUSH_PROMISE или заголовков соответствующих кадров, который открывает активно доставляемый поток данных. В случае такого решения, узел-посредник отправляет соответствующий кадр на клиент (этап 1002). Затем процесс останавливается после принятия решения, сохранять ли данные.

Значение приоритета, согласованное между сервером и узлом-посредником может отличаться от значения приоритета, согласованного между клиентом и узлом-посредником. Таким образом, в случае, когда данные имеют обычный приоритет (т.е. не низкий приоритет и не высокий приоритет), узел-посредник проверяет, управляет ли узел-посредник значением приоритета сегмента. Как показано на фиг. 10 (этапы 1020-1026), узел-посредник использует значение от клиента к узлу-посреднику для планирования времени, когда следует передавать данные: на узле-посреднике хранится список всех кадров, относящихся к видео, подлежащих передаче. Эти кадры упорядочиваются согласно значениям приоритета до отправки согласно этому порядку.

В случае, когда узел-посредник принимает кадр обновления приоритета (этап 1010), узел-посредник идентифицирует связанный видеосегмент (этап 1011). Если его значение приоритета не управляется узлом-посредником (этап 1012) узел-посредник пересылает кадр обновления приоритета на сервер (этап 1013). В противном случае, узел-посредник сохраняет это новое значение приоритета и соответственно переупорядочивает передачу видеосегмента (этап 1014). В случае возникновения потенциального конфликта, в частности, в случае, когда доставка видеосегмента от сервера предполагается слишком поздней для нужд клиента, узел-посредник может пересылать значение приоритета на сервер.

Этапы 1020-1026 относятся к случаю, когда узел-посредник, который принимает запрос от клиента на видеосегмент (этап 1020), который уже обещан сервером другому клиенту (этап 1021). В зависимости от приоритета, присвоенного этому запросу, узел-посредник вычисляет минимальный приоритет от узла-посредника к серверу, который будет удовлетворять запросу клиента (этап 1022). Это вычисление осуществляется путем вычисления значение приоритета от узла-посредника к серверу, которое будет гарантировать, что время доставки от сервера к узлу-посреднику меньше, чем ожидаемое время доставки от узла-посредника к клиенту. Приоритет изменяется, если вычисленный приоритет ниже установленного в данный момент приоритета (этап 1023), и в этом случае узел-посредник будет отправлять сообщение обновления приоритета на сервер (этап 1024), и узел-посредник будет помечать приоритет этого видеосегмента как управляемый узлом-посредником, что позволяет узлу-посреднику отправлять видеосегмент двум своим клиентам в наилучшее время для их потребностей. Аналогично этому процессу, узел-посредник может принимать несколько обновлений приоритета в отношении одного и того же сегмента от нескольких клиентов, и в этом случае узел-посредник может фактически отправлять самое низкое значение приоритета, которое удовлетворяет всем клиентам.

Со ссылкой на фиг. 11 описан вариант осуществления, согласно которому клиент принимает событие активно доставляемых данных, значение приоритета которых указывает, что сервер хочет использовать его для измерения полосы. Измерение полосы может осуществляться с использованием пакетов TCP/IP посредством активных или пассивных измерений для вычисления времен прохождения в двух направлениях. На основании времен прохождения в двух направлениях, доступную полосу можно вычислять, как описано в документе Saubhasik et al. “Bandwidth Estimation and Rate Control in BitVampire". Это вычисление потенциально может учитывать эффекты потока управления HTTP/2. Делая возможным извещение, что некоторые кадры данных используются для оценивания полосы, можно оценивать полосу, доступную без потока управления HTTP/2.

Процесс начинается с этапа 1100, на котором активно доставляемый кадр данных принимается от сервера. Затем проверяется, указывает ли соответствующий приоритет потока, что сервер измеряет полосу (этап 1101). В этом случае, выделенный буфер максимизируется (этап 1102). Альтернативно поток управления потоками можно деактивировать. Если принимающий узел является узлом-посредником (этап 1103), он может пересылать данные сегмента. В противном случае, клиент принимает решение, сохранять ли сегмент (этап 1104). Клиент сохраняет активно доставляемый сегмент (этап 1105). В любом случае, клиент отправляет подтверждение на сервер в форме WINDOWS_UPDATE (этап 1106) для окна для каждого соединения. Затем это подтверждение будет использоваться сервером для оценивания полосы соединения. В случае, когда клиент является узлом-посредником, он пересылает активно доставляемые данные (этап 1108) как можно быстрее. В случае приема подтверждения от концевого клиента, узел-посредник также пересылает его обратно на сервер (этапы 1109, 1110).

Для оценивания доступной полосы, сервер может использовать время прохождения в двух направлениях отправленного кадра данных, который вычисляется как разность между временем отправки кадра данных и временем приема сообщения подтверждения, причем сопряжение между ними базируется, например, на размере кадра данных, который должен быть равен обновлению размера окна. Времена прохождения в двух направлениях можно вычислять из различных кадров данных одного или более видеосегментов. Для увеличения точности, кадры данных могут иметь различные размеры. Разделение видеосегмента на несколько кадров данных разных размеров может осуществляться сервером. Серверу нужно только гарантировать, что уровень сети не будет делить кадры DATA на несколько пакетов TCP/IP (следовательно, меньшие кадры DATA) или не будет буферизовать контент, подлежащий отправке, и объединять несколько кадров данных в пакет TCP/IP. На основании этих измерений, стандартные методы можно использовать для вычисления доступной полосы (пример можно найти в вышеупомянутом документе), которую сервер может использовать для фактического принятия решения, какое представление видео использовать.

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

Процесс на стороне клиента начинается с этапа 1200 приема активно доставляемых данных. Затем клиент проверяет, имеет ли приоритет значение быстрого запуска (этап 1201). В этом случае, клиент обычно максимизирует выделенный буфер (этап 1202). Эта максимизация осуществляется в случае приема PUSH_PROMISE активно доставляемых данных. Затем данные сохраняются (этап 1203), и клиент отправляет подтверждение на сервер с использованием кадра WINDOW_UPDATE (этап 1204). Затем клиент проверяет, достаточно ли данных доступно для запуска воспроизведения видео (этап 1205). Если это так, начинается воспроизведение видео (этап 1206). В противном случае клиент ожидает дополнительных данных (этап 1207), пока не будет доступно достаточно данных для запуска воспроизведения данных.

Процесс на стороне сервера начинается с этапа 1211 отправки кадров данных сегмента с приоритетом быстрого запуска (этап 1210). Затем сервер принимает подтверждения (этап 1211), которые разрешают вычисление доступной полосе (этап 1212). Когда получено достаточно измерений, сервер выбирает оптимальное представление (этап 1213) и начинает активно доставлять сегменты оптимального представления (этап 1214). Сервер принимает решение, когда переключать представление. Это имеет, по меньшей мере, два преимущества. Во-первых, сервер может знать, когда измерения достаточно точны и, в этом случае, может переключаться с одного разрешения на другое, хотя для клиента это будет сопряжено с некоторой задержкой. Во-вторых, сервер может принять решение переключиться с одного разрешения на другое, когда это меньше нарушает ощущения пользователя. В действительности, сервер имеет знание видеоконтента. В частности, MPD можно дополнить информацией о предполагаемых наилучших временах переключения разрешения.

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

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

Улучшенный способ потоковой передачи снижает рассогласование между решениями сервера касательно активной доставки некоторых медиаданных и потребностей клиента в таких данных. Как будет ясно из нижеследующего, сервер и клиент совместно используют политику активной доставки таким образом, что они оба определяют одни и те же медиаданные, подлежащие активной доставке, из любых медиаданных, запрашиваемых клиентом. Политика активной доставки указывает, как определять данные для активной доставки, и может рассматриваться как правило определения, какие ресурсы, связанные с запрашиваемыми данными, подлежат активной доставке после обработки запрашиваемых данных (после запроса GET), и, возможно, как они активно доставляются (например, в каком порядке). Обычно, связанные ресурсы определяются с использованием одного документа, например, файла манифеста, например, файла MPD (в контексте DASH для мультимедийных данных), или документа HTML.

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

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

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

По сравнению с процессом, описанным со ссылкой на фиг. 1d и 1e, дополнительные этапы 1400 и 1402 позволяют, соответственно, серверу и клиенту определять стратегию активной доставки, которую они совместно используются, и, таким образом, подлежит использованию.

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

Например, алгоритм предварительно определяется либо в ходе установки клиента и сервера, либо относительно конкретного стандарта. Типичный пример алгоритма может состоять в активной доставке N ресурсов после запрашиваемого ресурса в порядке разбора файла манифеста, где N - предварительно определенное число, например 4.

Согласно фигуре, этапы 1400 и 1402 состоят, в случае неявной политики активной доставки, в загрузке в память предварительно определенного алгоритма для идентификации ресурсов, подлежащих активной доставке (этап 1403 на стороне сервера).

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

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

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

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

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

Одно преимущество явного подхода опирается на тот факт, что сервер может использовать отдельную политику активной доставки для каждого клиента или для каждой мультимедийной презентации (например, каждого MPD), для лучшего согласования с их характеристиками обработки. Фиг. 15a демонстрирует, с использованием блок-схемы операций, этап 1400 определения совместно используемой политики активной доставки на стороне клиента на основе явного подхода, и фиг. 15b демонстрирует, с использованием блок-схемы операций, этап 1402 определения политики активной доставки на стороне сервера в случае использования явного подхода.

Как показано на фиг. 15b, сервер генерирует на этапе 1504 сообщение для декларации политики активной доставки и затем отправляет его на клиент на этапе 1505, для его совместного использования. Информация, описывающая политику активной доставки в сообщении декларации именуется информацией политики активной доставки.

Описанные ниже фиг. 16-18 подробно иллюстрируют, как политика активной доставки декларируется и передается на клиент.

Ресурсы, подлежащие активной доставке с использованием политики активной доставки, определенные на этапе 1402, затем идентифицируются на этапе 1403 согласно алгоритму выбора (или алгоритму определения вторых медиаданных), заданному в сообщении декларации политики активной доставки, сгенерированной на этапе 1504.

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

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

Можно использовать различные способы декларации политики активной доставки.

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

В DASH, файлом описания является, например, файл MPD. Нижеследующее описание, в основном, опирается на DASH и файлы MPD. Однако тот же подход применяется к другим способам потоковой передачи на основе манифеста, например, Smooth Streaming или HTTP Live Streaming.

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

Это проиллюстрировано на фиг. 16, который демонстрирует документ MPD, в котором узел 1600 PushPolicy используется для указания политики активной доставки, применяемой сервером.

В этом примере, узел 1600 PushPolicy включает в себя атрибут активной доставки, а именно “SegmentIdx”, для декларации количества сегментов, подлежащих активной доставке после приема запроса GET. Например, если клиент запрашивает сегмент 1601 в своем запросе GET, он будет принимать, в качестве ответа, кадр PUSH_PROMISE для следующих двух сегментов в порядке разбора документа MPD. В этом примере, первый атрибут активной доставки идентифицирует вторые незапрашиваемые медиаданные относительно первых медиаданных, запрашиваемых в файле описания. В более общем случае, предварительно определенное количество K сегментов, подлежащих активной доставке, используется для задания значения политики активной доставки. В результате, для каждого сегмента, запрашиваемого клиентом, сервер будет активно доставлять K следующих сегментов.

В то время, как пример 1600, показанный на фиг. 16, демонстрирует единичный атрибут активной доставки, может существовать несколько атрибутов активной доставки. Каждый атрибут активной доставки может представлять ограничение на узлах дерева DOM (Document Object Model), представляющих манифест для выбора сегментов, подлежащих активной доставке. Согласно предыдущему примеру, приведенному на фиг. 4b, узел 1600 политики активной доставки может относиться к медиаданным, описанным в файле описания (файле MPD) с использованием атрибутов медиаданных (элементов и/или атрибутов MPD), включающих в себя атрибут периода “PeriodIdx”, который относится к элементу Period, которому принадлежат медиаданные, атрибут адаптации “AdaptationSetIdx”, который относится к элементу AdaptationSet медиаданных, атрибут представления “RepresentationIdx”, который относится к элементу Representation, т.е. версии кодирования (конкретному кодеку, разрешению или битовой скорости...) медиаданных, и атрибут сегмента “SegmentIdx”, который относится к сегменту в данном представлении.

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

Например, атрибут активной доставки может быть связан с атрибутом PeriodIdx для указания ограничения на период для выбора сегмента для активной доставки; другой может быть связан с атрибутом AdaptationSetIdx для указания ограничения на адаптацию; еще один может быть связан с атрибутом RepresentationIdx для указания ограничения на представление; помимо вышеупомянутого первого атрибута активной доставки, связанного с атрибутом SegmentIdx.

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

Значение атрибутов активной доставки может использовать следующий синтаксис:

атрибут активной доставки=[оператор] операнд

где “оператор” является необязательным и принимает значение ‘+’ или ‘-’ для задания сегментов, подлежащих активной доставке, относительно (“+” означает "после", и "-" означает "до") запрашиваемого сегмента, и где “операнд” представляет собой либо целочисленное значение, большее или равное 0, или ‘*’ в качестве подстановочного параметра.

Фиг. 17 демонстрирует, с использованием блок-схемы операций, этапы идентификации и помечания некоторых сегментов как готовых к активной доставке, согласно совместно используемой политике активной доставки “PushPolicy”. Эта блок-схема операций демонстрирует этап 1403.

Сначала сервер идентифицирует на этапе 1700 запрашиваемый сегмент в файле манифеста. Запрос включает в себя идентифицированный “reqSegIdx” этого сегмента.

Для каждого типа узла в файле манифеста MPD, каждому узлу присваивается значение индекса. Значение получает приращение для каждого узла в порядке появления в файле манифеста.

Затем индексы Period, AdaptationSet, Representation и SegmentURL, которые соответствуют запрашиваемому сегменту (т.е. сегменту, указанному в запросе GET), извлекаются путем разбора всего MPD, пока не будет достигнут запрашиваемый сегмент.

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

Когда оператор не указан, значение операнда идентифицирует индекс узла, в котором нужно извлекать данные, подлежащие активной доставке. Например, когда первый атрибут активной доставки “SegmentIdx” не имеет оператора, это идентификатор, в файле описания, конкретного сегмента, подлежащего активной доставке. В одной альтернативе, когда оператор не указан, значение операнда может идентифицировать значения диапазона, например, “SegmentIdx=2-5” будет возвращать сегменты с индексом, равным 2, 3, 4 и 5.

В противном случае (оператор указан), значение операнда представляет значение смещения (именуемый “idxOffset”) для применения к индексу запрашиваемого сегмента (“reqSegIdx”, полученному на этапе 1700). В таком случае, сегменты, подлежащие активной доставке, должны находиться в узлах с индексами, содержащимися в диапазоне [reqSegIdx, reqSegIdx+idxOffset], если оператор является “+”, и в диапазоне [regSegldx-idxOffset, regSegldx], если оператор является “-”. Использование оператора позволяет задавать атрибут или атрибуты медиаданных для вторых незапрашиваемых медиаданных относительно соответствующего атрибута или соответствующих атрибутов медиаданных для первых медиаданных в файле описания.

Например, рассмотрим следующие политики активной доставки:

1. <PushPolicy RepresentationIdx ="-1" SegmentIdx="2"/>

2. <PushPolicy PeriodIdx ="+1" SegmentIdx="+2"/>

3. <PushPolicy PeriodIdx ="+0" SegmentIdx ="+2"/>

PushPolicy #1 указывает, что сервер будет активно доставлять сегмент с индексом 2 в узле представления, предшествующем узлу представления запрашиваемого сегмента.

Согласно PushPolicy #2, сервер будет активно доставлять два сегмента после запрашиваемого сегмента, либо в текущем периоде, либо в следующем. Например, при запрашивании сегмента 2401 на фиг. 24, будут активно доставляться сегменты 2405 и 2402.

PushPolicy #3 во многом аналогична PushPolicy#2, главное отличие наблюдается, когда запрашиваемый сегмент является предпоследним относительно периода. Например, при запрашивании 2401, будет активно доставляться только последний сегмент 2405 в текущем периоде (вместо двух сегментов). Согласно PushPolicy #3, PeriodIdx ограничивает поиск сегмента узлом Period запрашиваемого сегмента, и, таким образом, активно доставляется только последний сегмент периода (поскольку запрашиваемый сегмент является предпоследним сегментом в периоде). Напротив, согласно PushPolicy #2, сегменты можно извлекать из следующего периода.

Альтернативно или в качестве необязательного значения, значение операнда также может быть ‘*’ (подстановочным значением), и это означает, что следует активно доставлять любой сегмент. Когда оно связано с оператором ‘+’ (соответственно, ‘-’), это означает, что следует активно доставлять все последующие (соответственно, предшествующие) сегменты относительно запрашиваемого.

Эта альтернатива позволяет клиенту отправлять один единственный запрос HTTP для извлечения всех сегментов одного периода, например, согласно следующей PushPolicy: <PushPolicy PeriodIdx ="+0" SegmentIdx ="+*">.

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

атрибут активной доставки:[оператор]операнд[,смещение]

где “смещение” является положительным или отрицательным целым числом, отличным от 0, для применения к индексу запрашиваемого сегмента. В таком случае диапазон поиска равен [reqSegIdx+offset, reqSegIdx+idxOffset+offset], когда операторам является ‘+’ и [reqSegIdx-idxOffset+offset, reqSegIdx+offset], когда операторам является ‘-’.

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

<PushPolicy SegmentIdx ='+*[size<500000]'> задает политику активной доставки для активной доставки не более чем 500 килобайт данных сегментов.

<PushPolicy SegmentIdx ='+*[time<0:01:30]’> задает политику активной доставки для активной доставки не более чем 1 минуты и 30 секунд данных следующих сегментов.

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

В порядке примера, можно применять декларацию порядка передачи активно доставляемых сегментов, как описано выше со ссылкой на фиг. 7-12.

В одном альтернативном варианте осуществления для порядка передачи активно доставляемых сегментов, информация описания в файле описания включает в себя атрибуты приоритета, связанные с медиаданными, по одному атрибуту приоритета (например “priorityIdx”) для каждых медиаданных, и порядок передачи вторых медиаданных базируется на соответствующих атрибутах приоритета. Благодаря передаче файла описания, клиенту также известны значения, принимаемые этими атрибутами приоритета, что позволяет ему определять назначенный порядок передачи.

Как показано в примере, приведенном на фиг. 16, каждый сегмент (например, идентифицированный одним узлом SegmentURL), описанный в файле манифеста, включает в себя атрибут (1604) priorityIdx, который указывает порядок активной доставки сегмента. В примере, приведенном на фиг. 16, сегмент 1603 активно доставляется до сегмента 1602. Эти приоритеты вычисляются в ходе подготовки медиасегментов на стороне сервера. Могут использоваться разные значения приоритета: относительное значение приоритета в данном представлении (как на фиг. 16) или абсолютное значение приоритета, либо как 32-битовое число с 4 старшими битами для приоритета Period, 4 следующими MSB для значения приоритета AdaptationSet, следующими 8 битами для значения приоритета Representation и 16 младшими битами для приоритета сегмента. Альтернативный способ сигнализации абсолютного значения приоритета предусматривает использование списка значений приоритета, разделенных запятой, по одному для каждого из вышеупомянутых уровней, например: priorityIdx ='1, 1, 2, 1' для последовательного задания приоритета Period, приоритета AdaptationSet, приоритета Representation и затем приоритета сегмента. Первый вариант осуществления с 32-битовым значением будет давать (в двоичном выражении):

priorityIdx ='00010001000000100000000000000001'.

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

Согласно фиг. 17, на основании политики активной доставки, заданной в файле MPD, сервер определяет на этапе 1701 количество сегментов, подлежащих активной доставке. Это количество непосредственно выводится из значения атрибута SegmentIdx: если оператор не используется в значении атрибут, это количество равно 1; в противном случае (оператором является “-” или “+”) количество равно значению операнда и предполагается бесконечным, когда операнд равен “*” (но ограничивается другими ограничениями и количеством существующих сегментов).

Затем итерационный процесс, состоящий из этапов 1702-1705, применяется сервером потоковой передачи, пока не будет достигнуто количество сегментов для активной доставки (проверка 1702), для помечания каждого из сегментов, подлежащих активной доставке.

Для каждой итерации, сервер извлекает на этапе 1703 список сегментов, заданный в файле MPD, которые подчиняются ограничениям PushPolicy (ограничениям Adaptation Set, Representation, Period и Segment и необязательным условиям).

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

В противном случае, первый сегмент из списка помечается на этапе 1705 как подлежащий активной доставке на этапах 103 (PUSH_PROMISE) и 104 (обещанные сегменты).

В этих примерах на основе MPD декларирования политики активной доставки, одна политика активной доставки задается с использованием элемента PushPolicy (см. 1600 на фиг. 16).

Напомним, что файл описания описывает медиаданные с использованием множества уровней атрибута медиаданных, а именно, элементов Period, AdaptationSet и Representation, заданных выше.

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

Это проиллюстрировано на фиг. 23, где политика активной доставки задается с использованием, например, описателя “SupplementalProperty” на нужном уровне, в данном случае на уровне представления.

Использование политики активной доставки для каждого уровня <MPD> позволяет иметь постоянную и одинаковую стратегию активной доставки для всех медиаданных.

Использование политики активной доставки для каждого уровня <Period> позволяет иметь стратегию активной доставки, которая может изменяться со временем.

Использование политики активной доставки для каждого уровня <AdaptationSet> позволяет иметь стратегию активной доставки, адаптированную к медиаданным.

Использование политики активной доставки для каждого уровня <Representation> позволяет иметь стратегию активной доставки, которую можно адаптировать к характеристикам медиаданных (полосе...).

В примере, приведенном на фиг. 23, политика активной доставки, указанная на уровне представления, позволяет активно доставлять больше сегментов видеосегментов для низкой битовой скорости (2300), чем для видео высокой битовой скорости (2301), во избежание чрезмерного использования полосы для активной доставки данных.

Заметим, что объяснения, приведенные выше в отношении синтаксиса атрибутов активной доставки, также можно применять к этой небольшой разновидности. В частности, политику активной доставки можно сигнализировать в манифесте как новый элемент (как на фиг. 16), или с использованием существующего описателя с новым schemeIdUri (как на фиг. 23) или как новый описатель (не представленный) или любое средство, согласующееся со схемой MPD или точками расширения схемы MPD.

MPD также может содержать список альтернативных политик активной доставки, каждая из которых имеет уникальный идентификатор (дополнительное объяснение, касающееся списка, см. ниже).

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

<push_policy Segments='+complementary'>

или значение='complementary' при использовании описателя DASH.

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

Другая политика активной доставки также может состоять в активной доставке сегментов из соответствующих представлений, сигнализируемых либо посредством атрибута @associationId, либо посредством role='supplementary'.

В случае потоковой передачи, полностью инициированной сервером, политика активной доставки может обеспечивать информацию о том, должно ли поведение сервера быть ‘агрессивным’ (или ‘оптимистическим’) или ‘консервативным’, т.е., соответственно, должен ли он стараться активно доставлять сегменты более высокого качества или стараться активно доставлять на том же уровне качества (сохраняя полосу).

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

Эти варианты осуществления позволяют изменять политику активной доставки в течение времени, поскольку они больше не зависят от передачи файла MPD, как описано выше, и клиент и сервер обмениваются данными с использованием протокола HTTP/2.

На фиг. 18 приведен пример связи между сервером и клиентом, когда политика активной доставки передается в заголовке “политика активной доставки” HTTP (имя заголовка “политика активной доставки” приведено лишь для примера).

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

На фиг. 18a, сервер в ответ на запрос MPD от клиента (стрелка 1800) передает (этап 1801) политику активной доставки в заголовке HTTP, сопутствующем отправленному MPD, для совместного использования политики активной доставки.

Например, политика активной доставки указывает, что будет активно доставляться сегмент, следующий за запрашиваемым сегментом. В результате, когда клиент запрашивает (стрелка 1802) сегмент Data1.1, сервер отправляет (стрелка 1803) PUSH PROMISE для сегмента Data2.1 и затем данные сегмента Data1.1 (стрелка 1804).

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

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

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

Согласно варианту осуществления, запрос политики активной доставки от клиента переносится в заголовке HTTP или запросе, именуемом “запрос политики активной доставки” (имя здесь приведено лишь для примера).

Фиг. 18b демонстрирует иллюстративные этапы обмена данными между клиентом и сервером, когда клиент запрашивает новую политику активной доставки.

Обмены начинаются так же, как на фиг. 18a.

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

В результате, клиент отправляет на этапе 1805 "запрос политики активной доставки", с помощью которого просит сервер активно доставлять больше сегментов (3 вместо 1) для каждого нового запроса.

Сервер положительно отвечает на этот "запрос политики активной доставки" посредством OK 200, на этапе 1806. Этот положительный ответ означает, что сервер будет использовать новую политику активной доставки, описанную в "запросе политики активной доставки" для любого нового запроса от того же клиента.

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

Затем, когда клиент запрашивает на этапе 1807 следующий сегмент Data3.1, сервер отвечает на этапе 1808 посредством PUSH PROMISE для следующих трех сегментов Data4.1, Data5.1 и Data6.1.

Фиг. 21 демонстрирует, с использованием блок-схемы операций, этапы процесса на стороне сервера при использовании запроса HTTP для совместного использования политики активной доставки, и фиг. 22 демонстрирует, с использованием блок-схемы операций, этапы процесса на стороне клиента при использовании запроса HTTP для совместного использования политики активной доставки.

По сравнению с процессом, представленным на фиг. 14, сервер включает в себя новые этапы обработки (2100-2105) для обработки запроса политики активной доставки от клиента и также для отправки начальной политики активной доставки и ее обновлений.

Если запрос, принятый сервером, является запросом политики активной доставки от клиента (проверка 2100), сервер сначала разбирает запрос политики активной доставки на этапе 2101 для извлечения ограничений активной доставки данных, предложенных клиентом.

На этом этапе сервер может принять решение следовать политике активной доставки, запрашиваемой клиентом. В таком случае, сервер обновляет свою внутреннюю политику активной доставки (этап 2102) и отправляет ответ OK 200 на клиент на этапе 2103, для удостоверения предложенной политики активной доставки.

В противном случае, когда сервер отвергает политику активной доставки (например, поскольку предложенная политика слишком затратна в отношении ресурсов или не может применяться), на этапе 2102 внутренняя политика активной доставки на сервере не изменяется, и код ошибки передается на клиент на этапе 2103.

Согласно конкретному варианту осуществления, сервер может, кроме того, обновлять свою политику активной доставки независимо от запросов клиента. В таком случае, сервер определяет политику активной доставки на этапе 1402 и может либо принимать решение на изменение своих характеристик (например, анализируя запросы, осуществляемые клиентом, и характеристики сети), либо видеть, что определенная политика активной доставки отличается от текущей. В такой ситуации, сервер должен совместно использовать новую политику активной доставки с клиентом, если последнему она еще не известна (проверка 2104), и в этом случае новая политика активной доставки передается в заголовке HTTP на этапе 2105.

Соответствующий процесс на стороне клиента объяснен со ссылкой на фиг. 22. Что касается обработки на сервере, добавлены новые этапы обработки (2200-2204) по сравнению с процессом, представленным на фиг. 14, для обработки сообщений политики активной доставки и осуществления запросов политики активной доставки.

Определив текущую совместно используемую политику активной доставки (т.е. политику активной доставки сервера) на этапе 1400, клиент может пожелать новую политику активной доставки, например, для уменьшения количества запросов HTTP для отправки для извлечения сегментов медиапотока. Таким образом, когда клиенту требуется новая политика активной доставки (проверка 2200), клиент отправляет на этапе 2201 запрос HTTP с “запросом политики активной доставки”, как описано ранее.

Ответ на этот запрос обрабатывается на этапе 2204, в котором клиент проверяет, ли удостоверяет сервер запрос, возвращая ответ OK 200 или, в противном случае, код ошибки.

Если сервер возвращает ответ OK 200, текущая политика активной доставки, определенная на этапе 1400, заменяется запрашиваемой политикой. В противном случае она не изменяется.

Помимо процесса, показанного на фиг. 14, когда клиент принимает от сервера кадр с новой политикой активной доставки (проверка 2202), политика активной доставки разбирается и сохраняется (этап 2203) в памяти для извлечения при следующем наступлении этапа 1400.

Следует отметить, что, когда запрос политики активной доставки присутствует в кадре, который также включает в себя другие данные (например, медиаданные), другие данные обрабатываются на этапах 109-111-113-115.

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

В одном варианте осуществления, запрос политики активной доставки отправляется как дополнительный заголовок одного из запросов HTTP, используемых для запрашивания одного из ресурсов сервера: обычно, запрос политики активной доставки отправляется в заголовке HTTP "принять политику активной доставки" в запросе GET для файла MPD.

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

В еще одном варианте осуществления, запрос политики активной доставки отправляется в специальном запросе HTTP, не зависящем ни от одного ресурса, известного серверу. Например, запрос GET (или POST) формируется с URL, не соответствующим ни одному ресурсу веб-страницы, например http://server/push_policy, и также с по меньшей мере, одним заголовком "принять политику активной доставки".

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

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

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

Например, MPD может указывать политику активной доставки с аргументами шаблона, которые затем задаются (или даже перегружаются) сервером благодаря запросу политики активной доставки HTTP. В порядке примера, политика активной доставки, заданная в файле MPD, может иметь вид: <PushPolicy SegmentIdx =”parameter”/>, и значение переменной “параметр” может задаваться в запросе политики активной доставки HTTP. В этом примере, вторая часть политики активной доставки содержит (только) одно или более значений одной или более соответствующих переменных, заданных в первой части политики активной доставки.

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

В другом варианте осуществления для декларации политики активной доставки клиенту, политика активной доставки опирается на описатель <Role>, заданный в MPD для указания, в каком представлении будут выбраны активно доставляемые данные. Обычно политика активной доставки может указывать, что стратегия активной доставки будет использовать сегмент в представлении, где роль принимает значение “альтернативная” или “вспомогательная”.

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

Например, в манифесте потоковой передачи выражение XPath “following[name()=”SegmentURL”][2]” можно использовать для выбора, в качестве сегментов, подлежащих активной доставке, следующие два сегмента после сегмента, запрашиваемого клиентом в запросе GET. Также для случай использования с переходом между главами, выражение XPath “((following[name()=”Period”]//SegmentURL)[2])” позволяет выбирать первые два сегмента следующего периода для предварительной загрузки первых двух сегментов каждой главы. Например, когда клиент запрашивает сегмент 2401 в файле MPD, показанном на фиг. 24, сегменты 2402 и 2403 следующего периода также передаются сервером в качестве активно доставляемых данных.

Кроме того, дерево приоритетов сначала можно переупорядочивать, например, с использованием инструкции XSLT для упрощения записи выражения XPath для усовершенствованных правил политики активной доставки. Инструкция XSLT позволяет реорганизовать дерево до применения политики активной доставки. Выражения XPath предпочтительно передавать на клиент, например, в одном заголовке HTTP, и таблица стилей XSLT задается в веб-странице. Это применяется, в частности, к документам HTML, например, для группирования всех изображений, продекларированных в документе, всех ресурсов CSS в качестве последовательных узлов на одном и том же уровне дерева DOM.

Например, дерево 2501, показанное на фиг. 25, представляет страницу HTML с разными ресурсам разных типов: заштрихованные узлы (2511-2514) соответствуют ресурсам изображения, и одноцветные узлы (2521-2524) являются ресурсами, заданными сценарием (CSS или Javascript). Дерево 2502 является примером результата преобразования XSLT для группирования ресурсов по типу (изображений в 2530 и ресурсов, заданных сценарием, в 2540). Таким образом, можно задать простое выражение XPath для указания, что некоторые ресурсы для данного типа будут активно доставляться, как только будет запрошен первый ресурс этого данного типа.

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

Например, MPD 1900, показанный на фиг. 19, имеет политику активной доставки, которая указывает, что будут активно доставляться три сегмента после запрашиваемого сегмента (см. элемент <PushPolicy>). В результате, если клиент запрашивает сегмент инициализации посредством запроса GET на медиаданные 1901 с байтовым диапазоном, равным 0-999, сервер отправит на этапе 103 три сообщения PUSH_PROMISE 1902.

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

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

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

Например, три обещания 1902 активной доставки заменяются единственным обещанием 1903 активной доставки, показанным на фиг. 19.

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

Альтернативно, даже если обещания активной доставки имеют разъединенные интервалы байтового диапазона, все обещания активной доставки можно заменить списком байтовых диапазонов (где последовательные интервалы байтового диапазона сцеплены).

Кроме того, если обещания активной доставки не включают в себя интервалы байтового диапазона, но довольно различные значения SegmentURL, обещания активной доставки также могут сцепляться для генерации единого сообщения обещания активной доставки следующим образом: способ сгенерированного сообщения обещания активной доставки задается как MGET (для множественных GET), и поле пути является списком URL сегмента, как представлено в 1904. Аналогично предыдущему варианту осуществления, для отмены активной доставки всех сегментов клиенту нужно закрыть единственный поток, соответствующий сгенерированному обещанию активной доставки.

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

Кроме того, кадр SETTINGS HTTP/2 расширяется для включения нового параметра SETTINGS_ENABLE_GROUP_PUSH_PROMISE, который позволяет указывать, разрешено ли группирование обещаний активной доставки для сеанса потоковой передачи.

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

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

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

Как описано выше в стандартном процессе, на первом этапе клиента запрашивает файл описания, в данном случае, файл MPD (этап 2650). Затем клиент ожидает ответа сервера (этап 2651).

В это время сервер анализирует файл MPD (этап 2652), в частности, для идентификации (этап 2653) данных инициализации, которые помогут клиенту ускорить запуск, как объяснено ниже. Иллюстративный вариант осуществления этапа 2653 описан ниже со ссылкой на фиг. 27.

Когда данные инициализации идентифицированы сервером, он отправляет кадр PUSH_PROMISE на клиент на этапе 2654 для указания своего намерения активно доставлять данные инициализации, не ожидая запроса клиента.

Кроме того, он может сигнализировать, что он также будет активно доставлять начальные медиаданные (этап 2656), путем отправки еще одного кадра PUSH_PROMISE включающий в себя поля заголовка, которые позволяют клиенту идентифицировать рассматриваемый ресурс, т.е. рассматриваемые начальные медиаданные, например,:scheme,:host и:path.

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

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

Таким образом, когда кадры PUSH_PROMISE отправляются на клиентское устройство, сервер отправляет файл MPD на клиентское устройство на этапе 2655.

Если сервер за это время не принял от клиентского устройства ни сообщения CANCEL, ни сообщения ERROR, он начинает активную доставку данных инициализации (этап 2657) и первых медиаданных (этап 2658).

Кадры PUSH_PROMISE и активная доставка данных от сервера на клиентское устройство осуществляется, например, в соответствии с соответствующими признаками, проявляющимися в кадре HTTP 2.0, как описано, например, в документе “Hypertext Transfer Protocol version 2.0, draft-ietf-httpbis-http2-latest", HTTPbis Working Group, Internet-Draft, June 24, 2013 (доступном, например, по адресу http://http2.github.io/http2-spec/).

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

Когда файл MPD полностью принят клиентом, он разбирает его (этап 2662) и начинает декодирование и отображение (этап 2663) при условии буферизации достаточного объема данных (этап 2661). В противном случае, и когда клиентское устройство знает из кадров PUSH_PROMISE, отправленных сервером (см. этап 2656), что будет отправляться больше сегментов, он ожидает на этапе 2664 завершения активной доставки первых медиаданных от сервера. На этом холостом этапе 2664, клиентское устройство может подготовить следующие запросы для последующих сегментов, которые будут выданы в стандартном DASH под управлением клиента (этап 2665), как объяснено выше. Это возможно, поскольку клиентское устройство приняло информацию о начальных медиаданных, подлежащих активной доставке (или активно доставляемых) в соответствующем кадре PUSH_PROMISE (см. этап 2656 выше) и, таким образом, может подготавливать запросы на временной сегмент, непосредственно следующий за последним временным сегментом, предназначенным для активной доставки сервером.

Клиентское устройство, полностью принявшее MPD, также может использовать информацию о начальных медиаданных, принятых на этапе 2656, для проверки, наполнен ли буфер этими начальными медиаданными, и если нет, отправлять запрос на следующие медиаданные (например, медиаданные, соответствующие временному сегменту, следующему за временным сегментом, представляемым начальными медиаданными) согласно стандартному процессу DASH под управлением клиента до этапа 2661 (в отличие от показанного на фиг. 26, где показан случай, когда буфер наполнен активно доставленными начальными медиаданными). Это позволяет клиенту корректировать плохую оценку сервера в отношении объема первых медиаданных для активной доставки.

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

Однако этот процесс по-прежнему согласуется с текущим стандартом DASH, поскольку:

- не происходит изменения файла MPD: его передача остается легкой и быстрой;

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

Фиг. 27 описывает иллюстративный способ, осуществляемый на стороне сервера после запроса манифеста (или файла описания) от клиентского устройства.

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

На этапе 2700 принимается запрос манифеста. Затем сервер проверяет на этапе 2701, вставило ли клиентское устройство в запрос некоторые предпочтения. Это можно делать через специальный заголовок HTTP, например, для выражения скорости передачи медиапрезентации и предпочтительного языка аудиопотока:

GET http://myserver.com/presentation/pres1.mpd \r\n

Prefered-MediaRange: bw=2000;lang=FR\r\n\r\n

Если запрос включает в себя предпочтения (проверка 2701 дает истину), сервер анализирует предпочтения клиента (этап 2703) и устанавливает свой параметр confidence_level на значение "высокое" (этап 2704).

Если в запросе не обеспечено никакого указания (проверка 2701 дает ложь), сервер проверяет на этапе 2702, зарегистрирована ли информация использования услуги (журналы) для этого клиента (т.е. статистика или данные использования на основании предыдущих этапов обмена данными между пользовательским или клиентским устройством и сервером) или информация из заголовка "пользовательский агент". В действительности, заголовок "пользовательский агент" задается как заголовок HTTP в RFC2616 (см., например, http://www.ietf.org/rfc/rfc2616.txt) и обеспечивает средство для приложений для обмена информацией, например, об операционной системе, типе браузера, имени приложения и т.д.). Например, сервер DASH может иметь схему аутентификации клиентов прежде, чем они смогут использовать услугу; альтернативно, это может быть регистрация пользователя до получения доступа к услуге. Таким образом, сервер может связывать параметры медиаданных с подключенным пользователем или устройством.

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

Благодаря регистрации метрик качества DASH, сервер может иметь в своих журналах изменения среди различных представлений, которые обычно осуществляет пользователь/клиент. Отсюда, сервер определяет обычное поведение между “агрессивным” или постоянным в зависимости от частоты изменений (под изменениями мы понимаем переключения на другое представление, согласно любому критерию: полосы, разрешения, частоты кадров и т.д.). Агрессивным клиентом является клиентом DASH, который будет автоматически переключаться на другое представление, когда его контекст изменяется. В порядке примера, при мониторинге полосы или наполненности буфера, агрессивный клиент будет запрашивать представление с другой полосой, как только новое представление имеет характеристики, более близкие к контексту клиента по сравнению с текущим представлением. Напротив, постоянный клиент будет стараться избегать частых переключений представления для поддержания стабильных качества и скорости отображения. Когда поведение пользовательского/клиентского устройства достаточно агрессивно в отношении адаптации, сервер знает, что при любом выборе в качестве начального представления для запуска потоковой передачи, клиент будет стараться адаптироваться в следующие первые секунды или минуты потоковой передачи.

Когда предпочтения выводятся из журналов, сервер устанавливает свой параметр confidence_level на значение “среднее" на этапе 2706. В действительности, эта информация может быть немного менее значима, чем явные предпочтения, сигнализируемые самим клиентом (проверка 2701 дает истину).

Когда информация журнала недоступна (проверка 2702 дает ложь), сервер устанавливает свой параметр confidence_level на самое низкое значение: “низкое” на этапе 2707. Это указывает, что сервер осуществляет наилучшее предположение об информации, которую он активно доставляет, поскольку он не имеет априорной информации для принятия решения. Ниже приведено дополнительное описание этого процесса (см. этап 2711).

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

Разбор манифеста (этап 2708) предоставляет информацию серверу во время выбора (на этапе 2709) подходящего представления в качестве начального представления (т.е. начальных медиаданных) для запуска потоковой передачи.

Оба этапа 2703 и 2705 (получения предпочтений, соответственно, в запросе или на основании данных использования из предыдущих этапов обмена данными) состоят в переводе предпочтений или использований от клиентского устройства/пользователя в конкретные параметры, которые будут согласовываться с атрибутами MPD. Например, это может быть полоса, ширина и высота видеозаписи, разновидность используемого кодека, язык для субтитров или аудиопотоков. Затем сервер сравнивает полученные значения этих параметров со значениями в манифесте для идентификации, на этапе 2709, наиболее удобного представления для активной доставки на клиент.

Можно отметить, что этот этап 2709 обычно непрерывно осуществляется клиентским устройством в протоколе динамической и адаптивной потоковой передачи, например DASH. Здесь, тот же этап осуществляется сервером в начале сеанса потоковой передачи средством разбора MPD.

В случае если на этапе 2709 не удается вывести подходящее представление, проверка 2710 дает ложь, и сервер устанавливает свой параметр confidence_level на значение “низкое" (на ранее упомянутом этапе 2707).

Когда параметр confidence_value имеет “низкое" значение (либо потому, что не удается определить предпочтения, либо потому, что не удается найти подходящее представление на основании предпочтений), сервер принимает решение на этапе 2711 для выбора простейшего представления. Для видео, например, простейшее представление может быть представлением с самым низким пространственным разрешением и предназначаться для самой низкой полосы.

Согласно возможному комплементарному признаку (не представленному на фиг. 27), в отсутствие неопределенности в отношении кодека (т.е. все представления видео имеют одинаковое значение атрибута кодека, т.е. для кодирования всех представлений видео использовался один и тот же кодек, например HEVC), параметр confidence_level можно повысить до значения “среднее".

На следующем этапе после этапа 2711, или когда найдено подходящее представление (проверка 2710 дает истину), идентифицируются данные инициализации (этап 2712). В действительности, в манифесте DASH (или файле описания), информацию инициализации можно сигнализировать по-разному: ее можно явно поместить в элемент Initialization элемента SegmentBase, SegmentList или SegmentTempIate, который обеспечивает прямой URL данным инициализации.

В этом случае, этот URL помещается в поле заголовка кадра PUSH_PROMISE (см. этап 2654, описанный выше со ссылкой на фиг. 26), что позволяют клиенту идентифицировать ресурс, обещанный для активной доставки (путем задания переменных:scheme,:host и:path и, в конце концов,:Range).

Когда данные инициализации явно не описаны, это означает, что медиасегменты являются самоинициализируемыми. В таком случае, сервер должен выявлять начало сегмента (например, блоки информации индекса сегмента для сегментов в формате mp4). На основании этого анализа, он может построить соответствующий URL с надлежащим байтовым диапазоном, который будет задан как заголовок в кадре PUSH_PROMISE.

Будучи идентифицирован, кадр PUSH_PROMISE для данных инициализации немедленно отправляется на клиент (этап 2713, соответствующий этапу 2654 на фиг. 26), после чего сразу же следует активная доставка данных инициализации (этап 2717a, соответствующий этапу 2657 на фиг. 26). Приняв данные инициализации, клиент может инициализировать свои медиадекодеры (этап 2717b).

В необязательном порядке, для улучшения сигнализации сегмента и последующей идентификации клиентским устройством при обработке кадра PUSH_PROMISE (см. описанный ниже этап 2806), сервер может указывать на этапе 2713: природу активно доставляемых данных: инициализационные или медиа или оба вида (в случае самоинициализирующихся сегментов); параметры шаблона URL или указание сегмента как путь в дереве представлений MPD, показанной на фиг. 5b (например: P2AS21R211S1; т.е. сцепление типа элемента с последующим идентификатором). Можно отметить, что для этого клиентское устройство должно принимать MPD. Затем сервер может принимать решение добавлять эту конкретную информацию только в сообщения PUSH_PROMISE, которые, согласно его прогнозу, будут обрабатываться после приема MPD клиентским устройством. Для помощи клиентскому устройству в принятии решения, принимать ли PUSH_PROMISE, до приема и разбора MPD, сервер может указывать, вместо пути сегмента в MPD, качественную информацию о активно доставляемом сегменте, например, является ли он сегментом из базового уровня или уровня улучшения; согласно другому примеру, сервер может помещать в заголовок атрибуты выбранного представления с их значениями.

Согласно возможному варианту осуществления (не представленному на фиг. 27), когда при разборе манифеста на этапе 2708 определяется, что данные инициализации присутствует в элементах манифеста верхнего уровня (т.е. для любых представлений, данные инициализации являются общими для всех представлений; например, в случае зависимого представления), сервер может немедленно (т.е. одновременно с этапом 2708) отправлять кадр PUSH_PROMISE, указывающий данные инициализации с параметром confidence_level, заданным равным значению “высокое", поскольку не существует опасности рассогласования между активно доставляемыми данными и выбранными клиентом. Преимущество отправки параметра confidence_level с кадром PUSH_PROMISE, например, в качестве заголовка HTTP, состоит в том, что это может помочь клиентскому устройству принять или отклонить обещание активной доставки (см. нижеприведенное описание фиг. 28).

Благодаря этому признаку, клиент будет заранее принимать данные инициализации, необходимые запуска своих декодеров (ввиду ранней отправки кадра PUSH_PROMISE). Это также работает, когда данные инициализации уникальны для данного типа медиаданных (например, один единственный InitializationSegment на AdaptationSet при любом количестве представлений в этом AdaptationSet). Эта ускоренная активная доставка будет происходить сразу после разбора манифеста (вышеописанный этап 2708), таким образом, до обработки журналов или предпочтений (вышеописанные этапы 2701, 2703 и 2705).

Затем, если параметр confidence_level, ранее определенный сервером, больше или равен “среднему" значению (проверка 2714), сервер инициирует активную доставку первых медиаданных, которые он считает пригодными для клиента.

Это осуществляется итерационно в два этапа: сначала отправляется кадр PUSH_PROMISE (этап 2715, соответствующий этапу 2656 на фиг. 26) и затем на этапе 2719 начинается активная доставка первых медиаданных. Это повторяется для каждого сегмента первых медиаданных, выбранных для активной доставки на этапе 2709.

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

Возможное расписание различных передач данных выглядит следующим образом: до фактической активной доставки первых медиаданных, сервер начинает активную доставку данных инициализации на вышеупомянутом этапе 2717a; параллельно отправке кадра PUSH_PROMISE, относящегося к первым медиаданным и данным инициализации, сервер также отправляет файл MPD (манифест) на этапе 2718 и оставляет поток открытым, пока активно доставляемые данные не будут полностью отправлены.

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

При активной доставке первых медиаданных, сервер определяет полный объем данных для активной доставки и скорость для использования (управления потоками).

Согласно первому аспекту, сервер может использовать информацию из манифеста, например, атрибут minBufferTime, упомянутый в начале манифеста. С использованием этого атрибута и с учетом представления, выбранного на этапе 2709 или 2711, и при условии, что атрибут длительности сегмента также обеспечен в манифесте, сервер легко определяет количество сегментов для активной доставки, в соответствии с ограничением minBufferTime (т.е. количеством сегментов, иначе говоря, объемом данных, образующих начальные медиаданные, подлежащие активной доставке). Преимущественно, когда разбор манифеста (этап 2708) осуществляется в автономном режиме, это количество первых медиасегментов можно записывать в таблице в памяти сервера.

Согласно второму аспекту, на основании длительности сегмента и полосы выбранного представления, сервер может получать оценку необходимой битовой скорости. Это обеспечивает, в основном для видеосегментов, используемую скорость передачи. Например, для сжатого представления видео с полосой, равной 1,6 Мбит/с, имеющего сегменты длительностью 5 секунд, каждый сегмент будет представлять 1 мегабайт данных для отправки. По умолчанию, управление потоками в HTTP v2.0 обеспечивает размер окна потока, равный, максимум, 65535 байтам. Таким образом, в нашем примере, это означает, что клиенту понадобится отправлять обратно на сервер подтверждение для каждого пакета 65536 активно доставленных байтов, что в нашем примере составляет более 15 сегментов! Поскольку задача состоит в сокращении прохождений в двух направлениях и трафика в сети при использовании функции активной доставки в разработке HTTP 2.0, можно отчетливо видеть, что необходимо изменить поведение по умолчанию (фактически, размер окна перегрузки по умолчанию) для обеспечения быстрого запуска DASH (путем уменьшения сетевого трафика).

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

Фиг. 28 описывает возможный способ, осуществляемый клиентским устройством при осуществлении обмена данными с сервером, выполняющим способ, например, описанный на фиг. 27, в соответствии с принципами изобретения.

Согласно возможному применению этого способа, клиентское устройство подключается к серверу, чтобы воспользоваться услугой видео по требованию. Соединение между клиентом и сервером устанавливается традиционным образом. В настоящем примере, клиентское устройство и сервер способны обмениваться сообщениями с использованием протокола HTTP/2.0, описанного, например, в уже упомянутом документе "Hypertext Transfer Protocol version 2.0, draft-ietf-httpbis-http2-latest".

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

Затем клиентское устройство подготавливает запрос загрузки манифеста (этап 2800). В предпочтительном варианте осуществления, клиент добавляет посредством заголовков HTTP некоторые предпочтения относительно разрешения видео, кодеков, поддерживаемой полосы (этап 2801). Затем клиентское устройство отправляет свой запрос на сервер (этап 2802).

В настоящем варианте осуществления, клиентское устройство затем отправляет на этапе 2803 кадр SETTINGS HTTP/2.0 для указания начального размера окна (SETTINGS_INITIAL_WINDOW_SIZE) в соответствии с его возможностями буферизации (см. вышеупомянутый документ "Hypertext Transfer Protocol version 2.0, draft-ietf-httpbis-http2-latest", раздел 3.8.5).

На этапе 2804 клиентское устройство начинает обрабатывать различные ответы сервера: принимает данные, образующие манифест, и разбирает его (этап 2805), а также кадр(ы) PUSH_PROMISE, отправленный(е) сервером (этап 2806).

До принятия решения, принять или отклонить активную(ые) доставку(и), указанную(ые) в кадре(ах) PUSH_PROMISE, клиент строит URL ресурса, который сервер намеревается активно доставлять (этап 2806) и проверяет (этап 2807) параметр confidence_level, включенный в кадр PUSH_PROMISE сервером.

Параллельно и когда манифест (или файл описания) полностью принят, клиентское устройство строит (этап 2808) список медиасегментов, которые оно желает получить (т.е. список версий каждого сегмента, которые наилучшим образом согласуются с его потребностями) и инициализирует текущую переменную segment_index на 0 (этап 2809). Первый этап обработки PUSH_PROMISE состоит (этап 2810a) в проверке параметра confidence_level. Затем, в зависимости от (заранее заданных) настроек клиента или предпочтений пользователя, клиент может принять решение отклонить PUSH_PROMISE при определенном уровне доверия, например, PUSH_PROMISE, для которых кадры PUSH_PROMISE включают в себя параметр confidence_level со значением "низкий".

Если клиент может согласовывать (этап 2810b) URL, упомянутый в кадре PUSH_PROMISE с URL нужного сегмента (выведенного из манифеста на вышеупомянутом этапе 2808), он инициализирует таблицу для списка ожидающих сегментов, передаваемых с их статусом передачи (этап 2811). Если клиент не может идентифицировать сегмент, назначенный для активной доставки сервером на этапе 2810b в списке нужных медиасегментов, затем он отменяет активную доставку (этап 2812) путем отправки надлежащей инструкции CANCEL на сервер.

Для облегчения идентификации сегментов на этапе 2810b, клиент может использовать дополнительную информацию заголовка, например, индекс активно доставляемого сегмента, как путь в древовидном представлении MPD (см. фиг. 5b), или параметры шаблона URL, когда файл описания (т.е. файл MPD или манифест) опирается на SegmentTemplate.

Здесь это специальное сообщение CANCEL (этап 2812), поскольку с использованием иерархического отношения, вставленного сервером при построении PUSH_PROMISE (см. вышеприведенного описания фиг. 27), клиент может отправлять рекурсивное CANCEL, что будет приводить к отмене текущего PUSH_PROMISE плюс следующих.

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

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

Когда сегмент, подлежащий приему путем активной доставки от сервера, соответствует нужному сегменту (проверка 2810b дает истину), затем клиент продолжает обработку кадров PUSH_PROMISE (проверка 2813 и цикл на этапе 2806).

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

Когда в буфере приема клиента принято достаточно медиасегментов (проверка 2815), они обрабатываются клиентом (2816). Затем текущая переменная segment_index обновляется порядковым номером первого сегмента в списке (этап 2817). Следует отметить, что не все клиенты могут получать доступ к буферу клиента. Например, веб-приложения, в частности, обычно не имеют доступа к кэш-памяти веб-браузера. В таком случае, сервер может отправлять список активно доставляемых сегментов непосредственно на клиент веб-приложения. Эта информация может передаваться с сервера на клиент с использованием соединения через веб-сокеты, например.

После обработки всех активно доставленных медиасегментов, клиент может вернуться к стандартному DASH на основе вытягивания (этап 2818), начиная запрашивать данные, соответствующие следующему сегменту, указанному переменной segment_index+1. Параллельно, данные активно доставляемого сегмента используются для запуска декодирования и отображения выбранного видео.

На фиг. 13 показана схема устройства согласно вариантам осуществления. Устройством может быть сервер, клиент или узел-посредник. Устройство содержит память 1302 RAM, которая может использоваться как рабочая память для блока 1301 управления, выполненного с возможностью реализации способа согласно вариантам осуществления. Например, блок управления может быть выполнен с возможностью выполнения инструкций компьютерной программы, загруженной из памяти 1303 ROM. Программа также может загружаться с жесткого диска 1306. Например, компьютерная программа построена на основании блок-схем операций на фиг. 8-12, 14, 15, 17, 20-22 и 26-28, и вышеприведенного описания.

Устройство также содержит сетевой интерфейс 1304, который может быть единственным сетевым интерфейсом или содержать набор сетевых интерфейсов (например, несколько беспроводных интерфейсов, или несколько типов проводных или беспроводных интерфейсов). Устройство может содержать пользовательский интерфейс 1305 для отображения информации пользователю и для приема вводов от пользователя.

Устройство также может содержать модуль 1307 ввода/вывода для приема и/или отправки данных от/на внешние устройства.

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

В формуле изобретения, слово “содержащий” не исключает наличия других элементов или этапов, и употребление их наименований в единственном числе не исключает наличия их множества. Единственный процессор или другой блок может осуществлять функции нескольких элементов, упомянутых в формуле изобретения. Лишь тот факт, что разные признаки упомянуты в отличающихся друг от друга зависимых пунктах формулы изобретения, не указывает, что нельзя успешно использовать комбинацию этих признаков. Никакие ссылочные позиции в формуле изобретения не следует рассматривать в порядке ограничения объема изобретения.

Изобретение относится к сетям связи на основе динамической адаптивной потоковой передачи по HTTP (DASH). Технический результат заключается в сохранении ресурсов на стороне сервера потоковой передачи данных. Предложен способ управления потоковой передачей по сетям связи, где серверные и клиентские устройства совместно используют политику активной доставки, что позволяет клиентскому устройству прогнозировать активную доставку данных сервером. Прогнозирование позволяет заблаговременно отменять отправку некоторых активно доставляемых данных, таким образом снижая расходование полосы. Совместно используемая политика активной доставки может быть неявной как для сервера, так и для клиента. В вариантах осуществления это явно указывается сервером клиенту, например, путем вложения в файл описания медиапрезентации или включения в специальный заголовок HTTP. Клиент также может запрашивать обновление совместно используемой политики активной доставки в соответствии со своими собственными требованиями. 6 н. и 19 з.п. ф-лы, 39 ил.

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

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

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

- отменяют, на сервере, в ответ на прием от клиента запроса отмены, активную доставку идентифицированных данных клиенту.

2. Способ управления по п. 1, в котором сообщение подтверждения отправляют клиенту в качестве упомянутого уведомления.

3. Способ управления по п. 1, в котором кадр PUSH_PROMISE, определенный посредством HTTP/2, отправляют клиенту в качестве упомянутого уведомления.

4. Способ управления по п. 1, в котором сообщение, определенное посредством Веб-Сокета (WebSocket), отправляют клиенту в качестве упомянутого уведомления.

5. Способ управления по п. 1, в котором идентификацию выполняют в ответ на прием предопределенного запроса от клиента.

6. Способ управления по п. 5, в котором упомянутый предопределенный запрос представляет собой запрос MPD (описания медиапрезентации).

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

8. Способ управления по п. 1, в котором один или более сегментов идентифицированных медиаданных сообщают клиенту посредством упомянутого уведомления.

9. Способ управления по п. 1, в котором упомянутый запрос отмены соответствует кадру RST_STREAM, определенному посредством HTTP/2.

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

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

12. Способ управления по п. 1, в котором согласованные с медиаданными данные представляют собой по меньшей мере один из (i) сегмента инициализации, который содержит метаданные, подлежащие использованию для воспроизведения медиаданных, и (ii) медиасегмента, который содержит упомянутые медиаданные.

13. Способ управления приемом клиентом согласованных с медиаданными данных от сервера, причем способ содержит этапы, на которых:

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

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

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

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

14. Способ управления по п. 13, в котором сообщение подтверждения принимают на клиенте в качестве упомянутого уведомления.

15. Способ управления по п. 13, в котором кадр PUSH_PROMISE, определенный посредством HTTP/2, принимают на клиенте в качестве упомянутого уведомления.

16. Способ управления по п. 13, в котором один или более сегментов медиаданных сообщают посредством упомянутого уведомления.

17. Способ управления по п. 13, в котором упомянутый запрос отмены соответствует кадру RST_STREAM, определенному посредством HTTP/2.

18. Сервер для предоставления клиенту согласованных с медиаданными данных, содержащий:

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

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

- средство отмены для отмены, в ответ на прием от клиента запроса отмены, активной доставки идентифицированных данных клиенту.

19. Сервер по п. 18, в котором сообщение подтверждения отправляется клиенту в качестве упомянутого уведомления.

20. Сервер по п. 18, в котором кадр PUSH_PROMISE, определенный посредством HTTP/2, отправляется клиенту в качестве упомянутого уведомления.

21. Клиент для приема медиаданных с сервера, причем клиент содержит:

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

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

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

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

22. Клиент по п. 21, в котором сообщение подтверждения принимается на клиенте в качестве упомянутого уведомления.

23. Клиент по п. 21, в котором кадр PUSH_PROMISE, определенный посредством HTTP/2, принимается на клиенте в качестве упомянутого уведомления.

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

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