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

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

Иллюстрации

Показать все

Реферат

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

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

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

В качестве глобально стандартизированного протокола доставки движущегося изображения, который может использоваться для доставки движущегося изображения по Интернету, существует известный протокол DASH MPEG (Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP, динамическая адаптивная потоковая HTTP-передача - группа экспертов по движущимся изображениям, здесь дополнительно упоминаемый как DASH), который использует одноадресную HTTP-передачу, подобную просмотру веб-сайтов и т.п.(например, обратитесь к непатентной литературе 1).

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

Таким образом, в DASH метаданные, называемые MPD (Media Presentation Description, описание медиапрезентации), предоставляются стороной предоставления стороне приема, так чтобы сторона приема могла адаптивно выбрать и принять поток.

Адрес (информация URL) веб-сервера, который является источником предоставления сегментных потоков разделенного на блоки контента (медиаданные, такие как Audio/Video/Subtitle, аудио/видео/подзаголовок), описывается в MPD. Сторона приема, основываясь на информации URL, передает запрос HTTP на веб-сервер, являющийся источником предоставления контента, и принимает и воспроизводит поток сегментов, который веб-сервер передает посредством одноадресной передачи в соответствии с этим HTTP-запросом.

На фиг. 1 показан пример построения системы предоставления контента, которая передает сегментные потоки контента, основываясь на DASH.

Эта система 10 предоставления контента построена из множества устройств 20-1 -20-К предоставления контента на стороне, предоставляющей контент, и множества DASH-клиентов 30-1 - 30-N на стороне, принимающей контент. Здесь ниже, когда нет необходимости различать устройства 20-1 - 20-K предоставления контента, они будут просто называться устройством 20 предоставления контента. То же самое относится к DASH-клиентам 30-1 - 30-N.

Каждое из устройств 20 предоставления контента и DASH-клиента 30 соединяется с Интернетом 11. CDN (сеть доставки контента) 12 создается в Интернете 11.

Устройство 20 предоставления контента является устройством, которое доставляет множество сегментных потоков одного и того же контента, но с различными битовыми скоростями передачи, и имеет канальный стример 21, сегментный DASH-стример 22 и DASH-сервер 23 MPD.

Канальный стример 21 управляет исходными данными контента для доставки DASH-клиенту 30 и формирует множество потоковых данных с разными битовыми скоростями передачи из исходных данных контента и выводит их на сегментный DASH-стример 22.

Сегментный DASH-стример 22 временно делит (разбивает на части) данные каждой потоковой передачи на сегменты, чтобы сформировать сегментный поток. Кроме того, сегментный DASH-стример 22 формирует файлы и хранит сегментный поток и, как веб-сервер, в соответствии с запросом (HTTP-запрос) от DASH-клиента 30, через CDN 12 доставляет посредством одноадресной HTTP-передачи файл сегментного потока DASH-клиенту 30, который является источником запроса. Кроме того, сегментный DASH-стример 22 уведомляет DASH-сервер 23 MPD об адресе источника предоставления файла сегментного потока.

DASH-сервер 23 MPD формирует MPD, содержащий адреса и т.п., указывающие источник предоставления файла сегментного потока, который запрашивает DASH-клиент 30, чтобы получить файл сегментного потока. Кроме того, DASH-сервер 23 MPD, в качестве веб-сервера, в соответствии с запросом (HTTP-запрос) от DASH-клиента 30, через CDN 12 доставляет посредством одноадресной HTTP-передачи сгенерированный MPD DASH-клиенту 30, который является источником запроса.

DASH-клиент 30 запрашивает MPD от DASH-сервера 23 MPD и в ответ принимает MPD, доставленный посредством одноадресной HTTP-передачи. Кроме того, DASH-клиент 30, основываясь на принятом MPD, запрашивает потоковый файл от сегментного DASH-стримера 22 и в ответ принимает и воспроизводит файл сегментного потока, доставляемый посредством одноадресной HTTP-передачи.

Заметим, что прокси-сервер 13, который кэширует MPD и файл сегментного потока, переданный посредством одноадресной HTTP-передачи через CND 12, обеспечивается в CDN 12. Прокси-сервер 13 вместо DASH-сервера 23 MPD или сегментного DASH-стримера 22 в качестве веб-серверов доставляет посредством одноадресной HTTP-передачи источнику запроса кэшированный MPD или файл сегментного потока.

Литература

Непатентная литература

Непатентная литература 1: Hirabayashi, Mitsuhiro "Realizing Moving Image Delivery With No Drop-outs in an Existing Web Server", Nikkei Electronics, March 19, 2012

Раскрытие изобретения Техническая проблема

Как упомянуто выше, обеспечивая в CDN 12 прокси-сервер 13, можно улучшить характеристики ответной реакции на запросы от DASH-клиента 30.

Однако, прокси-сервер 13, способный доставлять MPD или сегментный поток вместо DASH-сервера 23 MPD или сегментного DASH-стримера 22 в качестве вебсерверов, ограничивается случаем, когда их уже кэшировали. То есть, в то время, как он способен к быстрому ответу в случае другого DASH-клиента 30, делающего запрос и которому доставка уже была сделана соответственно кэшированной, в случае, когда запрашивается что-то, что не каптировано, он был неспособен ответить.

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

Решение проблемы

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

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

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

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

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

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

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

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

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

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

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

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

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

Предпочтительные результаты изобретения

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

В соответствии со вторым вариантом настоящего раскрытия, возможна оптимизация кэширования прокси-сервером.

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

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

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

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

Фиг. 3 - блок-схема примера конфигурации оптимизируемого прокси-сервера.

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

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

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

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

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

Фиг. 9 - блок-схема примера конфигурации компьютера.

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

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

Пример конфигурации системы предоставления контента

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

Эта система 50 предоставления контента состоит из множества устройств 60-1 - 60-K предоставления контента, CDN 72, выполненной в сети 71, и множества оконечных устройств 80-1 - 80-N. Устройства 60-1 - 60-K предоставления контента и оконечные устройства 80-1 - 80-N соединяются с сетью 71.

Здесь далее, когда нет необходимости различать устройства 60-1 - 60-K предоставления контента, их просто называют устройством 60 предоставления контента. То же самое относится к оконечным устройствам 80-1 - 80-N.

Устройство 60 предоставления контента содержит канальный стример 61, DASH-сегментатор 62, FLUTE-стример 63, генератор 64 MPD, веб-сервер 65 и многоадресный сервер 66.

Заметим, что канальный стример 61 и многоадресный сервер 66, которые имеет устройство 60 предоставления контента, могут быть интегрированы в одном устройстве или могут быть распределены по Интернету или аналогичным образом.

Канальный стример 61 управляет данными источника контента для подачи оконечному устройству 80 и формирует множество потоковых данных, отличающихся по битовой скорости передачи от данных источника одного и того же контента. Кроме того, канальный стример 61 выводит сформированные потоковые данные на DASH-сегментатор 62.

DASH-сегментатор 62 посредством временного разделения потоковых данных на периоды и последующего разделения их на сегменты, генерирует сегментный поток, такой как фрагментированный МР4, и выводит его на веб-сервер 65 и FLUTE-стример 63. Кроме того, DASH-сегментатор 62 уведомляет генератор 64 MPD метаданных, содержащих адресную информацию веб-сервера 65, что он становится источником предоставления файла, сгенерированного сегментного потока.

Генератор 64 MPD генерирует MPD, требующийся для оконечного устройства 80, чтобы принять сегментный поток, и выводит его на FLUTE-стример 63 и на веб-сервер 65.

FLUTE-стример 63, сохраняя в пакетах FLUTE сегментный поток, введенный от DASH-сегментатора 62, генерирует FLUTE-поток и выводит его на многоадресный сервер 66. Кроме того, FLUTE-стример 63 выводит MPD, введенный от генератора 64 MPD, на многоадресный сервер 66.

Веб-сервер 65, в соответствии с запросом получения MPD (запрос HTTP) от оконечного устройства 80, передает посредством одноадресной передачи HTTP MPD, введенный от генератора 64 MPD, через CDN 72 оконечному устройству 80, являющемуся источником запроса. Кроме того, веб-сервер 65, в соответствии с запросом получения сегментного потока (запросом HTTP) от оконечного устройства 80, доставляет посредством одноадресной передачи HTTP файл сегментного потока, введенный от DASH-сегментатора 62, через CDN 72 оконечному устройству 80, которое является источником запроса.

Многоадресный сервер 66 передает MPD посредством многоадресной FLUTE-передачи от FLUTE-стримера 63 через CDN 72. Кроме того, многоадресный сервер 66 передает FLUTE-поток посредством многоадресной FLUTE-передачи от FLUTE-стримера 63 через CDN 72. Кроме того, например, USD для (e)MBMS, OMA-ESG и т.п., используются для распространения портальных каналов многоадресной FLUTE-передачи.

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

CDN 72 создается в сети 71. В CDN 72 обеспечивается множество оптимизируемых прокси-серверов 73, портальные серверы MPD 74 и серверы 75 сценария. Кроме того, хотя его графический дисплей отсутствует, в CDN 72 может существовать традиционный прокси-сервер 13.

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

Кроме того, оптимизируемый прокси-сервер 73 посредством контроля метаданных (таких как OMA-ESG и т.п.), в которых контент MPD и FLUTE-поток, передаваемые посредством многоадресной передачи через CDN 72, описываются и сопоставляются с его собственной базой данных, принимает решение, является ли их приоритет высоким (вероятность получения впредь запроса, передаваемого от оконечного устройства 80, которое соединяется с ним, является высокой). Затем он кэширует MPD или FLUTE-поток с высоким приоритетом (упоминается ниже как многоадресный процесс предварительного кэширования).

Кроме того, оптимизируемый прокси-сервер 73, посредством контроля MPD и сегментного потока, передаваемых путем одноадресной передачи через CDN 72, и сопоставления их с его собственной базой данных, определяет, обладают ли они высоким приоритетом. Затем, он кэширует MPD и сегментный поток с высоким приоритетом (упоминается ниже как процесс одноадресного кэширования).

Кроме того, оптимизируемый прокси-сервер 73 может искать и определять MPD и сегментные потоки с высоким приоритетом от портального сервера 74 MPD, запрашивать от устройства 60 предоставления контента указанные MPD и сегментные потоки и кэшировать те, которые передаются в ответ посредством одноадресной HTTP-передачи.

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

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

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

Оконечное устройство 80 имеет блок 81 приема/воспроизведения, блок 82 регистрации 82 и блок 83 запроса сценария. Блок 81 приема/воспроизведения принимает MPD и, основываясь на MPD, принимает и воспроизводит сегментный поток и FLUTE-поток. Блок 82 регистрации выполняет процесс регистрации или отмены регистрации политики процесса предварительного кэширования на оптимизируемом прокси-сервере 73 Блок 83 запроса сценария запрашивает у сервера 75 сценария сценарий автоматического соединения с оптимизируемым прокси-сервером 73, который оптимален для него самого (например, тот, который располагается в непосредственной близости, тот, который может принимать передачи широковещательной сети, которые он сам не может принимать).

Пример подробной конфигурации оптимизируемого прокси-сервера 73

Далее на фиг. 3 показан подробный пример конфигурации оптимизируемого прокси-сервера 73.

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

Блок 91 контроля в качестве посредника контролирует запросы получения MPD и запросы получения сегментных потоков от оконечного устройства 80 и в случае, когда запрошенный MPD или сегментный поток кэширован в блоке 92 хранения, считывает их из блока 92 хранения и передает посредством одноадресной передачи источнику запроса. Кроме того, блок 91 контроля в качестве посредника выводит на блок 93 анализа проконтролированные запросы получения MPD и запросы получения сегментного потока. Кроме того, блок 91 контроля в качестве посредника выполняет контроль MPD и сегментных потоков, которые передаются посредством одноадресной передачи HTTP, и выводит их на блок 93 анализа.

В блоке 92 хранения хранятся (кэшируются) MPD и сегментные потоки, введенные из блока 93 анализа и оцениваемые как обладающие высоким приоритетом. Кроме того, блок 92 хранения содержит MPD и FLUTE-потоки, оцениваемые как обладающие высоким приоритетом, которые вводятся из блока 95 предварительного кэширования.

Блок 93 анализа анализирует контролируемые запросы получения MPD и запросы получения сегментного потока. Конкретно, URL MPD, информация о профиле, описанная в MPD/@profile, максимальное значение размера сегмента (значение @duration или значение @maxSegmentDuration, @maxSubSegmentDuration), контент метаданных, описывающий контент, который ищет Programlnformation (в частности, получение и анализ заголовка, краткое содержание, жанр и т.п. контента как процесс загрузки, разрешает и накапливает их как информацию о предпочтениях), контент схемы, которая ищет Role, и контент схемы доступности, которая ищет Accessibility (например, в случае присутствия запроса получения сегментов для потока, содержащего речевое контролируемое руководство, можно вывести предпочтение пользователя для речевого потока, степени неспособности и т.п.), тип языка, описанный в @lang, информация о рейтинге, которую ищет Rating, распределение @bandwidth, информация о количестве пикселей по вертикали и по горизонтали, выраженная комбинацией @width и @height, информация о частоте выборки, описанная в @audioSamplingRate, тип кодека, описанный в @codec, информация о конфигурации звукового канала, которую ищет audioChannelConfiguration, считывая тип DRM, который ищет contentProtection, и заставляет эти контенты храниться в качестве статистической информации, связанной с частотой запросов получения в базе 94 данных результатов анализа.

Кроме того, блок 93 анализа дает оценку приоритета MPD и сегментного потока, вводимых от блока 91 контроля в качестве посредника и контролируемых по одноадресной HTTP-передаче, и заставляет тех из них, которые имеют высокий приоритет, храниться в блоке 92 хранения. Кроме того, блок 93 анализа дает оценку приоритета MPD и FLUTE-потока, введенных от блока 95 тюнера и переданных посредством многоадресной FLUTE-передачи, и заставляет тех из них, которые имеют высокий приоритет, сохраняться в блоке 92 хранения.

База 94 данных результатов анализа содержит информацию о тактовом сигнале результатов анализа, вводимую от блока 93 анализа.

Блок 95 тюнера принимает MPD и FLUTE-потоки, переданные посредством многоадресной FLUTE-передачи, и их метаданные и выводит их на блок 93 анализа.

Порядок действия системы 50 предоставления контента

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

Описание процесса передачи контента

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

На этапе S1 канальный стример 61 генерирует множество данных потоковой передачи с различными битовыми скоростями передачи из данных исходного контента и выводит их в DASH-сегмент и на веб-сервер 65.

На этапе S2 DASH-сегментатор 62 генерирует сегментный поток, такой как фрагментированный МР4, из данных потоковой передачи и выводит его на FLUTE-стример 63 и на веб-сервер 65. Кроме того, DASH-сегментатор 62 уведомляет генератор 64 MPD об URL источника предоставления сгенерированного сегментного потока.

На этапе S3 FLUTE-стример 63 генерирует FLUTE-поток, сохраняя сегментный поток в FLUTE-пакете, и выводит его на многоадресный сервер 66. На этапе S4 генератор 64 MPD генерирует MPD и выводит его на FLUTE-стример 63 и на веб-сервер 65.

На этапе S5 FLUTE-стример 63 выводит MPD на многоадресный сервер 66. Многоадресный сервер 66 распространяет MPD посредством многоадресной FLUTE-передачи через CDN 72.

На этапе S6 веб-сервер 65, в случае, когда существует запрос получения MPD (HTTP-запрос) от оконечного устройства 80, в ответ передает MPD посредством однонаправленной HTTP-передачи через CDN 72.

На этапе S7 многоадресный сервер 66 передает FLUTE-поток посредством многоадресной FLUTE-передачи через CDN 72. На этапе S8 веб-сервер 65, в случае, когда существует запрос получения сегментного потока (HTTP-запрос) от оконечного устройства 80, передает сегментный поток посредством одноадресной HTTP-передачи источнику запроса через CDN 72. Этим завершается описание процесса передачи контента устройством 60 предоставления контента.

Описание процесса анализа запроса,

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

Когда оконечное устройство 80 в качестве этапа S11 передает запрос получения MPD на веб-сервер 65 через CDN 82, на этапе S21 блок 91 контроля в качестве посредника оптимизируемого прокси-сервера 73 контролирует запрос получения MPD и выводит его на блок 93 анализа. На этапе S22 блок 93 анализа анализирует запрос получения MPD и записывает результат в базу 94 данных результатов анализа.

Заметим, что в случае MPD, соответствующего запросу получения MPD, контролируемому на этапе S21, уже кэшированного в блоке 92 хранения, блок 91 контроля в качестве посредника считывает MPD из блока 92 хранения и передает его посредством одноадресной HTTP-передачи источнику запроса. На фиг. 5 показан пример случая MPD, который не был кэширован, и в этом случае, как на этапе S6 процесса предоставления контента, описанном выше, веб-сервер 65 передает посредством одноадресной HTTP-передачи источнику запроса MPD соответствующий запрос получения MPD через CDN 72.

MPD, который передается посредством одноадресной HTTP-передачи, принимается оконечным устройством 80 на этапе S12. Когда оконечное устройство 80, как на этапе S13, передает веб-серверу 65 через CDN 82 запрос получения сегментного потока, основываясь на MPD, на этапе S23 блок 91 контроля в качестве посредника контролирует запрос получения сегментного потока и выводит его на блок 93 анализа. На этапе S24 блок 93 анализа анализирует запрос получения сегментного потока и записывает результат в базу 94 данных результатов анализа.

Заметим, что в случае, когда блок 92 хранения уже кэшировал сегментный поток, соответствующий запросу получения сегментного потока, контролируемого на этапе S23, блок 91 контроля в качестве посредника считывает сегментный поток из блока 92 хранения и передает его посредством одноадресной HTTP-передачи источнику запроса. На фиг. 5 представлен пример случая сегментного потока, который не был кэширован, и в этом случае, как на этапе S8 процесса предоставления контента, описанном выше, вебсервер 65 передает посредством одноадресной HTTP-передачи источнику запроса через CDN 72 сегментный поток, соответствующий запросу получения сегментного потока.

Сегментный поток, переданный посредством одноадресной HTTP-передачи, принимается и воспроизводится оконечным устройством 80, как на этапе S14. Этим завершается процесс анализа запроса.

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

Описание многоадресного процесса предварительного кэширования

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

Когда многоадресный сервер 66 устройства 60 предоставления контента на этапе S31 передает MPD посредством многоадресной FLUTE-передачи, как на этапе S5 процесса предоставления контента, описанном выше, блок 95 тюнера оптимизируемого прокси-сервера 73 принимает MPD и выводит его на блок 93 анализа. Блок 93 анализа обращается к базе 94 данных результатов анализа и в случае, когда MPD обладает высоким приоритетом, заставляет его кэшироваться в блоке 92 хранения.

Аналогично, когда многоадресный сервер 66 устройства 60 предоставления контента передает посредством многоадресной FLUTE-передачи FLUTE-поток, как на этапе S7 процесса предоставления контента, описанном выше, на этапе S32 блок 95 тюнера принимает FLUTE-поток и выводит его на блок 93 анализа. Блок 93 анализа обращается к базе 94 данных результатов анализа и в случае, когда FLUTE-поток обладает высоким приоритетом, заставляет его кэшироваться в блоке 92 хранения. Этим завершается многоадресный процесс предварительного кэширования.

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

Описание одноадресного процесса предварительного кэширования

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

Когда оконечное устройство 80 передает запрос получения MPD, как на этапе S41, веб-сервер 65 передает посредством одноадресной HTTP-передачи MPD, соответствующий запросу получения MPD, как на этапе S6 процесса предоставления контента, описанном выше, и оконечное устройство 80 на этапе S42 принимает MPD, переданный посредством одноадресной HTTP-передачи.

На этапе S51 блок 91 контроля в качестве посредника оптимизируемого прокси-сервера 73 контролирует этот MPD, переданный посредством одноадресной HTTP-передачи, и выводит его на блок 93 анализа. Блок 93 анализа оценивает приоритет MPD, переданных посредством одноадресной HTTP-передачи, и заставляет тех, которые обладают высоким приоритетом, сохраняться в блоке 92 хранения. Заметим, что в отношении запроса получения MPD, которые передало оконечное устройство 80, он контролируется и анализируется и результат процесса анализа запроса накапливается в базе 94 данных результатов анализа, как описано выше.

Когда оконечное устройство 80 на этапе S43 передает запрос получения сегментного потока, основываясь на принятом MPD, веб-сервер 65 передает посредством одноадресной HTTP-передачи сегментный поток, соответствующий запросу получения сегментному потоку, как этап S8 процесса предоставления контента, описанный выше, и оконечное устройство 80 в качестве этапа S42 принимает и воспроизводит сегментный поток, передаваемый посредством одноадресной HTTP-передачи,

На этапе S52 блок 91 контроля в качестве посредника оптимизируемого прокси-сервера 73 контролирует этот сегментный поток, передаваемый посредством одноадресной HTTP-передачи, и выводит его на блок 93 анализа. Блок 93 анализа оценивает приоритет сегментных потоков, передаваемых посредством одноадресной HTTP-передачи, и заставляет тех, которые обладают высоким приоритетом, сохраняться в блоке 92 хранения. Заметим, что в отношении запроса получения сегментного потока, который передало оконечное устройство 80, он контролируется и анализируется и результат накапливается в базе 94 данных результатов анализа, как описано выше, в качестве процесса анализа запроса.

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

Описание процесса предоставления сценария

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

На этапе S61, когда блок 83 запроса сценария оконечного устройства 80, используя WPAD (Web Proxy Auto-Discover Protocol, веб-протокол прокси-автообнаружения) и т.п., передает CDN 72 запрос РАС (Proxy Auto-Config, прокси-автоконфигурация) сценария, который выполняет настройку, чтобы иметь возможность соединяться с оптимизируемым прокси-сервером 72, который оптимален для себя самого, этот запрос принимается сервером 75 сценария.,

На этапе S71 сервер 75 сценария определяет оптимизируемый прокси-сервер 73, * оптимальный для оконечного устройства 80, которое передало запрос сценария РАС, и предоставляет источнику запроса сценарий, который выполняет настройку для соединения оконечного устройства 80 с оптимизируемым прокси-сервером 73.

На этапе S72 сервер 75 сценария, блок 83 запроса сценария оконечного устройства 80 выполняет пред