СПОСОБ ДЛЯ ДИНАМИЧЕСКОЙ АДАПТАЦИИ ЧАСТОТЫ СЛЕДОВАНИЯ БИТОВ ПРИ ПРИЕМЕ И СООТВЕТСТВУЮЩИЙ ПРИЕМНИК

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

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

Предшествующий уровень техники

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

Известные протоколы потоковой передачи включают в себя 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, чтобы получить число битов (двоичные элементы), и деления результата умножения на продолжительность приема.

А именно выражение мгновенной частоты следования битов:

B_i=Байты×8/rangeduration.

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

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

i - индекс, который относится к i-й итерации вычисления полезной частоты следования битов и ее дисперсии, в течение времени передачи принятых данных.

Оценка частоты следования битов в будущем для следующей итерации вычисляется таким образом:

=(1-α)× +α× ,

где представляет собой измеренную частота следования битов,

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

Преимущественно значение α равно 1/16.

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

Δ_i=| - |,

=(1-β)× +β×Δ_I,

где Δ_i представляет собой разность между измеренной частотой следования битов и средней частотой следования битов для текущей итерации вычисления,

var_i представляет собой дисперсию, вычисленную для текущей итерации, величина β представляет собой весовой коэффициент для значения дисперсии текущей оценки.

Преимущественно значение β равно 1/8.

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

max= -4× .

Таким образом, если дисперсия большая, это означает, что приемник использует меньшую, чем средняя доступная полоса пропускания. Кроме того, когда полоса пропускания устойчивая, и дисперсия низкая, приемник использует всю полосу пропускания доступную между ним и сервером.

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

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

=( + )/2

и

=avg_i+1/10.

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