RU2658672C2 - Устройство предоставления контента, программа, оконечное устройство и система предоставления контента - Google Patents

Устройство предоставления контента, программа, оконечное устройство и система предоставления контента Download PDF

Info

Publication number
RU2658672C2
RU2658672C2 RU2016105844A RU2016105844A RU2658672C2 RU 2658672 C2 RU2658672 C2 RU 2658672C2 RU 2016105844 A RU2016105844 A RU 2016105844A RU 2016105844 A RU2016105844 A RU 2016105844A RU 2658672 C2 RU2658672 C2 RU 2658672C2
Authority
RU
Russia
Prior art keywords
flute
stream
sdp
mode
transmission
Prior art date
Application number
RU2016105844A
Other languages
English (en)
Other versions
RU2016105844A (ru
Inventor
Ясуаки ЯМАГИСИ
Original Assignee
Сони Корпорейшн
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Сони Корпорейшн filed Critical Сони Корпорейшн
Publication of RU2016105844A publication Critical patent/RU2016105844A/ru
Application granted granted Critical
Publication of RU2658672C2 publication Critical patent/RU2658672C2/ru

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6405—Multicasting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84—Generation or processing of descriptive data, e.g. content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Library & Information Science (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Изобретение относится к устройству предоставления контента, который доставляется посредством многоадресной передачи по протоколу доставки файлов через однонаправленный транспорт (FLUTE). Технический результат заключается в обеспечении уведомления стороны приема, которая получает FLUTE-сеанс в режиме приема. Предложено устройство предоставления контента, содержащее: блок формирования потока фрагментов, выполненный с возможностью формирования потока фрагментов на основе исходных данных контента; блок формирования FLUTE-потока, выполненный с возможностью формирования FLUTE-потока из сформированного потока фрагментов; блок создания протокола описания сеанса (SDP), выполненный с возможностью создания SDP, содержащего режим приема в случае приема стороной приема FLUTE-сеанса, содержащего FLUTE-поток; и блок многоадресной передачи, выполненный с возможностью передачи FLUTE-потока посредством многоадресной FLUTE-передачи и передачи до передачи FLUTE-потока посредством многоадресной FLUTE-передачи, SDP посредством многоадресной FLUTE-передачи. 5 н. и 3 з.п. ф-лы, 6 ил.

Description

Область техники, к которой относится изобретение
Настоящее раскрытие относится к устройству предоставления контента, способу предоставления контента, программе, оконечному устройству и системе предоставления контента и, в частности, к устройству предоставления контента, способу предоставления контента, программе, оконечному устройству и системе предоставления контента, пригодным для использования, когда контент доставляется посредством многоадресной передачи по протоколу FLUTE (File Delivery over Unidirectional Transport, доставка файлов через однонаправленный транспорт).
Уровень техники
В последние годы основным потоком при обслуживании потоков с использованием Интернет был OTT-V (Over The Top Video) и в качестве глобально стандартизированного протокола доставки движущихся картинок, который может использоваться для этого, известен протокол MPEG-DASH (Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP, здесь далее называемый DASH), который использует протокол HTTP, подобный протоколу просмотра веб-сайтов и т.п. (обратитесь, например, к непатентной литературе 1).
В DASH применяется технология адаптивной потоковой передачи данных. Иначе говоря, на стороне предоставления контента подготавливаются и подаются многочисленные потоки с одним и тем же контентом, но с разными битовыми скоростями передачи, зависящими от качества изображения и размера угла зрения. С другой стороны, сторона приема может выбирать, принимать и воспроизводить оптимальный поток в соответствии со средой связи Интернет, ее собственными возможностями декодирования и т.п. для множества потоков, которые подготовила сторона передачи.
Метафайлы, называемые MPD (Media Presentation Description), подаются со стороны передачи на сторону приема, так что сторона приема может адаптивно выбирать, принимать и воспроизводить потоки.
Адрес (информация URL) сервера, передающего потоки прерывистого контента (метаданные, такие как аудио/видео/подзаголовок), описывается в MPD. Сторона приема, основываясь на информации URL, получает доступ к серверу, который является источником предоставления контента, чтобы запросить поток, принимает поток, переданный через однонаправленную HTTP-передачу от сервера в соответствии с запросом, и воспроизводит его.
На фиг. 1 показан пример организации системы предоставления контента, передающей контент потоком, основанным на DASH.
Эта система 10 предоставления контента состоит из множества устройств 20 предоставления контента, которые предоставляют контент, и множества DASH-клиентов 30, которые принимают и воспроизводят контент. DASH-клиент 30 соединяется с устройством 20 через CDN (Contents Delivery Network, сеть доставки контента) 12, которая использует Интернет 11.
Устройство 20 предоставления контента доставляет множество потоков, имеющих один и тот же контент, но разные битовые скорости передачи. Устройство 20 предоставления контента имеет сервер 21 управления контентом, сегментный DASH-стример 22 и DASH-сервер 23 MPD.
Сервер 21 управления контентом управляет исходными данными контента для доставки DASH-клиенту 30, формирует множество потоковых данных с различными битовыми скоростями передачи из исходных данных и выводит их на сегментный DASH-стример 22.
Сегментный DASH-стример 22 делит каждые из потоковых данных временно на сегменты, чтобы сформировать сегментный поток, такой как фрагментированный МР4 (Fragmented МР4) и т.п., и файлы, и сохраняет сформированный сегментный поток. Кроме того, сегментный DASH-стример 22 в качестве веб-сервера в соответствии с запросом (HTTP-запрос) от DASH-клиента 30 подает источнику запроса посредством однонаправленной HTTP-передачи хранящийся у него файл сегментного потока. Дополнительно сегментный DASH-стример 22 подает DASH-серверу 23 MPD метаданных уведомление, содержащее адрес, указывающий источник предоставления файла сегментного потока.
DASH-сервер 23 MPD формирует MPD, содержащий адрес и т.п., указывающий источник предоставления (то есть, сегментный DASH-стример 22) файла сегментного потока. Кроме того, DASH-сервер 23 MPD в качестве веб-сервера в соответствии с запросом (HTTP-запросом) от DASH-клиента 30 доставляет источнику запроса сформированный MPD посредством однонаправленный HTTP-передачи.
DASH-клиент 30 запрашивает MPD у DASH-сервера 23 MPD и в ответ принимает MPD, доставленный посредством одноадресной HTTP-передачи. Кроме того, DASH-клиент 30, основываясь на принятом MPD, запрашивает файл сегментного потока от сегментного DASH-стримера 22 и в ответ принимает и воспроизводит файл сегментного потока, доставляемый посредством одноадресной HTTP-передачи.
Заметим, что CDN 12 содержит сервер кэширования (не показан) и сервер кэширования кэширует MPD и файл сегментного потока, доставляемый посредством одноадресной HTTP-передачи через CDN 12. Сервер кэширования, вместо DASH-сервера 23 MPD или сегментного DASH-стримера 22 в качестве веб-серверов, может доставлять посредством одноадресной HTTP-передачи кэшированный MPD и файл сегментного потока DASH-клиенту 30 источника запроса.
Литература
Непатентная литература
Непатентной литература 1: Hirabayashi, Mitsuhiro. "Realizing Moving Image Delivery With No Drop-outs in an Existing Web Server." Nikkei Electronics, March 19, 2012
Раскрытие изобретения
Техническая проблема
Как упоминалось выше, в DASH технология адаптивной потоковой передачи применяется, используя одноадресную HTTP-передачу.
Если сторона приема совместима не только с доставкой посредством одноадресной HTTP-передачи, но также и с многоадресной FLUTE-доставкой, используя, например, сеть связи мобильных телефонов, желательно использовать ее для доставки потока, чтобы иметь возможность адаптивного выбора потока на стороне приема.
То есть, при многоадресной FLUTE-передаче, поскольку QoS (гарантированная полоса/задержка) гарантируется, в случае передачи контента, в котором требуется свойство в реальном времени, такое как живое видео, по сравнению с одноадресной передачей HTTP на приемной стороне можно ожидать стабильного приема и воспроизведения.
Однако, в случае, когда сторона приема принимает и воспроизводит поток, который передается посредством многоадресной FLUTE-передачи, когда после начала приема FLUTE-сеанса содержащийся в нем FDT не анализируется, невозможно знать контент пакетов (пакетов ALC/LCT), передаваемых в FLUTE-сеансе. Напротив, при получении пакетов, которые передаются в последующем FLUTE-сеансе после приема и анализа FDT, иногда невозможно принимать желаемые пакеты. В частности, в случаях, когда требуется немедленность, таких как живая потоковая передача, и частота повторной передачи одного и того же пакета низкая, эта тенденция нарастает.
Соответственно, если сторона приема, принимающая FLUTE-сеанс, была уведомлена о режиме приема таким образом, как "Необходимо получить все пакеты (что означает, что поскольку одни и те же пакеты не будут посылаться повторно или частота повторной передачи низкая, лучше принять все пакеты)", это может быть более удобным для стороны приема. Однако, в настоящее время такой способ не был принят
Настоящее раскрытие было сделано с точки зрения описанных выше обстоятельств и способно уведомлять сторону приема, которая получает FLUTE-сеанс в режиме приема.
Решение проблемы
В соответствии с первым вариантом настоящего раскрытия, устройство предоставления контента, которое передает контент посредством многоадресной FLUTE-передачи, содержит: блок формирования потока фрагментов на основе исходных данных контента; блок формировани FLUTE-потока, который формирует FLUTE-поток из сформированного потока фрагментов; блок создания SDP, который создает SDP, содержащий режим приема в случае, когда сторона приема принимает FLUTE-сеанс, содержащий FLUTE-поток; и блок многоадресной передачи, который передает FLUTE-поток посредством многоадресной FLUTE-передачи и перед передачей FLUTE-потока посредством многоадресной FLUTE-передачи передает SDP посредством многоадресной FLUTE-передачи
Блок создания SDP может создавать SDP, содержащий в качестве режима приема любого из Promiscuous, One-cop и Keep-обновленный.
Блок создания SDP может создавать SDP, содержащий в качестве режима приема любой из таких режимов, как Promiscuous, One-copy, Keep-обновленный, и комбинации Promiscuous, One-copy и Keep-обновленный.
Блок создания SDP может создавать SDP, дополнительно содержащий тип атрибута, указывающий, что сеанс FLUTE содержит элементарный поток типа одиночного медиа.
Устройство предоставления контента, соответствующее первому варианту настоящего раскрытия, может дополнительно содержать блок одноадресной передачи, который посредством одноадресной HTTP-передачи передает сформированный поток фрагментов.
В соответствии с первым вариантом настоящего раскрытия, способ предоставления контента устройства предоставления контента, которое доставляет контент посредством многоадресной FLUTE-передачи, содержит этапы, на которых: формируют посредством устройства предоставления контента поток фрагментов на основе исходных данных контента; формируют посредством устройства предоставления контента FLUTE-поток из сформированного потока фрагментов; создают SDP посредством устройства формирования контента, содержащий режим приема в случае, когда сторона приема принимает FLUTE-сеанс, содержащий FLUTE-поток; и передают посредством многоадресной FLUTE-передачи с помощью устройства предоставления контента FLUTE-поток и, перед передачей FLUTE-потока посредством многоадресной FLUTE-передачи, передают SDP посредством многоадресной FLUTE-передачи.
В соответствии с первым вариантом настоящего изобретения, программа заставляет компьютер, передающий контент посредством многоадресной FLUTE-передачи, функционировать как: блок формирования потока фрагментов, который формирует поток фрагментов на основе данных источника контента; блок формирования FLUTE-потока, который формирует FLUTE-поток из сформированного потока фрагментов; блок создания SDP, который создает SDP, содержащий режим приема в случае, когда сторона приема принимает FLUTE-сеанс, содержащий FLUTE-поток; и блок многоадресной передачи, который передает FLUTE-поток посредством многоадресной FLUTE-передачи и, перед передачей FLUTE-потока посредством многоадресной FLUTE-передачи, передает SDP посредством многоадресной FLUTE-передачи.
В первом варианте настоящего раскрытия поток фрагментов формируется на основе исходных данных контента, FLUTE-поток формируется из потока фрагментов, который сформирован, создается SDP, содержащий режим приема, когда сторона приема принимает FLUTE-сеанс, содержащий FLUTE-поток, и SDP передается посредством многоадресной FLUTE-передачи перед многоадресной FLUTE-передачей FLUTE-потока.
В соответствии со вторым вариантом настоящего раскрытия, оконечное устройство принимает и воспроизводит переданный посредством многоадресной FLUTE-передачи FLUTE-поток от устройства предоставления контента, содержащего блок формирования потока фрагментов, который формирует поток фрагментов на основе исходных данных контента, блок формирования FLUTE-потока, который формирует FLUTE-поток из сформированного потока фрагментов, блок создания SDP, который создает SDP, содержащий режим приема в случае, когда сторона приема принимает FLUTE-сеанс, содержащий FLUTE-поток, и блок многоадресной передачи, который передает FLUTE-поток посредством многоадресной FLUTE-передачи и до передачи FLUTE-потока посредством многоадресной FLUTE-передачи передает SDP посредством многоадресной FLUTE-передачи. Оконечное устройство получает SDP перед приемом FLUTE-потока и в соответствии с режимом приема, содержащимся в SDP, принимает FLUTE-поток.
В случае получения SDP до приема FLUTE-потока и режима приема, содержащегося в SDP, являющемся неупорядоченным, оконечное устройство, соответствующее второму варианту настоящего раскрытия, может принимать все пакеты FLUTE-сеанса, в том числе, FLUTE-поток.
Во втором варианте настоящего раскрытия SDP получают перед приемом FLUTE-потока, и в соответствии с режимом приема, содержащимся в SDP, принимается FLUTE-поток.
В соответствии с третьим вариантом настоящего раскрытия, система предоставления контента содержит: устройство предоставления контента и оконечное устройство. Устройство предоставления контента содержит блок формирования потока фрагментов, который формирует поток фрагментов на основе исходных данных контента, блок формирования FLUTE-потока, который формирует FLUTE-поток из сформированного потока фрагментов, блок создания SDP, который создает SDP, содержащий режим приема в случае стороны приема, принимающей FLUTE-сеанс, содержащий FLUTE-поток, и блок многоадресной передачи, которые передает FLUTE-поток посредством многоадресной FLUTE-передачи и перед передачей FLUTE-потока посредством многоадресной FLUTE-передачи передает SDP посредством многоадресной FLUTE-передачи. Оконечное устройство получает SDP перед приемом FLUTE-потока и в соответствии с режимом приема, содержащимся в SDP, принимает FLUTE-поток.
В третьем варианте настоящего раскрытия, посредством устройства предоставления контента формируется поток фрагментов на основе исходных данных контента, FLUTE-поток формируется из сформированного потока фрагментов, SDP, содержащий режим приема, когда сторона приема принимает FLUTE-сеанс, содержащий создание FLUTE-потока, и SDP передается посредством многоадресной FLUTE-передачи FLUTE-потока. Кроме того, с помощью оконечного устройства SDP получают перед приемом FLUTE-потока, и в соответствии с режимом приема, содержащимся в SDP, принимается FLUTE-поток.
Полезные результаты изобретения
В соответствии с первым вариантом настоящего раскрытия, можно уведомлять сторону приема, которая получает FLUTE-сеанс, о режиме приема.
В соответствии со вторым вариантом настоящего раскрытия, можно воспрепятствовать пропуску пакетов, передаваемых в FLUTE-сеансе.
В соответствии с третьим вариантом настоящего раскрытия, можно передавать поток контента посредством многоадресной FLUTE-передачи.
Краткое описание чертежей
Фиг. 1 - блок-схема примера построения традиционной системы предоставления контента.
Фиг. 2 - схема, в которой пакеты передаются во FLUTE-сеансе.
Фиг. 3 - блок-схема примера конфигурации системы предоставления контента, применяющей настоящее раскрытие.
Фиг. 4 - пример описания SDP.
Фиг. 5 - блок-схема последовательности выполнения операций процесса, выполняемого устройством предоставления контента.
Фиг. 6 - блок-схема примера конфигурации компьютера.
Осуществление изобретения
Здесь далее будет описан наилучший способ выполнения настоящего раскрытия (далее именуемого вариантом осуществления), но перед этим будет описана схема передаваемых пакетов во FLUTE-сеансе и схема настоящего варианта осуществления,
На фиг. 2 схематично представлена схема пакетов, передаваемых в FLUTE-сеансе. Как показано на чертеже, в FLUTE-сеансе, определяемом IP-адресом источника и TSI (Transport Session Identifier, транспортный идентификатор сеанса), передаются пакеты ALC/LCT. В каждом пакете ALC/LCT, например, хранится видеопоток или аудиопоток, и уникальный TOI (Transport Object Identifier, транспортный идентификатор объекта) задается в FLUTE-сеансе. Заметим, что указывается, что ТОI=0 задается для пакетов ALC/LCT, в которых помещается FDT (File Delivery Table, таблица доставки файлов). Для пакетов, в которых хранятся другие данные, когда источник данных один и тот же, задается общий TOI. Например, общий TOI задается для всех пакетов ALC/LCT, в которых видеопоток делится и сохраняется. Точно также, общий TOI задается для всех пакетов ALC/LCT, в которых аудиопоток делится и сохраняется.
Во время FLUTE-сеанса FDT периодически передается с информацией атрибута, связанной с данными, помещенными в пакеты ALC/LCT, кроме ТОI=0, и информацией для их реконструкции, описываемой в них.
Сторона, принимающая FLUTE-сеанс, получает TOI=0 FDT посредством FLUTE-сеанса и посредством анализа полученный FDT принимает требуемые пакеты ALC/LCT. Например, в случае желания принимать пакеты ALC/LCT, в которых помещается видеопоток, она анализирует FDT, подтверждает TOI для пакетов ALC/LCT, в которых помещается видеопоток, получает пакеты ALC/LCT, в которых TOI задается из FLUTE-сеанса, выполняет реконструкцию и воспроизведение.
Однако, в таком случае, во время сбора и анализа FDT пакеты ALC/LCT, в которые помещается желаемый видеопоток, не могут быть приняты, и, таким образом, невозможно их воспроизведение, может появиться желаемый видеопоток без выпадений. Это можно заметить, когда частота повторной передачи пакетов ALC/LCT низкая или когда повторная передача не выполняется такой, как во время живой потоковой передачи.
Поэтому в настоящем варианте осуществления, чтобы передать элементарный поток типа одиночного медиа с помощью FLUTE-сеанса, перед получением FLUTE-сеанса, используя SDP (Session Media Protocol, протокол медиасеанса) переданный на FLUTE-уровне представления, он пытается уведомить сторону приема о типе медиа и режиме приема.
Здесь в качестве режимов приема предполагаются три типа режимов Promiscuous, One-copy и Keep-update, которые определяются в проекте 3GPP.
Режим Promiscuous является режимом приема для стимулирования стороны приема принимать все пакеты ALC/LCT, которые передаются в FLUTE-сеансе. Уведомление об использовании режима Promiscuous принимается, когда, например, частота повторной передачи пакетов ALC/LCT низкая или когда повторная передача не выполняется, так как во время живой потоковой передачи.
Режим One-copy является режимом приема для уведомления стороны приема, что нет необходимости контролировать присутствие обновления в пакетах ALC/LCT, так как не существует передачи обновления для контента пакетов ALC/LCT, которые были когда-то переданы. Режим Keep-updated является режимом приема для уведомления стороны приема, что существует необходимость контроля наличия обновления для пакетов ALC/LCT, так как будет иметь место передача обновления для контента пакетов ALC/LCT, которые были когда-то переданы.
Кроме того, возможно добавление к режимам приема совокупностей вышеупомянутых трех типов режимов приема, например, Promiscuous+Keep-updated..
Пример конфигурации системы предоставления контента
На фиг. 3 показан пример конфигурации системы предоставления контента, которая является вариантом осуществления настоящего раскрытия.
Система 50 предоставления контента состоит от множества устройств 60 предоставления контента и множества оконечных устройств 80. Устройства 60 предоставления контента и оконечные устройства 80 могут соединяться через сеть 51.
Сеть 51 является сетью, содержащей, помимо сети двусторонней связи, представленной Интернетом и CDN, которая ее использует, различные широковещательные сети, использующие наземную широковещательную передачу, спутниковое вещание, и мобильную широковещательную передачу (e)MBMS.
Устройство 60 предоставления контента передает потоки контента как посредством одноадресной HTTP-передачи, так и посредством многоадресной FLUTE-передачи, и имеет канальный сервер 61, сегментатор 62, формирователь 63 MPD, FLUTE-стример 64, веб-сервер 65 и сервер 66 многоадресной передачи.
Заметим, что устройства с канального сервера 61 по сервер 66 многоадресной передачи, который входят в состав устройства 60 предоставления контента, могут быть расположены полностью в одном месте, но могут располагаться и распределенными по Интернету и т.п.
Канальный сервер 61 формирует множество данных потоковой передачи, отличающихся по скорости передачи от исходных данных контента для передачи оконечным устройствам 80, и выводит их на сегментатор 62.
Сегментатор 62 посредством временного разделения каждых данных потоковой передачи на сегменты, формирует сегментный поток, такой как фрагментированный поток МР4, и выводит сформированный сегментный поток сегмента на FLUTE-стример 64 и веб-сервер 65. Кроме того, сегментатор 62 уведомляет формирователь 63 метаданных MPD, содержащих адрес, который выражает источник предоставления файла сегментного потока.
FLUTE-стример 64 преобразует сегментные потоки, последовательно введенные от сегментатора 62, в FLUTE-потоки и выводит их на сервер 66 многоадресной передачи. Кроме того, FLUTE-стример 64 сохраняет MPD, сформированный формирователем 63 MPD в FLUTE-пакетах, и выводит их на сервер 66 многоадресной передачи. Дополнительно, FLUTE-стример 64 создает SDP, относящийся к FLUTE-сеансу, и выводит его на сервер 66 многоадресной передачи.
Формирователь 63 MPD, основываясь на метаданных, сообщенных от сегментатора 62, формирует MPD, который описывает адрес и т.п., выражающие источник предоставления файла сегментного потока, (веб-сервер 65), и выводит его на FLUTE-стример 64 и веб-сервер 65. В этом MPD описывается источник получения SDP, в котором описывается исходный IP-адрес FLUTE-сеанса FLUTE-потока, передаваемого посредством многоадресной FLUTE-передачи, переключаемой с сегментного потока, доставляемого посредством одноадресной HTTP-передачи.
Веб-сервер 65, в соответствии с запросом MPD (HTTP-запрос) от оконечного устройства 80, передает посредством одноадресной HTTP-передачи MPD, введенный от формирователя 63 MPD, источнику запроса. Кроме того, веб-сервер 65, в соответствии с запросом сегментного потока (HTTP-запрос) от оконечного устройства 80, посредством одноадресной HTTP-передачи передает файл сегментного потока источнику запроса.
Сервер 66 многоадресной передачи передает MPD посредством многоадресной FLUTE-передачи. Кроме того, сервер 66 многоадресной передачи передает SDP посредством многоадресной FLUTE-передачи. Кроме того, сервер 66 многоадресной передачи передает FLUTE-поток посредством многоадресной передачи FLUTE-потока.
Оконечное устройство 80 получает MPD от устройства 60 предоставления контента через сеть 51. Конкретно, оно передает HTTP-запрос и в ответ либо принимает MPD, передаваемый посредством одноадресной HTTP-передачи, либо принимает MPD, переданный посредством многоадресная FLUTE-передачи. Заметим, что когда оконечное устройство 80 принимает MPD, переданный посредством многоадресной FLUTE-передачи, ссылка делается на информацию объявления, содержащую портальный канал сервера 66 многоадресной передачи, выполняющий многоадресную FLUTE-передачу.
Информация объявления известна через канал взаимодействия или широковещательный канал /многоадресной передачи посредством USD (User Service Description, описание службы пользователя) в MBMS, когда многоадресная FLUTE-передача выполняется через мобильный широковещательный (e)MBMS, присутствующий в сети 51. Информация объявления известна через канал взаимодействия или широковещательный канал многоадресной передачи с помощью DVB-H (IPDC) ESG (Electronic Service Guide, руководство по электронной службе), когда многоадресная FLUTE-передача выполняется через наземную широковещательную передачу или через спутниковую широковещательную передачу, содержащуюся в сети 51.
Кроме того, оконечное устройство 80 запрашивает сегментный поток от вебсервера 65, основываясь на полученном MPD, и в ответ принимает и воспроизводит файл сегментного потока, переданный посредством многоадресной HTTP-передачи.
Кроме того, оконечное устройство 80 принимает SDP, основываясь на полученном MPD, и принимает и воспроизводит FLUTE-поток, переданный посредством многоадресной FLUTE-передачи, основываясь на SDP. В это время обращаются к режиму приема, описанному в SDP, и например, если режимом приема является Promiscuous, все пакеты ALC/LCT, передаваемые в соответствующем FLUTE-сеансе, немедленно принимаются.
Однако, поскольку возможно, что сторона приема не имеет достаточного буфера для хранения всех пакетов ALC/LCT, на усмотрение стороны приема оставляется, выполнять ли операцию, соответствующую режиму приема, о котором уведомил SDP.
Пример описания SDP
Далее на фиг. 4 показан пример описания SDP.
SDP состоит их описания сеанса и описания носителя, где каждое из них содержит множество строк, имеющих в качестве основной структуры одиночную текстовую строку в формате <type>=<value>. <type> определяется одним буквенным символом и во всем протоколе имеет тот смысл, который имеет строка.<value> является строкой символов, которая описывается и которая зависит от типа соответствующего <type>, уникальный формат и смысл которых соответственно указываются.
Например, смысл текста, описанного в <TYPE> описания сеанса, является следующим.
v = (версия протокола)
0 = (источник передачи и идентификатор сеанса)
s = (имя сеанса)
i = (информация сеанса)
а = (атрибут, относящийся ко всему сеансу)
t = (время, в течение которого сеанс активен),
Значение текста, описанного в <TYPE> описания носителя, является следующим.
m = (имя медиа и адрес передачи)
с = (информация о соединении - опция, когда содержится в опции пометки сеанса)
b = (информацию о запрете 0 или более строк),
а = (атрибут, относящийся к носителю)
В настоящем варианте осуществления классификация атрибута, определяемая форматом, показанным ниже, вводится в описание носителя.
a=single-fmt: <media> <encoding name> <receive mode>
<media> показывает тип медиа, описывая, например, видео, аудио и т.п.
<encoding name> показывает формат кодирования, и описывает Н.264, Н.261, GSM (зарегистрированная торговая марка) и т.п.
<promiscuous> показывает режим приема и описывается режим promiscuous, One-copy или Keep-updated. Заметим, что к режиму приема также можно добавить комбинацию, такую как Promiscuous + Keep-updated..
a=single-fmt:video Н264/9000 promiscouos, описанный в примере на фиг. 4, указывает, что типом медиа является видео, формат кодирования - Н.264, временной масштаб времени составляет 90 кГц, и режимом приема является promiscouos.
Заметим, что a=single-fmt:<media><encoding name><receive mode> может также быть введен в описание сеанса. В этом случае классификация атрибутов обрабатывается как информация, относящаяся ко всему FLUTE-сеансу.
Порядок работы системы 50 предоставления контента
Далее будет описан порядок работы системы 50 предоставления контента.
На фиг. 5 представлена блок-схема последовательности выполнения операций процесса, выполняемого устройством 60 предоставления контента, передающим сегментный поток контента посредством одноадресной HTTP-передачи и передающим FLUTE-поток посредством многоадресной FLUTE-передачи (здесь далее называемого процессом устройства предоставления контента).
На этапе S1 канальный сервер 61 формирует множество данных потоковой передачи со скоростями передачи, отличными от исходных данных контента, для передачи оконечному устройству 80 и выводит их на сегментатор 62. На этапе S2 сегментатор 62 формирует сегментный поток, такой как фрагментированный МР4, основываясь на каждых данных потоковой передачи, и выводит его на FLUTE-стример 64 и веб-сервер 65. Кроме того, сегментатор 62 информирует формирователь 63 MPD о метаданных, в том числе, об адресе, показывая источник предоставления сегментного потока.
На этапе S3 FLUTE-стример 64 преобразует сегментный поток, введенный от сегментатора 62, в FLUTE-поток и выводит его на сервер 66 многоадресной передачи. Кроме того, FLUTE-стример 64 сохраняет MPD, сформированный формирователем 63 MPD, в пакетах FLUTE и выводит их на сервер 66 многоадресной передачи. Кроме того, FLUTE-стример 64 формирует SDP, относящийся к FLUTE-сеансу, и выводит его на сервер 66 многоадресной передачи.
На этапе S4 формирователь 63 MDP формирует MPD, описывая адрес, выражающий источник предоставления (веб-сервер 65) файла сегментного потока, передаваемого посредством одноадресной HTTP-передачи, и источник получения SDP, в котором описывается исходный IP-адрес FLUTE-сеанса FLUTE-потока, передаваемого посредством многоадресной FLUTE-передачи, переключаемой с сегментного потока, и выводит его на сервер 66 многоадресной передачи.
На этапе S5 сервер 66 многоадаресной передачи передает MPD и SDP посредством многоадресной FLUTE-передачи.
На этапе S6 в случае, когда существует запрос MPD от оконечного устройства 80, веб-сервер 65 передает посредством одноадресной HTTP-передачи MPD, введенный от формирователя 63 MPD, источнику запроса.
Когда оконечное устройство 80, которое приняло MPD, выдает HTTP-запрос, запрашивающий сегментный поток, основываясь на MPD, на этапе S7 веб-сервер 65 посредством одноадресной HTTP-передачи передает источнику запроса файл запрошенного сегментного потока. Сегментный поток, переданный посредством одноадресной HTTP-передачи, принимается и воспроизводится оконечным устройством 80.
С другой стороны, сервер 66 многоадресной передачи на этапе S8 передает посредством многоадресной FLUTE-передачи FLUTE-поток. FLUTE-сеанс, содержащий FLUTE-поток, передаваемый посредством многоадресной FLUTE-передачи, принимается и воспроизводится оконечным устройством 80, которое получает SDP, основываясь на полученном MPD, и анализируется SDP, и при этом делается ссылка на режим приема, описанный в SDP. Конкретно, когда режимом приема является Promiscuous, все пакеты ALC/LCT, переданные посредством соответствующего FLUTE-сеанса, немедленно принимаются перед получением и анализом FDT. Однако, на усмотрение стороны приема оставляется, выполнять или не выполнять операцию, соответствующую режиму приема, сообщенному посредством SDP, и сторона предоставления не может принудительно управлять работой оконечного устройства 80.
Как описано выше, в соответствии с процессом, выполняемым устройством предоставления контента, перед тем, как оконечное устройство 80 начнет прием FLUTE-сеанса, возможно уведомить оконечное устройство 80 о режиме приема, пригодном для приема. Поэтому можно запретить пропуск пакетов ALC/LCT на стороне оконечного устройства 80. Кроме того, поскольку это уведомление не является что-то таким, что принудительно управляет работой стороны оконечного устройства 80, возможно запретить переключение состояния, так чтобы буфер на стороне оконечного устройства 80 переполнялся.
Устройство 60 предоставления контента, выполняющее ряд процессов, описанных выше, и оконечное устройство 80 могут быть реализованы с помощью компьютерного программного обеспечения в дополнение к их осуществлению с помощью аппаратурного обеспечения. Компьютер, использующий специализированное аппаратурное обеспечение, или, например, универсальный персональный компьютер и т.п., способные выполнять различных функций с помощью установки различных программ, содержатся в таком компьютере.
На фиг. 6 приведена блок-схема примера конфигурации аппаратурного обеспечения упомянутого выше компьютера.
В компьютере 200 CPU (центральный процессор) 201, ROM (постоянная память) 202 и RAM (оперативная память) 203 соединяются друг с другом шиной 204.
Интерфейс 205 ввода-вывода также соединяется с шиной 204. Устройство 206 ввода, устройство 207 вывода, запоминающее устройство 208, блок 209 связи и привод 210 соединяются с интерфейсом 205 ввода-вывода.
Устройство 206 ввода содержит клавиатуру, мышь, микрофон и т.п. Устройство 207 вывода содержит дисплей, громкоговоритель и т.п. Запоминающее устройство 208 содержит жесткий диск, энергонезависимую память и т.п. Блок 209 связи содержит сетевой интерфейс и т.п. Привод 210 приводит в движение съемный носитель 211, такой как магнитный диск, оптический диск, магнитно-оптический диск или полупроводниковая память.
В компьютере 200, который построен упомянутым выше способом, CPU 201 загружает и исполняет программу, хранящуюся в запоминающем устройстве 208, через интерфейс 205 ввода-вывода и шину 204, посредством чего выполняется упомянутый выше ряд процессов.
Программа, выполняемая компьютером 200 (CPU 201), может обеспечиваться посредством записи, например, на съемных носителях 211, таких как пакет носителей. Альтернативно, программа может быть предоставлена через проводную или беспроводную среду передачи, такую как локальная сеть, Интернет и цифровая спутниковая широковещательная передача.
Программа может быть установлена в запоминающем устройстве 208 через интерфейс 205 ввода-вывода, загружая съемные носители 211 на привод 210. Кроме того, программа может быть принята блоком 209 связи через проводную или беспроводную среду передачи и установлена в блоке 208 запоминающего устройства. Кроме того, программа может также быть установлена заранее в ROM 202 или в запоминающее устройство 208.
Программа, исполняемая компьютером 200, может быть программой, в которой процесс выполняется в хронологическом порядке в последовательности, описанной в настоящем описании, или программой, в которой процесс выполняется параллельно или с заданной синхронизацией, то есть, когда она вызывается.
Вариант осуществления настоящего раскрытия не ограничивается описанным выше вариантом осуществления и может допускать различные изменения в рамках объема настоящего раскрытия.
Дополнительно, настоящая технология может также быть выполнена нижеследующим образом.
(1)
Устройство предоставления контента, которое передает контент посредством многоадресной FLUTE-передачи, причем упомянутое устройство предоставления контента содержит:
блок формирования потока фрагментов, который формирует поток фрагментов на основе исходных данных контента;
блок формирования FLUTE-потока, который формирует FLUTE-поток из сформированного потока фрагментов;
блок создания SDP, который создает SDP, содержащий режим приема в случае, когда сторона приема принимает FLUTE-сеанс, содержащий FLUTE-поток; и
блок многоадресной передачи, который передает FLUTE-поток посредством многоадресной FLUTE-передачи и до передачи FLUTE-потока посредством многоадресной FLUTE-передачи передает SDP посредством многоадресной FLUTE-передачи.
(2)
Устройство предоставления контента по п. (1), в котором
блок создания SDP создает SDP, содержащий в качестве режима приема любой из таких режимов, как Promiscuous, One-copy и Keep-updated.
(3)
Устройство предоставления контента по п. (1), в котором
блок создания SDP создает SDP, содержащий в качестве режима приема любой из таких режимов, как Promiscuous, One-copy, Keep-updated и сочетания таких режимов Promiscuous, One-copy, Keep-updated.
(4)
Устройство предоставления контента по любому из пп. (1)-(3), в котором блок создания SDP создает SDP, дополнительно содержащий тип атрибута, показывающий, что FLUTE-сеанс содержит элементарный поток одномедийного типа.
(5)
Устройство предоставления контента по любому из пп. (1)-(4), дополнительно содержащее:
блок одноадресной передачи, который передает посредством одноадресной HTTP-передачи сформированный поток фрагментов.
Перечень ссылочных позиций
50 Система предоставления контента
51 Сеть
60 Устройство предоставления контента
61 Канальный сервер
62 Сегментатор
63 Формирователь
64 FLUTE-стример
65 Веб-сервер
66 Сервер многоадресной передачи
80 Оконечное устройство
200 Компьютер
201 Центральный процессор, CPU

Claims (35)

1. Устройство предоставления контента, характеризующееся тем, что выполнено с возможностью передачи контента посредством многоадресной FLUTE-передачи, причем упомянутое устройство предоставления контента содержит:
блок формирования потока фрагментов, выполненный с возможностью формирования потока фрагментов на основе исходных данных контента;
блок формирования FLUTE-потока, выполненный с возможностью формирования FLUTE-потока из сформированного потока фрагментов;
блок создания протокола (SDP) медиасеанса, выполненный с возможностью создания SDP, содержащего режим приема; и
блок многоадресной передачи, выполненный с возможностью передачи для каждого из FLUTE-сеансов FLUTE-потока, соответствующего элементарному потоку одномедийного типа, посредством многоадресной FLUTE-передачи и передачи, до передачи FLUTE-потока посредством многоадресной FLUTE-передачи, SDP посредством многоадресной FLUTE-передачи,
при этом блок создания SDP выполнен с возможностью создания SDP, содержащего в качестве режима приема любой из следующих режимов: Promiscuous, One-copy и Keep-updated, при этом режим Promiscuous является режимом приема для стимулирования стороны приема принимать все пакеты ALC/LCT, которые передаются в FLUTE-сеансе, режим One-copy является режимом приема для уведомления стороны приема, что нет необходимости контролировать присутствие обновления в пакетах ALC/LCT, и режим Keep-updated является режимом приема для уведомления стороны приема, что существует необходимость контроля наличия обновления для пакетов ALC/LCT.
2. Устройство предоставления контента по п. 1, в котором
блок создания SDP выполнен с возможностью создания SDP, дополнительно содержащего сочетания режимов Promiscuous, One-copy и Keep-updated.
3. Устройство предоставления контента по п. 1, в котором
блок создания SDP выполнен с возможностью создания SDP, дополнительно содержащего тип атрибута, показывающий, что FLUTE-сеанс содержит элементарный поток одномедийного типа.
4. Устройство предоставления контента по п. 1, дополнительно содержащее:
блок одноадресной передачи, выполненный с возможностью передачи посредством одноадресной HTTP-передачи сформированного потока фрагментов.
5. Способ предоставления контента устройства предоставления контента, передающего контент посредством многоадресной FLUTE-передачи, причем упомянутый способ предоставления контента содержит этапы, на которых:
формируют поток фрагментов посредством устройства предоставления контента на основе исходных данных контента;
формируют FLUTE-поток посредством устройства предоставления контента из сформированного потока фрагментов;
создают протокол (SDP) медиасеанса посредством устройства предоставления контента, содержащий режим приема; и
передают с помощью устройства предоставления контента для каждого из FLUTE-сеансов FLUTE-поток, соответствующий элементарному потоку одномедийного типа, посредством многоадресной FLUTE-передачи и передают, до передачи FLUTE-потока посредством многоадресной FLUTE-передачи, SDP посредством многоадресной FLUTE-передачи,
при этом на этапе создания SDP создают SDP, содержащий в качестве режима приема любой из следующих режимов: Promiscuous, One-copy и Keep-updated, при этом режим Promiscuous является режимом приема для стимулирования стороны приема принимать все пакеты ALC/LCT, которые передаются в FLUTE-сеансе, режим One-copy является режимом приема для уведомления стороны приема, что нет необходимости контролировать присутствие обновления в пакетах ALC/LCT, и режим Keep-updated является режимом приема для уведомления стороны приема, что существует необходимость контроля наличия обновления для пакетов ALC/LCT.
6. Носитель записи, содержащий программу, вызывающую выполнение компьютером, передающим контент посредством многоадресной FLUTE-передачи, функций:
блока формирования потока фрагментов, выполненного с возможностью формирования потока фрагментов на основе исходных данных контента;
блока формирования FLUTE-потока, выполненного с возможностью формирования FLUTE-потока из сформированного потока фрагментов;
блока создания протокола (SDP) медиасеанса, выполненного с возможностью создания SDP, содержащего режим приема; и
блока многоадресной передачи, выполненного с возможностью передачи для каждого из FLUTE-сеансов FLUTE-потока, соответствующего элементарному потоку одномедийного типа, посредством многоадресной FLUTE-передачи и передачи, до передачи FLUTE-потока посредством многоадресной FLUTE-передачи, SDP посредством многоадресной FLUTE-передачи,
при этом блок создания SDP выполнен с возможностью создания SDP, содержащего в качестве режима приема любой из следующих режимов: Promiscuous, One-copy и Keep-updated, при этом режим Promiscuous является режимом приема для стимулирования стороны приема принимать все пакеты ALC/LCT, которые передаются в FLUTE-сеансе, режим One-copy является режимом приема для уведомления стороны приема, что нет необходимости контролировать присутствие обновления в пакетах ALC/LCT, и режим Keep-updated является режимом приема для уведомления стороны приема, что существует необходимость контроля наличия обновления для пакетов ALC/LCT.
7. Устройство приема, характеризующееся тем, что выполнено с возможностью приема и воспроизведения FLUTE-потока, передаваемого посредством многоадресной FLUTE-передачи от устройства предоставления контента, причем устройство приема выполнено с возможностью
запроса описания (MDP) медиапрезентации посредство одноадресной HTTP-передачи;
приема MPD посредством одноадресной HTTP-передачи;
запроса сегментного потока контента на основе принятого MPD посредством одноадресной HTTP-передачи;
приема и воспроизведения сегментного потока посредством одноадресной HTTP-передачи;
получения протокола (SDP) медиасеанса, содержащего режим приема от FLUTE-сеанса, содержащего FLUTE-поток контента;
при этом устройство приема выполнено с возможностью получения SDP до приема FLUTE-потока и приема FLUTE-потока в соответствии с режимом приема, содержащимся в SDP,
при этом SDP содержит в качестве режима приема любой из следующих режимов: Promiscuous, One-copy и Keep-updated, при этом режим Promiscuous является режимом приема для стимулирования стороны приема принимать все пакеты ALC/LCT, которые передаются в FLUTE-сеансе, режим One-copy является режимом приема для уведомления стороны приема, что нет необходимости контролировать присутствие обновления в пакетах ALC/LCT, и режим Keep-updated является режимом приема для уведомления стороны приема, что существует необходимость контроля наличия обновления для пакетов ALC/LCT.
8. Система предоставления контента, содержащая:
устройство предоставления контента по любому из пп. 1–4; и
устройство приема по п. 7.
RU2016105844A 2013-08-26 2014-08-12 Устройство предоставления контента, программа, оконечное устройство и система предоставления контента RU2658672C2 (ru)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2013-174133 2013-08-26
JP2013174133A JP2015043484A (ja) 2013-08-26 2013-08-26 コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
PCT/JP2014/071262 WO2015029768A1 (ja) 2013-08-26 2014-08-12 コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム

Publications (2)

Publication Number Publication Date
RU2016105844A RU2016105844A (ru) 2017-08-24
RU2658672C2 true RU2658672C2 (ru) 2018-06-22

Family

ID=52586337

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2016105844A RU2658672C2 (ru) 2013-08-26 2014-08-12 Устройство предоставления контента, программа, оконечное устройство и система предоставления контента

Country Status (9)

Country Link
US (2) US10045094B2 (ru)
EP (1) EP3041242B1 (ru)
JP (1) JP2015043484A (ru)
CN (1) CN105474648B (ru)
BR (1) BR112016003593B1 (ru)
CA (1) CA2919977C (ru)
MX (2) MX364746B (ru)
RU (1) RU2658672C2 (ru)
WO (1) WO2015029768A1 (ru)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10015235B2 (en) * 2014-10-23 2018-07-03 Sprint Communications Company L.P. Distribution of media content to wireless communication devices

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060015568A1 (en) * 2004-07-14 2006-01-19 Rod Walsh Grouping of session objects
WO2007068290A1 (en) * 2005-12-13 2007-06-21 Telefonaktiebolaget Lm Ericsson (Publ) Technique for distributing content via different bearer types
RU2438245C2 (ru) * 2006-09-14 2011-12-27 Нокиа Корпорейшн Динамическое обновление sdp при широковещательной передаче данных по протоколу ip в системе dvb-h
US20130182643A1 (en) * 2012-01-16 2013-07-18 Qualcomm Incorporated Method and system for transitions of broadcast dash service receptions between unicast and broadcast

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101459664B (zh) * 2007-10-22 2010-10-20 华为技术有限公司 一种获取iptv业务媒体描述信息的方法及装置
WO2009151265A2 (ko) * 2008-06-09 2009-12-17 엘지전자(주) 방송 신호 수신 방법 및 수신 시스템
WO2010058958A2 (ko) * 2008-11-18 2010-05-27 엘지전자 주식회사 비실시간 서비스 처리 방법 및 방송 수신기
CN101771662B (zh) * 2008-12-30 2012-11-07 华为技术有限公司 网络电视架构中下载业务信息的获取方法、装置及系统
WO2010128491A1 (en) * 2009-05-08 2010-11-11 Nokia Corporation Method and apparatus for configuring presentation of service guides
PL2497267T3 (pl) * 2009-11-03 2015-02-27 Ericsson Telefon Ab L M Strumieniowanie z opcjonalną rozgłoszeniową transmisją segmentów danych
US8411608B2 (en) * 2010-02-26 2013-04-02 Microsoft Corporation Efficient and reliable multicast over a Wi-Fi network
KR101702562B1 (ko) * 2010-06-18 2017-02-03 삼성전자 주식회사 멀티미디어 스트림 파일의 저장 파일 포맷, 저장 방법 및 이를 이용한 클라이언트 장치
US9485108B2 (en) * 2011-03-14 2016-11-01 Qualcomm Incorporated System and apparatus for using multichannel file delivery over unidirectional transport (“FLUTE”) protocol for delivering different classes of files in a broadcast network
CN103535046B (zh) * 2011-04-20 2017-02-15 Lg电子株式会社 用于广播服务的发送方法、接收方法及其接收设备
KR101719998B1 (ko) * 2011-12-12 2017-03-27 엘지전자 주식회사 미디어 컨텐트를 수신하는 장치 및 방법
US9137621B2 (en) * 2012-07-13 2015-09-15 Blackberry Limited Wireless network service transaction protocol
US9357272B2 (en) * 2012-08-03 2016-05-31 Intel Corporation Device orientation capability exchange signaling and server adaptation of multimedia content in response to device orientation
US9883247B2 (en) * 2012-08-13 2018-01-30 Saturn Licensing Llc Reception apparatus, reception method, transmission apparatus, and transmission method
US8923880B2 (en) * 2012-09-28 2014-12-30 Intel Corporation Selective joinder of user equipment with wireless cell
US9900166B2 (en) * 2013-04-12 2018-02-20 Qualcomm Incorporated Methods for delivery of flows of objects over broadcast/multicast enabled networks
US9781181B2 (en) * 2013-06-17 2017-10-03 Qualcomm Incorporated Multiple file delivery over unidirectional transport protocol sessions for a service

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060015568A1 (en) * 2004-07-14 2006-01-19 Rod Walsh Grouping of session objects
WO2007068290A1 (en) * 2005-12-13 2007-06-21 Telefonaktiebolaget Lm Ericsson (Publ) Technique for distributing content via different bearer types
RU2438245C2 (ru) * 2006-09-14 2011-12-27 Нокиа Корпорейшн Динамическое обновление sdp при широковещательной передаче данных по протоколу ip в системе dvb-h
US20130182643A1 (en) * 2012-01-16 2013-07-18 Qualcomm Incorporated Method and system for transitions of broadcast dash service receptions between unicast and broadcast

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
COLIN PERKINS, Re: [MMUSIC] SDP Session Description for FLUTE Sessions, 06 May 2004, найдено в Интернет на URL: https://www.ietf.org/mail-archive/web/mmusic/current/msg02446.html. *
Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs (Release 11), 3GPP TS 26.346, V11.5.0, 2013-06. *

Also Published As

Publication number Publication date
RU2016105844A (ru) 2017-08-24
EP3041242B1 (en) 2018-12-19
MX364746B (es) 2019-05-06
US20180270546A1 (en) 2018-09-20
CN105474648B (zh) 2019-07-05
US20160192036A1 (en) 2016-06-30
CA2919977C (en) 2022-05-31
MX2016002147A (es) 2016-06-23
CN105474648A (zh) 2016-04-06
JP2015043484A (ja) 2015-03-05
EP3041242A1 (en) 2016-07-06
WO2015029768A1 (ja) 2015-03-05
EP3041242A4 (en) 2017-03-29
BR112016003593A2 (ru) 2017-08-01
US10045094B2 (en) 2018-08-07
CA2919977A1 (en) 2015-03-05
MX2019005175A (es) 2019-08-12
BR112016003593B1 (pt) 2023-05-02

Similar Documents

Publication Publication Date Title
JP6329964B2 (ja) 送信装置、送信方法、受信装置、及び、受信方法
JP2014230055A (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
WO2014208377A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
KR102137858B1 (ko) 송신 장치, 송신 방법, 수신 장치, 수신 방법 및 프로그램
US10623463B2 (en) Content supplying apparatus, content supplying method, program, terminal device, and content supplying system
JP6597604B2 (ja) 受信装置、送信装置、データ通信方法、およびデータ処理方法
JP6466850B2 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
RU2658672C2 (ru) Устройство предоставления контента, программа, оконечное устройство и система предоставления контента
KR20160058756A (ko) 콘텐츠 공급 장치, 콘텐츠 공급 방법, 프로그램, 단말 장치 및 콘텐츠 공급 시스템
US11075855B2 (en) Content supply device, content supply method, program, terminal device, and content supply system
WO2015064384A1 (ja) 送信装置、送信方法、受信装置、及び、受信方法