СПОСОБ ПРЕДОСТАВЛЕНИЯ ВОЗМОЖНОСТИ КОМПЕНСАЦИИ ЗАДЕРЖКИ ПЕРЕДАЧИ ПАКЕТОВ ПРИ ПОТОКОВОЙ ПЕРЕДАЧЕ МУЛЬТИМЕДИЙНЫХ ДАННЫХ Российский патент 2008 года по МПК G06F15/16 H04L12/56 

ОБЛАСТЬ ТЕХНИКИ

Настоящее изобретение относится к потоковой передаче мультимедийных данных и, в частности, к услуге потоковой передачи с коммутацией пакетов (PSS) стандарта 3GPP.

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

Услуга потоковой передачи с коммутацией пакетов (PSS) стандарта 3GPP (Проект партнерства в разработках 3-его поколения мобильной связи) определяет нормативные требования к буферизации видеоинформации, которая предназначена для компенсации изменения задержки кодирования, являющейся специфической для сервера, свойственной сжатию и передаче видеоинформации с переменной скоростью передачи данных (VBR) (см. документ 3GPP TS 26.234 V5.1.0, «Transparent End-to-End Packet Switched Streaming Service (PSS); Protocols and Codecs (Release 5)», июнь 2002, далее упоминаемый как TS 26.234; и Nokia, «PSS Buffering Requirements for Continuous Media» 3GPP TSG-SA WG4 Meeting #18 contribution S4-010497, сентябрь 2001). Подобный нормативный документ «Video Buffering Verifier» определен для стандарта MPEG-4 (см. приложение D ISO/IEC IS 14496-2, «Information Technology - Generic Coding of Audio-Visual Objects (MPEG-4), Part 2: Visual», октябрь 1998).

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

Стандарты 3GPP определяют услугу потоковой передачи с коммутацией пакетов как прозрачную услугу в беспроводной сети 3G и не определяют никаких конкретных алгоритмов для использования клиентом, чтобы учитывать искажения передачи и/или характеристики транспортной сети. Таким образом, требования буферизации видеоинформации PSS не включают в себя буферизацию рассогласования в качестве средства компенсации изменения задержки передачи пакетов. Требования буферизации PSS относятся к указанным «буферу перед декодером» и «буферу после декодера» в потоковом клиенте.

Изменение доступной скорости передачи данных для передачи пакетов по маршруту передачи во времени, например изменение скорости передачи данных однонаправленного канала беспроводной сети радиодоступа 3G, является реальной причиной изменения задержки передачи пакетов. Адаптация скорости передачи пакетов и скорости передачи мультимедийной информации к изменяющимся условиям скорости передачи данных на маршруте передачи обычно выполняется в потоковом сервере для поддержания транспортировки пакета в реальном времени (т.е. чтобы избежать ненужной приостановки воспроизведения из-за опустошения буфера перед декодером). Пример такой системы адаптации скорости может быть найден в патенте Haskell и др. (патент США № 5565924 на «Управление буфером кодера/декодера для переменного канала»).

Целью адаптации скорости является обеспечение поступления переданного пакета до его времени воспроизведения. Это время воспроизведения определяется временем выборки пакета плюс заданная константа «полной задержки». Эта полная задержка состоит из «задержки буферизации сервера», «задержки передачи» (также известной как «буфер канала») и «задержки буферизации клиента». Сервер отвечает за оценку задержки передачи и выбор пакетов для передачи, которые могут достигать потокового клиента в пределах полной задержки, после задержки буферизации сервера. В течение сеанса сервер должен контролировать задержку передачи и ее изменение и затем настраивать свою собственную задержку буферизации сервера так, чтобы не было никаких нарушений в буфере клиента. Хотя потоковый клиент должен выполнять нормативные требования к буферизации для данной услуги, он может свободно выбирать максимальную задержку буферизации клиента.

В случае услуги PSS о рекомендованных параметрах буферизации для клиента потоковый сервер сообщает потоковому клиенту с использованием потокового протокола реального времени (RTSP) (см. IETF RFC2326 «Real Time Streaming Protocol (RTSP)», апрель 1998). В стандарте MPEG-4 о параметрах буферизации сообщается как часть заголовка информации конфигурации битового видеопотока. При выборе алгоритмов управления скоростью и/или формирования скорости, сервер предполагает, что клиент будет использовать точно те параметры, которые рекомендованы сервером.

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

В указанном выше патенте США на имя Haskell и др. предполагается, что параметры буферизации сервера и клиента (т.е. размер буфера и начальная задержка буферизации) известны априорно серверу и клиенту, и не учитывается, как это достигается.

В работе Clark и др. «RTCP Extensions for Voice over IP Metric Reporting» (IETF draft-clark-avt-rtcpvoip-01.txt) предложено, чтобы так называемый параметр «системная задержка» передавался в сообщениях RTCP (т.е. определялся в расширении RTCP). В данном случае системная задержка определяется, как полная задержка буферов кодирования, декодирования и рассогласования, определенная в конечной точке передачи. Она определяется как задержка, которая является результатом того, что принятый кадр RTP буферизуется, декодируется, преобразуется «в аналоговую» форму, возвращается назад в местный «аналоговый» интерфейс, кодируется и предоставляется для передачи в виде кадра RTP. На практике использование определенного таким образом показателя в применении к потоковой передаче мультимедийной информации предоставляется невозможным.

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

Существует давно ощущаемая потребность в поиске решения, при котором буферизация клиента выбирается оптимально и используется посредством совместной работы клиента и сервера для обеспечения, чтобы буфер клиента не переполнялся и не опустошался. До сих пор эта потребность не была удовлетворена.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

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

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

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

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

Предпочтительно, потоковый клиент обеспечивает передачу потоковому серверу информации, относящейся к параметрам буферизации клиента, в сообщении запроса ОПЦИИ RTSP (RTSP OPTIONS).

Предпочтительно, потоковый клиент обеспечивает передачу потоковому серверу информации, относящейся к параметрам буферизации клиента, в сообщении запроса ВОСПРОИЗВЕДЕНИЕ RTSP (RTSP PLAY).

Предпочтительно, потоковый клиент обеспечивает передачу потоковому серверу информации, относящейся к параметрам буферизации клиента, в сообщении запроса ПРОВЕРКА ДОСТУПНОСТИ RTSP (RTSP PING).

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

В частности, сигнализация потоковых параметров буферизации клиента для потокового сервера выполняется в контексте верификатора буферизации TS 26.234 (см. приложение G TS 26.234).

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

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

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

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

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

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

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

Предпочтительно, устройство клиента адаптируется для обеспечения передачи потоковому серверу информации, относящейся к выбранным параметрам буферизации, в сообщении запроса ОПЦИИ RTSP.

Предпочтительно, устройство клиента адаптируется для обеспечения передачи потоковому серверу информации, относящейся к выбранным параметрам буферизации, в сообщении запроса ВОСПРОИЗВЕДЕНИЕ RTSP.

Предпочтительно, устройство клиента адаптируется для обеспечения передачи потоковому серверу информации, относящейся к выбранным параметрам буферизации, в сообщении запроса ПРОВЕРКА ДОСТУПНОСТИ RTSP.

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

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

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

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

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Фиг. 1 - структурная схема системы потоковой передачи мультимедийных данных согласно настоящему изобретению.

Фиг. 2 - график, иллюстрирующий пример задержек различных буферов в системе потоковой передачи мультимедийных данных.

ПРЕДПОЧТИТЕЛЬНЫЙ ВАРИАНТ ОСУЩЕСТВЛЕНИЯ ИЗОБРЕТЕНИЯ

На Фиг. 1 представлена структурная схема системы 1 потоковой передачи мультимедийных данных согласно настоящему изобретению, в которой предусмотрено средство передачи информации о параметрах буферизации от потокового клиента 60 на потоковый сервер 10.

Потоковый сервер 10 содержит средство 20 сигнализации прикладного уровня, контроллер 30 скорости и буфер 40 сервера. Потоковый клиент 60 содержит средство 70 сигнализации прикладного уровня, соответствующее средству 20 сигнализации прикладного уровня в потоковом сервере 10 и адаптированное для осуществления связи с ним. Он дополнительно содержит буфер 80 клиента, который в варианте осуществления изобретения, показанном на фиг. 1, содержит буфер 82 рассогласования и буфер 84 перед декодером, интегрированные в один модуль. В других вариантах осуществления изобретения потоковый клиент 60 может включать в себя буфер рассогласования и буфер перед декодером, которые реализованы по отдельности. Потоковый клиент дополнительно содержит декодер 90 мультимедийных данных, буфер 100 после декодера, буферный контроллер 110 и устройство 120 воспроизведения/отображения.

Система, изображенная на фиг. 1, дополнительно содержит «буфер канала» 50, расположенный между потоковым сервером 10 и потоковым клиентом 60. Как описано выше для предшествующего уровня техники, он представляет переменную задержку передачи, которая имеет место во время передачи пакетов данных от потокового сервера к клиенту.

Средство 20 сигнализации прикладного уровня потокового сервера адаптировано для передачи рекомендованных параметров буферизации для потокового клиента, как обозначено ссылочной позицией 200 на фиг. 1. В предпочтительном варианте осуществления изобретения, реализованном в соответствии со стандартами, определяющими услугу PSS 3-го поколения мобильной связи, эти параметры, включающие в себя, например, указание начального времени буферизации перед декодером или размер буфера перед декодером, передаются от мультимедийного потокового сервера 10 клиенту 60 с использованием потокового протокола реального времени (RTSP). В альтернативных вариантах осуществления изобретения, реализованных согласно другим стандартам, таким как MPEG-4, могут использоваться другие механизмы.

Контроллер 30 скорости сервера предназначен для настройки скорости, с которой мультимедийные данные передаются от потокового сервера. Он работает, регулируя скорость передачи данных в соответствии с переменной скоростью передачи данных в канале передачи, учитывая параметры буферизации клиента, таким образом стремясь избежать пауз в воспроизведении в клиенте из-за опустошения буфера перед декодером.

Буфер 40 сервера временно хранит пакеты данных, прежде чем они будут передаваться от потокового сервера по каналу передачи потоковому клиенту 60. В сценарии «прямой» потоковой передачи данных, при выборке пакетов данных в реальном времени, буфер сервера действительно является физическим буфером, куда пакеты данных помещаются в момент выборки и извлекаются во время передачи. В сценарии предварительного кодирования потоковой передачи данных, когда не осуществляется выборка пакетов данных в реальном времени, а они сохраняются в предварительно кодированном файле и считываются из файла во время передачи, буфер сервера является виртуальным буфером, который представляет разность между временем выборки (относительно синхроимпульсов выборки, запускаемых в потоковом сервере, когда передается первый пакет данных предварительно закодированного файла) и временем передачи пакетов данных.

В потоковом клиенте мультимедийные данные принимаются из канала передачи и буферизируются в буфере 80 клиента. Параметры буфера 84 перед декодером и буфера 82 рассогласования устанавливаются с помощью буферного контроллера 110. Эти параметры выбираются в виде совокупности рекомендованных сервером параметров буферизации перед декодером и дополнительной буферизации, оцениваемой клиентом. Клиент определяет, что необходимо для учета ожидаемых изменений задержки передачи пакетов (т.е. рассогласования) в доступном канале передачи. Такая совокупность параметров ограничена максимальными возможностями буферизации клиента. Декодер 90 мультимедийных данных извлекает мультимедийные данные из буфера клиента и декодирует мультимедийные данные способом, подходящим для рассматриваемого вида мультимедийных данных. Понятно, что мультимедийные данные в общем случае будут содержать различные типы мультимедийных данных. Например, если переданные от сервера мультимедийные данные представляют собой видеопоследовательность, то вероятно, что они содержат по меньшей мере аудиокомпонент в дополнение к видеоданным. Поэтому ясно, что декодер 90 мультимедийных данных, как показано на фиг. 1, может в действительности содержать более одного декодера, например видеодекодер, воплощенный согласно конкретному стандарту кодирования видеоданных, и соответствующий аудиодекодер. Когда мультимедийные данные декодируются с помощью декодера 90 мультимедийных данных, они выводятся в буфер 100 после декодера, где временно сохраняются до запланированного времени их воспроизведения, когда они передаются из буфера после декодера на устройство 120 отображения/воспроизведения под управлением буферного контроллера 110.

Согласно изобретению, буферный контроллер 110 адаптируется для обеспечения указания параметров буферизации клиента средству 70 сигнализации прикладного уровня. Средство сигнализации прикладного уровня в свою очередь адаптируется для передачи потоковому серверу указания параметров буферизации клиента, как обозначено ссылочной позицией 300 на фиг. 1. В предпочтительном варианте осуществления изобретения возможности буферизации рассогласования клиента указываются потоковому серверу только в неявном виде, как различие между передаваемыми действительными параметрами буферизации, используемыми клиентом, и рекомендованными параметрами буферизации перед декодером, обеспеченными потоковым сервером. Предпочтительно, это указание обеспечивается посредством сообщения сигнализации, передаваемого от средства 70 сигнализации прикладного уровня в потоковом клиенте по каналу передачи к потоковому средству 20 прикладного уровня в потоковом сервере. Таким образом, обеспечивается механизм для сообщения потоковому серверу о возможностях буферизации потокового клиента. Это обеспечивает множество существенных технических преимуществ по сравнению с системами, в которых не обеспечивается подобное указание. В частности, если в потоковом сервере 10 известны фактические параметры буферизации клиента, используемые во время потоковой передачи данных, сервер может применять алгоритмы управления скоростью и/или формирования скорости, которые используют фактические параметры буферизации клиента, для компенсации задержки передачи пакетов и изменений скорости канала. Настоящее изобретение использует комбинацию буферизации перед декодером и буферизации рассогласования и использует сигнализацию для одного набора параметров буферизации для указания потоковому серверу возможностей клиента по компенсации задержки передачи пакетов.

Потоковый сервер 10, зная, что клиент 60 будет передавать информацию о фактических параметрах буферизации, которые он выбрал для использования, может первоначально передать клиенту информацию о параметрах буферизации перед декодером, которые являются действительно рекомендованными параметрами для надежного канала с постоянной задержкой. Таким образом, сигнализация о буферизации перед декодером от сервера к клиенту не будет использована некорректным образом, позволяя потоковому серверу мультимедиа более точно и определенно управлять скоростью.

Фиг. 2 показывает примерные задержки различных буферов системы потоковой передачи мультимедийной информации. На фиг. 2 горизонтальная ось (ось X) обозначает время в секундах, а вертикальная ось (ось Y) обозначает совокупное количество данных в байтах. Кривая выборки (S) указывает процесс генерирования данных, если бы кодер мультимедийной информации работал в реальном времени. Кривая (Т) передатчика показывает совокупное количество данных, переданных сервером в заданное время. (Следует отметить, что прямая линия указывает передачу с постоянной скоростью передачи данных). Кривая (R) приемника показывает совокупное количество данных, принятых и помещенных в буфер клиента в заданное время, в то время как кривая (Р) воспроизведения показывает совокупное количество данных, которые в заданное время были извлечены из буфера перед декодером и обработаны этим декодером. Кривая (S) выборки является копией кривой (Р) воспроизведения и фактически является сдвинутой по оси времени версией кривой воспроизведения.

Фиг. 2 иллюстрирует задержки различных буферов. «Полная» задержка представлена разностью по оси X между кривой (S) выборки и кривой (Р) воспроизведения. Разность по оси X между кривой (S) выборки и кривой (Т) передатчика указывает «задержку буферизации сервера». Переменная «задержка передачи» представлена разностью по оси X между кривой (R) приемника и кривой (Т) передатчика, в то время как «задержка буферизации клиента» обозначена разностью по оси X между кривой (Р) воспроизведения и кривой (R) приемника. Таким образом, ясно, что «полная задержка», представленная разностью по оси X между кривой (Р) воспроизведения и кривой (S) выборки, равна сумме «задержки буферизации сервера», «задержки передачи» и «задержки буферизации клиента».

Рассматривая график по оси совокупных данных, можно видеть, что разность по оси Y между кривой (R) приемника и кривой (Р) воспроизведения показывает количество данных в буфере клиента в заданное время. Разность по оси Y между кривой (Т) передатчика и кривой (R) приемника соответствует количеству данных, которые в заданное время были уже переданы, но еще не приняты в приемнике (потоковом клиенте).

Сдвинутая кривая (ST) передатчика показывает разделение буферизации перед декодером и буферизации рассогласования в потоковом клиенте. Разность по оси X между кривой (Р) воспроизведения и сдвинутой кривой (ST) передатчика при нулевых совокупных данных, обозначенная (t (P0) - t(ST0)) на фиг. 2, показывает рекомендованную начальную задержку буферизации перед декодером, применение которой достаточно для декодирования переданного потока по каналу с постоянной задержкой. Разность по оси X между сдвинутой кривой (ST) передатчика и кривой (R) приемника при нулевых совокупных данных, показанная как (t(ST0) - t(R0)) на фиг. 2, является начальной задержкой буферизации рассогласования, которую клиент применяет для компенсации разной задержки передачи пакетов.

Тот факт, что кривая приемника пересекает сдвинутую кривую передатчика несколько раз, не вызывая опустошение буфера клиента, указывает на полезность объединения задержки буфера перед декодером с буфером задержки рассогласования согласно настоящему изобретению. Предполагается, что сервер может обнаруживать большие изменения задержки передачи пакетов посредством сообщений RTCP и может также применять управление скоростью и/или формирование скорости для их компенсации. В примере на фиг. 2 сервер не должен фактически применять никакой корректирующей настройки скорости, поскольку буферизация клиента достаточна для исправления разной задержки передачи пакетов. Если в сервере не известны параметры буферизации клиента, то применение управления скоростью и/или формирования скорости не является необходимым.

Правила для сигнализации о параметрах буферизации клиента

Сообщение сигнализации, содержащее параметры буферизации клиента, можно посылать в любое время, но наиболее полезно посылать его сразу, когда клиент точно узнает параметры буферизации, которые он фактически использует для данного потокового сеанса. Это сообщение сигнализации не является сообщением, критичным к задержке, или сообщением, которое должно быть синхронизировано с временем сервера, потому что параметры буферизации клиента обычно постоянны в течение более длительного промежутка времени и очень редко изменяются. Например, обычно существует потребность в передаче новых параметров буферизации клиента только после начала нового воспроизведения мультимедийных данных (т.е. после каждого нового запроса ВОСПРОИЗВЕДЕНИЕ RTSP).

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

Реализация

Те же самые параметры расширения RTSP, как определено в TS 26.234 «Приложение G.2 параметры буферизации PSS» для сообщения ответа «OK», посланного потоковым сервером на запрос ВОСПРОИЗВЕДЕНИЕ, могут использоваться для передачи сообщения сигнализации согласно настоящему изобретению. Параметры расширения RTSP, как определено в TS 26.234, являются следующими:

- x-predecbufsize: <размер гипотетического буфера перед декодером>

(Это задает предполагаемый размер гипотетического буфера перед декодером в байтах согласно приложению G).

- x-initpredecbufperiod: <начальный период буферизации перед декодером>

(Это задает требуемый начальный период буферизации перед декодером, определенный согласно приложению G. Значения интерпретируются как такты системных часов с частотой 90 кГц. Таким образом, значение увеличивается на единицу для каждой 1/90 000 секунды. Например, значение 180 000 соответствует двухсекундному начальному периоду буферизации перед декодером).

- x-initpostdecbufperiod: <начальный период буферизации после декодера>

(Это задает требуемый начальный период буферизации после декодера, определенный согласно приложению G. Значения интерпретируются как такты системных часов с частотой 90 кГц).

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

Клиент может посылать эти параметры RTSP в запросе ОПЦИИ RTSP. Сервер должен ответить на такой запрос и сбросить таймер окончания времени сеанса. Иначе такой запрос ОПЦИИ не влияет на состояние сервера.

Например, когда клиент сообщает, что фактический начальный период буферизации клиента равен половине секунды, в запросе параметр «начальный период буферизации перед декодером» используется повторно (как показано в примере запроса ОПЦИИ RTSP и сообщения ответа «OK», представленном ниже):

C-> S: ОПЦИИ, *RTSP/1.0

CSeq: 833

Сеанс: 12345678

x-initpredecbufperiod: 45000

S-> C: RTSP/1.0 200 OK:

CSeq: 833

Общедоступные параметры: ОПИСАНИЕ, УСТАНОВКА, ОТМЕНА, ВОСПРОИЗВЕДЕНИЕ, ПАУЗА

Клиент может также передать эти параметры RTSP в пустом запросе ВОСПРОИЗВЕДЕНИЕ RTSP (т.е. без заголовка «Диапазон») от потокового клиента на потоковый сервер, когда он находится в активном состоянии ВОСПРОИЗВЕДЕНИЕ (т.е. не в состоянии ПАУЗА). Потоковый сервер, согласно IETF RFC2326, не должен предпринимать никаких действий в ответ на пустой запрос ВОСПРОИЗВЕДЕНИЕ, который принят, когда он находится в активном состоянии ВОСПРОИЗВЕДЕНИЕ (т.е. если сервер еще не закончил передачу пакетов из запрошенного диапазона ВОСПРОИЗВЕДЕНИЕ), но следует учитывать возможные неверные интерпретации, когда такие запросы ВОСПРОИЗВЕДЕНИЕ могут также быть поставлены в очередь, в этом случае они указывают, что поток должен быть перезапущен, как только текущий диапазон ВОСПРОИЗВЕДЕНИЕ пройдет местоположение, где он был остановлен. Следующий пример показывает, как пустой запрос ВОСПРОИЗВЕДЕНИЕ RTSP может использоваться для передачи параметров буферизации перед декодером согласно изобретению:

C-> S: ВОСПРОИЗВЕДЕНИЕ rtsp: // audio.example.com/twister.en RTSP/1.0

CSeq: 833

Сеанс: 12345678

x-initpredecbufperiod: 45000

S-> C: RTSP/1.0 200 OK

CSeq: 833

Клиент может также передать эти параметры RTSP в запросе ПРОВЕРКА ДОСТУПНОСТИ RTSP.

Если сервер понимает расширения параметра буферизации клиента, он должен учесть переданные фактические параметры буферизации клиента в активном в данное время состоянии ВОСПРОИЗВЕДЕНИЕ (т.е. применяя их только к последнему запрошенному диапазону ВОСПРОИЗВЕДЕНИЕ в потоковом сеансе).

Следует отметить, что настоящее изобретение направлено на совместный алгоритм работы потокового клиента и сервера. Полезно, если и клиент, и сервер реализуют совместный потоковый алгоритм. Таким образом, если клиент посылает параметры буферизации во время потоковой передачи данных, сервер фактически использует эту информацию для управления скоростью. Обмен информацией о возможностях может использоваться для обеспечения того, что потоковый сервер и клиент поддерживают способ сигнализации. Следует отметить, что существует много возможностей определения имени этой функции. Одной из этих возможностей является «передача параметров буферизации клиента», например, и это имя можно передать в первом запросе УСТАНОВКА следующим образом:

C-> S: УСТАНОВКА rtsp: // audio.example.com/twister.en/video RTSP/1.0

CSeq: 3

Запрашивается: «передача параметров буферизации клиента»

Если сервер не поддерживает эту функцию, то он должен возвратить поле «не поддерживает» как в примере:

S-> C: RTSP/1.0 200 OK

CSeq: 3

Не поддерживается: «передача параметров буферизации клиента»

<Другие относящиеся к УСТАНОВКЕ параметры>

Если клиенту понятно, что эта функция не поддерживается, он не будет посылать такие параметры в запросе ОПЦИИ. Если нет заголовка «не поддерживается» (что указывает, что сервер поддерживает данную функцию), клиент может надежным образом передавать потоковому серверу параметры буферизации клиента. Клиент может надежно передать параметры буферизации клиента (в запросе ОПЦИЙ, в запросе ВОСПРОИЗВЕДЕНИЕ без заголовка диапазона или в запросе ПРОВЕРКА ДОСТУПНОСТИ), если ему понятно, что данная функция поддерживается.

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

Заявлены способ и устройство для предоставления возможности компенсации задержки передачи пакетов при потоковой передаче мультимедийных данных. Технический результат заключается в возможности потоковому серверу оптимально управлять своими алгоритмами управления скоростью и формирования скорости для компенсации изменений задержки передачи пакетов. Технический результат достигается благодаря тому, что на потоковый сервер передается информация, указывающая возможности буферизации рассогласования потокового клиента. Данная информация содержит выбранные клиентом параметры буферизации перед декодером так, чтобы возможности буферизации рассогласования для клиента могли определяться сервером на основе разности между выбранными клиентом параметрами буферизации перед декодером и параметрами буферизации перед декодером, обеспеченными потоковым сервером. 5 н. и 28 з.п. ф-лы, 2 ил.

1. Способ приема потоковой передачи мультимедийных данных, заключающийся в том, что

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

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

передают информацию, указывающую на выбранные параметры буферизации, на сервер.

буфер перед декодером для хранения принятого потока пакетов перед декодированием принятых мультимедийных данных;

буфер рассогласования для компенсации изменения задержки передачи пакета;

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

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

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

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

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

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

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

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

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

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