+

RU2367011C2 - Устройство и способ передачи сигналов с упреждающей адаптацией скорости - Google Patents

Устройство и способ передачи сигналов с упреждающей адаптацией скорости Download PDF

Info

Publication number
RU2367011C2
RU2367011C2 RU2005136435/09A RU2005136435A RU2367011C2 RU 2367011 C2 RU2367011 C2 RU 2367011C2 RU 2005136435/09 A RU2005136435/09 A RU 2005136435/09A RU 2005136435 A RU2005136435 A RU 2005136435A RU 2367011 C2 RU2367011 C2 RU 2367011C2
Authority
RU
Russia
Prior art keywords
server
client
data
adaptation
parameter
Prior art date
Application number
RU2005136435/09A
Other languages
English (en)
Other versions
RU2005136435A (ru
Inventor
Давид ЛЕОН (US)
Давид ЛЕОН
Виктор ВАРСА (US)
Виктор ВАРСА
Игор Данило Диего КУРСИО (FI)
Игор Данило Диего КУРСИО
Original Assignee
Нокиа Корпорейшн
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Нокиа Корпорейшн filed Critical Нокиа Корпорейшн
Publication of RU2005136435A publication Critical patent/RU2005136435A/ru
Application granted granted Critical
Publication of RU2367011C2 publication Critical patent/RU2367011C2/ru

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L12/5602—Bandwidth control in ATM Networks, e.g. leaky bucket
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/30—Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Control Of Electric Motors In General (AREA)
  • Nitrogen And Oxygen Or Sulfur-Condensed Heterocyclic Ring Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

Изобретение относится к передаче потоков мультимедийных данных и более конкретно к адаптации скорости передачи данных между сервером и клиентом в услугах передачи потоков мультимедийных данных. Технический результат - обеспечение адаптивного управления уровнем приемного буфера в сети потоковой передачи мультимедийных данных. Сеть потоковой передачи мультимедийных данных имеет сервер, предназначенный для предоставления потоковых данных в клиент. Сервер отвечает за адаптацию скорости передачи к скорости приема или управления накоплением и за адаптацию частоты дискретизации к скорости передачи. Таким образом, сервер управляет сдвигом и поддерживает его в пределах рабочего диапазона адаптации скорости. Клиент отвечает за компенсацию вариации задержки передачи пакета, которая также известна как быстрые флуктуации в сети. Клиент также отвечает за установку параметров рабочего диапазона адаптации скорости сервера. Клиент выбирает и передает параметры сдвига на сервер, но сервер самостоятельно адаптирует свою скорость кодирования или скорость передачи, когда отвечает на эти параметры. 5 н. и 31 з.п. ф-лы, 3 ил.

Description

Область техники, к которой относится изобретение
Настоящее изобретение, в общем, относится к передаче потоков мультимедийных данных и более конкретно к адаптации скорости передачи данных между сервером и клиентом в услугах передачи потоков мультимедийных данных.
Уровень техники
В услуге передачи потоков мультимедийных данных участвуют три объекта: потоковый сервер, потоковый клиент и канал передачи данных или используемая для передачи сеть. Обычно узким местом услуги при передаче является канал передачи данных как по пропускной способности, так и в отношении надежности (то есть в случаях, когда предполагается отсутствие гарантированной скорости передачи битов), но ограничения по пропускной способности также могут возникать в клиенте и/или в сервере.
В системе с потоковой передачей данных в режиме реального времени, из-за динамического изменения характеристик пропускной способности канала, клиента и сервера, потоковая передача данных должна быть адаптивной для поддержания воспроизведения данных для пользователя в режиме реального времени. Сервер должен адаптировать скорость передачи данных в соответствии с изменяющейся пропускной способностью системы. Пример такой системы с адаптивной скоростью можно найти в публикации Haskell и др. (патент US № 5,565,924, "Encoder/Decoder Buffer Control for Variable Channel").
Клиент потоковой передачи данных обеспечивает буферизацию в приемнике для сохранения поступающих данных перед передачей их в декодер мультимедийных данных для воспроизведения. Буфер приемника используется для компенсации разницы между скоростью кодирования источника (также называемой частотой дискретизации) и скоростью передачи (буферизация перед декодером). Он также используется для компенсации вариаций задержки при передаче пакета по каналу (буферизации быстрых флуктуаций). Обычно предполагается, что эти две функции комбинируют в одном буфере приемника. Однако в приемнике также могут быть установлены два отдельных буфера, хотя такой вариант выполнения не является оптимальным с точки зрения задержки. Буферизация в приемнике также позволяет сглаживать неточности адаптации (то есть, если пропускная способность системы не точно согласована по выходу сервера).
Если буфер приемника становится пустым (то есть происходит опустошение буфера), что означает, что в декодер не поступают данные для декодирования, клиент должен приостановить воспроизведение и дождаться заполнения буфера поступающими данными перед его продолжением. С другой стороны, если скорость поступающих данных выше, чем скорость воспроизведения, емкость приемного буфера может быть полностью заполнена (то есть происходит переполнение буфера), в результате чего происходит сброс пакетов из буфера с тем, чтобы высвободить место для новых поступающих пакетов. Когда происходит сброс пакетов, ухудшается качество видеоизображения. Для обеспечения непрерывного воспроизведения без искажений приемный буфер клиента следует поддерживать в определенном диапазоне заполнения. Для того чтобы гарантированно исключить опустошение или переполнение буфера приемника, необходимо обеспечить соответствующее управление скоростью передачи битов при передаче и во время дискретизации на сервере, а также при приеме и воспроизведении в клиенте.
Ниже будет описано управление скоростью передачи битов со ссылкой на графики изменения скорости передачи битов (по горизонтальной оси обозначено время в секундах; по вертикальной оси обозначено совокупное количество данных в байтах или битах), на которых представлены следующие кривые:
- кривая воспроизведения, P(t), которая представляет совокупное количество данных, обработанных декодером в течение заданного времени, поступивших из приемного буфера;
- кривая дискридитации, S(t), представляющая код генерирования данных, как если бы мультимедийный декодер работал в режиме реального времени (она представляет собой эквивалент кривой воспроизведения и, собственно, является ее версией со сдвигом по времени);
- кривая T(t) передачи представляет совокупное количество данных, переданных сервером в течение заданного времени; и
- кривая приема, R(t), представляет совокупное количество данных, принятых и помещенных в буфер клиента в течение заданного времени.
Различие между любыми двумя кривыми определяет задержку и "размер буфера" между этими двумя кривыми. Скорость передачи битов ограничена определенными пределами по разности между двумя кривыми (например, максимальным размером буфера или максимальной задержкой). Типичный график изменения скорости передачи битов показан на фиг.1.
Для определения наилучшей организации взаимодействия между сервером и клиентом при управлении скоростью передачи битов необходимо учитывать следующее.
A. Кривую дискретизации - управление (то есть выбор потока битов для передачи) необходимо полностью предоставить серверу, поскольку:
1) только на сервере известны точные характеристики каждого потока битов, например, положения переключения, приоритет фреймов, размеры будущих фреймов, и
2) может отсутствовать скорость потока битов, которая была бы согласована со скоростью битов в сети, и сервер мог бы использовать некоторые "трюки" (например, разрежение, повышение и снижение скорости).
B. Кривую передачи - управление (то есть скорость при передаче) также необходимо предоставить серверу (то есть использовать отчеты RTCP (ПУРВ, протокол управления передачей в реальном времени) или другую информацию о полосе пропускания, поступающую от клиента), поскольку:
1) обычно только сервер может измерить количество данных в канале передачи, и
2) может потребоваться адаптировать скорость передачи для кривой дискретизации, если управление кривой дискретизации имеет ограниченную гибкость.
Сервер должен поддерживать некоторые ограничения в режиме реального времени путем адаптации своей кривой дискретизации S(t) к своей кривой передачи T(t). Адаптация кривой дискретизации к кривой передачи гарантирует, что при адекватной буферизации приемник сможет воспроизвести мультимедийные данные с правильной синхронизацией. В каждый момент t времени кривая S(t) дискретизации не должна отклоняться от кривой T(t) передачи на слишком большое количество байтов.
Если сервер работает в пределах определенных ограничений режима реального времени, клиент отвечает за обеспечение любой необходимой буферизации, чтобы следовать за сервером в пределах этих ограничений. В этом случае клиент должен компенсировать:
1) буферизацию предварительного декодера для |S(t) - T(t)|, и
2) буферизацию быстрых флуктуаций для вариации задержки передачи {T(t) - R(t)}.
Кроме того, клиент должен допускать определенное несоответствие между кривой воспроизведения и кривой дискретизации (например, смещение синхронизации или замедление воспроизведения из-за проблем операционной системы платформы клиента).
В системах потоковой передачи мультимедийных данных отправитель или сервер должен в каждый момент времени решать, как кодировать (с какой скоростью) следующий пакет, который он будет отправлять, и решать, в какой момент времени отправить его. При нормальной работе отправитель может поддерживать воспроизведение в приемнике в режиме реального времени с использованием только отчетов RTCP. Услуга потоковой передачи данных с коммутацией пакетов (PSS, ПКП) для 3GPP (3ППП, Проект партнерства 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). Когда одновременно сервер и клиент потоковой передачи данных соответствуют требованиям буферизации, гарантируется, что клиент будет способен воспроизводить поток, передаваемый сервером, без нарушения работы буфера клиента (то есть в этом случае отсутствует опустошение или переполнение буфера клиента) при условии, что поток от сервера передают по надежному каналу передачи данных с постоянной задержкой. Однако такое условие невозможно в определенных обстоятельствах, например, во время передачи клиента, повторной передачи данных или смещения тактовой частоты. В результате, отправитель и получатель могут предпринимать действия, вступающие в конфликт друг с другом, что может привести к значительному ухудшению услуги, предоставляемой пользователю.
В известном уровне техники приемник модифицирует уровень своего буфера путем использования скорости (кодирования с субдискретизацией звука и/или видео) и масштаба (мультипликативного повышения или снижения скорости передачи битов) полей заголовков RTSP (ППРВ, протокол потоковой передачи данных в режиме реального времени). Эти заголовки определены в IETF RFC2326. Приемник также может использовать команды переключения скорости передачи битов клиентом, как описано в публикации "End-to-End bit rate adaptation for PSS", 3GPP SA4 doc S4-030024.
Сущность изобретения
Настоящее изобретение разделяет ответственность при адаптации скорости передачи между отправителем и получателем следующим образом.
Отправитель отвечает за:
- Адаптацию скорости передачи данных к скорости приема данных (то есть управление перегрузкой).
- Адаптацию скорости дискретизации к скорости передачи данных (то есть управление сдвигом и поддержанием его в пределах рабочего диапазона адаптации скорости).
Получатель отвечает за:
- Компенсацию вариации задержки передачи пакета (то есть быстрые флуктуации в сети).
- Установку параметров рабочего диапазона адаптации скорости передачи сервера (то есть диапазон сдвига).
Рабочий диапазон для адаптации скорости передачи сервера определяет пределы "динамического планирования сервера" путем указания допустимого минимального и максимального сдвига для любого пакета, передаваемого сервером. Параметры рабочего диапазона адаптации скорости передачи сервера обуславливают между сервером и приемником для минимизации вероятности возникновения опустошения, переполнения и ухудшения качества в таких случаях, как передача клиента, повторная передача данных и сдвиг тактовой частоты.
Таким образом, в первом аспекте настоящее изобретение направлено на способ адаптивного управления уровнем буфера приемника в клиенте, в сети потоковой передачи мультимедийных данных, причем сеть потоковой передачи данных содержит сервер, предоставляющий потоковые данные в клиент, при этом буфер приемника используют для компенсации разности между количеством данных, передаваемых сервером, и количеством данных, используемых клиентом, что позволяет клиенту иметь достаточное количество потоковых данных для воспроизведения без перерывов, заключающийся в том, что
определяют в клиенте, по меньшей мере, один параметр для определения рабочего диапазона адаптации скорости для выполнения адаптации скорости передачи между сервером и клиентом;
адаптируют на сервере количество данных к скорости приема на основе указанного, по меньшей мере, одного параметра; и
регулируют в клиенте вариации задержки передачи пакета на основе указанной адаптации.
В соответствии с настоящим изобретением этот, по меньшей мере, один параметр содержит величину минимального сдвига, указывающую разность между временем дискретизации и временем передачи пакета на сервере, что позволяет серверу выполнять указанную адаптацию на основе минимальной величины сдвига.
В соответствии с настоящим изобретением, по меньшей мере, один параметр содержит целевую величину сдвига, указывающую величину сдвига, большую, чем разность между временем дискретизации и временем передачи пакета на сервере, что позволяет серверу выполнять указанную адаптацию на основе целевой величины сдвига.
В соответствии с настоящим изобретением, по меньшей мере, один параметр содержит число, обозначающее максимальную разность между количеством байтов, которые были переданы, и количеством дискретизированных байтов, что позволяет серверу выполнять указанную адаптацию на основе этого числа.
В соответствии с настоящим изобретением указанную адаптацию на сервере выполняют путем регулировки скорости передачи данных или частоты дискретизации или обоих этих параметров.
В соответствии с настоящим изобретением, по меньшей мере, один параметр содержит величину сдвига тактовой частоты, предназначенного для предотвращения перерывов при воспроизведении в клиенте.
В соответствии с настоящим изобретением способ дополнительно содержит этап, на котором адаптируют частоту дискретизации к скорости передачи данных на сервере на основе указанного, по меньшей мере, одного параметра.
В соответствии с настоящим изобретением две или более величин из минимальной величины сдвига, целевой величины сдвига, обозначающего числа и тактовой частоты передают вместе на сервер.
Во втором аспекте настоящее изобретение направлено на систему потоковой передачи мультимедийных данных. Система содержит, по меньшей мере, клиент; и сервер, предназначенный для предоставления потоковых данных в клиент, причем клиент имеет буфер приемника, предназначенный для компенсации разности между количеством данных, передаваемых сервером, и количеством данных, используемых клиентом, что позволяет клиенту иметь достаточное количество потоковых данных для воспроизведения без перерывов, при этом клиент содержит
механизм для определения, по меньшей мере, одного параметра, для определения рабочего диапазона адаптации скорости, что позволяет серверу адаптировать количество данных к скорости приема на основе, по меньшей мере, указанного одного параметра; и
механизм для регулирования вариации задержки передачи пакета на основе указанной адаптации.
В соответствии с настоящим изобретением указанный, по меньшей мере, один параметр может включать в себя минимальную величину сдвига, указывающую разность между временем дискретизации и временем передачи пакета на сервере, что позволяет серверу выполнять указанную адаптацию на основе минимальной величины сдвига; целевую величину сдвига, указывающую величину сдвига, большую, чем разность между временем дискретизации и временем передачи пакета на сервере, что позволяет серверу выполнять указанную адаптацию на основе целевой величины сдвига; число, обозначающее максимальную разность между количеством переданных байтов и количеством дискретизированных байтов, и величину сдвига тактовой частоты для предотвращения перерывов при воспроизведении в клиенте.
В соответствии с настоящим изобретением сервер содержит механизм адаптации, предназначенный для адаптации частоты дискретизации к скорости передачи данных на основе указанного, по меньшей мере, одного параметра.
В третьем аспекте настоящее изобретение направлено на программный продукт, предназначенный для использования в клиенте в сети потоковой передачи мультимедийных данных для адаптивного управления уровнем буфера приемника в клиенте, причем сеть потоковой передачи мультимедийных данных содержит сервер, выполненный с возможностью предоставления потоковых данных в клиент, при этом буфер приемника используется для компенсации разности между количеством данных, передаваемых сервером, и количеством данных, используемых клиентом, что позволяет клиенту иметь достаточное количество потоковых данных для воспроизведения без перерывов, содержащий
код для определения, по меньшей мере, одного параметра, предназначенного для определения рабочего диапазона адаптации скорости на сервере, для выполнения адаптации скорости между сервером и клиентом; и
код для регулирования вариации задержки передачи пакета на основе указанной адаптации.
В соответствии с настоящим изобретением указанный, по меньшей мере, один параметр может включать в себя минимальную величину сдвига, указывающую разность между временем дискретизации и временем передачи пакета на сервере; целевую величину сдвига, указывающую величину сдвига, большую, чем разность между временем дискретизации и временем передачи пакета на сервере; число, обозначающее максимальную разность между количеством переданных байтов и количеством дискретизированных байтов; и величину сдвига тактовой частоты для предотвращения перерывов при воспроизведении в клиенте.
В четвертом аспекте настоящее изобретение направлено на терминал в сети потоковой передачи мультимедийных данных, имеющей, по меньшей мере, сервер, предназначенный для предоставления потоковых данных в терминал, причем терминал имеет буфер приемника, предназначенный для компенсации разности между количеством данных, переданных сервером, и количеством данных, используемых терминалом, что позволяет терминалу иметь достаточное количество потоковых данных для воспроизведения без перерывов. Терминал содержит
механизм для определения, по меньшей мере, одного параметра, который определяет рабочий диапазон адаптации скорости на сервере, что позволяет серверу адаптировать количество передаваемых данных к скорости приема на основе указанного, по меньшей мере, одного параметра; и
механизм для регулирования вариации задержки передачи пакета на основе указанной адаптации.
В соответствии с настоящим изобретением механизм определения содержит программу программного обеспечения, имеющую, по меньшей мере, код для определения указанного, по меньшей мере, одного параметра, и механизм регулирования содержит программу программного обеспечения, имеющую, по меньшей мере, код, предназначенный для регулирования вариации задержки передачи пакета.
В пятом аспекте настоящее изобретение направлено на сетевой элемент в сети потоковой передачи мультимедийных данных, имеющей, по меньшей мере, терминал, который принимает потоковые данные от сетевого элемента, причем терминал имеет буфер приемника для компенсации разности между количеством данных, переданных сетевым элементом, и количеством данных, используемых терминалом, что позволяет терминалу иметь достаточное количество потоковых данных для воспроизведения без перерывов. Сетевой элемент содержит
средство приема запроса от терминала, причем в запросе указан, по меньшей мере, один параметр, который определяет рабочий диапазон адаптации скорости сетевого элемента; и
механизм, предназначенный для адаптации, на основе указанного, по меньшей мере, одного параметра, количества передаваемых данных к скорости приема терминала, что позволяет терминалу регулировать вариацию задержки передачи пакета на основе указанной адаптации.
В соответствии с настоящим изобретением механизм адаптации содержит программу программного обеспечения, имеющую, по меньшей мере, код, предназначенный для адаптации количества передаваемых данных.
В соответствии с настоящим изобретением программа программного обеспечения содержит код, предназначенный для регулирования скорости передачи или частоты дискретизации или обоих этих параметров.
Настоящее изобретение будет более понятно при чтении его описания со ссылкой на фиг.1-3.
Краткое описание чертежей
На фиг.1 показан график, определяющий параметры в соответствии с кривыми дискретизации и передачи данных.
На фиг.2 показан график, иллюстрирующий передачу клиента и ее влияние на уровень приемного буфера для определенных параметров сдвига.
На фиг.3 показана блок-схема, представляющая систему потоковой передачи мультимедийных данных, включающую в себя устройство сервера и устройство клиента, которые могут выполнять способ адаптации скорости передачи данных, в соответствии с настоящим изобретением.
Подробное описание изобретения
Для определения, какой минимальный и максимальный сдвиг разрешен для любого пакета, передаваемого сервером, в настоящем изобретении "сдвиг" определен с использованием следующей модели адаптации скорости.
А. Модель адаптации скорости при взаимодействии
Разность времени α между временем дискретизации (то есть отметкой времени) мультимедийных данных в пакете RTP (ТПР, транспортный протокол реального времени) и временем передачи пакета (то есть, когда он отправлен сервером) определена как "сдвиг". Как можно видеть по кривым дискретизации (S) и передачи (T), сдвиг α может быть выражен как T(t) = S(t + α).
Сдвиг представляет собой положительную величину, когда время дискретизации пакета наступает позже, чем время передачи пакета. Сдвиг имеет отрицательную величину, когда время дискретизации пакета наступает раньше, чем время передачи пакета.
На основе определения "сдвига" параметры минимального и максимального сдвигов определяются следующим образом.
B. Параметры рабочего диапазона адаптации скорости передачи сервера
Параметры рабочего диапазона адаптации скорости передачи определены следующим образом.
1) Минимальный сдвиг - этот параметр определяет наименьший сдвиг, который может использовать отправитель. Он определяет для времени t передачи самое позднее допустимое время дискретизации данных, которые могут быть переданы. Если этот параметр представляет собой α_min, отправитель должен отправить в момент времени t пакет, время дискретизации которого не раньше, чем t + α_min.
При сравнении этого максимального предела, самого позднего времени, когда пакеты могут быть отправлены, с их временем дискретизации, в приемнике может поддерживаться воспроизведение в режиме реального времени. Приемник может выполнять оценку максимального времени, в которое он может ожидать пакеты, для исключения задержки при воспроизведении (то есть при отсутствии опустошения приемного буфера).
Необходимо задать размеры исходной задержки буферизации приемника (то есть опережение при передаче данных) для обеспечения минимального сдвига и, кроме того, для компенсации вариации задержки при передаче пакета. В качестве примера, допустим, что минимальный сдвиг составляет -2000 мс. Это означает, что когда отправитель передает пакет, время дискретизации пакета должно быть максимум на 2 секунды раньше по сравнению с временем его передачи, но не больше. Для того чтобы исключить опустошение приемного буфера, приемник первоначально должен поместить в буфер максимальную ожидаемую вариацию задержки передачи пакета, плюс 2 секунды. Чем меньше (отрицательное) значение, тем выше потребность в исходной буферизации в приемнике.
Когда приемник детектирует сдвиг тактовой частоты (то есть отклонение кривой воспроизведения приемника от кривой дискретизации, поддерживаемой на сервере), параметр минимального сдвига может быть модифицирован с тем, чтобы вынудить сервер следовать кривой воспроизведения с моментами времени передачи пакета. Например, если приемник работает быстрее, он может воспроизвести данные с более высокой скоростью, чем выполняется их дискретизация. Это, в конечном счете, может привести к опустошению буфера. Такое опустошение может быть исключено путем отправки в отправитель запроса увеличить его минимальный сдвиг.
Если приемник работает медленнее, чем отправитель, минимальный сдвиг необходимо уменьшить. Если приемник работает быстрее, чем отправитель, он должен быть увеличен.
Исходное значение минимального сдвига обычно должно быть отрицательным, но приемник может модифицировать его так, что оно также может стать положительным. Например, в случае более быстрого приемника (то есть тактовой частоты для более быстрого воспроизведения), когда минимальный сдвиг увеличивается, он, в конечном счете, может стать положительным. Например, если исходная величина составляет -2 секунды, отправитель может затем запросить установить сдвиг -1,9 секунды, затем -1,7 секунды и т.д.
2) Целевой сдвиг - этот параметр определяет сдвиг, который клиент желает, чтобы был установлен отправителем. Если этот параметр представляет собой α_target, отправитель должен передавать в момент времени t пакет, время дискретизации которого составляет t+α_target.
Целевой сдвиг всегда должен быть больше, чем минимальный сдвиг, определенный выше. По определению, если отправитель передает пакет в соответствии с целевым сдвигом, он также, очевидно, соответствует минимальному сдвигу.
Целевой сдвиг предназначен для снижения потребности в уменьшении частоты дискретизации, когда скорость передачи данных необходимо резко уменьшить (например, при передаче клиента), но при этом необходимо удовлетворять конечные сроки режима реального времени (то есть минимальный сдвиг). Другими словами, целевой сдвиг предназначен для того, чтобы отправитель передавал пакеты раньше, чем строго необходимо для удовлетворения требований режима реального времени, когда скорость передачи не достаточно хороша.
Для того чтобы лучше пояснить использование этого второго параметра, предположим, что отправитель работает близко к значению минимального сдвига. Теперь предположим, что скорость передачи данных существенно уменьшается (такое может произойти, например, при передаче клиента или при повторных передачах RTP, которые могут снизить доступную скорость передачи битов для исходного потока). Для того чтобы гарантировать минимальный сдвиг (и, таким образом, режим реального времени), отправитель также должен резко уменьшить свою частоту дискретизации. Это может привести к снижению качества, поскольку отправитель может, например, быть вынужден пропустить фреймы для того, чтобы получить такое снижение частоты дискретизации.
В случае когда сервер работает близко к значению целевого сдвига, когда скорость передачи данных уменьшается, не требуется, чтобы уменьшение частоты дискретизации было таким же резким, как уменьшение скорости передачи данных. Отправитель, который снижает скорость передачи данных без снижения частоты дискретизации, уменьшит действительный сдвиг ниже целевого сдвига, но при этом все еще может поддерживаться минимальный сдвиг без необходимости уменьшения частоты дискретизации в такой значительной степени, как наблюдаемое уменьшение скорости передачи данных.
После того, как сервер был вынужден уменьшить свой сдвиг, он должен восстановить целевой сдвиг, когда скорость передачи данных снова повышается. Для достижения целевого сдвига, передаваемого приемником, отправитель может использовать комбинацию увеличения скорости передачи данных и уменьшения частоты дискретизации (или уменьшения скорости передачи данных и повышения частоты дискретизации) в зависимости от текущих ограничений скорости передачи данных.
При определении целевого сдвига, таким образом, устраняется необходимость передачи приемником "команд" на сервер для того, чтобы вначале уменьшить, а затем снова увеличить сдвиг при значительном падении скорости передачи данных. Сам отправитель принимает решение на уменьшение сдвига от величины целевого сдвига, но затем снова увеличивает сдвиг до величины целевого сдвига, значение которого было ранее передано приемником.
По этой причине такую схему можно назвать упреждающей. При этом не требуется выполнять передачу сигналов (о сдвиге), когда снижается скорость передачи данных.
3) Максимальное количество заранее переданных байтов - этот параметр определяет максимальную разность между количеством байтов, которые были переданы в момент времени t, и количеством байтов, дискретизацию которых выполнили до момента времени t (то есть разность между кривой передачи и кривой дискретизации: T(t) - S(t)). Этот параметр ограничивает необходимый размер буфера в приемнике для содержания пакетов, которые были приняты в результате положительного сдвига и которые, таким образом, должны ожидать в приемнике времени своего воспроизведения. Цель этого параметра состоит в предотвращении переполнения буфера.
Эти параметры представлены на фиг.1 на примере кривой T(t) передачи и кривой S(t) дискретизации.
C. Требования соответствия сервера параметрам рабочего диапазона адаптации скорости передачи
Параметры "минимального сдвига" и "максимального количества" заранее переданных байтов должны строго поддерживаться на сервере. При этом сервер пытается работать в условиях нормальной передачи, как можно ближе к "целевому сдвигу", насколько это позволяют его возможности и доступное кодирование мультимедийных данных.
Ввиду возможных вариаций скорости кодирования мультимедийных данных с течением времени "целевой сдвиг" не может точно поддерживаться сервером для всех передаваемых пакетов. Отклонение от "целевого сдвига" разрешено по усмотрению сервера в условиях передачи данных, когда он определяет, что строгое следование "целевому сдвигу" приведет к ненужному ухудшению качества (см. примеры случая использования, приведенные ниже). Также решением/возможностями сервера определяется, насколько быстро "целевой сдвиг" будет восстановлен после такого отклонения.
Всякий раз, когда параметры "целевой сдвиг" и "максимальное количество заранее переданных байтов" вступают в конфликт (то есть поддержание целевого сдвига приведет к превышению максимального количества заранее переданных байтов), последний получает приоритет.
D. Разделение ответственности между сервером и клиентом
Ключевой момент при поддержании воспроизведения без перерывов состоит в эффективном управлении уровнем буфера приемника. Такое управление может быть обеспечено при использовании, по меньшей мере, подразумеваемого или предполагаемого управления как над кривой воспроизведения, так и над кривой приема в клиенте. Клиент по определению знает и управляет линией времени декодирования/воспроизведения. Благодаря введению отправителем возможности управления над сдвигом, клиенту предоставляется, по меньшей мере, предполагаемое управление кривой приема данных и ее соответствия кривой дискретизации, и, таким образом, предоставляется возможность управления уровнем буфера приемника.
В соответствии с этим клиент выбирает и запрашивает параметры сдвига с учетом своих абсолютных ограничений по буферизации. В такой модели адаптации скорости передачи данных с взаимодействием приемник запрашивает только параметры сдвига, и отправитель по своему усмотрению адаптирует свою скорость кодирования и/или скорость передачи данных при ответе на запрос. При этом может быть адаптированной либо кривая передачи, или кривая дискретизации, или может использоваться комбинация обоих этих вариантов.
Однако частоту дискретизации (то есть выбор потока битов для передачи) оставляют под управлением сервера, поскольку:
- Только сервер знает точные характеристики каждого потока битов, например, положения переключения, приоритеты фреймов, будущие размеры фреймов.
- Может отсутствовать скорость потока битов, которая соответствует скорости потока битов в сети, так что сервер может использовать некоторые "трюки" (например, разрежение, переключение с повышением и снижением скорости) для согласования скорости потока битов со скоростью потоков битов в сети.
Управление скоростью передачи данных (то есть скоростью, с которой происходит передача данных) также оставляют для сервера (то есть с использованием отчетов RTCP), поскольку:
- В общем случае только сервер может измерить количество данных в ходе работы.
- Может возникнуть потребность связать скорость передачи битов с частотой дискретизации, если управление частотой дискретизации имеет ограниченную гибкость.
Отправитель ограничен при попытке обеспечить адаптацию следующими моментами.
- Модификация кривой передачи: кривая передачи ограничена кривой приема, и, таким образом, отправитель может не иметь возможности увеличить ее. Он может увеличить ее, только если ранее не была полностью использована его общая доступная полоса пропускания. Например, сервер может использовать механизм TFRC (УСБП, управление скоростью, благоприятное для протокола управления передачей) (или прием подробной информации о полосе пропускания с использованием передачи приемником соответствующих сигналов) для расчета своей допустимой скорости передачи данных и не должен увеличивать свою скорость выше скорости, которую допускает TFRC (или действительное, полученное с помощью передачи сигналов значение полосы пропускания).
- Модификация кривой дискретизации: зависит от возможности адаптации скорости отправителя. Например, если отправитель выполняет переключение потока битов и если отправитель выполняет передачу с самым низким (или с самым высоким) потоком битов, он не может дополнительно уменьшить (или увеличить) частоту дискретизации.
E. Случаи использования
В соответствии с настоящим изобретением параметры рабочего диапазона адаптации скорости передачи сервера согласовывают между сервером и приемником для минимизации возникновения опустошения, переполнения и ухудшения качества в таких случаях, как передача клиента, повторная передача и смещение тактовой частоты.
В случае передачи пакетов RTP приемник может выбирать количество повторных передач пакетов, которые он желает выполнить, и задержку, которая будет для него допустимой при повторной передаче.
В случае передачи клиента приемник может получить, например, на основе типа радиосети ожидаемую длительность передачи и, таким образом, определить требуемый целевой сдвиг. Приемник лучше знает параметры канала радиосвязи и также может детектировать передачу внутри системы и необходимость соответствующей адаптации параметров сдвига тактовой частоты.
Приемник может компенсировать смещение тактовой частоты с отправителем путем обновления параметров сдвига тактовой частоты.
Повторная передача RTP
Перед подачей запроса на повторную передачу приемник обычно должен оценить возможность повторной передачи пакета до его времени воспроизведения. Если пакет не может быть передан, повторная передача будет напрасно занимать доступную полосу пропускания.
Отправитель знает время дискретизации пакетов, которые были запланированы, по меньшей мере, со сдвигом α_min, для того, чтобы обеспечить соответствие ограничениям реального времени в приемнике.
Пакет повторной передачи в этом отношении не отличается от пакета, отправляемого в первый раз. Поскольку минимальный сдвиг указывает пороговое значение опустошения в приемнике, отправитель не должен выполнять повторную передачу пакета, если его временная метка меньше, чем t + α_min, где t представляет текущее время.
Передача сигнала с параметрами сдвига, таким образом, позволяет более эффективно выполнять повторную передачу пакетов, позволяя отправителю не выполнять повторную передачу пакетов, которые не смогут поступить в приемник до времени их декодирования и повторная передача которых напрасно использовала бы доступную полосу пропускания. Приемник не должен быть чрезмерно консервативным в своей оценке возможности приема недостающего пакета до его воспроизведения. Неправильная оценка не будет иметь эффекта (кроме бесполезного запроса), как если бы сервер не выполнил повторную передачу пакета.
Приемник также может принимать компромиссное решение в отношении количества повторных передач, которые он хотел бы выполнить, с использованием целевого сдвига. Чем больше величина целевого сдвига, тем больше пакетов будет отправлено заранее (и тем выше будет уровень приемного буфера), пока условия в сети хорошие. Это в свою очередь даст больше времени для повторных передач, когда условия сети ухудшаются.
Здесь снова сдвиг тактовой частоты является упреждающим. Приемнику не требуется синхронизировать запрос на сдвиг с запросом RTCP.
Передачи клиента
Передачу сигналов с указанием значений сдвига тактовой частоты можно использовать как инструмент для предотвращения перерывов воспроизведения в приемнике в результате передачи клиента.
Предположим, что приемник подключен к сети, и он знает, что ожидаемая длительность передачи клиента для этой сети составляет TH. Предположим, что приемник устанавливает свой целевой сдвиг так, чтобы он был, по меньшей мере, больше на значение TH, чем минимальный сдвиг, то есть α_target > α_min + TH.
Перед передачей клиента отправитель обеспечивает соответствие целевому сдвигу путем более ранней передачи пакетов. Когда отправитель детектирует передачу клиента, он должен остановить передачу данных (исключая, таким образом, потерю пакета из-за переполнения сетевого буфера). Во время передачи клиента импульсы тактовой частоты продолжают поступать в отсутствие передачи новых данных. Как следствие этого, передача клиента уменьшает сдвиг на величину времени TH (если предположить, что время передачи клиента продолжается ровно TH). Поскольку отправитель работал с целевым сдвигом перед передачей клиента, сдвиг после передачи клиента составит α_target - TH.
Эта величина все еще больше, чем минимальный сдвиг α_min. Это означает, что режим реального времени все еще удовлетворяется, и в приемнике отсутствует опустошение буфера. Во время передачи клиента приемник может воспроизводить пакеты, которые были переданы отправителем, в соответствии с целевым сдвигом и без существенного ухудшения качества.
После передачи клиента отправитель восстанавливает целевой сдвиг, когда его скорость передачи данных снова увеличивается. При этом не требуется передача каких-либо сигналов.
Приемник передает сигнал с новым параметром сдвига, только если ему требуется увеличить свой целевой сдвиг, для дополнительного увеличения допустимой длительности передачи клиента. Это может случиться, в частности, если выполняется передача клиента в сеть другого типа с другой ожидаемой длительностью передачи клиента.
Отправитель, конечно, должен иметь возможность детектировать передачу клиента. Отправитель обычно детектирует передачу клиента, когда он не принимает пакет RTCP в течение нескольких интервалов RTCP. Чтобы обеспечить возможность как можно более раннего детектирования отправителем передачи клиента, приемник должен передавать ранний пакет обратной связи, если AVPF доступен. AVPF представляет собой расширенный профиль для обратной связи на основе RTCP.
Если приемник передает параметры с использованием RTSP, он может передать новый запрос после передачи клиента (с теми же параметрами или с обновленным значением). Это может помочь отправителю более быстро детектировать, что произошла передача клиента, если быстрая обратная связь RTCP не доступна.
Передача клиента и ее влияние на уровень буфера показаны на фиг.2. В этом примере, во время передачи клиента, уровень буфера уменьшается, но не происходит его опустошение. После передачи клиента отправитель самостоятельно восстанавливает исходное целевое значение α_target. Однако поскольку буфер был практически опорожнен во время передачи клиента, приемник может выбрать передачу сигнала с указанием большего целевого значения сразу после выполнения передачи клиента. Это может происходить из-за того, что первая передача клиента была больше, чем приемник первоначально ожидал, и он желает гарантировать возможность поддержки более длительных передач клиента в будущем. Передача сигналов с указанием нового целевого значения и ее влияние на кривые показаны на фигуре.
Смещение тактовой частоты
Из-за смещения тактовой частоты между отправителем и приемником или по каким-либо другим причинам (например, когда операционная система платформы клиента является медленнодействующей) отправитель может выглядеть слишком медленным или слишком быстрым для приемника. Смещение можно корректировать путем отправки новых параметров сдвига.
Например, в случае медленного приемника приемник может периодически запрашивать снижение значения минимального сдвига.
F. Формат сообщения и транспортировка
Новый заголовок RTSP может быть определен как "Параметры- сдвига-3GPP". Этот заголовок можно использоёвать в запросах клиента для передачи сигнала с параметрами сдвига, запрашиваемыми клиентом.
Если запрос относится к сеансу URL (УУР, унифицированный указатель ресурса) на уровне RTSP, этот сдвиг можно применять для всех мультимедийных данных в ходе сеанса. Если запрос относится к URL на уровне мультимедийных данных RTSP, этот сдвиг должен применяться только для этих мультимедийных данных. Отправитель также использует в своем ответе "Параметры-сдвига-3GPP". Параметры могут представлять собой параметры, запрашиваемые клиентом. Однако отправитель может возвращать параметры, которые только близки, в возможно большей степени к запрашиваемым параметрам (из-за ограниченных возможностей отправителя).
Этот новый заголовок может быть отправлен с использованием любого способа RTSP.
Ниже представлен ABNF для этого заголовка RTP:
3gppshiftparameters = "3GPP-Shift-Parameters" ":"
shift-parameter * (";" shift-parameter) CRLF
shift-parameter = alpha-min / alpha-target / max-size
alpha-min = "alpha_min" "=" "+" / "-" 1*DIGIT; ms
alpha-target = "alpha_target" "=" "+" / "-" 1*DIGIT; ms
max-size = "max_size" "=" 1*DIGIT; bytes
В первый раз клиент передает все параметры. При последующих запросах клиент может передать только параметр (параметры), изменение которого он запрашивает.
Если изменение является приемлемым, серверу не требуется передавать заголовок, если все параметры были установлены так, как запрашивал приемник.
Если новый запрос поступает в сервер до выполнения предыдущего запроса, сервер должен выполнить самый последний запрос.
Отправитель также может передавать сигнал в приемник в начале сеанса, с указанием параметров, которые хотел бы использовать отправитель. Приемник учитывает эти параметры, когда выбирает значения параметров для запроса.
Хотя предпочтительный способ передачи сигналов с указанием параметров представляет использование RTSP, также можно использовать ненадежный протокол транспортирования, такой как RTCP.
На фиг.3 показана блок-схема, иллюстрирующая систему 1 потоковой передачи мультимедийных данных в сети потоковой передачи данных, в соответствии с настоящим изобретением, в которой используется средство для передачи сигналов с указанием параметров, которые определяют рабочий диапазон адаптации скорости передачи данных для элемента сети или сервера 10 потоковой передачи данных, в соответствии с согласованием между терминалом или клиентом 60 потоковой передачи данных с сервером 10 потоковой передачи данных.
Сервер 10 потоковой передачи данных содержит механизм 20 передачи сигналов на уровне прикладной программы, контроллер 30 скорости передачи и буфер 40 сервера. Клиент 60 потоковой передачи данных содержит механизм 70 передачи сигналов на уровне прикладной программы, соответствующий и адаптированный для связи с механизмом 20 передачи сигналов на уровне прикладной программы в сервере 10 потоковой передачи данных. Он дополнительно содержит буфер 80 клиента, который, в варианте выполнения изобретения, представленном на фиг.3, содержит буфер 82 для компенсации быстрых флуктуаций и буфер 84 перед декодированием, интегрированные как единый модуль. В других вариантах выполнения изобретения клиент 60 потоковой передачи данных может включать буфер для компенсации быстрых флуктуаций и буфер перед декодированием, которые выполнены отдельно. Клиент потоковой передачи данных дополнительно содержит декодер 90 мультимедийных данных, буфер 100 после декодирования, контроллер 110 буфера и устройство 120 отображения/воспроизведения.
В системе, изображенной на фиг.3, также показан "буфер 50 канала", расположенный между сервером 10 потоковой передачи данных и клиентом 60 потоковой передачи данных, который представляет переменную задержку передачи, которая происходит во время передачи пакетов данных от сервера потоковой передачи данных в клиент.
В клиенте 60 потоковой передачи данных принимают мультимедийные данные из канала передачи данных и выполняют их буферизацию в буфере 80 клиента. Параметры буфера 84 перед декодированием и буфера 82 компенсации быстрых флуктуаций устанавливаются контроллером 110 буфера. Эти параметры выбирают как совокупность рекомендованных сервером параметров буферизации перед декодированием и дополнительной буферизации, требуемой в соответствии с оценкой клиента. Клиент оценивает потребности для допуска ожидаемой вариации задержки при передаче пакета (то есть за счет быстрых флуктуаций) по доступному каналу передачи данных. Такое совокупное значение ограничено максимальными возможностями буферизации клиента. Декодер 90 выделяет мультимедийные данные из буфера клиента и декодирует эти мультимедийные данные в соответствии с типом мультимедийных данных. Следует понимать, что мультимедийные данные обычно содержат множество различных типов мультимедийных данных. Например, если мультимедийные данные, переданные из сервера, представляют собой видеопоследовательности, то они, вероятно, кроме видеоданных содержат, по меньшей мере, компонент звука. Поэтому следует понимать, что мультимедийный декодер 90, как показано на фиг.3, в действительности может содержать более чем один декодер, например видеодекодер, выполненный в соответствии с определенным стандартом видеокодирования, и соединенный с ним декодер звука. После того, как мультимедийные данные будут декодированы декодером 90 мультимедийных данных, они поступают в буфер 100 после декодирования, где их временно сохраняют до запланированного времени воспроизведения, и в этот момент времени они поступают из буфера после декодирования в устройство 120 отображения/воспроизведения под управлением контроллера 110 буфера.
В соответствии с изобретением контроллер 110 буфера предназначен для обеспечения указания минимального сдвига, целевого сдвига и максимального количества заранее переданных байтов в механизм 70 передачи сигналов на уровне прикладной программы. Эти параметры определяются с помощью программы 116 программного обеспечения, например, на основе ограничений буферизации клиента, временной линии декодирования/воспроизведения и т.д. Механизм передачи сигналов на уровне прикладной программы в свою очередь адаптирован для передачи сигнала 300, в котором указаны эти параметры адаптации скорости передачи в рабочем диапазоне, в сервер 10 потоковой передачи данных. Эти параметры передают из клиента в сервер с использованием, например, протокола потоковой передачи данных в реальном времени (RSTP). Заголовок RSPT может быть определен, например, как "Параметры-сдвига-3GPP".
В сервере контроллер 30 скорости передачи сервера адаптирует скорость передачи данных к скорости приема данных и адаптирует частоту дискретизации к скорости передачи данных, управляя сдвигом и поддерживая его в диапазоне адаптации скорости передачи данных. Сервер также имеет блок 32 тактовой частоты передачи данных для установки временных меток в пакетах, передаваемых в клиент. Сервер, используя программу 36, регулирует скорость передаваемых данных в соответствии с параметрами, рекомендованными клиентом, изменяя скорость передачи битов в канале передачи данных, с учетом рекомендованных клиентом параметров сдвига, стремясь, таким образом, исключить паузы при воспроизведении в клиенте возникающие из-за опустошения буфера перед декодером или потери пакетов в клиенте, из-за переполнения буфера.
В буфере 40 сервера временно хранятся пакеты данных перед тем, как они будут переданы из сервера потоковой передачи данных по каналу передачи данных в клиент 60 потоковой передачи данных. При использовании сценария потоковой передачи данных в режиме "прямой передачи", когда дискретизацию пакетов данных выполняют в режиме реального времени, буфер сервера в действительности представляет собой физический буфер, в который помещают пакеты данных во время дискретизации и выделяют во время передачи. В сценарии потоковой передачи данных с "предварительным кодированнием", когда дискретизацию пакетов данных не выполняют в режиме реального времени, но записывают в виде заранее закодированного файла и которые считывают из файла во время передачи, буфер сервера представляет собой виртуальный буфер, который предоставляет разность между временем дискретизации (со ссылкой на тактовую частоту дискретизации, начатую в сервере потоковой передачи данных, когда передают первый пакет данных предварительно кодированного файла) и временем передачи пакетов данных.
Сервер также может использовать механизм 20 передачи сигналов на уровне прикладной программы для передачи в приемник в начале сеанса сигнала 300, указывающего параметры, которые сервер хотел бы использовать. Учитывая параметры, представляемые сигналом 300, приемник выбирает параметры рабочего диапазона адаптации скорости передачи данных сервера. Основываясь на возможностях сервера, сервер может использовать сигнал 300 в ответ на запрос клиента, возвращая параметры, которые сервер может использовать для адаптации скорости передачи данных.
Преимущества настоящего изобретения
Способы известного уровня техники (заголовки RTSP и переключение скорости передачи битов) имеют множество ограничений. Одно из ограничений состоит в том, что заголовок SPEED можно передавать только в запросе воспроизведения PLAY RTSP.
- Не предполагалось использование PLAY для управления буфером, а скорее для передачи запросов пользователя от клиента на сервер.
- Нельзя ожидать, что ответ на новый PLAY в запросе диапазона будет синхронизирован с действительным положением воспроизведения в тот момент времени, когда сервер получает запрос (то есть возможны пропуски или повторная передача данных).
- Модификация скорости передачи данных в соответствии с запросом клиента с использованием RTSP SPEED часто может быть невозможна вообще, поскольку скорость передачи данных должна быть адаптирована с доступной скоростью передачи битов.
- Работа происходит в области скорости передачи битов, которая не может быть непосредственно отображена приемником на область времени (то есть величину времени, необходимую для воспроизведения приемником заданного количества данных). Это происходит из-за того, что кривая дискретизации обычно не представляет собой прямую линию.
- Может не существовать такая скорость передачи битов, которая соответствует скорости передачи битов NW.
- Клиент не знает, насколько уровень буфера приемника понижается/повышается в результате изменения скорости передачи битов в пределах данного потока битов, или из-за накопления различий между средней скоростью передачи потока битов и скоростью передачи данных.
- В отправителе и в приемнике возникает конфликт между решениями о форме кривой дискретизации, поскольку отсутствует разделение задач сервера и клиента. Это следует отличать от передачи сигналов с указанием сдвига тактовой частоты, с помощью которой обеспечивается явное разделение ответственности отправителя и приемника. Приемник только модифицирует ограничения кривых, в то время как отправитель выполняет действительное формирование кривых для удовлетворения этих ограничений.
Настоящее изобретение имеет следующие преимущества.
- Схема может работать в более упреждающем режиме. Идея состоит в том, чтобы сервер мог выполнять управление скоростью передачи данных с меньшими ограничениями и более гибко, когда клиент запрашивает рабочий диапазон, а не строго установленную рабочую точку.
- Запрашиваемый рабочий диапазон адаптации скорости передачи сервером теперь ясно и однозначно определен, что упрощает выполнение адаптивного сервера.
- Дополнительные расходы на схему передачи сигналов уменьшены благодаря уменьшению требуемой частоты и скорости (то есть синхронно RTP) при передаче сигналов клиента на сервер.
- Надежность транспортирования и правильная конвейерная обработка пакетов сообщений запроса, передаваемых из клиента на сервер в отношении рабочего диапазона адаптации скорости передачи данных сервером может быть обеспечена с использованием передачи сигналов RTSP. Это соответствует (то есть больше не противоречит) ослабленному требованию по скорости и частоте передачи сигналов.
В общем, настоящее изобретение обеспечивает способ и систему адаптивного управления уровнем приемного буфера в терминале или в клиенте в сети потоковой передачи мультимедийных данных. Сеть потоковой передачи мультимедийных данных имеет сетевой элемент или сервер, предназначенный для предоставления потоковых данных в клиент. Сервер отвечает за адаптацию скорости передачи данных к скорости приема или управление накоплением, и за адаптацию частоты дискретизации к скорости передачи данных. Таким образом, сервер управляет сдвигом и поддерживает его в рабочем диапазоне адаптации скорости передачи данных. Клиент отвечает за компенсацию вариации задержки передачи пакетов, которая также известна как быстрые флуктуации сети. Клиент также отвечает за передачу параметров рабочего диапазона адаптации скорости передачи данных сервером. Клиент выбирает и передает параметры сдвига на сервер, но сервер самостоятельно адаптирует свою скорость кодирования или скорость передачи данных в ответ на эти параметры.
Хотя изобретение было описано в отношении одного или нескольких вариантов его выполнения, для специалистов в данной области техники будет понятно, что указанные выше и другие различные изменения, исключения и отклонения в его форме и деталях могут быть выполнены без отхода от объема настоящего изобретения.

Claims (36)

1. Способ адаптивного управления уровнем буфера приемника в клиенте в сети потоковой передачи мультимедийных данных, причем сеть потоковой передачи данных содержит сервер, предоставляющий потоковые данные в клиент, при этом буфер приемника используют для компенсации разности между количеством данных, передаваемых сервером, и количеством данных, используемых клиентом, что позволяет клиенту иметь достаточное количество потоковых данных для воспроизведения без перерывов, отличающийся тем, что
определяют в клиенте, по меньшей мере, один параметр для определения рабочего диапазона адаптации скорости для выполнения адаптации скорости передачи между сервером и клиентом,
адаптируют на сервере количество данных к скорости приема на основе указанного, по меньшей мере, одного параметра, и
регулируют в клиенте вариации задержки передачи пакета на основе указанной адаптации.
2. Способ по п.1, отличающийся тем, что указанный, по меньшей мере, один параметр содержит величину минимального сдвига, указывающую разность между временем дискретизации и временем передачи пакета на сервере, что позволяет серверу выполнять указанную адаптацию на основе минимальной величины сдвига.
3. Способ по п.1, отличающийся тем, что указанный, по меньшей мере, один параметр содержит целевую величину сдвига, указывающую величину сдвига, большую, чем разность между временем дискретизации и временем передачи пакета на сервере, что позволяет серверу выполнять указанную адаптацию на основе целевой величины сдвига.
4. Способ по п.1, отличающийся тем, что указанный, по меньшей мере, один параметр содержит число, обозначающее максимальную разность между количеством байтов, которые были переданы, и количеством дискретизированных байтов, что позволяет серверу выполнять указанную адаптацию на основе этого числа.
5. Способ по п.1, отличающийся тем, что дополнительно адаптируют частоту дискретизации к скорости передачи на сервере, на основе указанного, по меньшей мере, одного параметра.
6. Способ по п.1, отличающийся тем, что указанный, по меньшей мере, один параметр содержит величину сдвига тактовой частоты для предотвращения перерывов воспроизведения в клиенте.
7. Способ по п.1, отличающийся тем, что указанная адаптация содержит регулировку скорости передачи.
8. Способ по п.1, отличающийся тем, что указанная адаптация содержит регулировку частоты дискретизации.
9. Способ по п.1, отличающийся тем, что указанная адаптация содержит регулировку как скорости передачи, так и частоты дискретизации.
10. Способ по п.1, отличающийся тем, что указанный, по меньшей мере, один параметр содержит
минимальную величину сдвига, указывающую разность между временем дискретизации и временем передачи пакета на сервере;
целевую величину сдвига, указывающую величину сдвига, большую, чем разность между временем дискретизации и временем передачи пакета на сервере;
число, обозначающее максимальную разность между количеством байтов, которые были переданы, и количеством дискретизированных байтов; и
величину сдвига тактовой частоты, и при этом две или более величин из минимальной величины сдвига, целевой величины сдвига, обозначающего числа и тактовой частоты передают вместе на сервер.
11. Система потоковой передачи мультимедийных данных, содержащая
по меньшей мере, клиент; и
сервер, предназначенный для предоставления потоковых данных в клиент, причем клиент имеет буфер приемника, предназначенный для компенсации разности между количеством данных, передаваемых сервером, и количеством данных, используемых клиентом, что позволяет клиенту иметь достаточное количество потоковых данных для воспроизведения без перерывов, при этом клиент содержит
механизм для определения, по меньшей мере, одного параметра для определения рабочего диапазона адаптации скорости, что позволяет серверу адаптировать количество данных к скорости приема, на основе указанного, по меньшей мере, одного параметра; и
механизм для регулирования вариации задержки передачи пакета на основе указанной адаптации.
12. Система потоковой передачи мультимедийных данных по п.11, отличающаяся тем, что указанный, по меньшей мере, один параметр содержит минимальную величину сдвига, указывающую разность между временем дискретизации и временем передачи пакета на сервере, что позволяет серверу выполнять указанную адаптацию.
13. Система потоковой передачи мультимедийных данных по п.11, отличающаяся тем, что указанный, по меньшей мере, один параметр содержит целевую величину сдвига, указывающую величину сдвига, большую, чем разность между временем дискретизации и временем передачи пакета на сервере, что позволяет серверу выполнять указанную адаптацию.
14. Система потоковой передачи мультимедийных данных по п.11, отличающаяся тем, что указанный, по меньшей мере, один параметр содержит число, обозначающее максимальную разность между количеством переданных байтов и количеством дискретизированных байтов, что позволяет серверу выполнять указанную адаптацию.
15. Система потоковой передачи мультимедийных данных по п.11, отличающаяся тем, что сервер содержит механизм адаптации, предназначенный для адаптации частоты дискретизации к скорости передачи на основе указанного, по меньшей мере, одного параметра.
16. Система потоковой передачи мультимедийных данных по п.11, отличающаяся тем, что указанный, по меньшей мере, один параметр содержит величину сдвига тактовой частоты для предотвращения перерывов воспроизведения в клиенте.
17. Система потоковой передачи мультимедийных данных по п.11, отличающаяся тем, что сервер содержит механизм адаптации для регулирования скорости передачи.
18. Система потоковой передачи мультимедийных данных по п.11, отличающаяся тем, что сервер содержит механизм адаптации для регулирования частоты дискретизации.
19. Система потоковой передачи мультимедийных данных по п.11, отличающаяся тем, что сервер содержит механизм адаптации для регулирования как скорости передачи, так и частоты дискретизации.
20. Система потоковой передачи мультимедийных данных по п.11, отличающаяся тем, что сервер содержит программу программного обеспечения, имеющую, по меньшей мере, код для выполнения указанной адаптации.
21. Машиночитаемый запоминающий носитель с содержащимся там программным продуктом для использования в клиенте в сети потоковой передачи мультимедийных данных для адаптивного управления уровнем буфера приемника в клиенте, причем сеть потоковой передачи мультимедийных данных содержит сервер, выполненный с возможностью предоставления потоковых данных в клиент, при этом буфер приемника используется для компенсации разности между количеством данных, передаваемых сервером, и количеством данных, используемых клиентом, что позволяет клиенту иметь достаточное количество потоковых данных для воспроизведения без перерывов, упомянутый программный продукт отличается тем, что содержит
код для определения, по меньшей мере, одного параметра, предназначенного для определения рабочего диапазона адаптации скорости на сервере, для выполнения адаптации скорости между сервером и клиентом; и
код для регулирования вариации задержки передачи пакета на основе указанной адаптации.
22. Машиночитаемый запоминающий носитель по п.21, отличающийся тем, что указанный, по меньшей мере, один параметр содержит минимальную величину сдвига, указывающую разность между временем дискретизации и временем передачи пакета на сервере, что позволяет серверу выполнять указанную адаптацию скорости.
23. Машиночитаемый запоминающий носитель по п.21, отличающийся тем, что указанный, по меньшей мере, один параметр содержит целевую величину сдвига, указывающую величину сдвига, большую, чем разность между временем дискретизации и временем передачи пакета на сервере, что позволяет серверу выполнять указанную адаптацию скорости.
24. Машиночитаемый запоминающий носитель по п.21, отличающийся тем, что указанный, по меньшей мере, один параметр содержит число, обозначающее максимальную разность между количеством переданных байтов и количеством дискретизированных байтов, что позволяет серверу выполнять указанную адаптацию скорости.
25. Машиночитаемый запоминающий носитель по п.21, отличающийся тем, что указанный, по меньшей мере, один параметр содержит величину сдвига тактовой частоты для предотвращения перерывов при воспроизведении в клиенте.
26. Терминал в сети потоковой передачи мультимедийных данных, имеющей, по меньшей мере, сервер, предназначенный для предоставления потоковых данных в терминал, причем терминал имеет буфер приемника, предназначенный для компенсации разности между количеством данных, переданных сервером, и количеством данных, используемых терминалом, что позволяет терминалу иметь достаточное количество потоковых данных для воспроизведения без перерывов, отличающийся тем, что содержит
механизм для определения, по меньшей мере, одного параметра, который определяет рабочий диапазон адаптации скорости на сервере, что позволяет серверу адаптировать количество передаваемых данных к скорости приема, на основе указанного, по меньшей мере, одного параметра; и
механизм для регулирования вариации задержки передачи пакета на основе указанной адаптации.
27. Терминал по п,26, отличающийся тем, что указанный механизм определения содержит программу программного обеспечения, имеющую, по меньшей мере, код для определения указанного, по меньшей мере, одного параметра.
28. Терминал по п.26, отличающийся тем, что указанный механизм регулирования содержит программу программного обеспечения, имеющую, по меньшей мере, код для регулирования вариации задержки передачи пакета.
29. Терминал по п.26, отличающийся тем, что указанный, по меньшей мере, один параметр содержит минимальную величину сдвига, указывающую разность между временем дискретизации и временем передачи пакета на сервере, что позволяет серверу выполнять указанную адаптацию на основе минимальной величины сдвига.
30. Терминал по п.26, отличающийся тем, что указанный, по меньшей мере, один параметр содержит целевую величину сдвига, указывающую величину сдвига, большую, чем разность между временем дискретизации и временем передачи пакета на сервере, что позволяет серверу выполнять указанную адаптацию на основе целевой величины сдвига.
31. Терминал по п.26, отличающийся тем, что указанный, по меньшей мере, один параметр содержит число, обозначающее максимальную разность между количеством переданных байтов и количеством дискретизированных байтов, что позволяет серверу выполнять указанную адаптацию на основе этого числа.
32. Сетевой элемент в сети потоковой передачи мультимедийных данных, имеющей, по меньшей мере, терминал, который принимает потоковые данные от сетевого элемента, причем терминал имеет буфер приемника для компенсации разности между количеством данных, переданных сетевым элементом, и количеством данных, используемых терминалом, что позволяет терминалу иметь достаточное количество потоковых данных для воспроизведения без перерывов, отличающийся тем, что содержит
средство приема запроса из терминала, причем в запросе указан, по меньшей мере, один параметр, который определяет рабочий диапазон адаптации скорости сетевого элемента; и
механизм, предназначенный для адаптации, на основе указанного, по меньшей мере, одного параметра, количества передаваемых данных к скорости приема терминала, что позволяет терминалу регулировать вариацию задержки передачи пакета на основе указанной адаптации.
33. Сетевой элемент по п.32, отличающийся тем, что указанный механизм адаптации содержит программу программного обеспечения, имеющую, по меньшей мере, код, предназначенный для адаптации количества передаваемых данных.
34. Сетевой элемент по п.33, отличающийся тем, что программа программного обеспечения содержит код, предназначенный для регулирования скорости передачи.
35. Сетевой элемент по п.33, отличающийся тем, что программа программного обеспечения содержит код, предназначенный для регулирования частоты дискретизации.
36. Сетевой элемент по п.33, отличающийся тем, что программа программного обеспечения содержит код, предназначенный для регулирования как скорости передачи, так и частоты дискретизации.
RU2005136435/09A 2003-04-24 2004-04-23 Устройство и способ передачи сигналов с упреждающей адаптацией скорости RU2367011C2 (ru)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US46512003P 2003-04-24 2003-04-24
US60/465,120 2003-04-24
US10/826,687 2004-04-16
US10/826,687 US7844727B2 (en) 2003-04-24 2004-04-16 Method and device for proactive rate adaptation signaling

Publications (2)

Publication Number Publication Date
RU2005136435A RU2005136435A (ru) 2006-06-10
RU2367011C2 true RU2367011C2 (ru) 2009-09-10

Family

ID=33423544

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2005136435/09A RU2367011C2 (ru) 2003-04-24 2004-04-23 Устройство и способ передачи сигналов с упреждающей адаптацией скорости

Country Status (13)

Country Link
US (1) US7844727B2 (ru)
EP (1) EP1616267B1 (ru)
JP (1) JP4347883B2 (ru)
KR (1) KR20060011964A (ru)
AT (1) ATE446631T1 (ru)
DE (1) DE602004023710D1 (ru)
DK (1) DK1616267T3 (ru)
ES (1) ES2332315T3 (ru)
MX (1) MXPA05011247A (ru)
MY (1) MY140711A (ru)
RU (1) RU2367011C2 (ru)
TW (1) TWI266201B (ru)
WO (1) WO2004097660A1 (ru)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2690755C2 (ru) * 2010-02-19 2019-06-05 Телефонактиеболагет Л М Эрикссон (Пабл) Способ и устройство для переключения воспроизведений в потоковой передаче по протоколу передачи гипертекста

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004072765A2 (en) * 2003-02-13 2004-08-26 Nokia Corporation Method for signaling streaming quality adaptation and control mechanisms in multimedia streaming
FR2857198B1 (fr) * 2003-07-03 2005-08-26 Canon Kk Optimisation de qualite de service dans la distribution de flux de donnees numeriques
JP4183586B2 (ja) * 2003-09-12 2008-11-19 三洋電機株式会社 映像表示装置
US7818444B2 (en) 2004-04-30 2010-10-19 Move Networks, Inc. Apparatus, system, and method for multi-bitrate content streaming
US8868772B2 (en) * 2004-04-30 2014-10-21 Echostar Technologies L.L.C. Apparatus, system, and method for adaptive-rate shifting of streaming content
US7571246B2 (en) * 2004-07-29 2009-08-04 Microsoft Corporation Media transrating over a bandwidth-limited network
KR20060065482A (ko) * 2004-12-10 2006-06-14 마이크로소프트 코포레이션 스트리밍 미디어 데이터의 코딩 비트 레이트의 제어 시스템및 프로세스
US20060143678A1 (en) * 2004-12-10 2006-06-29 Microsoft Corporation System and process for controlling the coding bit rate of streaming media data employing a linear quadratic control technique and leaky bucket model
US7543073B2 (en) * 2004-12-10 2009-06-02 Microsoft Corporation System and process for performing an exponentially weighted moving average on streaming data to establish a moving average bit rate
US7536469B2 (en) * 2004-12-10 2009-05-19 Microsoft Corporation System and process for controlling the coding bit rate of streaming media data employing a limited number of supported coding bit rates
TWI401918B (zh) * 2005-02-03 2013-07-11 Nokia Corp 傳送指示接收器緩衝架構之緩衝參數信號的通訊方法
US20060184697A1 (en) * 2005-02-11 2006-08-17 Microsoft Corporation Detecting clock drift in networked devices through monitoring client buffer fullness
US8683066B2 (en) 2007-08-06 2014-03-25 DISH Digital L.L.C. Apparatus, system, and method for multi-bitrate content streaming
US8370514B2 (en) 2005-04-28 2013-02-05 DISH Digital L.L.C. System and method of minimizing network bandwidth retrieved from an external network
JP4274149B2 (ja) * 2005-05-19 2009-06-03 ソニー株式会社 コンテンツ再生装置及びコンテンツ再生方法
US7743183B2 (en) 2005-05-23 2010-06-22 Microsoft Corporation Flow control for media streaming
US8214516B2 (en) * 2006-01-06 2012-07-03 Google Inc. Dynamic media serving infrastructure
US7962637B2 (en) * 2006-11-03 2011-06-14 Apple Computer, Inc. Dynamic adjustments of video streams
KR100899659B1 (ko) * 2006-12-01 2009-05-27 한국전자통신연구원 패킷 스케줄러 및 패킷 스케줄링 방법
RU2380839C2 (ru) * 2007-03-21 2010-01-27 Общество с ограниченной ответственностью "Линкстрим" Способ адаптивного управления передачей потоковых медиаданных
FR2923118B1 (fr) * 2007-10-30 2016-04-01 Canon Kk Procede, dispositif et programme d'ordinateur pour la gestion de la quantite de donnees emises par un dispositif d'emission
US8370622B1 (en) * 2007-12-31 2013-02-05 Rockstar Consortium Us Lp Method and apparatus for increasing the output of a cryptographic system
US8305899B2 (en) * 2008-05-28 2012-11-06 Microsoft Corporation Pull-based data transmission approach
KR20110045086A (ko) * 2008-08-28 2011-05-03 쿄세라 코포레이션 무선 단말 및 통신 단말
CA2759880C (en) * 2009-03-23 2013-09-24 Azuki Systems, Inc. Method and system for efficient streaming video dynamic rate adaptation
KR20110065100A (ko) * 2009-12-09 2011-06-15 삼성전자주식회사 멀티미디어 스트리밍 서비스를 지원하는 방법 및 장치
US9439100B2 (en) * 2012-06-27 2016-09-06 Aruba Networks, Inc. System and method for dynamic rate adaptation based on real-time call quality metrics
US9131251B2 (en) * 2012-09-20 2015-09-08 Google Technology Holdings LLC Use of a receive-window size advertised by a client to a content server to change a video stream bitrate streamed by the content server
US9462021B2 (en) 2012-09-24 2016-10-04 Google Technology Holdings LLC Methods and devices for efficient adaptive bitrate streaming
US9544344B2 (en) * 2012-11-20 2017-01-10 Google Technology Holdings LLC Method and apparatus for streaming media content to client devices
US9137285B2 (en) * 2013-10-21 2015-09-15 Broadcom Corporation Adaptive audio video (AV) stream processing
WO2017063189A1 (en) * 2015-10-16 2017-04-20 Qualcomm Incorporated Deadline signaling for streaming of media data
KR102532645B1 (ko) * 2016-09-20 2023-05-15 삼성전자 주식회사 적응적 스트리밍 서비스에서 스트리밍 어플리케이케이션으로 데이터를 제공하는 방법 및 장치
US10741143B2 (en) * 2017-11-28 2020-08-11 Nvidia Corporation Dynamic jitter and latency-tolerant rendering
US10691082B2 (en) * 2017-12-05 2020-06-23 Cisco Technology, Inc. Dynamically adjusting sample rates based on performance of a machine-learning based model for performing a network assurance function in a network assurance system
US11350268B2 (en) * 2018-05-18 2022-05-31 Qualcomm Incorporated End-to-end rate adaptation using RAN assisted rate adaptation
CN111246284B (zh) * 2020-03-09 2021-05-25 深圳创维－Rgb电子有限公司 视频流播放方法、系统、终端及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5565924A (en) * 1995-01-19 1996-10-15 Lucent Technologies Inc. Encoder/decoder buffer control for variable bit-rate channel
US6157614A (en) * 1997-10-22 2000-12-05 Netro Corporation Wireless ATM network with high quality of service scheduling
US6188697B1 (en) * 1996-05-29 2001-02-13 Nippon Telegraph And Telephone Corporation ATM cell transport system for wireless communications
RU2189072C2 (ru) * 1996-01-31 2002-09-10 Ипсилон Нетуоркс, Инк. Усовершенствованный способ и устройство для динамического смещения между пакетами маршрутизации и коммутации в сети передачи данных

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR0176806B1 (ko) * 1995-12-29 1999-05-01 구자홍 텔레비젼의 2화면 구성장치
US6175856B1 (en) * 1996-09-30 2001-01-16 Apple Computer, Inc. Method and apparatus for dynamic selection of compression processing during teleconference call initiation
EP0847171A1 (en) 1996-11-27 1998-06-10 Sony Europa B.V. Method and device for streaming data, including provision of write addresses
US6292834B1 (en) * 1997-03-14 2001-09-18 Microsoft Corporation Dynamic bandwidth selection for efficient transmission of multimedia streams in a computer network
US5903673A (en) * 1997-03-14 1999-05-11 Microsoft Corporation Digital video signal encoder and encoding method
JP3734946B2 (ja) 1997-12-15 2006-01-11 松下電器産業株式会社 データ送出装置、データ受信装置及びデータ伝送装置
JP3589851B2 (ja) * 1998-02-20 2004-11-17 株式会社日立製作所 パケット通信システム及びパケット通信装置
US6643259B1 (en) 1999-11-12 2003-11-04 3Com Corporation Method for optimizing data transfer in a data network
US6700893B1 (en) 1999-11-15 2004-03-02 Koninklijke Philips Electronics N.V. System and method for controlling the delay budget of a decoder buffer in a streaming data receiver
US7016970B2 (en) * 2000-07-06 2006-03-21 Matsushita Electric Industrial Co., Ltd. System for transmitting stream data from server to client based on buffer and transmission capacities and delay time of the client
WO2002010499A2 (en) * 2000-08-01 2002-02-07 Unilever Plc Textile treatment process and product
US7346698B2 (en) 2000-12-20 2008-03-18 G. W. Hannaway & Associates Webcasting method and system for time-based synchronization of multiple, independent media streams
DE10102154C2 (de) * 2001-01-18 2003-02-13 Fraunhofer Ges Forschung Verfahren und Vorrichtung zum Erzeugen eines skalierbaren Datenstroms und Verfahren und Vorrichtung zum Decodieren eines skalierbaren Datenstroms unter Berücksichtigung einer Bitsparkassenfunktion
JP2003158543A (ja) * 2001-11-22 2003-05-30 Anritsu Corp 中継装置及び中継方法
KR100420601B1 (ko) 2001-11-22 2004-03-02 에스케이 텔레콤주식회사 비디오 데이터 스트리밍 서비스 방법
EP1359722A1 (en) * 2002-03-27 2003-11-05 BRITISH TELECOMMUNICATIONS public limited company Data streaming system and method
US7305483B2 (en) * 2002-04-25 2007-12-04 Yahoo! Inc. Method for the real-time distribution of streaming data on a network
US7133925B2 (en) * 2002-07-15 2006-11-07 Hewlett-Packard Development Company, L.P. System, method, and format thereof for scalable encoded media delivery
AU2003249115A1 (en) * 2002-07-16 2004-02-02 Nokia Corporation Method for enabling packet transfer delay compensation in multimedia streaming
SG111978A1 (en) * 2002-11-20 2005-06-29 Victor Company Of Japan An mpeg-4 live unicast video streaming system in wireless network with end-to-end bitrate-based congestion control
US6968387B2 (en) * 2003-01-10 2005-11-22 Realnetworks, Inc. Stochastic adaptive streaming of content

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5565924A (en) * 1995-01-19 1996-10-15 Lucent Technologies Inc. Encoder/decoder buffer control for variable bit-rate channel
RU2189072C2 (ru) * 1996-01-31 2002-09-10 Ипсилон Нетуоркс, Инк. Усовершенствованный способ и устройство для динамического смещения между пакетами маршрутизации и коммутации в сети передачи данных
US6188697B1 (en) * 1996-05-29 2001-02-13 Nippon Telegraph And Telephone Corporation ATM cell transport system for wireless communications
US6157614A (en) * 1997-10-22 2000-12-05 Netro Corporation Wireless ATM network with high quality of service scheduling

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2690755C2 (ru) * 2010-02-19 2019-06-05 Телефонактиеболагет Л М Эрикссон (Пабл) Способ и устройство для переключения воспроизведений в потоковой передаче по протоколу передачи гипертекста

Also Published As

Publication number Publication date
JP4347883B2 (ja) 2009-10-21
ES2332315T3 (es) 2010-02-02
EP1616267A1 (en) 2006-01-18
KR20060011964A (ko) 2006-02-06
DE602004023710D1 (de) 2009-12-03
US7844727B2 (en) 2010-11-30
MY140711A (en) 2010-01-15
MXPA05011247A (es) 2005-12-14
ATE446631T1 (de) 2009-11-15
TWI266201B (en) 2006-11-11
TW200508883A (en) 2005-03-01
US20040267956A1 (en) 2004-12-30
RU2005136435A (ru) 2006-06-10
JP2006524452A (ja) 2006-10-26
DK1616267T3 (da) 2010-01-04
EP1616267A4 (en) 2007-08-15
EP1616267B1 (en) 2009-10-21
WO2004097660A1 (en) 2004-11-11

Similar Documents

Publication Publication Date Title
RU2367011C2 (ru) Устройство и способ передачи сигналов с упреждающей адаптацией скорости
US7558869B2 (en) Rate adaptation method and device in multimedia streaming
JP4430660B2 (ja) マルチメディアストリーミングのための方法及び装置
EP1535419B1 (en) Method and devices for controlling retransmissions in data streaming
US9191664B2 (en) Adaptive bitrate management for streaming media over packet networks
US8306058B2 (en) Communication system and techniques for transmission from source to destination
US7111058B1 (en) Server and method for transmitting streaming media to client through a congested network
US20040057446A1 (en) Method for enabling packet transfer delay compensation in multimedia streaming
WO2001037571A1 (en) System and method for controlling the delay budget of a decoder buffer in a streaming data receiver
JP2005526455A (ja) 仮想的な受信バッファを使用してチャネル伝送レートの変動を吸収する伝送方法
CN102484741A (zh) 用于规划媒体数据的传输时间的装置和方法
CN100405350C (zh) 预设速率匹配信号通知的方法和装置
KR20050019880A (ko) 멀티미디어 스트리밍에서 패킷 전달 지연 보상을 가능하게하기 위한 방법

Legal Events

Date Code Title Description
PC41 Official registration of the transfer of exclusive right

Effective date: 20160602

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载