УСТРОЙСТВО И СПОСОБ ПЕРЕДАЧИ СИГНАЛОВ С УПРЕЖДАЮЩЕЙ АДАПТАЦИЕЙ СКОРОСТИ
DEVICE AND METHOD OF TRANSMITTING SIGNALS WITH ANTICIPATORY ADAPTATION OF SPEED

Область техники, к которой относится изобретение
Настоящее изобретение, в общем, относится к передаче потоков мультимедийных данных и более конкретно к адаптации скорости передачи данных между сервером и клиентом в услугах передачи потоков мультимедийных данных.
Уровень техники
В услуге передачи потоков мультимедийных данных участвуют три объекта: потоковый сервер, потоковый клиент и канал передачи данных или используемая для передачи сеть. Обычно узким местом услуги при передаче является канал передачи данных как по пропускной способности, так и в отношении надежности (то есть в случаях, когда предполагается отсутствие гарантированной скорости передачи битов), но ограничения по пропускной способности также могут возникать в клиенте и/или в сервере.
В системе с потоковой передачей данных в режиме реального времени, из-за динамического изменения характеристик пропускной способности канала, клиента и сервера, потоковая передача данных должна быть адаптивной для поддержания воспроизведения данных для пользователя в режиме реального времени. Сервер должен адаптировать скорость передачи данных в соответствии с изменяющейся пропускной способностью системы. Пример такой системы с адаптивной скоростью можно найти в публикации 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.
Передачи клиента
Передачу сигналов с указанием значений сдвига тактовой частоты можно использовать как инструмент для предотвращения перерывов воспроизведения в приемнике в результате передачи клиента.
H
H,
H
Предположим, что приемник подключен к сети, и он знает, что ожидаемая длительность передачи клиента для этой сети составляет T. Предположим, что приемник устанавливает свой целевой сдвиг так, чтобы он был, по меньшей мере, больше на значение T чем минимальный сдвиг, то есть α_target > α_min + T.
H
H
H.
Перед передачей клиента отправитель обеспечивает соответствие целевому сдвигу путем более ранней передачи пакетов. Когда отправитель детектирует передачу клиента, он должен остановить передачу данных (исключая, таким образом, потерю пакета из-за переполнения сетевого буфера). Во время передачи клиента импульсы тактовой частоты продолжают поступать в отсутствие передачи новых данных. Как следствие этого, передача клиента уменьшает сдвиг на величину времени T (если предположить, что время передачи клиента продолжается ровно T). Поскольку отправитель работал с целевым сдвигом перед передачей клиента, сдвиг после передачи клиента составит α_target - T
.
Эта величина все еще больше, чем минимальный сдвиг α_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. Это соответствует (то есть больше не противоречит) ослабленному требованию по скорости и частоте передачи сигналов.
В общем, настоящее изобретение обеспечивает способ и систему адаптивного управления уровнем приемного буфера в терминале или в клиенте в сети потоковой передачи мультимедийных данных. Сеть потоковой передачи мультимедийных данных имеет сетевой элемент или сервер, предназначенный для предоставления потоковых данных в клиент. Сервер отвечает за адаптацию скорости передачи данных к скорости приема или управление накоплением, и за адаптацию частоты дискретизации к скорости передачи данных. Таким образом, сервер управляет сдвигом и поддерживает его в рабочем диапазоне адаптации скорости передачи данных. Клиент отвечает за компенсацию вариации задержки передачи пакетов, которая также известна как быстрые флуктуации сети. Клиент также отвечает за передачу параметров рабочего диапазона адаптации скорости передачи данных сервером. Клиент выбирает и передает параметры сдвига на сервер, но сервер самостоятельно адаптирует свою скорость кодирования или скорость передачи данных в ответ на эти параметры.
Хотя изобретение было описано в отношении одного или нескольких вариантов его выполнения, для специалистов в данной области техники будет понятно, что указанные выше и другие различные изменения, исключения и отклонения в его форме и деталях могут быть выполнены без отхода от объема настоящего изобретения.