RU2627303C2 - Система и способ для адаптивной потоковой передачи в среде с несколькими путями передачи - Google Patents

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

Info

Publication number
RU2627303C2
RU2627303C2 RU2012152900A RU2012152900A RU2627303C2 RU 2627303 C2 RU2627303 C2 RU 2627303C2 RU 2012152900 A RU2012152900 A RU 2012152900A RU 2012152900 A RU2012152900 A RU 2012152900A RU 2627303 C2 RU2627303 C2 RU 2627303C2
Authority
RU
Russia
Prior art keywords
servers
bit rate
client
server
controller
Prior art date
Application number
RU2012152900A
Other languages
English (en)
Other versions
RU2012152900A (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 RU2012152900A publication Critical patent/RU2012152900A/ru
Application granted granted Critical
Publication of RU2627303C2 publication Critical patent/RU2627303C2/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/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/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • 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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2665—Gathering content from different sources, e.g. Internet and satellite
    • 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/637—Control signals issued by the client directed to the server or network components
    • H04N21/6373—Control signals issued by the client directed to the server or network components for rate control, e.g. request to the server to modify its transmission rate
    • 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/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • 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/631—Multimode Transmission, e.g. transmitting basic layers and enhancement layers of the content over different transmission paths or transmitting with different error corrections, different keys or with different transmission protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • Astronomy & Astrophysics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Abstract

Изобретение относится к адаптивной потоковой передаче в среде с несколькими путями передачи. Техническим результатом является улучшение эффективности потоковой передачи мультимедийного контента. Предложена система для осуществления передачи мультимедийного контента путем использования технологии многоканальной адаптивной потоковой передачи в сетевой среде, содержащая множество серверов (14, 16, 18), являющихся соответственно способными передавать мультимедийный контент в среде RTP/RTSP по соответственному каналу (20, 22, 24) передачи данных на клиент (12), причем клиент (12) включает в себя средство (40) контроллера, приспособленное зондировать каждый канал из упомянутых каналов (20, 22, 24) передачи данных, чтобы определять соответственную полосу пропускания, связанную с каждым из упомянутых каналов (20, 22, 24) передачи данных, и запрашивать порцию упомянутого мультимедийного контента для каждого из упомянутых серверов (14, 16, 18) согласно соответственной полосе пропускания. 2 н. и 13 з.п. ф-лы, 7 ил.

Description

ВВЕДЕНИЕ
Данное изобретение относится к системе для адаптивной потоковой передачи в среде с несколькими путями передачи. Более конкретно, данное изобретение относится к системе для осуществления адаптивной потоковой передачи в многопутевой среде, в которой условия пропускной способности сети не гарантируются и, следовательно, изменяются, чтобы улучшить потоковую передачу аудио/видео. Кроме того, изобретение относится к способу для адаптивной потоковой передачи в многопутевой среде.
ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ
Потоковая передача является процессом, когда используемый клиентом контент посылается на клиент малыми частями, в противоположность загрузке по сети, когда мультимедийный файл целиком передается на клиент до воспроизведения. Существующие протоколы потоковой передачи включают в себя протокол передачи данных в реальном масштабе времени (RTP) или протокол транспортного потока стандарта MPEG (Экспертная группа по вопросам движущегося изображения) на основе передачи дейтаграмм пользователя (MPEG TS/UDP). С другой стороны, загрузка по сети обычно выполняется с использованием протокола передачи гипертекста (протокола HTTP).
В системах развлекательных услуг и связи обеспечивается протокол потоковой передачи в реальном масштабе времени (протокол RTSP) в качестве протокола управления сетью, чтобы управлять серверами потокового мультимедиа. Передача потоковых данных посредством серверов с поддержкой RTSP выполняется по протоколу передачи данных в реальном масштабе времени (RTP). Протокол RTSP задает управляющие последовательности, используемые в управлении воспроизведением потоковых данных. Управляющие последовательности определены в стандарте RFC 2326 комитетом по инженерным вопросам сети Интернет (IETF).
Сеанс потоковой передачи инициируется клиентом в направлении сервера потоковой передачи. Сервер потоковой передачи доставляет запрошенное видео по одноадресной связи на клиент. Установление сеанса потоковой передачи предусматривает несколько сообщений протокола RTSP между клиентом и сервером потоковой передачи, обычно включающих в себя выбор контента и указание характеристик клиента, таких как размеры экрана, скорость передачи битов (цифрового потока) или максимальный размер буфера. Сеанс одноадресной потоковой передачи по RTP окончательно устанавливается с использованием предварительно согласованных параметров. Параметры сеанса потоковой передачи обычно остаются неизменными, пока клиент не выберет дополнительный контент или не завершит сеанс потоковой передачи. Очевидно, этот тип среды не является хорошо приспособленным к изменяющимся характеристикам сети. Некоторые операторы просто предпочитают ограничивать доступ к некоторым услугам для клиентов, имея достаточную дополнительную полосу пропускания сверх фактической требуемой полосы пропускания, чтобы избежать проблем.
Потоковая передача в реальном времени стала в возрастающей степени популярной для передачи телевизионных (TV) каналов через сеть Интернет (IP-телевидение, IPTV). Однако должно обеспечиваться средство для решения проблемы изменяющихся скоростей полосы пропускания между поставщиком мультимедиа и клиентом. Иначе будет происходить "застывание" мультимедийных потоков, которое обычно рассматривается потребителем как раздражающая помеха.
Были предприняты различные усилия по отношению к решению вышеупомянутой проблемы изменяющихся скоростей полосы пропускания.
В патентном документе WO 2002/073441 A1 одиночный файл разделяется на множественные под-файлы, которые последовательно распределяются и сохраняются на одном или нескольких серверах. Под-файлы могут передаваться параллельно и одновременно от одного или нескольких серверов, что повышает скорость, с которой могут доставляться данные. Кроме того, по меньшей мере, один из под-файлов может сохраняться более чем на одном сервере, чтобы обеспечивать избыточность. Если сервер не является доступным, или если линия передачи является медленной или недоступой, под-файл может передаваться потоком от другого сервера.
В патентном документе US 2009/0259762 A1 показана распределенная и масштабируемая архитектура потоковой передачи контента, которая включает в себя множество контроллеров и множество серверов. Контроллеры действуют с возможностью устанавливать сеансы по протоколу потоковой передачи в реальном времени (RTSP) с отдельными устройствами. Контроллер выбирает сервер, чтобы поставлять запрошенный поток мультимедиа на устройство. Сервер может выбираться на основании его близости к устройству, доступности полосы пропускания или характеристик задержки передачи. Дополнительные серверы могут добавляться к системе без нарушения работы системы.
В патентном документе WO 2010/111261 A1 показана система потоковой передачи мультимедиа, которая использует динамическую адаптацию скорости передачи. Она включает в себя формат файла, совместимый с существующей инфраструктурой протокола HTTP, для доставки мультимедиа по возобновляемому соединению. Существующие клиентские мультимедийные проигрыватели способны динамически изменять кодированную скорость доставки мультимедиа по возобновляемому соединению.
В патентном документе US 2010/0094955 A1 показано распределенное хранилище, в котором для каждой группы из, по меньшей мере, одного выполняющего сборку устройства, выбирается подгруппа серверов CDN (сеть доставки контента) частичного хранения согласно, по меньшей мере, одному критерию. Множество подгрупп серверов выбирается для множества групп выполняющих сборку устройств. Кодированные со стиранием фрагменты, связанные со множественными сегментами контента, извлекаются выполняющими сборку устройствами из подгрупп серверов, пока суммарная полоса пропускания, используемая для извлечения фрагментов, не достигнет суммарной полосы пропускания серверов, включенных в подгруппы, и до тех пор, пока суммарная полоса пропускания, используемая для доставки каждого сегмента, не превысит суммарную полосу пропускания для серверов, хранящих фрагменты, сформированные на основе сегмента.
В патентном документе US 2006/0215596 A1 показаны регулировки скорости пересылки для устройства, например, мультимедийного сервера. Эти регулировки скорости основываются на определении посредством мультимедийного сервера различных параметров качества обслуживания исходя из линии радиосвязи между двумя другими сетевыми узлами, которые могут содержать точку доступа и видеопроигрыватель, соответственно.
В документе US6405256 B1 потоковая передача данных раскрывается относительно сетевого сервера, соединенного с клиентским устройством по сети связи с наличием одного или нескольких поддерживающих кэширование серверов. Сетевой сервер содержит приложение потоковой передачи данных и запоминающее устройство для хранения данных. Ряд соединений, каждое использует схему потоковой передачи данных, образуется серверами с кэшированием в тракте передачи между исходной сетью и клиентским устройством. Каждый сервер с кэшированием может принимать на себя перегрузку сети в своем нисходящем к клиенту соединении путем использования расширяемого буфера для хранения дополнительных сегментов передаваемых потоком данных и изменения скорости передачи данных в нисходящем к клиенту соединении.
Кроме того, в Проекте партнерства в области систем связи третьего поколения (3GPP) стандартизирована инфраструктура доставки, включающая в себя формат контейнера, способный сохранять несколько версий (которые должны иметь скорости передачи битов различного кодирования) одинакового контента, который в связке с интеллектуальной управляющей логикой на стороне сервера потоковой передачи поможет решить проблему изменчивости условий сети. Эта управляющая логика, однако, не была описана проектом 3GPP.
Потоковая передача по протоколу HTTP является технологией, недавно объявленной корпорацией Apple относительно iPhone, корпорацией Microsoft относительно Smoothstreaming (плавная потоковая передача) или проектом 3GPP относительно его адаптивной потоковой передачи по протоколу HTTP. Недавние способы используют протокол HTTP, чтобы периодически обеспечивать обратную связь от клиента на сервер о текущих условиях сети. Адаптивный контент, представляющий малые порции (chunk: порция мультимедиа с описанием) мультимедийного контента фиксированной длительности, но с переменной скоростью передачи битов, подают на соответствующий клиент, при этом постоянно адаптируя к условиям сети.
Очевидный недостаток состоит в том, что качество, воспринимаемое клиентом, может значительно ухудшаться, если меняется полоса пропускания. Кроме того, эти способы не используют существующую аппаратуру IPTV, основывающуюся на протоколах RTP/RTSP.
Соответственно, в области техники имеется потребность в обеспечении способа и системы для адаптивной потоковой передачи в многопутевой среде, которые соответственно устраняют, по меньшей мере, частично, недостатки, связанные с системами предшествующего уровня техники.
КРАТКОЕ ОПИСАНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ
Согласно изобретению, обеспечивается система для адаптивной потоковой передачи в среде с несколькими путями передачи, содержащая множество серверов, являющихся соответственно способными передавать мультимедийный контент в среде RTP/RTSP по соответственному каналу передачи данных на клиент, причем клиент включает в себя средство контроллера, способное зондировать каждый из упомянутых каналов передачи данных, чтобы определять соответственную полосу пропускания, связанную с каждым из упомянутых каналов передачи данных, и запрашивать порцию упомянутого мультимедийного контента для каждого из упомянутых серверов согласно соответственной полосе пропускания.
Согласно варианту осуществления изобретения, средство контроллера включает в себя средство для оценки пропускной способности канала, способное выполнять управление скоростью сервера, измерение полосы пропускания и оценку полосы пропускания для каждого соответственного сервера и канала передачи данных.
Согласно дополнительному варианту осуществления изобретения, средство контроллера включает в себя средство для планирования порции, способное выполнять выбор скорости передачи битов для следующей порции мультимедиа, подлежащей доставке посредством соответственного сервера.
Согласно дополнительному варианту осуществления изобретения, средство контроллера включает в себя средство для распределения контейнера (bin), способное связывать конкретную порцию мультимедиа одного из серверов с контейнером, выделяемым из структуры «связный список», для получения корректной очередности использования.
Согласно дополнительному варианту осуществления изобретения, средство контроллера включает в себя средство для перенумерации и переопределения временных отметок по протоколу RTP, способное обновлять временные отметки и порядковые номера RTP, так что декодер не может отличать поток, принимаемый от нескольких серверов, от потока, принимаемого от одиночного сервера.
В дополнительном аспекте изобретения, обеспечивается способ адаптивной потоковой передачи в многопутевой среде, который содержит обеспечение клиента и обеспечение множества серверов, соответственно способных передавать мультимедийный контент в среде RTP/RTSP по соответственному каналу передачи данных на клиент, причем клиент включает в себя средство контроллера, способное зондировать каждый из упомянутых каналов передачи данных, чтобы определить соответственную полосу пропускания, связанную с каждым из упомянутых каналов передачи данных, и запрашивать порцию упомянутого мультимедийного контента для каждого из упомянутых серверов согласно соответственной полосе пропускания.
Согласно варианту осуществления изобретения, средство контроллера включает в себя средство для оценки пропускной способности канала, чтобы выполнять управление скоростью сервера, измерение полосы пропускания и оценку полосы пропускания параллельно для каждого из серверов, используемых в сеансе многопутевой потоковой передачи.
Согласно варианту осуществления изобретения, оценку пропускной способности канала периодически повторяют.
Согласно варианту осуществления изобретения, оценка пропускной способности канала управляет скоростью каждого сервера путем добавления стандартного атрибута запроса на передачу (RTS) скорости к запросу воспроизведения с тем, чтобы определять, выдержит ли соответственный канал передачи данных передачу со скоростью выше текущей скорости.
Согласно варианту осуществления изобретения, текущая скорость передачи, предназначенная для каждого сервера, затем используется алгоритмом сглаживания, чтобы итеративно определять надежную оценку для выведения достижимой скорости передачи битов исходя из скорости передачи битов, измеренной в течение предыдущих итераций.
Согласно варианту осуществления изобретения, для каждого сервера вычисляется дисперсия текущей скорости передачи.
Согласно варианту осуществления изобретения, средство контроллера включает в себя средство для планирования порции мультимедиа, способное выполнять выбор скорости передачи битов для следующей порции, подлежащей доставке посредством соответственного сервера.
Согласно варианту осуществления изобретения, отдельные оценки скорости передачи битов суммируются для всех серверов, чтобы получить суммарную скорость передачи битов, и скоростью воспроизведения порции мультимедиа выбирают скорость передачи битов с кодированием, которая непосредственно ниже суммарной скорости передачи битов.
Согласно варианту осуществления изобретения, средство контроллера включает в себя средство для распределения контейнера, способное связывать конкретную порцию мультимедиа одного из серверов с контейнером, распределяемым из связного списка, для получения корректной очередности использования.
Согласно варианту осуществления изобретения, средство контроллера включает в себя средство для перенумерации и переопределения временных отметок по RTP, способное обновлять временные отметки и порядковые номера RTP, так что декодер не может отличить поток, принимаемый от множества серверов, от потока, принимаемого от одиночного сервера.
Изобретение предлагает механизм, представляющий непосредственный контроль над скоростью потоковой передачи для клиента, используя при этом существующую инфраструктуру IPTV, применяющую протокол RTSP/RTP. RTSP (RFC 2326) является протоколом для установления и управления потоковой передачей мультимедиа. Он не охватывает транспортный протокол для самих данных, которым обычно является RTP. Кроме того, он компенсирует флуктуации в сети путем параллельного использования множества каналов связи, таким образом сглаживая полную скорость приема и связанное с этим восприятие пользователя.
Согласно изобретению предлагается формат файла, который дает возможность бесшовного переключения между версиями с различными скоростями передачи битов, подобно адаптивной потоковой передаче HTTP.
Интеллектуальное использование протокола RTSP дает возможность зондировать состояние сети и управлять скоростью передачи потока посредством клиента без модификации существующей инфраструктуры сервера, используя при этом связь с несколькими путями передачи. Вместо запрашивания всего потока, как в случае существующего IPTV, клиент принимает независимые фрагменты потоков от нескольких серверов, чтобы использовать преимущество многопутевой связи. Скорость передачи регулируется индивидуально для каждого сервера, чтобы минимизировать риск перегрузки сети.
Кроме того, клиент периодически запрашивает серверы для передачи потоком небольших фрагментов потока со скоростью выше номинальной скорости передачи, чтобы оценивать емкость сети между собой и сервером для доставки более важной доли контента. Когда суммарная емкость всех сетевых трактов является достаточной для потока более высокой скорости, клиент посылает другой запрос на все серверы, чтобы выбрать версию более высокой скорости для потока. Когда скорость приема потока является слишком медленной для текущей скорости воспроизведения, клиент запрашивает серверы для выбора версии контента с более низкой скоростью передачи битов.
Изобретение добавляет возможность приспосабливаться к изменчивости сети в так называемой (управляемой) среде IPTV, являясь полностью совместимым со связанным набором протоколов на основе RTSP/RTP без необходимости замены единиц оборудования. Кроме того, оно направлено на сглаживание быстрых изменений полосы пропускания для одиночного сетевого тракта путем распределения передачи по нескольким сетевым трактам.
ПОДРОБНОЕ ОПИСАНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ
Изобретение теперь будет описано более подробно в виде примера со ссылкой на следующие чертежи, на которых:
Фиг. 1 - схематичный вид системы для адаптивной потоковой передачи в многопутевой среде согласно варианту осуществления изобретения;
Фиг. 2 - дополнительный схематичный вид системы для адаптивной потоковой передачи в многопутевой среде согласно варианту осуществления изобретения;
Фиг. 3 - схематичный вид связи клиент-сервер согласно варианту осуществления изобретения;
Фиг. 4 - дополнительный схематичный вид связи клиент-сервер согласно варианту осуществления изобретения;
Фиг. 5 - дополнительный схематичный вид связи клиент-сервер согласно варианту осуществления изобретения;
Фиг. 6 - дополнительный схематичный вид связи клиент-сервер согласно варианту осуществления изобретения; и
Фиг. 7 - дополнительный схематичный вид клиента согласно варианту осуществления изобретения.
На чертеже сходные числовые позиции относятся к сходным частям, если не указано иное.
Теперь со ссылкой на Фиг. 1 конкретно изобретение, реализованное на ней, содержит систему 10 для адаптивной потоковой передачи в многопутевой среде, которая содержит клиент 12 и множество серверов, являющихся соответственно способными передавать мультимедийный контент в среде RTP/RTSP по соответственному каналу передачи данных на клиент 12. Клиент 12 изображен в виде телевизионной абонентской приставки вместе с устройством отображения. На Фиг. 1 показаны в виде примера первый сервер 14, второй сервер 16 и третий сервер 18, которые соответственно соединяются с клиентом по первому каналу 20, второму каналу 22 и третьему каналу 24.
Подобно большинству способов адаптивной потоковой передачи, контент предварительно должен кодироваться с несколькими скоростями передачи битов, чтобы поддерживать адаптивную доставку. Кроме того, различные версии потоков являются "синхронизированными по группе кадров (GOP)", что означает, что позиции опорных кадров, позволяющие произвольный доступ в потоки, находятся на одинаковых моментах времени для всех потоков с различными скоростями передачи битов. Эта характеристика дает возможность декодеру переключаться между различными потоками в некоторых точных позициях (опорных кадрах) без какого-либо визуального артефакта. Клиенту 12 затем позволяется запрашивать/загружать по сети порцию мультимедиа для любой из версий этого потока, причем порция является набором групп GOP и имеет постоянную длительность, например, 2с.
Этот многоскоростной контент затем распространяется на серверы 14, 16, 18, вместе с файлом описания, приводящим перечень доступных скоростей передачи битов. Этот файл описания подобен файлу манифеста, используемому в типовых реализациях адаптивной потоковой передачи. В этом варианте осуществления файл описания реализован в виде файла SDP (протокол описания сессии).
На Фиг. 2 изображена подготовка контента: мультимедийный контент 30 кодируется кодером 32 с несколькими скоростями передачи битов при дополнительном ограничении, что все опорные кадры появляются в одинаковый момент времени в каждом кодированном потоке. Считая, что переход от одной скорости передачи битов к некоторой другой может происходить не чаще, чем в каждой GOP, синхронизация опорных кадров может требоваться с периодом в десять миллисекунд (2 секунды в примере). В варианте осуществления контент кодируется с использованием кодеков стандарта H.264 и формата AAC усовершенствованного кодирования мультимедиа с опорными кадрами, появляющимися каждые 2 секунды, и затем инкапсулируется в транспортный поток MPEG. Примерный контент, используемый для описания варианта осуществления, кодируется со следующим набором полных скоростей передачи битов: 500 Кбит/с, 1000 Кбит/с, 1500 Кбит/с и 2000 Кбит/с. Описание потока может быть выражено с использованием протокола SDP.
В этом примере передаются 4 трека транспортного потока (TS) MPEG, и их скорости объявляются с использованием атрибута b=TIAS из протокола SDP. Кроме того, атрибут "X-altservers" (альтернативные серверы) обеспечивает клиенту 12 перечень альтернативных местоположений, из которых может приниматься контент 30. Эти альтернативные местоположения могут использоваться вместо основного местоположения, поскольку они содержат то же самое.
Обычная операция RTSP для управления сеансом потоковой передачи изображена на Фиг. 3. Первое сообщение дает возможность клиенту 12 обнаруживать атрибуты потока. Второе сообщение, названное SETUP (установка), подготавливает сеанс потоковой передачи, и в заключение сообщение PLAY заставляет сервер 14 начать посылку мультимедийного потока.
В изобретении клиент переключается от одного потока на другой в течение сеанса потоковой передачи. В этом варианте осуществления, для ясности, клиент выдает несколько сообщений SETUP в начале сеанса потоковой передачи. Одна установка выполняется для каждого доступного трека. Однако очевидно, что сообщение SETUP для каждого трека также может выдаваться клиентом непосредственно перед тем, как клиенту фактически необходимо принимать этот трек.
Эта фаза установки для нескольких дорожек показана на Фиг. 4. В качестве оптимизации, клиент 12 может также осуществлять установку всех дорожек сразу путем выдачи сообщения SETUP для унифицированного указателя ресурса (URL) сеанса вместо отдельных сообщений SETUP для отдельных дорожек сеанса. Чтобы поддерживать многосерверную работу, клиент 12 выполняет эту фазу инициализации для каждого сервера, приведенного в атрибуте X-altservers.
Как только установка всех дорожек была выполнена, клиент 12 запрашивает малые порции мультимедийного контента путем выдачи запросов PLAY с требуемым временным интервалом от требуемого трека, как показано на Фиг. 5.
Трек выбирают, используя атрибут trackID идентификатора трека, установленный в SDP. Временной интервал указывают на сервер, используя заголовок Range: (интервал). Например, чтобы выбрать временной интервал 2-4с, клиент добавит следующий заголовок к своему запросу воспроизведения:
PLAY rtsp://multimedia.example.com/stream/trackID=1
RTSP/1.0 Range: npt=2-4
Чтобы избежать прерываний воспроизведения между порциями потока, клиент выдает новый RTSP-запрос PLAY для следующей порции заранее, чтобы поддерживать достаточное количество данных в буфере воспроизведения. В нашем варианте осуществления буфер воспроизведения содержит 2 секунды мультимедийного потока, загружаемого по сети заранее.
Для операции с несколькими путями передачи и с несколькими серверами клиент 12 запрашивает различные порции мультимедиа, подлежащие передаче потоком от каждого сервера 14, 16 и 18, параллельно со скоростью, соответствующей оценке клиента относительно емкости этого сетевого тракта, как показано на Фиг. 6.
На Фиг. 7 показано схематичное представление контроллера 40, подходящего для многопутевой и многосерверной работы клиента 12. Контроллер 40 включает в себя средство 42 для оценки пропускной способности канала, являющееся способным выполнять управление скоростью сервера, измерение полосы пропускания и оценку полосы пропускания для каждого соответственного сервера и канала передачи данных.
Кроме того, контроллер 40 включает в себя средство 44 для планирования порции мультимедиа, способное выполнять выбор скорости передачи битов для следующей порции мультимедиа, подлежащей доставке посредством соответственного сервера. Контроллер 40 дополнительно включает в себя средство 46 для распределения контейнера, являющееся способным связывать конкретную порцию мультимедиа одного из серверов с контейнером, распределяемым из связного списка, для получения корректной очередности использования. Контроллер 40 включает в себя средство 48 для перенумерации и для переопределения временных отметок RTP. Кроме того, присутствует блок 50 использования, который позволяет отображение принимаемого потока.
Клиент 12 агрегирует эти принимаемые потоки в единый поток таким образом, что он является идентичным потоку, который принимался бы от одиночного сервера, то есть, порядковые номера и временные отметки RTP являются монотонно возрастающими. Эта задача включает в себя буферизацию и перенумерации RTP-пакетов, принимаемых от других серверов. Она решается согласно показанному на Фиг. 7 этапу распределения контейнера и перенумерации RTP. В заключение этот суммарный поток вводится в клиентский буфер декодирования.
Пропускная способность канала (доступная скорость передачи битов для канала) оценивается средством 42 для оценки пропускной способности канала независимо для каждого сервера 14, 16 и 18 и связанного с ними сетевого тракта 20, 22 и 24. Таким образом, процесс, описанный в нижеследующем, выполняется параллельно для каждого из серверов, используемых в сеансе потоковой передачи с несколькими путями передачи.
Процесс оценки полосы пропускания состоит из следующих этапов. Во-первых, выполняется управление скоростью сервера. Соответственно, скоростью пересылки сервера 14, 16 и 18 управляет клиент 12, чтобы измерить фактическую доступную скорость передачи битов для сетевого тракта 20, 22 и 24. Во-вторых, происходит измерение полосы пропускания. Соответственно, определяются характеристики потока, принятого клиентом 12, сравниваются со скоростью пересылки серверов 14, 16 и 18, чтобы определить текущую скорость передачи битов в сети для текущей порции. В-третьих, выполняется оценка полосы пропускания. Отдельные измерения полосы пропускания сглаживаются, чтобы выдать в результате точное значение, применимое для выбора следующих порций.
Итак, скоростью пересылки сервера управляет клиент, чтобы измерять фактическую доступную скорость передачи битов для сети.
Измерение полосы пропускания состоит в определении характеристик потока, принимаемого клиентом, сравниваемого со скоростью посылки сервера, чтобы определить текущую скорость передачи битов сети для текущей порции мультимедиа. Оценка полосы пропускания состоит в сглаживании отдельной оценки полосы пропускания, чтобы выдать в результате точное значение, используемое для выбора следующих порций мультимедиа.
Процесс оценки полной полосы пропускания периодически повторяется, но не обязательно для каждой порции мультимедиа, в ситуациях, где условия в сети меняются медленно.
Преимущественно, затем является возможным использовать самые медленные пути передачи, чтобы получать порции мультимедиа, подлежащие визуализации "отдаленно" во времени, и использовать самые быстрые пути передачи для получения порций, подлежащих визуализации "в ближайшее время".
Скоростью сервера 14, 16 и 18 управляют путем добавления уже стандартного атрибута "Speed" (скорость) к запросу PLAY. Идея в основе модификации скорости сервера состоит в определении, выдержит ли сеть передачу со скоростью выше текущей скорости. В варианте осуществления по Фиг. 6 и 7, клиент 12 периодически зондирует емкость сети на возможность передавать на 20% быстрее путем запроса сервера послать порцию мультимедиа со скоростью в 1,2 раза выше текущей.
Примерным запросом RTSP будет:
PLAY rtsp://multimedia.example.com/stream/trackID=1
RTSP/1.0
CSeq: 833
Range: npt=2-4
Speed: 1.2
Сервер будет отвечать на вышеупомянутый запрос следующим образом:
RTSP/1.0 200 OK (успешно)
CSeq: 834
Range: npt=2-4
RTP
Info:url=rtsp://multimedia.example.com/stream/trackID=1;
seq=45102; rtptime=12345678
Параметр, именуемый rtptime, указывает временную отметку RTP, соответствующую началу выбранного интервала npt. С данной тактовой частотой клиент определяет интервал rtptime, соответствующий запрошенной порции мультимедиа. Чтобы вычислить текущую скорость Bi передачи битов, клиент 12 суммирует байты RTP пакета, принятые в вышеупомянутом интервале rtptime. Он делит это значение на длительность передачи этих байтов (измеряемую между первым принятым байтом и последним принятым байтом):
Bi=Bytes·8/transmitDuration (число байтов·8/длительность передачи)
Эта текущая скорость передачи битов затем используется алгоритмом сглаживания, чтобы определить надежную оценку. Алгоритм, используемый в этом варианте осуществления, является итеративным и осуществляет попытку вывести достижимую скорость передачи битов исходя из скорости передачи битов, измеренной в течение предыдущих итераций.
Средняя скорость передачи битов для следующей итерации вычисляется в виде взвешенного среднего для текущего среднего значения скорости передачи битов и текущего измерения, как показано в формуле ниже:
avgi+1=(1-α)·avgi+α·Bi
где Bi является измеренной скоростью передачи битов, avgi является средней скоростью передачи битов, вычисленной для текущей итерации, и α является весовым коэффициентом, заданным для измерения текущей скорости передачи битов. В одном примере весовой коэффициент был выбран в виде α=1/16.
В дополнение к средней скорости передачи битов алгоритм оценивает дисперсию скорости передачи битов. Дисперсия сглаживается таким же образом, как и скорость передачи битов, как показано ниже:
Δi=|Bi-avgi|
vari+1=(1-β)vari+βΔi
где Δi является разностью между измеренной скоростью передачи битов и средней скоростью передачи битов для текущей итерации, vari является дисперсией, вычисленной для текущей оценки, и β является весовым коэффициентом, заданным текущему измерению дисперсии. В реализации прототипа было выбрано, что значением β будет 1/8.
Для каждой итерации текущая оценка (или достижимая скорость передачи битов) вычисляется следующим образом:
Figure 00000001
=avgi-4·vari
Это означает, если дисперсия является большой, то клиент 12 использует значительно меньше средней полосы пропускания. С другой стороны, при устойчивой полосе пропускания и низкой дисперсии, клиент 12 стремится использовать полную полосу пропускания, доступную в линии связи.
Рассматриваются два исключительных случая, где оценка повторно устанавливается: когда дисперсия является слишком большой (например, выше половины средней скорости передачи битов), или если была разрывность в порядковых номерах RTP, которая означает, что RTP пакеты были потеряны.
В вышеупомянутых случаях оценки среднего и дисперсии повторно устанавливаются, как изложено ниже:
Figure 00000002
Событие разрывности RTP запускает новую оценку скорости передачи битов для рассматриваемого пути/сервера и/или повторное планирование всех предварительно спланированных порций мультимедиа.
Планирование сервера и порции мультимедиа выполняется средством 44 для планирования сервера и порции. Всякий раз, когда клиент 12 завершает прием запрошенной порции мультимедиа для данного сервера (сервер становится неактивным), он обновляет оценку полосы пропускания для этого сервера и использует соединение снова, чтобы извлечь другую порцию мультимедиа. В зависимости от доступности и относительных скоростей передачи битов для всех путей передачи сервера, соединение сервера может использоваться для извлечения либо следующей порции мультимедиа, которая подлежит воспроизведению, либо порции мультимедиа, которая подлежит воспроизведению позже, то есть, это называется планированием порции мультимедиа. Алгоритм планирования описывается в нижеследующем.
Сначала средство 44 для планирования сервера и порции выбирает скорость передачи битов следующей порции. Чтобы выполнить это, средство 44 для планирования сервера и порции суммирует отдельные оценки скорости передачи битов (см. ниже) для всех серверов 14, 16 и 18, чтобы получить суммарную скорость передачи битов, поскольку все серверы используются параллельно. Выбранной скоростью воспроизведения порции является скорость передачи битов с кодированием, которая непосредственно ниже суммарной скорости передачи битов.
В момент времени te, когда буфер декодера будет пустым, сначала вычисляется время поступления порции мультимедиа для каждого сервера 14, 16 и 18 с использованием текущих параметров воспроизведения и потоковой передачи: ak - время, когда путь k становится неактивным (завершен прием последней или спланированной порции мультимедиа), d - длительность порции, B - битовая скорость воспроизведения и Bk - текущая оценка скорости передачи битов для сервера/пути k. Время, которое потребуется для загрузки по сети следующей порции с сервера k, обозначается Dk, причем Dk=d·B/Bk. Временем поступления порции, если используется сервер k, становится: Rk=ak+Dk
Алгоритм выбирает сервер, который выдает низшее значение Rk. Кроме того, время поступления порции должно быть ранее времени, когда буфер декодера становится пустым (te), то есть, должно удовлетворяться Rk<te. Если это не так, то буфер истощится, и в воспроизведении будет видимое прерывание. В таком случае битовая скорость воспроизведения будет уменьшена до следующей более низкой скорости передачи битов. Если условие времени поступления удовлетворяется, то извлечение порции планируется на сервер k. Скорость передачи должна быть отрегулирована, чтобы соответствовать текущей оценке скорости передачи битов для сервера/пути k. Это выполняется с использованием заголовка Speed: RTSP запроса PLAY со значением Speed=Bk/B.
Например, при условии, что скоростью воспроизведения B является 1 Мбит/с (воспроизводится трек с trackID 1), текущей оценкой Bk скорости передачи битов является 400 Кбит/с, будет получено значение Speed=0,4. В качестве примечания, если процесс периодической оценки полосы пропускания был запущен для текущей порции мультимедиа, результирующую скорость нужно умножать на 1,2.
Ниже приведен соответствующий запрос, который посылается на сервер k (при условии, что не выполняется оценка полосы пропускания для текущей порции мультимедиа):
PLAY rtsp://multimedia.example.com/stream/trackID=1
RTSP/1.0
CSeq: 838
Range: npt=40-42
Speed: 0.4
Если сервер в настоящий момент является неактивным, то сразу выдается следующий запрос RTSP. Иначе, если сервер еще является используемым, то запрос RTSP будет задержан до тех пор, пока сервер не станет неактивным.
В заключение, новая порция будет помещаться в буфер, и, следовательно, значение te увеличивается на длительность порции (d): te=te+d. Если какой-либо из серверов является неактивным, предыдущие этапы повторяются, пока все серверы 14, 16 и 18 не будут заняты. Иначе средство 44 для планирования сервера и порции ожидает, пока сервер не станет неактивным снова.
Распределение контейнера выполняется средством 46 для распределения контейнера. Каждый раз, когда на сервер 14, 16 и 18 посылается запрос заданной порции, ответ связывается с контейнером, выделяемым из связного списка, который гарантирует корректную очередность использования. Таким образом, головным в списке является контейнер, содержащий следующие пакеты, которые будут выдаваться на декодер. Хвостовым в списке является контейнер, который содержит последние пакеты, подлежащие декодированию.
Перенумерация и переопределение временных отметок RTP выполняется средством 48 для перенумерации и переопределения временных отметок RTP. Необходимо нормализовать конечный RTP поток, доставляемый на видеодекодер/демультиплексор. Для каждого запроса, посылаемого на данный сервер 14, 16 и 18, контейнер приема был распределен с корректной очередностью использования. Как только все RTP пакеты, соответствующие этому запросу, были приняты, временные отметки и порядковые номера RTP обновляются, так что декодер не может отличить поток, принятый от нескольких серверов, от потока, принятого от одиночного сервера.
Практически, порядковый номер и время RTP для всех пакетов перенумеруются, начиная с последнего порядкового номера и временной отметки RTP, используемых для подачи в буфер декодирования.
Соответственно, изобретение дает возможность применения адаптивной потоковой передачи с несколькими путями к набору протоколов RTSP/RTP. Интеллектуальное использование параметра Speed в протоколе RTSP дает возможность параллельного использования множества серверов, а также зондирования состояния сети. Параллельное использование множества серверов RTSP клиентом дает возможность быстрого реагирования на изменение состояний сети и максимизации пользовательского восприятия. Изобретение применяется к существующему протоколу RTSP/RTP, как используется в инфраструктуре IPTV.
Другими словами, система, соответствующая предпочтительному варианту осуществления изобретения, является системой для осуществления передачи аудиовизуального контента путем применения способа многопутевой адаптивной потоковой передачи в сетевой среде, содержащей ряд серверов 14, 16, 18; каждый из серверов сконфигурирован для передачи мультимедийного контента на основании совместимого с RTP/RTSP протокола связи по соответственным каналам 20, 22, 24 передачи данных на клиент 12, причем клиент 12 включает в себя контроллер 40, способный зондировать каждый из упомянутых каналов 20, 22 и 24 передачи данных, чтобы определить соответственную полосу пропускания, связанную с каждым из каналов 20, 22 и 24 передачи данных, и запрашивать порцию упомянутого мультимедийного контента от каждого из серверов 14, 16 и 18 согласно определенной соответственной полосе пропускания.
Контроллер 40 включает в себя средство 42 для оценки доступной скорости передачи битов для каждого из каналов 20, 22 и 24 передачи данных между каждым из соответственных серверов 14, 16, 18 и клиентом 12, и сконфигурирован для выполнения управления скоростью сервера на серверах 14, 16 и 18.
Контроллер 40 также включает в себя средство 44 для выбора порции согласно доступной скорости передачи битов, чтобы выбирать следующую порцию мультимедиа, подлежащую доставке посредством соответственного сервера 14, 16, 18.
Контроллер 40 дополнительно включает в себя средство 46 для распределения контейнера, сконфигурированное для связывания конкретной порции мультимедиа одного из серверов 14, 16, 18 с контейнером, распределяемым из связного списка, для получения корректной очередности использования на стороне клиента (приемника).
В отношении перехода к построению (для формирования) одиночного когерентного потока, контроллер 40 включает в себя средство 48 для перенумерации и переопределения временных отметок RTP, чтобы обновлять временные отметки и порядковые номера RTP. Это дает возможность сформировать единый когерентный поток на стороне клиента, как если бы он принимался, например, от единственного сервера.
Способ, используемый согласно предпочтительному варианту осуществления изобретения является, таким образом, способом для адаптивной потоковой передачи в многопутевой среде, содержащим:
- обеспечение клиента; и
- обеспечение множества серверов 14, 16, 18, соответственно конфигурируемых с возможностью передавать на клиент мультимедийный контент в среде RTP/RTSP по соответственному каналу 20, 22, 24 передачи данных, причем клиент 12 включает в себя контроллер 40 для зондирования каждого из каналов 20, 22, 24 передачи данных, чтобы определять соответственную полосу пропускания, связанную с каждым из упомянутых каналов 20, 22 и 24 передачи данных, и запрашивать порцию мультимедийного контента от любого из серверов 14, 16, 18 согласно соответственной определенной полосе пропускания.
Контроллер включает в себя средство 42 для оценки скорости передач битов относительно канала, чтобы выполнять управление скоростью сервера на серверах 14, 16, 18, измерение полосы пропускания и оценку полосы пропускания параллельно для каждого из серверов 14, 16, 18, используемых в сеансе многопутевой потоковой передачи.
Согласно предпочтительному варианту осуществления оценка скорости передачи битов относительно канала периодически повторяется.
Оценка 42 скорости передачи относительно канала содержит этап управления скоростью соответствующего сервера 14, 16, 18 путем добавления стандартного атрибута RTS скорости к запросу воспроизведения.
Для каждого сервера 14, 16, 18 текущая скорость затем используется алгоритмом сглаживания, чтобы итеративно определять оценку для выведения достижимой скорости передачи исходя из скорости передачи битов, измеренной в течение предыдущих итераций.
Для каждого сервера 14, 16, 18 вычисляется дисперсия текущей скорости.
Средство контроллера 40 включает в себя средство 44 для планирования порции мультимедиа (или выбора порции мультимедиа), чтобы выполнять выбор скорости передачи битов для следующей порции, подлежащей доставке соответственным сервером 14, 16, 18.
Отдельные оценки скорости передачи битов суммируются для всех серверов 14, 16, 18, чтобы получить суммарную скорость передачи битов, и скоростью воспроизведения порции выбирают скорость передачи битов с кодированием, которая непосредственно ниже суммарной скорости передачи битов.
Ключевыми элементами изобретения являются стандартный протокол RTSP (в противоположность потоковой передаче по HTTP) и, следовательно, повторное использование существующей экосистемы, сигнализация нескольких версий контента с помощью стандартного SDP с новым атрибутом для указания доступности контента на нескольких серверах, параллельная работа нескольких серверов/нескольких сетевых трактов по сигнализации RTSP с постоянным оцениванием доступной полосы пропускания на отдельных сетевых трактах на основании протокола RTSP и постоянной балансировки скорости передачи данных на множестве путей передачи на основании схемы доставки с упреждением.
Хотя только некоторые варианты осуществления изобретения были описаны в документе, любой специалист в данной области техники поймет, что являются возможными другие модификации, разновидности и возможности. Такие модификации, разновидности и возможности, следовательно, должны рассматриваться находящимися в рамках существа и объема изобретения и, следовательно, составляющими часть изобретения, как описано и/или проиллюстрировано в документе.
По описанному в его предпочтительном варианте осуществления настоящему изобретению ясно, что оно допускает многочисленные модификации и исполнения в рамках умения специалистов в данной области техники и без применения дара изобретательства. Соответственно, объем охраны изобретения определяется объемом нижеследующей формулы изобретения.
Все примеры и условный язык, изложенные в документе, предназначены для учебных целей, чтобы помочь прочтению в понимании принципов изобретения и понятий, внесенных изобретателем для продвижения области техники, и должны рассматриваться неограничительно по отношению к таким конкретно изложенным примерам и условиям.
Кроме того, подразумевается, что все формулировки в документе, излагающие принципы, аспекты и варианты осуществления настоящих принципов, а также конкретные примеры таковых, охватывают и структурные, и функциональные эквиваленты таковых. Дополнительно, подразумевается, что такие эквиваленты включают в себя и известные на настоящий момент эквиваленты, а также эквиваленты, разработанные в будущем, то есть, любые разработанные элементы, которые выполняют ту же функцию, независимо от структуры.
Таким образом, например, специалистам в данной области техники должно быть понятно, что блок-схемы, представленные в документе, дают концептуальные представления иллюстративной схемы, осуществляющей настоящие принципы. Подобным образом, следует понимать, что любые последовательности операций, блок-схемы, диаграммы перехода состояний, псевдокод и подобное представляют различные процессы, которые по существу могут представляться в виде читаемого компьютером носителя и, значит, исполняться компьютером или процессором в любом случае, показан ли такой компьютер или процессор явно, или нет.
Функции различных элементов, показанных на фигурах, могут обеспечиваться с помощью специализированных аппаратных средств, а также аппаратных средств, способных исполнять программное обеспечение совместно с соответствующим программным обеспечением. При обеспечении посредством процессора, функции могут обеспечиваться одиночным специализированным процессором, одиночным совместно используемым процессором или рядом отдельных процессоров, некоторые из которых могут использоваться совместно. Кроме того, явное использование термина "декодер", "контроллер", "планировщик", "блок оценки" или их соответственных эквивалентных средств, выполняющих соответствующие функции, не следует рассматривать относящимися исключительно к аппаратным средствам, способным исполнять программное обеспечение, и могут неявно включать в себя, неограничительно, аппаратные средства цифровой обработки сигналов (DSP), постоянное запоминающее устройство (ПЗУ, ROM) для хранения программного обеспечения, оперативное запоминающее устройство (ОЗУ, RAM) и энергонезависимое запоминающее устройство.
Другие аппаратные средства, обычные и/или специальные, также могут охватываться. Подобным образом любое переключение, изложенное в описании, может выполняться посредством действия логики программы, посредством специализированной логики, посредством взаимодействия программного управления и специализированной логики, причем конкретный способ является выбираемым разработчиком, как более конкретно понято из контекста.
В пунктах формулы изобретения этого документа, любой элемент, выраженный в виде средства для выполнения указанной функции, подразумевается охватывающим любой способ выполнения таковой функции, включая, например, a) комбинацию схемных элементов, которая выполняет эту функцию или b) программное обеспечение в любой форме, включая, следовательно, микропрограммное обеспечение, микрокод или подобное, объединенное с надлежащей схемой для исполнения этого программного обеспечения, чтобы выполнить функцию. Настоящие принципы, как определено такими пунктами формулы изобретения, заключаются в факте, что функциональные возможности, обеспеченные различными изложенными средствами, комбинируются и сводятся воедино образом, требуемым пунктами формулы изобретения. Таким образом, считается, что любые средства, которые могут обеспечить эти функциональности, являются эквивалентными таковым, показанным в документе.
Ссылка в описании на "одно осуществление" или "вариант осуществления" настоящих принципов, а также на другие разновидности таковых, означает, что конкретная функция, структура, характеристика и т.д., описанные в связи с вариантом осуществления, включается, по меньшей мере, в один вариант осуществления настоящих принципов. Таким образом, появления фразы "в одном варианте осуществления" или "в варианте осуществления", также любые другие разновидности, появляющиеся в различных местах по всему описанию, не обязательно все ссылаются на одинаковый вариант осуществления.
Нужно подразумевать, что настоящие принципы могут быть реализованы в различных формах из аппаратных средств, программного обеспечения, микропрограммного обеспечения (tirmware), специализированных процессоров или комбинации таковых. Предпочтительно, настоящие принципы могут быть реализованы в виде комбинации аппаратного и программного обеспечения. Кроме того, программное обеспечение предпочтительно реализуется в виде прикладной программы, материально реализованной на устройстве хранения программ. Прикладная программа может быть загружена на вычислительную машину высшего уровня и исполняться таковой машиной, содержащей любую подходящую архитектуру. Предпочтительно, машина реализована на компьютерной платформе с наличием аппаратных средств, таких как один или несколько центральных процессоров (ЦП), оперативное запоминающее устройство (ОЗУ) и интерфейс(ы) ввода/вывода (I/O). Компьютерная платформа также включает в себя операционную систему и микрокомандный код. Различные процессы и функции, описанные в документе, могут являться либо частью микрокомандного кода, либо частью прикладной программы (или комбинацией таковых), которая исполняется с помощью операционной системы. Кроме того, различные другие периферийные устройства могут подключаться к компьютерной платформе, такие как дополнительное устройство хранения данных и печатающее устройство.
Нужно дополнительно подразумевать, что поскольку некоторые из составляющих систему компонентов и этапов способа, изображенных на сопроводительных чертежах, предпочтительно реализованы в виде программного обеспечения, фактические связи между компонентами системы (или этапами процесса) могут отличаться в зависимости от способа, которым запрограммированы настоящие принципы. Учитывая указания в документе, специалист в данной области техники будет способен рассмотреть эти и подобные реализации или конфигурации настоящих принципов.

Claims (18)

1. Система для осуществления передачи аудиовизуального контента путем использования технологии многоканальной адаптивной потоковой передачи в сетевой среде, содержащая множество серверов (14, 16, 18), при этом по меньшей мере первый и второй серверы хранят соответственно первую кодированную версию и вторую кодированную версию аудиовизуального контента, причем эти первая и вторая кодированные версии являются разными и представлены в виде наборов порций, при этом каждый из упомянутых серверов выполнен с возможностью передачи аудиовизуального контента на основе протокола связи RTP/RTSP по соответственным каналам (20, 22, 24) передачи данных на клиент (12), отличающаяся тем, что клиент (12) включает в себя контроллер (40), выполненный с возможностью зондировать каждый из каналов (20, 22, 24) передачи данных, чтобы определить соответственную полосу пропускания, связанную с каждым из каналов (20, 22, 24) передачи данных, и запрашивать порцию аудиовизуального контента от каждого из упомянутых серверов (14, 16, 18) согласно этой определенной соответственной полосе пропускания и времени воспроизведения аудиовизуального контента, при этом по меньшей мере две порции запрашиваются упомянутым клиентом в упомянутых по меньшей мере первом и втором серверах, причем данное клиентское устройство использует самые медленные каналы для получения порций, которые должны воспроизводиться позднее во времени, и использует самые быстрые каналы для получения порций, которые должны воспроизводиться в скором времени.
2. Система по п. 1, отличающаяся тем, что контроллер (40) включает в себя средство для оценки (42) доступной скорости передачи битов для каждого из каналов (20, 22, 24) передачи данных между каждым из соответственных серверов (14, 16, 18) и клиентом (12) и сконфигурирован для выполнения управления скоростью отправки с сервера (14, 16, 18).
3. Система по п. 1 или 2, отличающаяся тем, что контроллер (40) включает в себя средство для выбора (44) порции согласно доступной скорости передачи битов, чтобы выбирать следующую порцию, подлежащую доставке посредством соответственного сервера (14, 16, 18).
4. Система по п. 1, отличающаяся тем, что контроллер (40) включает в себя средство (46) для распределения контейнера, сконфигурированное для связывания конкретной порции контента одного из серверов (14, 16, 18) с контейнером, распределяемым из связного списка, для получения корректной очередности использования.
5. Система по п. 1, отличающаяся тем, что контроллер (40) включает в себя средство (48) для перенумерации и переопределения временных отметок RTP, чтобы обновлять временные отметки и порядковые номера RTP с тем, чтобы формировать одиночный когерентный поток.
6. Способ адаптивной потоковой передачи в многоканальной среде, содержащий этапы, на которых:
обеспечивают клиент; и
обеспечивают множество серверов (14, 16, 18), соответственно сконфигурированных для передачи аудиовизуального контента на основе протокола связи RTP/RTSP по соответственному каналу (20, 22, 24) передачи данных на клиент, при этом по меньшей мере первый и второй серверы хранят соответственно первую кодированную версию и вторую кодированную версию аудиовизуального контента, причем эти первая и вторая кодированные версии являются разными и представлены в виде наборов порций,
отличающийся тем, что клиент (12) включает в себя контроллер (40), посредством которого зондируют каждый из каналов (20, 22, 24) передачи данных, чтобы определять соответственную полосу пропускания, связанную с каждым из каналов (20, 22, 24) передачи данных, и запрашивать порцию аудиовизуального контента от любого из упомянутых серверов (14, 16, 18) согласно этой соответственной определенной полосе пропускания и времени воспроизведения аудиовизуального контента, при этом по меньшей мере две порции запрашиваются упомянутым клиентом в упомянутых по меньшей мере первом и втором серверах, причем данное клиентское устройство использует самые медленные каналы для получения порций, которые должны воспроизводиться позднее во времени, и использует самые быстрые каналы для получения порций, которые должны воспроизводиться в скором времени.
7. Способ по п. 6, отличающийся тем, что контроллер включает в себя средство (42) для оценки скорости передачи битов в отношении канала, чтобы выполнять регулирование скорости отправки с сервера (14, 16, 18), измерение полосы пропускания и оценку полосы пропускания параллельно для каждого из серверов (14, 16, 18), используемых в сеансе многоканальной потоковой передачи.
8. Способ по п. 7, отличающийся тем, что оценку скорости передачи битов в отношении канала периодически повторяют.
9. Способ по п. 7 или 8, отличающийся тем, что посредством оценки (42) скорости передачи битов в отношении канала управляют скоростью отправки с соответствующего сервера (14, 16, 18) путем добавления параметра скорости отправки в запрос воспроизведения, каковой параметр скорости отправки используется упомянутым соответствующим сервером.
10. Способ по п. 9, отличающийся тем, что для каждого сервера (14, 16, 18) текущая скорость передачи затем используется алгоритмом сглаживания, чтобы итеративно определять оценку для выведения достижимой скорости передачи битов исходя из скорости передачи битов, измеренной в течение предыдущих итераций.
11. Способ по п. 9, отличающийся тем, что для каждого сервера (14, 16, 18) для текущей скорости передачи вычисляют дисперсию.
12. Способ по п. 6 или 7, отличающийся тем, что средство (40) контроллера включает в себя средство (44) для планирования порции, посредством которого выполняют выбор скорости передачи битов для следующей порции, подлежащей доставке соответственным сервером (14, 16, 18).
13. Способ по п. 12, отличающийся тем, что отдельные оценки скорости передачи битов суммируются для всех серверов (14, 16, 18), чтобы получить суммарную скорость передачи битов, и скорость воспроизведения выбирают по скорости передачи битов при кодировании, которая непосредственно ниже суммарной скорости передачи битов.
14. Способ по п. 6 или 7, отличающийся тем, что средство (40) контроллера включает в себя средство (46) для распределения контейнера, посредством которого связывают конкретную порцию контента одного из серверов (14, 16, 18) с контейнером, распределяемым из связного списка, для получения корректной очередности использования.
15. Способ по п. 6 или 7, отличающийся тем, что средство (40) контроллера включает в себя средство (48) для перенумерации и переопределения временных отметок RTP, посредством которого обновляют временные отметки и порядковые номера RTP с тем, чтобы сформировать одиночный когерентный поток.
RU2012152900A 2011-12-22 2012-12-07 Система и способ для адаптивной потоковой передачи в среде с несколькими путями передачи RU2627303C2 (ru)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP11306744.1 2011-12-22
EP11306744.1A EP2608558A1 (en) 2011-12-22 2011-12-22 System and method for adaptive streaming in a multipath environment

Publications (2)

Publication Number Publication Date
RU2012152900A RU2012152900A (ru) 2014-06-20
RU2627303C2 true RU2627303C2 (ru) 2017-08-07

Family

ID=47290841

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2012152900A RU2627303C2 (ru) 2011-12-22 2012-12-07 Система и способ для адаптивной потоковой передачи в среде с несколькими путями передачи

Country Status (13)

Country Link
US (1) US9374409B2 (ru)
EP (2) EP2608558A1 (ru)
JP (1) JP6308718B2 (ru)
KR (1) KR102048898B1 (ru)
CN (1) CN103179107B (ru)
CA (1) CA2797895C (ru)
ES (1) ES2704625T3 (ru)
MX (1) MX349401B (ru)
MY (1) MY161489A (ru)
PL (1) PL2608559T3 (ru)
RU (1) RU2627303C2 (ru)
TR (1) TR201820876T4 (ru)
TW (1) TWI561071B (ru)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8560604B2 (en) 2009-10-08 2013-10-15 Hola Networks Ltd. System and method for providing faster and more efficient data communication
IL210169A0 (en) 2010-12-22 2011-03-31 Yehuda Binder System and method for routing-based internet security
US9571827B2 (en) * 2012-06-08 2017-02-14 Apple Inc. Techniques for adaptive video streaming
US9654533B2 (en) * 2013-01-17 2017-05-16 Electronics And Telecommunications Research Institute Method of adaptively delivering media based on reception status information from media client and apparatus using the same
US9485289B2 (en) 2013-08-28 2016-11-01 Cisco Technology, Inc. HTTP streaming client adaptation algorithm based on proportional-integral control
US9241044B2 (en) 2013-08-28 2016-01-19 Hola Networks, Ltd. System and method for improving internet communication by using intermediate nodes
US9401944B2 (en) 2013-10-22 2016-07-26 Qualcomm Incorporated Layered adaptive HTTP streaming
JP6305738B2 (ja) * 2013-11-27 2018-04-04 エヌ・ティ・ティ・コミュニケーションズ株式会社 メディア再生制御装置、メディア再生制御方法、及びプログラム
CN104735115A (zh) * 2013-12-24 2015-06-24 乐视网信息技术（北京）股份有限公司 一种p2p下载方法及装置
US9887914B2 (en) * 2014-02-04 2018-02-06 Fastly, Inc. Communication path selection for content delivery
US9680685B2 (en) * 2014-05-08 2017-06-13 Spb Tv Ag System and method for managing video content feeds
US10045367B2 (en) * 2014-10-03 2018-08-07 Qualcomm Incorporated Uplink data fragmentation for multi-user networks
JP6342839B2 (ja) * 2015-04-20 2018-06-13 西日本電信電話株式会社 受信端末及び映像視聴システム
US11057446B2 (en) 2015-05-14 2021-07-06 Bright Data Ltd. System and method for streaming content from multiple servers
US10003357B2 (en) * 2015-08-28 2018-06-19 Qualcomm Incorporated Systems and methods for verification of code resiliency for data storage
CN105430533B (zh) * 2015-12-31 2018-09-11 武汉鸿瑞达信息技术有限公司 Hls视频点播加速方法及***
US20180205802A1 (en) * 2017-01-13 2018-07-19 Cisco Technology, Inc. Cache Aware Streaming
EP3754520B1 (en) 2017-08-28 2022-02-02 Bright Data Ltd Method for improving content fetching by selecting tunnel devices
US11190374B2 (en) 2017-08-28 2021-11-30 Bright Data Ltd. System and method for improving content fetching by selecting tunnel devices
US11622020B2 (en) 2017-08-31 2023-04-04 Micro Focus Llc Push control
JP6471252B1 (ja) * 2018-03-20 2019-02-13 株式会社Ｊストリーム 再生装置及びプログラム
EP3850857A4 (en) * 2018-09-14 2022-10-05 National University of Singapore METHOD AND APPARATUS FOR STREAMING CONTENT
KR102195516B1 (ko) * 2018-11-01 2020-12-29 카테노이드 주식회사 방송 서비스 제공 장치, 방송 서비스 수신 장치 및 이를 이용한 방송 서비스 송수신 시스템
JP7222748B2 (ja) * 2019-02-13 2023-02-15 日本放送協会 受信装置及び配信サーバ
EP4236263A3 (en) 2019-02-25 2023-09-06 Bright Data Ltd. System and method for url fetching retry mechanism
WO2020202135A2 (en) 2019-04-02 2020-10-08 Luminati Networks Ltd. System and method for managing non-direct url fetching service
US11343551B1 (en) * 2019-07-23 2022-05-24 Amazon Technologies, Inc. Bandwidth estimation for video streams
EP3902275A1 (en) * 2020-04-21 2021-10-27 THEO Technologies A method for estimating bandwidth between a video server and a video client
CN117151440B (zh) * 2023-10-31 2024-02-09 合肥综合性国家科学中心人工智能研究院(安徽省人工智能实验室) 一种机器组策略选择的仓储分配方法及***

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7231442B2 (en) * 2002-04-03 2007-06-12 Tonic Software, Inc. Global network monitoring system
US20080189429A1 (en) * 2007-02-02 2008-08-07 Sony Corporation Apparatus and method for peer-to-peer streaming
US20090089445A1 (en) * 2007-09-28 2009-04-02 Deshpande Sachin G Client-Controlled Adaptive Streaming
RU2372646C2 (ru) * 2003-07-03 2009-11-10 Майкрософт Корпорейшн Формат полезных данных транспортного протокола реального времени
US20110055328A1 (en) * 2009-05-29 2011-03-03 Lahr Nils B Selective access of multi-rate data from a server and/or peer
WO2011109101A1 (en) * 2010-03-05 2011-09-09 Thomson Licensing Bit rate adjustment in an adaptive streaming system

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6405256B1 (en) 1999-03-31 2002-06-11 Lucent Technologies Inc. Data streaming using caching servers with expandable buffers and adjustable rate of data transmission to absorb network congestion
AU3829500A (en) * 1999-04-09 2000-11-14 Clearspeed Technology Limited Parallel data processing apparatus
JP2002176609A (ja) * 2000-08-25 2002-06-21 Matsushita Electric Ind Co Ltd データ受信再生方法及びデータ受信再生装置
US20020194361A1 (en) * 2000-09-22 2002-12-19 Tomoaki Itoh Data transmitting/receiving method, transmitting device, receiving device, transmiting/receiving system, and program
FI118830B (fi) * 2001-02-08 2008-03-31 Nokia Corp Tietovirran toisto
WO2002073440A1 (en) 2001-03-12 2002-09-19 Edgestream, Inc. Re-assembly of streaming files from separate connections
US8077679B2 (en) * 2001-03-28 2011-12-13 Qualcomm Incorporated Method and apparatus for providing protocol options in a wireless communication system
US6862028B2 (en) * 2002-02-14 2005-03-01 Intel Corporation Bin pointer and state caching apparatus and method
EP1395000B1 (en) * 2002-08-27 2006-01-04 Matsushita Electric Industrial Co., Ltd. A method of transmitting data streams dependent on the monitored state of the client application buffer
US7342968B2 (en) * 2003-08-13 2008-03-11 Skystream Networks Inc. Method and system for modeling the relationship of the bit rate of a transport stream and the bit rate of an elementary stream carried therein
US20060215596A1 (en) 2005-03-23 2006-09-28 Intel Corporation Network aware cross-layer protocol methods and apparatus
JP4706908B2 (ja) * 2005-06-30 2011-06-22 ソニー株式会社 同時再生システム、情報処理装置、途中参加方法及び途中参加プログラム
US9124357B2 (en) * 2006-04-20 2015-09-01 Qualcomm Incorporated Media access control for ultra-wide band communication
US7899137B2 (en) 2006-10-12 2011-03-01 Mediatek Inc. Mobile communication system with integrated GPS receiver
US20080163056A1 (en) * 2006-12-28 2008-07-03 Thibaut Lamadon Method and apparatus for providing a graphical representation of content
JP4809256B2 (ja) * 2007-01-31 2011-11-09 ヒューレット−パッカード デベロップメント カンパニー エル．ピー． データストリーミング方法
US20080291916A1 (en) * 2007-05-22 2008-11-27 Bo Xiong Systems and methods for dynamic quality of service
US8194657B2 (en) * 2007-05-22 2012-06-05 Actiontec Electronics, Inc. Systems and methods for dynamic quality of service
US20100268761A1 (en) * 2007-06-05 2010-10-21 Steve Masson Methods and systems for delivery of media over a network
CN101198016A (zh) * 2007-12-05 2008-06-11 中兴通讯股份有限公司 交互式个人电视媒体交付***的内容发布和存储方法
KR101003103B1 (ko) * 2008-04-11 2010-12-21 한국전자통신연구원 네트워크에서 파일을 분배하는 방법
US9003050B2 (en) 2008-04-11 2015-04-07 Mobitv, Inc. Distributed and scalable content streaming architecture
US20100153578A1 (en) * 2008-07-16 2010-06-17 Nokia Corporation Method and Apparatus for Peer to Peer Streaming
US8832292B2 (en) * 2008-10-15 2014-09-09 Aster Risk Management Llc Source-selection based internet backbone traffic shaping
US20100094962A1 (en) 2008-10-15 2010-04-15 Patentvc Ltd. Internet backbone servers with edge compensation
JP4934660B2 (ja) * 2008-11-28 2012-05-16 日本電信電話株式会社 通信帯域算出方法、装置、およびトラヒック管理方法
WO2010111261A1 (en) 2009-03-23 2010-09-30 Azuki Systems, Inc. Method and system for efficient streaming video dynamic rate adaptation
CN102006217A (zh) * 2009-08-28 2011-04-06 青岛海信传媒网络技术有限公司 内容分发带宽控制方法
CN102648636B (zh) * 2009-10-21 2016-08-17 爱立信(中国)通信有限公司 用于媒***置控制的方法、设备和***
US10003851B2 (en) * 2009-11-24 2018-06-19 Imagine Communications Corp. Managed multiplexing of video in an adaptive bit rate environment
EP2362651A1 (en) * 2010-02-19 2011-08-31 Thomson Licensing Multipath delivery for adaptive streaming
US8335172B2 (en) * 2010-06-10 2012-12-18 Cisco Technology, Inc. Switchable conference multicast streaming with dynamic asymmetry
US8935508B1 (en) * 2010-08-30 2015-01-13 Qualcomm Incorporated Implementing pseudo content access memory
US8589583B2 (en) * 2010-09-08 2013-11-19 Hulu, Inc. Method and apparatus for adaptive bit rate switching
CN102088620B (zh) * 2010-12-01 2014-06-18 中兴通讯股份有限公司南京分公司 一种内容分发网络中媒体文件下载方法及客户端
CN102123303B (zh) * 2011-03-25 2012-10-24 天脉聚源(北京)传媒科技有限公司 一种音视频文件播放方法、***及传输控制装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7231442B2 (en) * 2002-04-03 2007-06-12 Tonic Software, Inc. Global network monitoring system
RU2372646C2 (ru) * 2003-07-03 2009-11-10 Майкрософт Корпорейшн Формат полезных данных транспортного протокола реального времени
US20080189429A1 (en) * 2007-02-02 2008-08-07 Sony Corporation Apparatus and method for peer-to-peer streaming
US20090089445A1 (en) * 2007-09-28 2009-04-02 Deshpande Sachin G Client-Controlled Adaptive Streaming
US20110055328A1 (en) * 2009-05-29 2011-03-03 Lahr Nils B Selective access of multi-rate data from a server and/or peer
WO2011109101A1 (en) * 2010-03-05 2011-09-09 Thomson Licensing Bit rate adjustment in an adaptive streaming system

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
H. SCHULZRINNE et al, Real Time Streaming Protocol 2.0 (RTSP); draft-ietf-mmusic-rfc2326bis 28.txt, REAL TIME STREAMING PROTOCOL 2.0 (RTSP), IETF, 28 October 2011, найдено в Интернет на. https://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-rfc2326bis/draft-ietf-mmusic-rfc2326bis-29-from-28.diff.html. H. SCHULZRINNE et al, RTP: A Transport Protocol for Real-Time Applications, rfc3550.txt, IETF, 01 July 2003, найдено в Интернет на https://www.ietf.org/rfc/rfc3550.txt. *
STEPHANE GOUACHE et al, Distributed & adaptive HTTP streaming, IEEE International Conference on Multimedia and Expo (ICME), 2011, 11 July 2011, abstract. *

Also Published As

Publication number Publication date
KR102048898B1 (ko) 2020-01-08
CA2797895A1 (en) 2013-06-22
EP2608559A1 (en) 2013-06-26
CN103179107B (zh) 2019-06-28
PL2608559T3 (pl) 2019-03-29
JP2013135471A (ja) 2013-07-08
US9374409B2 (en) 2016-06-21
CA2797895C (en) 2020-01-14
MX349401B (es) 2017-07-27
US20130166768A1 (en) 2013-06-27
KR20130079212A (ko) 2013-07-10
TW201332342A (zh) 2013-08-01
TR201820876T4 (tr) 2019-01-21
JP6308718B2 (ja) 2018-04-11
MY161489A (en) 2017-04-14
ES2704625T3 (es) 2019-03-19
EP2608558A1 (en) 2013-06-26
EP2608559B1 (en) 2018-11-21
TWI561071B (en) 2016-12-01
CN103179107A (zh) 2013-06-26
MX2012015001A (es) 2015-06-01
RU2012152900A (ru) 2014-06-20

Similar Documents

Publication Publication Date Title
RU2627303C2 (ru) Система и способ для адаптивной потоковой передачи в среде с несколькими путями передачи
US11856329B2 (en) Dynamic advertisement stream replacement
CA3031584C (en) Client feedback enhanced methods and devices for efficient adaptive bitrate streaming
KR102110627B1 (ko) 적응적 비트레이트 스트리밍에서 대역폭 할당을 위한 방법들 및 디바이스들
EP2936742B1 (en) Low-latency streaming
JP6316967B2 (ja) Ｄａｓｈのためのコマンドを信号伝達するクライアント／サーバ
US8612620B2 (en) Client capability adjustment
WO2018165487A1 (en) Excess bitrate distribution based on quality gain in sabr server
US8990407B2 (en) Fast setup response prediction
US9003050B2 (en) Distributed and scalable content streaming architecture
KR20210042051A (ko) 적응적 스트리밍 서비스를 위한 다중 경로 기반 블록 전송 시스템 및 스트리밍 방법

Legal Events

Date Code Title Description
PD4A Correction of name of patent owner
PC41 Official registration of the transfer of exclusive right

Effective date: 20190927

PC41 Official registration of the transfer of exclusive right

Effective date: 20191206