СИСТЕМА И СПОСОБ ДЛЯ АДАПТИВНОЙ ПОТОКОВОЙ ПЕРЕДАЧИ В СРЕДЕ С НЕСКОЛЬКИМИ ПУТЯМИ ПЕРЕДАЧИ Российский патент 2017 года по МПК H04N21/6437 H04N21/6373 H04L29/06 

ВВЕДЕНИЕ

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

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

Потоковая передача является процессом, когда используемый клиентом контент посылается на клиент малыми частями, в противоположность загрузке по сети, когда мультимедийный файл целиком передается на клиент до воспроизведения. Существующие протоколы потоковой передачи включают в себя протокол передачи данных в реальном масштабе времени (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, соответствующий запрошенной порции мультимедиа. Чтобы вычислить текущую скорость B_i передачи битов, клиент 12 суммирует байты RTP пакета, принятые в вышеупомянутом интервале rtptime. Он делит это значение на длительность передачи этих байтов (измеряемую между первым принятым байтом и последним принятым байтом):

B_i=Bytes·8/transmitDuration (число байтов·8/длительность передачи)

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

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

avg_i+1=(1-α)·avg_i+α·B_i

где B_i является измеренной скоростью передачи битов, avg_i является средней скоростью передачи битов, вычисленной для текущей итерации, и α является весовым коэффициентом, заданным для измерения текущей скорости передачи битов. В одном примере весовой коэффициент был выбран в виде α=1/16.

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

Δ_i=|B_i-avg_i|

var_i+1=(1-β)var_i+βΔ_i

где Δ_i является разностью между измеренной скоростью передачи битов и средней скоростью передачи битов для текущей итерации, var_i является дисперсией, вычисленной для текущей оценки, и β является весовым коэффициентом, заданным текущему измерению дисперсии. В реализации прототипа было выбрано, что значением β будет 1/8.

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

=avg_i-4·var_i

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

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

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

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

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

Сначала средство 44 для планирования сервера и порции выбирает скорость передачи битов следующей порции. Чтобы выполнить это, средство 44 для планирования сервера и порции суммирует отдельные оценки скорости передачи битов (см. ниже) для всех серверов 14, 16 и 18, чтобы получить суммарную скорость передачи битов, поскольку все серверы используются параллельно. Выбранной скоростью воспроизведения порции является скорость передачи битов с кодированием, которая непосредственно ниже суммарной скорости передачи битов.

В момент времени t_e, когда буфер декодера будет пустым, сначала вычисляется время поступления порции мультимедиа для каждого сервера 14, 16 и 18 с использованием текущих параметров воспроизведения и потоковой передачи: a_k - время, когда путь k становится неактивным (завершен прием последней или спланированной порции мультимедиа), d - длительность порции, B - битовая скорость воспроизведения и B_k - текущая оценка скорости передачи битов для сервера/пути k. Время, которое потребуется для загрузки по сети следующей порции с сервера k, обозначается D_k, причем D_k=d·B/B_k. Временем поступления порции, если используется сервер k, становится: R_k=a_k+D_k

Алгоритм выбирает сервер, который выдает низшее значение R_k. Кроме того, время поступления порции должно быть ранее времени, когда буфер декодера становится пустым (t_e), то есть, должно удовлетворяться R_k<t_e. Если это не так, то буфер истощится, и в воспроизведении будет видимое прерывание. В таком случае битовая скорость воспроизведения будет уменьшена до следующей более низкой скорости передачи битов. Если условие времени поступления удовлетворяется, то извлечение порции планируется на сервер k. Скорость передачи должна быть отрегулирована, чтобы соответствовать текущей оценке скорости передачи битов для сервера/пути k. Это выполняется с использованием заголовка Speed: RTSP запроса PLAY со значением Speed=B_k/B.

Например, при условии, что скоростью воспроизведения B является 1 Мбит/с (воспроизводится трек с trackID 1), текущей оценкой B_k скорости передачи битов является 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 будет задержан до тех пор, пока сервер не станет неактивным.

В заключение, новая порция будет помещаться в буфер, и, следовательно, значение t_e увеличивается на длительность порции (d): t_e=t_e+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). Компьютерная платформа также включает в себя операционную систему и микрокомандный код. Различные процессы и функции, описанные в документе, могут являться либо частью микрокомандного кода, либо частью прикладной программы (или комбинацией таковых), которая исполняется с помощью операционной системы. Кроме того, различные другие периферийные устройства могут подключаться к компьютерной платформе, такие как дополнительное устройство хранения данных и печатающее устройство.

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

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

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 с тем, чтобы сформировать одиночный когерентный поток.