RU2598805C2 - Способ для динамической адаптации частоты следования битов при приеме и соответствующий приемник - Google Patents
Способ для динамической адаптации частоты следования битов при приеме и соответствующий приемник Download PDFInfo
- Publication number
- RU2598805C2 RU2598805C2 RU2013156038/08A RU2013156038A RU2598805C2 RU 2598805 C2 RU2598805 C2 RU 2598805C2 RU 2013156038/08 A RU2013156038/08 A RU 2013156038/08A RU 2013156038 A RU2013156038 A RU 2013156038A RU 2598805 C2 RU2598805 C2 RU 2598805C2
- Authority
- RU
- Russia
- Prior art keywords
- server
- receiver
- program
- versions
- audiovisual program
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 27
- 230000006978 adaptation Effects 0.000 title description 3
- 230000005540 biological transmission Effects 0.000 claims abstract description 54
- 230000004044 response Effects 0.000 claims description 11
- 230000004807 localization Effects 0.000 claims description 2
- 238000012546 transfer Methods 0.000 abstract description 8
- 238000005516 engineering process Methods 0.000 abstract description 4
- 230000000694 effects Effects 0.000 abstract description 2
- 230000009897 systematic effect Effects 0.000 abstract description 2
- 238000005259 measurement Methods 0.000 abstract 1
- 239000000126 substance Substances 0.000 abstract 1
- 230000032258 transport Effects 0.000 description 8
- 238000004891 communication Methods 0.000 description 6
- 230000015654 memory Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 239000003550 marker Substances 0.000 description 3
- 239000006185 dispersion Substances 0.000 description 2
- 238000011156 evaluation Methods 0.000 description 2
- 230000014509 gene expression Effects 0.000 description 2
- 238000009499 grossing Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 238000011084 recovery Methods 0.000 description 2
- 238000012800 visualization Methods 0.000 description 2
- 230000003936 working memory Effects 0.000 description 2
- 230000003044 adaptive effect Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000012804 iterative process Methods 0.000 description 1
- QEEAPRPFLLJWCF-UHFFFAOYSA-K potassium citrate (anhydrous) Chemical compound [K+].[K+].[K+].[O-]C(=O)CC(O)(CC([O-])=O)C([O-])=O QEEAPRPFLLJWCF-UHFFFAOYSA-K 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 238000005303 weighing Methods 0.000 description 1
Images
Classifications
-
- 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
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5003—Managing SLA; Interaction between SLA and QoS
- H04L41/5019—Ensuring fulfilment of SLA
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
- H04L41/5051—Service on demand, e.g. definition and deployment of services in real time
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/302—Route determination based on requested QoS
- H04L45/306—Route determination based on the nature of the carried application
- H04L45/3065—Route determination based on the nature of the carried application for real time traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/801—Real time traffic
-
- 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/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
-
- 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/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
-
- 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/70—Media network packetisation
-
- 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/75—Media network packet handling
- H04L65/752—Media network packet handling adapting media to network capabilities
-
- 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
- H04N21/23439—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 for generating different versions
-
- 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
- H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
-
- 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/47—End-user applications
- H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
- H04N21/47202—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand
-
- 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/637—Control signals issued by the client directed to the server or network components
- H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
- H04N21/6379—Control signals issued by the client directed to the server or network components directed to server directed to encoder, e.g. for requesting a lower encoding rate
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Databases & Information Systems (AREA)
- Human Computer Interaction (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Selective Calling Equipment (AREA)
- Information Transfer Between Computers (AREA)
Abstract
Изобретение относится к области приемников аудиовизуальных программ. Технический результат заключается в обеспечении динамического управления полосой пропускания, используемой во время передачи аудиовизуальных программ для стандартных инфраструктур IPTV, используя протокол управления/перемещения в реальном времени. Технический результат достигается за счет использования протокола транспорта в реальном времени и протокола управления в реальном времени между сервером и приемником, при этом аудиовизуальная программа доступна на сервере во множестве версий, соответствующих программе, кодированной в различных разрешениях, и дающих возможность ее передачи на различных частотах следования битов, в соответствии с запросами приемника; способ содержит систематическое измерение полосы пропускания сети приемником для того, чтобы подстроить частоту следования битов при передаче в соответствии с состоянием сети. 2 н. и 10 з.п. ф-лы, 8 ил.
Description
Область техники, к которой относится изобретение
Изобретение относится к области приемников аудиовизуальных программ и, более определенно, к динамической адаптации программы в соответствии с полосой пропускания, доступной в сети во время передачи программы, используя протокол передачи в реальном времени и протокол управления сервером в реальном времени, связанный с протоколом передачи в реальном времени, для передачи в виде потока.
Предшествующий уровень техники
Загрузка программы для ее отображения предписывает полное перемещение аудиовизуальной программы к приемнику перед ее воссозданием. Чтобы избежать сопутствующих ограничений, таких как требование ожидания окончания загрузки или необходимость наличия достаточного пространства для сохранения всей программы, использование потоковой передачи (непрерывной передачи программы в течение времени просмотра) является широко распространенным.
Известные протоколы потоковой передачи включают в себя RTP (RFC3550 и RFC, связанные согласно формату транспортируемых данных), связанный с протоколом управления сервером (RFC2326) и MPEG TS/UDP (транспортный поток Экспертной Группы по Движущимся Изображениям/протокол пользовательских датаграмм), в то время как загрузка обычно использует протокол HTTP (протокол передачи гипертекста).
Современные сети связи предлагают пропускные способности, которые делают возможной передачу аудиовизуальных программ в виде потока. Передача может быть осуществлена через сети, такие как Интернет, между сервером и клиентом. Потоковая передача является способом передачи, при котором передаваемая аудиовизуальная программа разбивается на временные части (последовательные части, которые должны быть визуализированы последовательно), одна за другой передаваемые по сети на протяжении передачи и воссоздания. Передача и воссоздание являются одновременными с добавлением незначительной задержки из-за использования буферной памяти на приемнике.
Стандарт 3GPP (3GPP, TSGS-SA, Прозрачная служба сквозной потоковой передачи с коммутацией пакетов (PSS), формат файлов 3GPP (3GP), TS 26.244, V6.3.0, 2005-03) определяет формат для организации данных и хранилища, содержащего несколько версий одной и той же программы, соответствующих различным частотам следования битов. Этот формат, связанный с логикой управления на сервере программ, дает возможность адаптации к условиям и, в частности, к изменениям в полосе пропускания, относящимся к использованию сети. Эта логика управления, реализуемая на сервере, однако, точно не определяется в стандарте 3GPP.
В 3GPP данные формата кодируются так, чтобы соответствовать ограничению частоты следования битов на линии передачи для фиксированной частоты следования битов: когда данные представляют собой изображения, кодирование состоит в адаптации разрешения изображений так, чтобы сделать возможной их транспортировку по линии связи с большей или меньшей полосой пропускания. Но 3GPP, однако, не определяет средство переключения, дающее возможность того, чтобы разрешение передаваемых изображений модифицировалось для того, чтобы подстроить прием данных под изменения в полосе пропускания. Некоторые способы известны для разрешения этой проблемы: они зависят от данных, передаваемых от клиента к серверу, таких как RR (Отчеты Приемника, Receiver Reports), определенные в протоколе RTCP (Протоколе Управления в Реальном Времени, Real-Time Control Protocol), и которые требуют этапов для обработки и интерпретации сервером для того, чтобы определить, следует ли осуществлять передачу на другой частоте следования битов.
Технология потоковой передачи HTTP недавно была представлена вниманию широкой публики благодаря Apple для iPhone и благодаря Microsoft для их Smoothstreaming. Технология потоковой передачи HTTP используется только в приемниках IPTV, для которых функционирование основывается на протоколах RTP и RTSP.
Способы передачи, используемые сегодня в IPTV, не допускают динамическую адаптацию частоты следования битов в соответствии с полосой пропускания, доступной в сети, без использования специфического сервера. Кроме того, когда условия доступа к серверу ухудшаются, в приемнике возникает риск прерывания в отношении услуги (службы).
Протокол (RTP) передачи в реальном времени, например, представляет собой протокол, используемый для инкапсуляции и передачи в реальном времени данных, кодирующих аудиовизуальную программу. Кодирование, используемое для данных, имеет обычно тип MPEG-TS или эквивалентный формат.
RTSP представляет собой пример протокола связи, создающего возможность управления удаленным медиа-сервером. Такой протокол предлагает функциональные возможности, типичные для видеоплеера, такие как “PLAY” и “PAUSE”, и делает возможным воспроизведение части аудиовизуальной программы от временного положения части программы в программе (в примере временной указатель или соответствующая позиция в файле).
Во время передач аудиовизуальных программ в виде потока, используя протоколы, такие как RTP и RTSP, например, существенные модификации в доступности сети оказывают очень существенное воздействие на воссоздание программ. Когда частота следования битов динамически не подстраивается в промежутке между началом и окончанием передачи, возникают прерывания, которые представляют существенное неудобство для пользователя.
Протокол RTP транспорта (транспортный протокол) основывается на протоколе UDP, и протокол HTTP основывается на соединенном протоколе TCP.
TCP известен как “соединенный” протокол, который реагирует на ограничения надежности, он дает возможность передачи данных без ошибок пакетов с сервера на приемник. Для осуществления этого приемник осуществляет связь с сервером, указывая ему принятые данные. В дополнение к зависимости от теряемых и повторно передаваемых данных средняя частота следования битов увязана с маршрутизацией подтверждений. Чем быстрее время маршрутизации, тем больше сокращается максимальная частота следования битов.
UDP представляет собой протокол, который не реагирует на те же самые ограничения надежности. Его называют “недостоверным” и “без соединения”. У него нет системы подтверждения, и его средняя частота следования битов не увязана с расстоянием между сервером и приемником. Именно по этой причине протокол UDP используется с RTP в приложениях IPTV.
Документ US 2010/161716 A1 (KAJOS GEORGE W. (US) ET AL.) 24 июня 2010 (2010-06-24) раскрывает способ доставки контента к клиентскому устройству по сети, при этом сообщение, которое указывает возможности визуализации у клиента, принимается сервером, который затем передает контент в формате, который может быть полностью декодирован клиентом в соответствии с его возможностями визуализации.
Сущность изобретения
Задачей изобретения является преодоление по меньшей мере одного из недостатков предшествующего уровня техники и, более определенно, создание возможности динамического управления полосой пропускания, используемой во время передачи аудиовизуальных программ для стандартных инфраструктур IPTV, используя некоторый протокол управления/перемещения в реальном времени, такой как, например, протоколы RTP и RTSP.
Использование протокола управления серверами в реальном времени, адаптированного в соответствии с изобретением, позволяет приемнику запрашивать с сервера передачу аудиовизуальной программы в виде последовательных частей. Приемник периодически измеряет, для каждой из переданных частей, условия передачи сети и, как следствие, подстраивает частоту следования битов при передаче. Подстройка частоты следования битов при передаче осуществляется приемником посредством выбора, для каждой части программы, последовательно запрашиваемой с сервера, версии программы из числа нескольких версий, кодируемых на различных частотах следования битов и доступных на сервере. Выбор версии приемником делается в соответствии с частотой следования битов при передаче, измеренной во время передачи предыдущей части. Таким образом, подстройка частоты следования битов не требует модификации сервера программ.
Изобретение относится к способу для приема аудиовизуальной программы, хранимой на сервере, для воспроизведения на устройстве отображения, подсоединенном к приемнику, причем аудиовизуальная программа доступна на сервере в по меньшей мере двух версиях, каждая из версий содержит временную последовательность блоков данных, кодирующих части программы (и таким образом последовательность блоков данных, которые должны быть последовательно визуализированы), каждая из версий содержит одно и то же число блоков, каждый из блоков начинается с изображения, кодируемого без опоры на предыдущее изображение. В соответствии с изобретением способ содержит этапы, на уровне приемника, приема, в соответствии с протоколом транспорта в реальном времени, первой части аудиовизуальной программы, содержащей по меньшей мере один блок данных из первой из версий, передаваемой сервером на первой частоте следования битов, определения полосы пропускания после приема первой части аудиовизуальной программы, передаваемой упомянутым сервером на первой частоте следования битов, передачи запроса к серверу в соответствии с протоколом управления сервером в реальном времени, причем запрос содержит идентификационную информацию второй части аудиовизуальной программы в одной из версий программы в соответствии с определенным значением полосы пропускания между сервером и приемником и параметром скорости передачи, при этом идентификационная информация содержит временные маркеры начала и окончания второй части.
В соответствии с вариантом осуществления изобретения этапы приема, определения полосы пропускания и передачи запроса приемником воспроизводятся повторно в течение времени приема аудиовизуальной программы.
В соответствии с вариантом осуществления изобретения версии аудиовизуальной программы содержатся в единственном файле, хранимом на сервере.
В соответствии с вариантом осуществления изобретения аудиовизуальная программа связывается на сервере с дескриптивным файлом, содержащим информацию, относящуюся к локализации версий аудиовизуальной программы в одном и том же файле.
В соответствии с вариантом осуществления изобретения определение доступной полосы пропускания между сервером и приемником содержит анализ упомянутой по меньшей мере одной характеристики частей аудиовизуальной программы, принятой на первой частоте следования битов.
В соответствии с вариантом осуществления изобретения по меньшей мере одна характеристика частей представляет собой число переданных битов.
В соответствии с вариантом осуществления изобретения этап передачи запроса использует команду PLAY протокола RSTP.
Изобретение также относится к устройству приема для аудиовизуальной программы, распространяемой сервером, причем программа доступна на сервере в по меньшей мере двух версиях, каждая из этих версий соответствует разрешению изображения аудиовизуальной программы и содержит последовательность частей, каждая из версий содержит одно и то же число частей и каждая из частей начинается с intra-изображения. В соответствии с изобретением устройство содержит средство для приема, в соответствии с протоколом транспорта в реальном времени, первой части аудиовизуальной программы в первой из версий, передаваемой упомянутым сервером на первой частоте следования битов, средство для определения полосы пропускания после приема первой части упомянутой аудиовизуальной программы, передаваемой упомянутым сервером на первой частоте следования битов, и средство для передачи запроса к серверу, в соответствии с протоколом управления в реальном времени, при этом запрос содержит идентификационную информацию второй части аудиовизуальной программы в одной из версий программы, в соответствии с определенным значением полосы пропускания между сервером и приемником, и параметр скорости передачи, при этом идентификационная информация содержит временные маркеры начала и окончания второй части.
Частота следования битов при передаче, таким образом, подстраивается для адаптации к полосе пропускания, доступной в сети, и для избегания прерываний во время воссоздания аудиовизуальной программы, даже если это означает воссоздание программы с более низким уровнем качества.
Очевидно, изобретение не ограничивается использованием протоколов RTP и RTSP и касается любого протокола передачи в реальном времени и соответствующего протокола управления сервером, имеющего аналогичные особенности, как у RTP и RTSP соответственно, и, в частности, предоставляющих команды управления, такие как команда PLAY с параметрами, дающими возможность выбора версии, времени начала и продолжительности (или времени остановки) для части аудиовизуальной программы, которая должна быть воспроизведена (визуализирована).
Краткое описание чертежей
Изобретение будет лучше понято и другие специфические особенности и преимущества проявятся после прочтения следующего описания, описание ссылается на приложенные чертежи, на которых:
Фиг. 1 показывает систему для приема аудиовизуальных программ посредством приемника/декодера в соответствии с вариантом осуществления изобретения.
Фиг. 2 показывает способ для кодирования, позволяющий создавать файл, содержащий несколько версий одной и той же программы.
Фиг. 3 показывает файл сервера, содержащий несколько версий одной и той же аудиовизуальной программы, кодированной для распространения на различных частотах следования битов, в соответствии с вариантом осуществления изобретения.
Фиг. 4 схематически показывает последовательность сообщений инициализации между приемником и сервером для передачи потока в соответствии с протоколом передачи RTP.
Фиг. 5 показывает ряд сообщений инициализации между приемником и сервером для передачи потока в соответствии с вариантом осуществления изобретения.
Фиг. 6 представляет собой схему, которая показывает способ, осуществляемый в приемнике, содержащий систематическую оценку полосы пропускания сети и передачу запросов, содержащих параметр частоты следования битов и параметр частоты следования, адаптированные к состоянию сети.
Фиг. 7 представляет собой функциональную схему приемника в соответствии с вариантом осуществления изобретения.
Фиг. 8 представляет собой функциональную схему, показывающую блок управления приемника, описанного на фиг. 7.
Подробное описание изобретения.
В общем, и без ограничения, изобретение относится к способу для приема аудиовизуальной программы в виде потока, делающему возможной динамическую адаптацию частоты следования битов для передачи программы в соответствии с загруженностью сети, определяемой посредством систематического измерения полосы пропускания.
Фиг. 1 показывает систему для приема аудиовизуальных программ приемником 2 через сеть 3. В течение времени приема приемник обрабатывает аудиовизуальную программу и передает сигналы к устройству 4 отображения для ее отображения. Программы кодируются и доступны на сервере 1 программ. Программы хранятся в форме цифровых файлов. Методики передачи, санкционирующие передачу программ с переменными частотами следования битов в течение времени воссоздания, требуют специфического кодирования для того, чтобы сделать доступной на сервере аудиовизуальную программу в различных версиях, соответствующих различным частотам следования битов, в течение времени передачи данных, которые кодируют программу. Различные версии одной и той же аудиовизуальной программы сохраняются на сервере 1 программ. Различные версии могут быть сохранены в отдельных файлах или могут быть собраны вместе в единственном файле и могут идентифицироваться по их соответствующим положениям в файле. Файл описания, связанный с каждой из программ, содержит информацию, относящуюся к различным версиям, их соответствующим частотам следования битов и их местоположениям. Эта информация передается к приемнику во время фазы инициализации передачи программы с сервера на приемник.
Фиг. 2 показывает кодирование аудиовизуальной программы для того, чтобы она была передана с подстройкой частоты следования битов в соответствии с условиями передачи в сети. Аудиовизуальная программа кодируется в несколько версий. Каждая из версий соответствует разрешению изображения и, таким образом, частоты следования битов при передаче. В каждой из версий программа состоит из последовательности блоков или групп изображений. Все блоки соответствуют элементарной продолжительности воссоздания (или воспроизведения) программы, например 2 секундам. Эти элементарные блоки обычно называют кусками, например, в случае технологии адаптивной потоковой передачи HTTP. Первое изображение каждого из блоков представляет собой intra-изображение. Intra-изображение определяется как изображение, закодированное без опоры на предыдущее изображение. Положение intra-изображений в начале блока является одним и тем же в каждой из версий. Таким образом, если приемник запрашивает сервер доставить следующий блок в непрерывности программы с точки зрения просматриваемого контента, но в другой версии и, таким образом, с другой частотой следования битов при передаче, декодер, интегрированный в приемник, может осуществить декодирование блока без проблем опоры на предыдущие изображения. Фиг. 2 описывает кодирование программы в версиях, соответствующих, в указанном порядке, частотам следования битов при приеме (и, таким образом, при передаче) 500 Кбит/с, 1 Мбит/с, 1,5 Мбит/с и 2 Мбит/с.
Фиг. 3 показывает файл 30, содержащий несколько версий 31, 32, 33, 34 одной и той же аудиовизуальной программы, как, например, из способа кодирования, показанного на фиг. 2. Различные версии размещаются в одном и том же файле с различными индексами. Переход от одной версии к другой во время передачи программы, таким образом, соответствует добавлению индекса к указателю воспроизведения. Версия аудиовизуальной программы соответствует каждому из возможных значений индекса, добавленных к указателю. Указатель идентифицирует временное положение части программы, которая должна быть воссоздана.
Фиг. 4 показывает установление связи между приемником и сервером распределения в соответствии с вариантом осуществления изобретения, используя стандарт передач RTP. Во время инициализации распределения, которое использует протокол RTP, приемник направляет (адресует) на сервер первое сообщение, озаглавленное RTSP DESCRIBE, включающее в себя url-адрес, для того чтобы получить от сервера информацию, относящуюся к программе, которая будет просматриваться на устройстве отображения, подсоединенном к приемнику. Термин url-адрес (унифицированный указатель ресурсов) описывает здесь сетевой адрес, который указывает на программу, подлежащую просмотру. Этот адрес имеет, например, синтаксис “multimedia.exemple.com”. Сервер направляет информацию к приемнику в сообщении ответа, озаглавленном RTSP DESCRIBE RESPONSE. Сообщение RTSP DESCRIBE RESPONSE указывает приемнику, хранятся ли версии программы на сервере в отдельных файлах или соединяются в единственном файле. Второй запрос, озаглавленный RTSP SETUP, затем направляется на сервер через приемник для того, чтобы подготовить сеанс потоковой передачи программы. Если различные версии программы хранятся на сервере в отдельных файлах, приемник затем инициализирует с сервером такое количество сеансов передачи, сколько имеются доступных версий. Если различные версии соединяются в одном и том же файле на сервере, приемник инициализирует единственный сеанс передачи. В случае, когда различные версии программы соединены в одном и том же файле, приемник добавит индекс к указателю воспроизведения, чтобы переходить от одной версии программы к другой и, таким образом, подстраивать частоту следования битов при передаче части воспроизводимой программы. Для каждого запроса инициализации сеанса, выполняемого приемником, сервер отвечает сообщением, озаглавленным RTSP SETUP RESPONSE. Третье сообщение, озаглавленное RTSP PLAY, отправленное приемником, запускает передачу программы сервером. Сообщение RTSP PLAY все еще называется запросом и содержит параметр временного маркера части программы, которая должна быть передана в целях ее воссоздания. Сообщение PLAY также содержит параметр скорости, указывающий серверу скорость, на которой передавать данные, которые соответствуют части программы, которая должна быть передана.
В соответствии с вариантом осуществления изобретения контент аудиовизуальной программы кодируется в соответствии с кодеками H.264 для видео и кодеками AAC для аудио, размер блока элементарных данных, начинающегося с intra-изображения, соответствует продолжительности 2 секунды при воссоздании, инкапсуляция данных делается в соответствии с форматом транспортного потока MPEG, и частоты следования битов, связанные с различными версиями, составляют 500 Кбит/с, 1 Мбит/с, 1,5 Мбит/с и 2 Мбит/с. Файл описания, связанный на сервере с файлом контента аудиовизуальной программы и содержащий информацию о различных версиях программы и о различных связанных частотах следования битов, представляет собой файл формата SDP, который имеет, например, следующую форму:
v=0
o=-11 IN IP4 192.168.1.33
s=Example of multimedia stream (Пример мультимедийного потока)
b=RR:0
a=X-keyframe-period=2
a=control:*
a=range:npt=0-300
m=video 0 RTP/AVP 33
b=TIAS:500000
a=control:trackID=0
m=video 0 RTP/AVP 33
b=TIAS:1000000
a=control:trackID=1
m=video 0 RTP/AVP 33
b=TIAS:1500000
a=control:trackID=2
m=video 0 RTP/AVP 33
b=TIAS:2000000
a=control:trackID=3
В этом примере файла SDP четыре потока (транспортные потоки MPEG) отмечаются и связываются с их соответствующими частотами следования битов посредством использования параметра b=TIAS, который соответствует частоте следования битов, выраженной в Мбит/с.
Фиг. 5 показывает установление связи между приемником и сервером распределения в соответствии с вариантом осуществления изобретения и когда различные версии программы, подлежащей просмотру, хранятся в отдельных файлах на сервере. Приемник инициализирует прием части аудиовизуальной программы, которая должна быть воссоздана из различных потоков. Во время упомянутого восстановления и для каждой части программы, запрашиваемой одна за другой, приемник указывает на сервер версию, адаптированную к состоянию полосы пропускания в сети, и принимает данные соответствующего потока. Каждый поток соответствует передаче данных из одной и той же версии. В соответствии с вариантом осуществления приемник направляет столько сообщений инициализации, сколько имеется доступных версий, до передачи.
Как только фаза инициализации (SETUP) была завершена для каждой из версий, приемник может переходить от одной версии к другой посредством отправки запроса PLAY, точно определяющего версию и временной интервал (посредством использования временных маркеров), соответствующие требуемому блоку, также как и скорости передачи. В соответствии с другим вариантом осуществления приемник может направлять запросы инициализации SETUP перед первым доступом к версии в течение времени передачи.
Фиг. 6 представляет собой блок-схему, которая показывает способ, используемый приемником, в соответствии с вариантом осуществления изобретения. Этап S1 представляет собой начальный этап, на котором приемник не инициализировал прием программы в виде потока. На этом этапе приемник находится в состоянии ожидания команды от пользователя, управляющего приемником. На этапе S2 приемник инициализирует сеанс потокового распределения. Он отправляет первое сообщение RTSP DESCRIBE, точно определяющее целевой url-адрес аудиовизуальной программы, которая должна быть принята от сервера для восстановления. Этот url-адрес может представлять собой, например, rtsp://exemple.com/movie/. Этот целевой адрес служит в качестве ссылки для управления распределением. Сервер направляет сообщение типа RTSP DESCRIBE RESPONSE, которое указывает приемнику характеристики потока передач, соответствующие различным версиям аудиовизуальной программы, кодированной для ее распространения на различных частотах следования битов. Эта информация содержит число версий, их соответствующие идентификаторы, частоты следования битов кодирования и размер блоков данных. Следующие обмены сообщениями, RTSP SETUP, передаваемое от приемника, и RTSP SETUP RESPONSE, передаваемое от сервера, подготавливают сеанс распределения потоковой передачи. Приемник сохраняет информацию, принятую в фазе S2 инициализации, и имеет возможность направлять последовательные запросы RTSP PLAY на распределение и прием частей (содержащих один или несколько блоков данных) аудиовизуальной программы. На этапе S3 приемник передает запрос RTSP PLAY, который содержит параметры, специфические для распределения части программ, которая должна быть принята (и, таким образом, должна быть распространена сервером).
Структура запроса RTSP PLAY в соответствии с вариантом осуществления изобретения:
PLAY rtsp://multimedia.exemple.com/stream/trackID=1 RTSP/1.0
Cseq: 833
Range: npt=0-2
Speed:1
Где PLAY указывает, что запрос представляет собой сообщение, запрашивающее распределение блока данных, в целях его восстановления.
Cseq указывает число последовательности, указанное сервером на этапе S2 инициализации, Range указывает часть программы, соответствующую временному положению от 0 до 2 секунд от начала распределения, и Speed указывает скорость распределения.
Чтобы избежать прерываний во время восстановления аудиовизуальной программы, приемник направляет запросы RTSP PLAY на следующую часть программы заранее, чтобы поддерживать достаточное количество данных в буфере приема. Преимущественно буфер приема содержит 2 секунды программы, принимаемой и доступной перед декодированием. Предпочтительно и для того, чтобы поглощать флуктуации в доступной полосе пропускания в сети, буфер приема может содержать некоторое число элементов данных, соответствующих нескольким секундам восстановления передаваемой аудиовизуальной программы.
В соответствии с вариантом осуществления изобретения и в целях упрощения распределение блоков данных из различных версий делается в течение времени единственного сеанса RTSP. Таким образом, выгодно соединить различные версии кодируемой программы в единственном файле на сервере.
Если предположить, что аудиовизуальная программа с продолжительностью d кодируется с частотой следования битов B0=500 Кбит/с, B1=1 Мбит/с, B2=1,5 Мбит/с и B3=2 Мбит/с, доступ к i-й версии программы, кодируемой на частоте следования битов Bi от временного положения t, параметр Range соответствующего запроса RTSP PLAY будет определяться следующим образом:
Range=i×d+t.
На этапе S4 приемник принимает блок данных, кодирующий часть программы, заданную на сервере. Приемник сохраняет этот блок данных в буфере приема, где он будет считан модулем аудио/видеодекодирования приемника.
Этап S5 определяет, была ли часть, ранее принятая на этапе S4, последней из программы, и, если это так, распределение завершается.
На этапе S6 и в случае, когда часть данных, принятых на этапе S4, не является последней из аудиовизуальной программы с точки зрения временного положения, приемник осуществляет оценку доступной полосы пропускания в сети.
Оценка полосы пропускания содержит в соответствии с вариантом осуществления изобретения этапы для определения частоты следования битов распределения, возможной от сервера, и этапы для измерения частоты следования битов за заранее определенный период. Предпочтительно оценка полосы пропускания может содержать этап взвешивания. В соответствии с вариантом осуществления изобретения этап взвешивания содержит этап сглаживания или интегрирования, который дает возможность получения среднего значения, преодолевая быстрые изменения в полосе пропускания около этого значения. Приемник содержит буферную память (буфер приема), способную поглотить быстрые изменения в полосе пропускания сети.
В соответствии с изобретением оценка полосы пропускания может повторяться для каждого из элементарных блоков данных или для части программы, содержащей заранее определенное число элементарных блоков данных.
В соответствии с вариантом осуществления изобретения приемник использует информацию, передаваемую сервером в ответ на запрос RTSP PLAY, чтобы провести оценку полосы пропускания.
Ответ, передаваемый сервером на запрос RTSP PLAY, имеет следующий вид:
RTSP/1,0 200 OK
Cseq: 834
Range: npt=0-2
RTP-Info: url=rtsp://multimedia.exemple.com/stream/trackID=1;
seq=45102; rtptime=12345678
Где rtptime представляет собой временной маркер, указывающий начало части программы, указанной посредством интервала npt.
Если, например, рассматривается временная программа потока, кодируемого в формате MPEG-2 TS, имеющая значение 9000, переданное приемнику на этапе инициализации сеанса передачи, приемник может вычислить временной интервал rangeduration, соответствующий времени приема блока данных:
rangeduration=rtptime end-rtptime start.
Где rtptime start представляет собой значение параметра rtptime, указанное в информационном поле RTP-Info ответа сервера,
и rtptime end=rtptime поля RTP-lnfo+90000.
Где 90000 представляет собой время RTP, указанное во время фазы инициализации сеанса распределения.
Мгновенная частота следования битов за период приема блока данных затем вычисляется посредством сложения числа байтов данных, принимаемых за временной интервал (байты, которые составляют пакеты данных распределения, в соответствии с протоколом RTP), умножения числа байтов на 8, чтобы получить число битов (двоичные элементы), и деления результата умножения на продолжительность приема.
А именно выражение мгновенной частоты следования битов:
Bi=Байты×8/rangeduration.
В соответствии с вариантом осуществления изобретения, значение мгновенной частоты следования битов, вычисленное таким образом, затем используется в алгоритме сглаживания для того, чтобы определить более точное значение частоты следования битов.
Алгоритм использует итеративный процесс для того, чтобы определить частота следования битов, которая может быть достигнута, рассматривая значения мгновенных частот следования битов, вычисленных в предыдущих итерациях:
i - индекс, который относится к i-й итерации вычисления полезной частоты следования битов и ее дисперсии, в течение времени передачи принятых данных.
Оценка частоты следования битов в будущем для следующей итерации вычисляется таким образом:
где 
представляет собой измеренную частота следования битов,
Преимущественно значение α равно 1/16.
Дополнительно к взвешенному среднему значению алгоритм, используемый изобретением, оценивает дисперсию в отношении частоты следования битов. Дисперсия сглаживается таким же образом, как частота следования битов:
Δi=| 
-
|,
где Δi представляет собой разность между измеренной частотой следования битов и средней частотой следования битов для текущей итерации вычисления,
vari представляет собой дисперсию, вычисленную для текущей итерации, величина β представляет собой весовой коэффициент для значения дисперсии текущей оценки.
Преимущественно значение β равно 1/8.
Для каждой из итераций алгоритма, оценка частоты следования битов, которая может быть достигнута для распределения аудиовизуальной программы, вычисляется следующим образом:
Таким образом, если дисперсия большая, это означает, что приемник использует меньшую, чем средняя доступная полоса пропускания. Кроме того, когда полоса пропускания устойчивая, и дисперсия низкая, приемник использует всю полосу пропускания доступную между ним и сервером.
Предпочтительно в случае, когда приемник использует всю доступную полосу пропускания, он направляет серверу запросы RTSP PLAY, нацеленные на группировку нескольких элементарных частей принимаемой программы, это делается для того, чтобы избежать перегрузки сервера слишком систематическими запросами. Приемник может, например, запросить в одном и том же запросе к серверу два или четыре элементарных блока данных.
В соответствии с вариантом осуществления изобретения, когда дисперсия слишком большая, например, если ее значение больше чем половина значения частоты следования битов, оценки частоты следования битов и дисперсии вычисляются следующим образом:
и
В соответствии с вариантом осуществления изобретения приемник определяет, дает ли сеть возможность распределения на частоте следования битов большей, чем текущая частота следования битов, посредством указания на ту же самую версию аудиовизуальной программы и модификации параметра скорости, определенного в протоколе управления RTSP. Если текущая частота следования битов составляет, например, 1,5 Мбит/с, приемник оценивает пропускную возможность сети передавать на 2 Мбит/с посредством отправки запроса на сервер, точно определяющего параметр “Speed” значением Speed=1,34.
Запрос RTSP, передаваемый, чтобы принять блок данных, соответствующий временному интервалу между второй и четвертой секундой аудиовизуальной программы, локализованной с помощью url-адреса “multimedia.exemple.com/stream”, имеет частоту следования битов 2 Мбит/с, в то время как текущая частота следования битов при распределении составляет 1,5 Мбит/с, имеет, например, следующий вид:
PLAY rtsp://multimedia.exemple.com/stream/tracklD=1 RTSP/1,0
Cseq: 833
Range: npt=2-4
Speed: 1,34
На этапе S7 приемник определяет параметры запроса для направления на сервер, принимая во внимание результат вычисления доступной полосы пропускания и дисперсию полосы пропускания. В соответствии с вариантом осуществления изобретения приемник модифицирует параметр скорости (“speed”) запроса RTSP в соответствии с комбинациями значений, вычисленных из полосы пропускания и дисперсии. Например, в соответствии с вариантом осуществления изобретения и в случае загруженности сети, которая может привести не только к уменьшению скорости передачи, но также и к потере данных, приемник осуществляет новый запрос для того, чтобы принять потерянные данные в соответствующей версии с более низкой частотой следования битов и увеличенной скоростью передачи. Использование более низкой частоты следования битов и увеличенной скорости передачи дает возможность, с одной стороны, уменьшить количество данных, которые передаются между сервером и приемником, но также и быстро компенсировать потерю времени, которая является результатом потери данных, ранее переданных сервером. В соответствии с вариантом осуществления изобретения приемник использует порядковый номер заголовка пакета RTP, который транспортирует данные, для того чтобы обнаружить потерю данных в течение времени передачи части программы. Вследствие потери данных и необходимости повторной передачи данных происходит сокращение скорости наполнения буфера приема и увеличение риска из-за артефактов, связанных с потерей данных в буфере, во время восстановления программы. Предпочтительно приемник затем направляет запрос RTSP PLAY, указывающий более низкую частоту следования битов и параметр скорости, больший чем 1, прежде чем заново осуществлять алгоритм, описанный ранее.
Фиг. 7 показывает устройство приема 2, адаптированное для приема и отображения аудиовизуальной программы, в соответствии с вариантом осуществления изобретения. Двунаправленный сетевой интерфейс 201 дает возможность воссоздания приема данных, кодирующих аудиовизуальную программу. Интерфейс 201 также дает возможность передачи и приема сообщений управления к и от сервера распределения. Демультиплексор 202 фильтрует данные, относящиеся к приему программы, из потока приема, а также из сообщений управления и сохраняет их в буфере 203 приема. Данные, которые кодируют аудиовизуальную программу, считываются аудио/видеодекодером 204, который декодирует их и передает соответствующие сигналы к интерфейсу 205 вывода. Устройство отображения (не показывается), подсоединенное к интерфейсу 205 вывода, дает возможность отображения программы для пользователя. Набор элементов 201, 202, 203, 204 и 205 управляется посредством блока 200 управления, который содержит в соответствии с вариантом осуществления изобретения микроконтроллер и связанные памяти, дающие возможность исполнения подпрограмм программного обеспечения, а также обработки данных. Блок 200 управления анализирует, дополнительно, сообщения управления при приеме от сервера и генерирует сообщения управления, передаваемые на сервер.
Фиг. 8 показывает блок 200 управления в соответствии с вариантом осуществления изобретения. Блок управления содержит микроконтроллер 210, ответственный за исполнение приложений программного обеспечения. Исполняемый код приложений сохраняется в энергонезависимой памяти 211 при вводе в эксплуатацию приемника 2 и может быть скопирован в рабочую память 212, когда приемник 2 является действующим. Рабочая память 212 содержит память с произвольной выборкой для хранения данных, специфических для исполнения программных приложений и хранения принятых данных. Блок 200 управления также содержит модуль 213 для оценки полосы пропускания. Модуль 213 оценки полосы пропускания вычисляет доступную полосу пропускания в линии связи между сервером и приемником 2, используя данные, считываемые из буфера приема. Модуль 214 управления RTSP составляет запрос RTSP в соответствии со значением полосы пропускания, вычисленным и доступной в модуле 213 оценки. Модуль управления RTSP считывает данные, которые составляют ответ на запрос RTSP PLAY, в буфере приема и передает временной маркер rtptime на модуль 213 оценки. Данные передаваемые между различными модулями блока 200 управления передаются через внутреннюю шину 216. Обмены множества данных с другими функциональными модулями приемника осуществляются через модуль 215 интерфейса.
Изобретение описано в настоящем документе с вариантом осуществления, основанном на протоколах RTP и RTSP, но изобретение, очевидно, не ограничивается использованием протоколов RTP и RTSP. Изобретение также имеет отношение к любому протоколу передачи в реальном времени и соответствующему протоколу управления сервером, имеющему подобные особенности, как соответственно RTP и RTSP, и, в частности, обеспечивающему команды управления, такие как команда PLAY с параметрами, дающими возможность определять, (выбирать) версию, время начала и продолжительность (или время остановки) для части аудиовизуальной программы, которая должна быть воспроизведена (визуализирована).
Claims (12)
1. Способ для приема аудиовизуальной программы, хранимой на сервере для воспроизведения на устройстве отображения, подсоединенном к приемнику, упомянутая аудиовизуальная программа доступна на упомянутом сервере в по меньшей мере двух версиях, каждая из упомянутых версий содержит последовательность блоков данных, представляющих соответствующие части упомянутой аудиовизуальной программы, которые должны быть последовательно визуализированы, каждая из упомянутых версий содержит одно и то же число блоков, каждый из упомянутых блоков начинается с изображения, кодированного без опоры на предыдущее изображение, упомянутый способ содержит этап, на котором принимают, на уровне упомянутого приемника, согласно протоколу транспорта, первую часть упомянутой аудиовизуальной программы, содержащую по меньшей мере один блок данных из первой из упомянутых версий, передаваемой упомянутым сервером на первой частоте следования битов, упомянутая первая часть является подмножеством файла на упомянутом сервере, упомянутый файл содержит множество частей, положение каждой из упомянутых частей указывается в упомянутом файле посредством индексации, упомянутый способ отличается тем, что он дополнительно содержит, на уровне упомянутого приемника, этапы, на которых:
- определяют полосу пропускания после приема упомянутой первой части упомянутой аудиовизуальной программы, передаваемой упомянутым сервером на упомянутой первой частоте следования битов,
- передают запрос, в соответствии с протоколом управления, на сервер, упомянутый протокол управления адаптирован для управления передачей контента в реальном времени посредством использования команд и адаптирован для идентификации в файле части данных, которая должна быть передана из числа нескольких частей данных, упомянутая идентификация достигается с помощью индексации, упомянутый запрос содержит:
- идентификационную информацию второй части упомянутой аудиовизуальной программы в одной из упомянутых версий упомянутой программы согласно значению, определенному из полосы пропускания между упомянутым сервером и упомянутым приемником,
упомянутая идентификационная информация содержит временные маркеры начала и окончания упомянутой второй части.
- определяют полосу пропускания после приема упомянутой первой части упомянутой аудиовизуальной программы, передаваемой упомянутым сервером на упомянутой первой частоте следования битов,
- передают запрос, в соответствии с протоколом управления, на сервер, упомянутый протокол управления адаптирован для управления передачей контента в реальном времени посредством использования команд и адаптирован для идентификации в файле части данных, которая должна быть передана из числа нескольких частей данных, упомянутая идентификация достигается с помощью индексации, упомянутый запрос содержит:
- идентификационную информацию второй части упомянутой аудиовизуальной программы в одной из упомянутых версий упомянутой программы согласно значению, определенному из полосы пропускания между упомянутым сервером и упомянутым приемником,
упомянутая идентификационная информация содержит временные маркеры начала и окончания упомянутой второй части.
2. Способ по п. 1, отличающийся тем, что упомянутый запрос дополнительно содержит параметр скорости передачи.
3. Способ по п. 1 или 2, отличающийся тем, что этап приема использует протокол передачи RTP.
4. Способ по любому из пп. 1, 2, отличающийся тем, что этап передачи запроса использует протокол управления RTSP.
5. Способ по любому из пп. 1, 2, отличающийся тем, что упомянутые версии упомянутой аудиовизуальной программы содержатся в одном файле, хранимом на упомянутом сервере.
6. Способ по любому из пп. 1, 2, отличающийся тем, что упомянутая аудиовизуальная программа связана на упомянутом сервере с дескриптивным файлом, содержащим информацию, относящуюся к локализации упомянутых версий упомянутой аудиовизуальной программы в упомянутом одном файле.
7. Способ по любому из пп. 1, 2, отличающийся тем, что определение доступной полосы пропускания между упомянутым сервером и упомянутым приемником содержит анализ по меньшей мере одной характеристики упомянутых частей упомянутой аудиовизуальной программы, принятых на упомянутой первой частоте следования битов.
8. Способ по п. 7, отличающийся тем, что упомянутая по меньшей мере одна характеристика упомянутых частей представляет собой число переданных битов.
9. Способ по любому из пп. 1, 2, отличающийся тем, что этап передачи запроса использует команду PLAY протокола RTSP.
10. Способ по любому из пп. 1, 2, отличающийся тем, что этап определения полосы пропускания между упомянутым сервером и упомянутым приемником использует ответ сервера на команду PLAY протокола RTSP.
11. Устройство для приема аудиовизуальной программы, распространяемой сервером, упомянутая программа доступна на упомянутом сервере в по меньшей мере двух версиях, каждая из упомянутых версий соответствует разрешению изображения упомянутой аудиовизуальной программы и содержит последовательность частей, каждая из упомянутых версий начинается с intra-изображения, упомянутое устройство отличается тем, что оно содержит:
- сетевой интерфейс для приема, согласно протоколу транспорта, первой части упомянутой аудиовизуальной программы в первой из упомянутых версий, распространяемой упомянутым сервером на первой частоте следования битов,
- блок управления для определения полосы пропускания после приема упомянутой первой части упомянутой аудиовизуальной программы, распространяемой упомянутым сервером на упомянутой первой частоте следования битов,
- сетевой интерфейс для передачи запроса на сервер согласно протоколу управления, упомянутый протокол управления адаптирован для управления передачей контента в реальном времени посредством использования команд и адаптирован для идентификации в файле части данных, которая должна быть передана из числа нескольких частей данных, упомянутая идентификация достигается посредством индексации, упомянутый запрос содержит:
- идентификационную информацию второй части упомянутой аудиовизуальной программы в одной из упомянутых версий упомянутой программы согласно значению, определенному из полосы пропускания между упомянутым сервером и упомянутым приемником,
- упомянутая идентификационная информация содержит временные маркеры начала и окончания упомянутой второй части.
- сетевой интерфейс для приема, согласно протоколу транспорта, первой части упомянутой аудиовизуальной программы в первой из упомянутых версий, распространяемой упомянутым сервером на первой частоте следования битов,
- блок управления для определения полосы пропускания после приема упомянутой первой части упомянутой аудиовизуальной программы, распространяемой упомянутым сервером на упомянутой первой частоте следования битов,
- сетевой интерфейс для передачи запроса на сервер согласно протоколу управления, упомянутый протокол управления адаптирован для управления передачей контента в реальном времени посредством использования команд и адаптирован для идентификации в файле части данных, которая должна быть передана из числа нескольких частей данных, упомянутая идентификация достигается посредством индексации, упомянутый запрос содержит:
- идентификационную информацию второй части упомянутой аудиовизуальной программы в одной из упомянутых версий упомянутой программы согласно значению, определенному из полосы пропускания между упомянутым сервером и упомянутым приемником,
- упомянутая идентификационная информация содержит временные маркеры начала и окончания упомянутой второй части.
12. Устройство по п. 11, отличающееся тем, что упомянутый запрос дополнительно содержит параметр скорости передачи.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1154334 | 2011-05-18 | ||
| FR1154334A FR2975555A1 (fr) | 2011-05-18 | 2011-05-18 | Methode d'adaptation dynamique du debit de reception et recepteur associe |
| PCT/EP2012/058187 WO2012156211A1 (en) | 2011-05-18 | 2012-05-04 | Method for dynamic adaptation of the reception bitrate and associated receiver |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| RU2013156038A RU2013156038A (ru) | 2015-06-27 |
| RU2598805C2 true RU2598805C2 (ru) | 2016-09-27 |
Family
ID=46025738
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| RU2013156038/08A RU2598805C2 (ru) | 2011-05-18 | 2012-05-04 | Способ для динамической адаптации частоты следования битов при приеме и соответствующий приемник |
Country Status (14)
| Country | Link |
|---|---|
| US (1) | US10015225B2 (ru) |
| EP (1) | EP2710778B1 (ru) |
| JP (1) | JP6436772B2 (ru) |
| KR (1) | KR102012528B1 (ru) |
| CN (1) | CN103548318B (ru) |
| CA (1) | CA2835384A1 (ru) |
| FR (1) | FR2975555A1 (ru) |
| HK (1) | HK1194882A1 (ru) |
| HU (1) | HUE026744T2 (ru) |
| MX (1) | MX2013013373A (ru) |
| MY (1) | MY168875A (ru) |
| RU (1) | RU2598805C2 (ru) |
| TW (1) | TWI573450B (ru) |
| WO (1) | WO2012156211A1 (ru) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3120605B1 (en) * | 2014-03-17 | 2020-01-08 | Telefonaktiebolaget LM Ericsson (publ) | Congestion level configuration for radio access network congestion handling |
| GB2519391B (en) * | 2014-04-02 | 2015-10-21 | Imagination Tech Ltd | Enhanced media quality management |
| US9767101B2 (en) * | 2014-06-20 | 2017-09-19 | Google Inc. | Media store with a canonical layer for content |
| EP3035628A1 (en) * | 2014-12-18 | 2016-06-22 | Alcatel Lucent | Method for analyzing a bitrate of user traffic of a data communication over a data communications line, and related devices |
| KR102313485B1 (ko) * | 2015-04-22 | 2021-10-15 | 삼성전자주식회사 | 가상현실 스트리밍 서비스를 위한 영상 데이터를 송수신하는 방법 및 장치 |
| CN104934049B (zh) * | 2015-06-24 | 2018-03-16 | 深圳市九洲电器有限公司 | 一种变比特率mp3播放时间获取方法及*** |
| EP3863296B1 (en) * | 2017-09-11 | 2023-11-22 | Tiledmedia B.V. | Streaming frames of spatial elements to a client device |
| US10484730B1 (en) * | 2018-01-24 | 2019-11-19 | Twitch Interactive, Inc. | Chunked transfer mode bandwidth estimation |
| US11875478B2 (en) * | 2020-08-28 | 2024-01-16 | Nvidia Corporation | Dynamic image smoothing based on network conditions |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040133919A1 (en) * | 2001-05-10 | 2004-07-08 | Incentis Fernando Carro | System and method for enhancing recorded radio or television programs with information on the world wide web |
| RU2251817C2 (ru) * | 1999-01-25 | 2005-05-10 | КАНАЛЬ+ Сосьетэ Аноним | Присваивание адресов в системе цифровой передачи |
| US20090148132A1 (en) * | 2007-12-11 | 2009-06-11 | Cisco Technology, Inc. | Inferential processing to ascertain plural levels of picture interdependencies |
| US7697475B2 (en) * | 2003-03-26 | 2010-04-13 | Thomson Licensing S.A. | Processing a data stream format for mobile audiovisual reception |
| US20100161716A1 (en) * | 2008-12-22 | 2010-06-24 | General Instrument Corporation | Method and apparatus for streaming multiple scalable coded video content to client devices at different encoding rates |
Family Cites Families (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6763392B1 (en) | 2000-09-29 | 2004-07-13 | Microsoft Corporation | Media streaming methods and arrangements |
| FI116498B (fi) | 2002-09-23 | 2005-11-30 | Nokia Corp | Kaistanleveyden mukauttaminen |
| WO2004072765A2 (en) * | 2003-02-13 | 2004-08-26 | Nokia Corporation | Method for signaling streaming quality adaptation and control mechanisms in multimedia streaming |
| US8868772B2 (en) | 2004-04-30 | 2014-10-21 | Echostar Technologies L.L.C. | Apparatus, system, and method for adaptive-rate shifting of streaming content |
| JP2007036666A (ja) | 2005-07-27 | 2007-02-08 | Onkyo Corp | コンテンツ配信システム、クライアント及びクライアントプログラム |
| EP1879346A1 (en) * | 2006-07-14 | 2008-01-16 | Sony Service Centre (Europe) N.V. | System and method of audio/video streaming |
| US8773494B2 (en) * | 2006-08-29 | 2014-07-08 | Microsoft Corporation | Techniques for managing visual compositions for a multimedia conference call |
| US8346959B2 (en) * | 2007-09-28 | 2013-01-01 | Sharp Laboratories Of America, Inc. | Client-controlled adaptive streaming |
| US20090259756A1 (en) * | 2008-04-11 | 2009-10-15 | Mobitv, Inc. | Transmitting media stream bursts |
| US7921222B2 (en) * | 2008-05-06 | 2011-04-05 | Vantrix Corporation | Method and system for fast channel switching using standard RTSP messages |
| JP5322518B2 (ja) * | 2008-07-08 | 2013-10-23 | キヤノン株式会社 | 通信方法 |
| US20100121974A1 (en) | 2008-11-11 | 2010-05-13 | Einarsson Torbjoem | Stepwise probing for adaptive streaming in a packet communication network |
| US8621044B2 (en) * | 2009-03-16 | 2013-12-31 | Microsoft Corporation | Smooth, stateless client media streaming |
| CA2711311C (en) * | 2009-08-10 | 2016-08-23 | Seawell Networks Inc. | Methods and systems for scalable video chunking |
| EP2486491A4 (en) * | 2009-10-06 | 2013-10-23 | Unwired Planet Llc | MANAGING NETWORK TRAFFIC BY EDITING A MANIFEST FILE AND / OR USING A INTERMEDIATE FLOW CONTROL |
| JP2011087103A (ja) * | 2009-10-15 | 2011-04-28 | Sony Corp | コンテンツ再生システム、コンテンツ再生装置、プログラム、コンテンツ再生方法、およびコンテンツサーバを提供 |
| EP2510669A4 (en) * | 2009-12-11 | 2013-09-18 | Nokia Corp | DEVICE AND METHODS FOR DESCRIBING SYNCHRONIZATION REPRESENTATIONS IN CONTINUOUSLY TRANSMITTED MULTIMEDIA FILES |
| CN101848205A (zh) * | 2010-03-16 | 2010-09-29 | 深圳市同洲电子股份有限公司 | 一种基于rtsp的移动终端播放流媒体的方法及*** |
| US8914534B2 (en) * | 2011-01-05 | 2014-12-16 | Sonic Ip, Inc. | Systems and methods for adaptive bitrate streaming of media stored in matroska container files using hypertext transfer protocol |
| WO2012134530A1 (en) * | 2011-04-01 | 2012-10-04 | Intel Corporation | Cross-layer optimized adaptive http streaming |
-
2011
- 2011-05-18 FR FR1154334A patent/FR2975555A1/fr not_active Withdrawn
-
2012
- 2012-05-04 WO PCT/EP2012/058187 patent/WO2012156211A1/en active Application Filing
- 2012-05-04 MX MX2013013373A patent/MX2013013373A/es active IP Right Grant
- 2012-05-04 CN CN201280023415.XA patent/CN103548318B/zh active Active
- 2012-05-04 TW TW101115870A patent/TWI573450B/zh not_active IP Right Cessation
- 2012-05-04 EP EP12718240.0A patent/EP2710778B1/en active Active
- 2012-05-04 KR KR1020137030154A patent/KR102012528B1/ko active IP Right Grant
- 2012-05-04 US US14/117,973 patent/US10015225B2/en active Active
- 2012-05-04 MY MYPI2013003857A patent/MY168875A/en unknown
- 2012-05-04 HU HUE12718240A patent/HUE026744T2/en unknown
- 2012-05-04 JP JP2014510722A patent/JP6436772B2/ja active Active
- 2012-05-04 CA CA2835384A patent/CA2835384A1/en not_active Abandoned
- 2012-05-04 RU RU2013156038/08A patent/RU2598805C2/ru active
-
2014
- 2014-08-11 HK HK14108202.1A patent/HK1194882A1/zh not_active IP Right Cessation
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2251817C2 (ru) * | 1999-01-25 | 2005-05-10 | КАНАЛЬ+ Сосьетэ Аноним | Присваивание адресов в системе цифровой передачи |
| US20040133919A1 (en) * | 2001-05-10 | 2004-07-08 | Incentis Fernando Carro | System and method for enhancing recorded radio or television programs with information on the world wide web |
| US7697475B2 (en) * | 2003-03-26 | 2010-04-13 | Thomson Licensing S.A. | Processing a data stream format for mobile audiovisual reception |
| US20090148132A1 (en) * | 2007-12-11 | 2009-06-11 | Cisco Technology, Inc. | Inferential processing to ascertain plural levels of picture interdependencies |
| US20100161716A1 (en) * | 2008-12-22 | 2010-06-24 | General Instrument Corporation | Method and apparatus for streaming multiple scalable coded video content to client devices at different encoding rates |
Also Published As
| Publication number | Publication date |
|---|---|
| JP6436772B2 (ja) | 2018-12-12 |
| MY168875A (en) | 2018-12-04 |
| CN103548318A (zh) | 2014-01-29 |
| EP2710778A1 (en) | 2014-03-26 |
| MX2013013373A (es) | 2014-07-30 |
| HUE026744T2 (en) | 2016-07-28 |
| HK1194882A1 (zh) | 2014-10-24 |
| EP2710778B1 (en) | 2016-01-06 |
| TWI573450B (zh) | 2017-03-01 |
| CA2835384A1 (en) | 2012-11-22 |
| US10015225B2 (en) | 2018-07-03 |
| JP2014520422A (ja) | 2014-08-21 |
| KR20140023983A (ko) | 2014-02-27 |
| CN103548318B (zh) | 2019-01-08 |
| RU2013156038A (ru) | 2015-06-27 |
| FR2975555A1 (fr) | 2012-11-23 |
| WO2012156211A1 (en) | 2012-11-22 |
| KR102012528B1 (ko) | 2019-08-20 |
| TW201249185A (en) | 2012-12-01 |
| US20140189142A1 (en) | 2014-07-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| RU2598805C2 (ru) | Способ для динамической адаптации частоты следования битов при приеме и соответствующий приемник | |
| US10911506B2 (en) | Methods for quality-aware adaptive streaming over hypertext transfer protocol and reporting quality of experience | |
| US9386308B2 (en) | Quality optimization with buffer and horizon constraints in adaptive streaming | |
| JP7307211B2 (ja) | クライアント、サーバ、受信方法及び送信方法 | |
| WO2013081617A1 (en) | Scalable video coding over real-time transport protocol | |
| CN111886875B (zh) | 一种通过网络传送媒体内容的方法及服务器 | |
| US20160072864A1 (en) | Method and client terminal for receiving a multimedia content split into at least two successive segments, and corresponding computer program product and computer readable mediium | |
| US20120303833A1 (en) | Methods for transmitting and receiving a digital signal, transmitter and receiver | |
| KR20230002784A (ko) | 오디오 및/또는 비디오 콘텐츠 전송을 위한 방법 및 서버 | |
| JP2014090419A (ja) | 通信パラメータに従ってコンテンツをダウンロードするための方法、および、関連するコンテンツ受信機 | |
| KR102304476B1 (ko) | 적응적 스트리밍 서비스를 위한 다중 경로 기반 블록 전송 시스템 및 스트리밍 방법 | |
| CN110881018B (zh) | 媒体流的实时接收方法及客户端 | |
| WO2017114393A1 (zh) | Http流媒体传输方法及装置 | |
| WO2018021950A1 (en) | Device and method for controlling media streaming from a server to a client | |
| GB2572357A (en) | Congestion response for timely media delivery |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PD4A | Correction of name of patent owner | ||
| PC41 | Official registration of the transfer of exclusive right |
Effective date: 20200213 |