RU2305908C2 - Адаптивный способ оценивания скорости передачи мультимедийных данных - Google Patents

Адаптивный способ оценивания скорости передачи мультимедийных данных Download PDF

Info

Publication number
RU2305908C2
RU2305908C2 RU2005123415A RU2005123415A RU2305908C2 RU 2305908 C2 RU2305908 C2 RU 2305908C2 RU 2005123415 A RU2005123415 A RU 2005123415A RU 2005123415 A RU2005123415 A RU 2005123415A RU 2305908 C2 RU2305908 C2 RU 2305908C2
Authority
RU
Russia
Prior art keywords
packet
transmission
rtcp
rate
packet loss
Prior art date
Application number
RU2005123415A
Other languages
English (en)
Other versions
RU2005123415A (ru
Inventor
Кванг-Деок СЕО (KR)
Кванг-Деок СЕО
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=36077276&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=RU2305908(C2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Эл Джи Электроникс Инк. filed Critical Эл Джи Электроникс Инк.
Publication of RU2005123415A publication Critical patent/RU2005123415A/ru
Application granted granted Critical
Publication of RU2305908C2 publication Critical patent/RU2305908C2/ru

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0001Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0002Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission rate
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/12Systems in which the television signal is transmitted via one channel or a plurality of parallel channels, the bandwidth of each channel being less than the bandwidth of the television signal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416Real-time traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/26Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H04L47/263Rate modification at the source after receiving feedback
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0001Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0023Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the signalling
    • H04L1/0026Transmission of channel quality indication

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Quality & Reliability (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

Изобретение относится к адаптивному вычислению скорости кодирования при использовании протокола передачи RTP/RTCP. Технический результат заключается в устранении завышения скорости передачи при больших потерях пакетов. Для этого производят адаптивную оценку скорости передачи в зависимости от коэффициента потерь пакетов: если коэффициент потерь мал, то используют известное уравнение для оценки, если коэффициент потерь средний, то используют линейную аппроксимацию известного уравнения для оценки, и если коэффициент потерь высок, то используют заранее выбранное значение минимальной скорости. 4 з.п. ф-лы, 5 ил.

Description

Уровень техники
Настоящее изобретение относится к системе передачи мультимедийных данных, основанной на протоколе передачи в реальном времени (RTP)/протоколе управления передачей в реальном времени (RTCP) в рамках протокола проводного IP (Интернет-протокола), в частности, к способу адаптивного оценивания скорости передачи мультимедийных данных с использованием функции контроля состояния сети протокола RTCP.
Предшествующий уровень техники
В общем случае, такие условия, как достаточная ширина полосы, малая задержка и малые потери пакетов и т.п. должны гарантироваться для передачи мультимедийных данных в проводной IP-сети, такой как Интернет. Однако сетевой уровень в современной проводной IP-сети не может обеспечить функцию, подходящую для удовлетворения требований по качеству обслуживания (QoS), необходимого для передачи видеоданных. Поэтому QoS должно быть обеспечено на более высоком сетевом уровне. С этой целью предложены протокол передачи в реальном времени (RTP) и протокол управления передачей в реальном времени (RTCP), работающие на транспортном уровне.
RTP представляет собой Интернет-протокол для мультимедийных данных реального времени, таких как аудио- и видеоданные, генерируемые в реальном времени. Хотя протокол RTP сам не гарантирует передачи данных в реальном времени, при использовании протокола RTP прикладные программы передачи/приема в системе передачи мультимедийных данных в реальном времени могут поддерживать потоковую передачу данных. Протокол RTP обычно исполняется на протоколе пользовательских дейтаграмм (UDP). Протокол RTCP представляет собой протокол, используемый для поддержания качества обслуживания (QoS) протокола RTP. Протокол RTP относится только к передаче данных, в то время как протокол RTCP относится к контролю передач данных и передаче информации, связанной с сеансами связи. Узлы протокола RTP посылают друг другу пакеты протокола RTCP, чтобы анализировать состояние сети и периодически сообщать, не перегружена ли сеть. При использовании протоколов RTP и RTCP могут учитываться характеристики в соответствии с временным ограничением при передаче мультимедийных данных, и можно противодействовать потерям, возникающим в сети.
В традиционной системе передачи мультимедийных данных мультимедийная прикладная программа (уровень приложений) определяет состояние сети посредством протокола RTCP и управляет скоростью кодирования мультимедийных данных реального времени, которые должны передаваться. Управление скоростью кодирования мультимедийных данных реального времени осуществляется за счет управления скоростью передачи, и традиционный способ оценивания эффективной скорости передачи путем использования информации состояния сети посредством протокола RTCP использует следующее уравнение (1):
Figure 00000002
(1)
Здесь R(t) обозначает эффективную скорость передачи, p(t) обозначает коэффициент потерь пакетов, получаемый посредством передачи по протоколу RTCP от приемной стороны. RTT(t) обозначает время задержки двустороннего распространения и s обозначает размер пакета.
Если время задержки двустороннего распространения RTT(t) и коэффициент потерь р(t) пакетов заданы, то общая эффективная скорость передачи оценивается с помощью уравнения (1). В частности, в известном способе оценивания скорости передачи с использованием уравнения (1), если размер (s) пакета постоянный, то оцениваемая скорость передачи изменяется в соответствии с временем задержки двустороннего распространения (RTT(t)) и коэффициентом потерь пакетов (р(t)).
На фиг.1 показано изменение доступной скорости передачи, оцениваемой согласно уравнению (1), когда коэффициент потерь пакетов (р(t)) и размер (s) пакетов постоянны, а время задержки двустороннего распространения (RTT(t)) изменяется линейным образом. Если коэффициент потерь пакетов является постоянным, так что p(t)≡0.015 и s≡625, а время задержки двустороннего распространения (RTT(t)) линейно возрастает от 80 мс до 380 мс, то минимальная скорость передачи для пользователя равна 50 кб/с, а максимальная скорость передачи равна 500 кб/с. Как показано на фиг.1, по мере того как время задержки двустороннего распространения (RTT(t)) увеличивается, оцениваемая доступная скорость передачи соответственно уменьшается.
На фиг.2 показано изменение доступной скорости передачи, оцениваемой согласно уравнению (1), когда время задержки двустороннего распространения (RTT(t)) и размер (s) пакетов постоянны, а коэффициент потерь пакетов (р(t)) изменяется линейным образом. Если время задержки двустороннего распространения (RTT(t)) равно 100 мс, размер (s) пакетов равен 625, а коэффициент потерь пакетов (р(t)) изменяется от 0,1% до 20%, то минимальная скорость передачи для пользователя равна 50 кб/с, а максимальная скорость передачи равна 500 кб/с.
Как показано на фиг.2, в известном способе для оценивания эффективной скорости передачи с использованием уравнения (1) не учитывается то, что вследствие больших потерь пакетов возникает такое явление как тайм-аут. Соответственно, когда коэффициент потерь пакетов мал, то доступная скорость передачи оценивается как имеющая подходящее значение. Однако если коэффициент потерь пакетов возрастает, то доступная скорость передачи оказывается преувеличенной. В частности, когда коэффициент потерь пакетов равен 10%, что является довольно высоким показателем, то доступная скорость передачи становится нежелательно завышенной примерно до 200 кб/с, если применяется традиционный способ оценивания скорости передачи.
Таким образом, традиционному способу оценивания скорости передачи свойственен недостаток, состоящий в том, что состояние перегрузки сети не может быть быстро разрешено, и качество приема мультимедийных данных ухудшается ввиду того, что скорость передачи получает завышенную оценку в условиях, когда коэффициент потерь пакетов велик.
Сущность изобретения
Поэтому задачей изобретения является создание способа адаптивного оценивания скорости передачи мультимедийных данных, обеспечивающего повышение точности оцениваемого значения доступной скорости передачи путем определения коэффициента потерь пакетов из пакета сообщения приемника протокола RTCP, передаваемого от приемной стороны, и изменения способа оценивания доступной скорости передачи в соответствии с коэффициентом потерь пакетов.
Для достижения этих и других результатов и в соответствии с назначением изобретения, как реализовано и в обобщенном виде описано ниже, предложен способ адаптивного оценивания скорости передачи мультимедийных данных, содержащий прием пакета сообщения приемника протокола управления передачей в реальном времени (RTCP), определения коэффициента потерь пакетов из пакета сообщения приемника протокола RTCP, и адаптивного оценивания доступной скорости передачи в соответствии с диапазоном, в который попадает коэффициент потерь пакетов.
Вышеуказанные и иные задачи, признаки, аспекты и преимущества настоящего изобретения поясняются в последующем детальном описании настоящего изобретения со ссылками на чертежи.
Краткое описание чертежей
Прилагаемые чертежи, которые включены для обеспечения более глубокого понимания изобретения и составляют часть данного описания, иллюстрируют варианты осуществления изобретения и вместе с описанием служат для пояснения принципов изобретения.
На чертежах показано следующее:
Фиг.1 - иллюстрация изменения доступной скорости передачи, оцененной известным способом оценивания, когда коэффициент потерь пакетов является постоянным, а время задержки двустороннего распространения изменяется линейным образом;
Фиг.2 - иллюстрация изменения доступной скорости передачи, оцененной известным способом оценивания, когда время задержки двустороннего распространения является постоянным, а коэффициент потерь пакетов изменяется линейным образом;
Фиг.3 - иллюстрация структуры известной системы передачи мультимедийных данных в реальном времени с использованием протоколов RTP и RTCP;
Фиг.4 - иллюстрация способа адаптивного оценивания скорости передачи мультимедийных данных в соответствии с настоящим изобретением и
Фиг.5 - иллюстрация изменения значений скорости передачи, оцененных способом вычислений, который варьируется в соответствии с величиной коэффициента потерь пакетов.
Детальное описание предпочтительных вариантов осуществления
Ниже детально описаны предпочтительные варианты осуществления настоящего изобретения, примеры которого иллюстрируются на чертежах.
На фиг.3 представлена структура известной системы передачи мультимедийных данных в реальном времени с использованием протоколов RTP и RTCP.
Как представлено на чертеже, блок передачи и блок приема известной системы передачи мультимедийных данных в реальном времени разделены на транспортные области и области сжатия (включенные в уровень приложений), соответственно.
Область сжатия блока передачи содержит видеокодер, который кодирует мультимедийные данные в соответствии с оцененной скоростью передачи; и блок видеосжатия, который сжимает кодированные мультимедийные данные. Транспортная область блока передачи содержит уровень протокола передачи в реальном времени (RTP), управляющий передачей мультимедийных данных, передаваемых от блока видеосжатия, уровень протокола пользовательских дейтаграмм (UDP) и уровень Интернет-протокола (IP) для передачи к блоку приема мультимедийных данных, передаваемых от уровня RTP, и блок управления скоростью передачи, связанный с уровнем RTP, определяющий коэффициент потерь пакетов из пакета сообщения приемника (RR) протокола RTCP, переданного от блока приема, измеряющий время задержки двустороннего распространения (RTT) с использованием пакета RR протокола RTCP, оценивающий скорость передачи с использованием коэффициента потерь пакетов и времени задержки двустороннего распространения и выдающий оцененную скорость передачи в видеокодер.
Транспортная область блока приема включает в себя уровень IP и уровень UDP, уровень RTP, управляющий передачей мультимедийных данных, передаваемых с уровня UDP, блок контроля качества обслуживания, контролирующий качество обслуживания (QoS) мультимедийных данных посредством информации, включенной в заголовок пакета протокола RTP уровня RTP, и блок сообщения канала для уведомления блока передачи об информации канала на основе контролируемого QoS. Блок сообщения канала передает информацию канала к блоку передачи посредством пакета RR протокола RTCP.
Пакет RR протокола RTCP включает в себя блок сообщения приема для подачи назад в блок передачи статистической информации о пакетах протокола RTCP, передаваемых от блока передачи. Блок сообщения приема также содержит коэффициент потерь пакетов и временную метку последнего сообщения отправителя (LSR). Временная метка LSR указывает время передачи последнего пакета сообщения отправителя (SR) протокола RTCP.
Уровень сжатия блока приема содержит видеодекодер, который декодирует мультимедийные данные, переданные с уровня RTP.
Пакет мультимедийных данных, переданный блоком передачи известной системы передачи мультимедийных данных, имеющей описанную структуру, может быть потерян в сети Интернет или может быть отклонен блоком приема ввиду избыточной временной задержки. Другие пакеты, поступающие в блок приема вовремя, передаются к видеодекодеру через уровни IP/UDP/RTP и затем декодируются.
Блок приема принимает пакет мультимедийных данных и затем вычисляет информацию о состоянии сети, такую как коэффициент потерь пакетов, задержку или т.п. посредством различной информации, существующей в RTP-заголовке пакета мультимедийных данных, тем самым контролируя качество обслуживания (QoS). Контролируемая информация подается назад в блок передачи посредством блока сообщения канала протокола RTCP. Блок передачи прогнозирует доступную ширину полосы текущего канала с использованием информации, которая была подана назад, и прогнозируемая доступная ширина полосы, в частности доступная скорость передачи, передается к видеокодеру. Видеокодер, имеющий прогнозируемую доступную скорость передачи, управляет выходной скоростью кодирования битового потока мультимедийных данных в соответствии с прогнозируемой скоростью передачи.
Настоящее изобретение предлагает новый способ оценивания скорости передачи, в котором скорость передачи оценивается посредством информации, включенной в пакет RR, когда блок передачи принимает пакет RR протокола RTCP от блока приема в системе передачи мультимедийных данных, в то же время способ не противоречит базовому принципу оценивания скорости передачи в соответствии с протоколом управления передачей (TCP).
В системе передачи мультимедийных данных, в которой может применяться настоящее изобретение, один пакет протокола RTCP передается каждый раз, когда передается предварительно заданное число пакетов мультимедийных данных с форматом пакета протокола RTP, и предварительно заданное число может составлять, например, 20.
Фиг.4 иллюстрирует адаптивный способ оценивания скорости передачи мультимедийных данных.
В системе передачи мультимедийных данных блок передачи передает мультимедийные данные в формате пакета протокола RTP к блоку приема (этап S11). В данном случае один пакет протокола RTCP передается каждый раз, когда передается предварительно заданное число пакетов протокола RTP, например 20. Таким образом, блок передачи передает к блоку приема по одному пакету SR протокола RTCP каждый раз, когда он передает 20 пакетов протокола RTP. Пакет SR протокола RTCP включает в себя информацию, относящуюся к времени передачи пакета SR, а именно значение временной метки протокола сетевого времени (NTP) в момент передачи пакета SR.
При приеме пакета SR протокола RTCP блок приема получает время передачи пакета SR на основе значения временной метки NTP для пакета SR протокола RTCP в поле LSR для генерации пакета RR протокола RTCP и передает генерированный пакет RR протокола RTCP блоку передачи (этап S13). Пакет RR протокола RTCP включает в себя коэффициент потерь пакетов.
Блок передачи, приняв пакет RR протокола RTCP, определяет коэффициент потерь пакетов из пакета RR протокола RTCP (этап S15) и оценивает допустимую скорость передачи (R(tn)) с помощью способа вычисления, который варьируется в соответствии с полученным коэффициентом потерь пакетов, как представлено в уравнении (2).
Figure 00000003
В частности, блок передачи оценивает допустимую скорость передачи (R1(tn)), когда полученный коэффициент потерь пакетов не превышает 5% (p(tn)≤0.05), блок передачи оценивает допустимую скорость передачи (R2(tn)), когда полученный коэффициент потерь пакетов больше 5%, но меньше 10% (0.05<p(tn)<0.1), и блок передачи оценивает допустимую скорость передачи (R3(tn)), когда полученный коэффициент потерь пакетов не меньше 10% (p(tn)≥0.1).
Иными словами, когда полученный коэффициент потерь пакетов не превышает 5% (p(tn)≤0.05), блок передачи оценивает допустимую скорость передачи (R1(tn)) с помощью традиционного способа оценивания с использованием уравнения (1). Когда полученный коэффициент потерь пакетов больше 5%, но меньше 10% (0.05<p(tn)<0.1), блок передачи делит полный размер данных, обычно поступающих в блок приема, соответствующий 20 пакетам протокола RTP, на время, требуемое для передачи 20 пакетов, тем самым оценивая допустимую скорость передачи (R2(tn)).
Время, требуемое для передачи 20 пакетов протокола RTP, вычисляется с использованием значения LSR, включенного в пакет RR протокола RTCP. Более конкретно, блок передачи вычитает значение LSR (LSR(tn-1)) ранее принятого пакета RR протокола RTCP из значения LSR (LSR(tn)) текущего принятого пакета RR протокола RTCP, тем самым получая время, требуемое для передачи 20 пакетов протокола RTP. А именно, блок передачи получает время передачи n-го переданного пакета SR (SR(tn)) посредством значения LSR (LSR(tn)) n-го переданного назад пакета RR (RR(tn)) и вычитает время передачи (n-1)-го пакета SR (SR(tn-1)) из времени передачи n-го пакета SR (SR(tn)), тем самым получая время, требуемое для передачи 20 пакетов протокола RTP (LSR(tn) - (LSR(tn-1)).
Таким образом, полный размер данных, нормально поступающих в блок приема, определяется следующим образом. Блок передачи проверяет число пакетов протокола RTP, обычно передаваемых между временем передачи (n-1)-го пакета SR (SR(tn-1)) и временем передачи n-го пакета SR (SR(tn)), и вычисляет размер нормально принимаемых данных с использованием проверенного числа нормально переданных пакетов протокола RTP. Число пакетов протокола RTP, нормально переданных в течение интервала между (n-1)-ым пакетом SR (SR(tn-1)) и n-ым пакетом SR (SR(tn)), равно s·20·(1-р(tn)). Здесь р(tn) обозначает коэффициент потерь пакетов, полученный из n-го пакета RR протокола RTCP, а s обозначает размер пакета.
α и β представляют собой весовые коэффициенты, заданные так, чтобы скорости передачи, оцененные посредством разных уравнений, имели непрерывные значения без существенных различий между ними, когда коэффициенты потерь пакетов равны 5% и 10%. α и β могут быть вычислены с использованием трех выражений в уравнении (3), когда коэффициент потерь пакетов для пакета RR протокола RTCP, переданного от блока приема, равен 5%, и когда коэффициент потерь пакетов для пакета RR протокола RTCP, переданного от блока приема, равен 10%.
Здесь, если время, требуемое для передачи данных, постоянно, то уравнение для оценки допустимой скорости передачи (R2(tn)) определяется как линейное выражение по отношению к коэффициенту р потерь пакетов.
Если коэффициент потерь пакетов, определенный на этапе S15 не меньше, чем 10% (p(tn)≥0.1), то блок передачи оценивает допустимую скорость передачи (R3(tn)) как минимальную скорость передачи, устанавливаемую пользователем.
На фиг.5 показаны скорости передачи, оцениваемые с использованием соответствующего изобретению способа вычислений, который варьируется в соответствии с коэффициентом потерь пакетов.
В частности, на фиг.5 показаны допустимые скорости передачи, оцениваемые в соответствии с увеличением коэффициента р потерь пакетов, когда s≡625, RTT≡100 мс и (LSR(tn)-(LSR(tn-1)≡ RTT/2·20. В данном случае α=44, β=395600.
Как показано на фиг.5, допустимая скорость передачи, оцениваемая в соответствии с уравнением (3), является той же, что и результирующее значение, получаемое с помощью уравнения (1) (результирующее значение, получаемое с помощью традиционного способа оценивания скорости передачи), когда коэффициент р потерь пакетов не превышает 5%. Когда коэффициент р потерь пакетов больше 5%, но меньше 10%, допустимая скорость передачи, оцениваемая в соответствии с уравнением (3), меньше, чем результирующее значение, получаемое с помощью уравнения (1), и когда коэффициент р потерь пакетов не меньше 10%, то допустимая скорость передачи представляет собой минимальную скорость передачи, устанавливаемую пользователем.
Таким образом, в способе оценивания скорости передачи, соответствующем изобретению, когда коэффициент потерь пакетов велик, допустимая скорость передачи оценивается как значение, меньшее, чем оцениваемое значение, получаемое с помощью традиционного способа оценивания скорости передачи.
Как описано выше, в настоящем изобретении определяется коэффициент потерь пакетов из пакета RR протокола RTCP, передаваемого от блока приема, и способ оценивания доступной скорости передачи выбирается адаптивным образом в соответствии с диапазоном, в который попадает полученный коэффициент потерь пакетов, так что доступная скорость передачи оценивается как имеющая меньшее значение, когда коэффициент потерь пакетов велик. Соответственно, состояние перегрузки сети может быть легко разрешено, и качество приема мультимедийных данных в условиях потерь пакетов может быть улучшено.
Так как настоящее изобретение может быть реализовано в различных формах без отклонения от его сущности, понятно, что вышеописанные варианты осуществления не ограничены какими-либо деталями, раскрытыми в приведенном описании, если только это не определено иным образом, а должно трактоваться в широком смысле в пределах сущности и объема, как определено формулой изобретения. Поэтому все изменения и модификации, находящиеся в рамках пунктов формулы изобретения или их эквивалентов, должны интерпретироваться как охватываемые формулой изобретения.

Claims (5)

1. Способ оценивания скорости передачи мультимедийных данных, содержащий прием пакета сообщения приемника протокола управления передачей в реальном времени (RTCP) от блока приема мультимедийных данных, определение коэффициента потерь пакетов из пакета сообщения приемника протокола RTCP и когда коэффициент потерь пакетов больше, чем первое значение, и меньше, чем второе значение, оценивают доступную скорость передачи посредством использования первого уравнения
Figure 00000004
,
где R(p(tn)) обозначает доступную скорость передачи;
s обозначает размер пакета;
p(tn) обозначает коэффициент потерь пакетов, получаемый из n-го пакета сообщения приемника (RR) протокола RTCP;
LSR(tn) обозначает время передачи n-го пакета сообщения отправителя (SR) протокола RTCP; и
α и β обозначают весовые коэффициенты.
2. Способ по п.1, в котором когда коэффициент потерь пакетов больше, чем второе значение и первое значение, оценивают доступную скорость передачи как минимальное значение, устанавливаемое пользователем.
3. Способ по п.1, в котором упомянутое первое значение составляет 5%.
4. Способ по п.2, в котором упомянутое второе значение составляет 10%.
5. Способ по п.1, в котором один пакет сообщения отправителя протокола RTCP передается и один пакет сообщения приемника протокола RTCP принимается каждый раз, когда передается 20 пакетов протокола RTP.
RU2005123415A 2004-07-23 2005-07-22 Адаптивный способ оценивания скорости передачи мультимедийных данных RU2305908C2 (ru)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2004-57737 2004-07-23
KR20040057737A KR100641159B1 (ko) 2004-07-23 2004-07-23 Rtcp패킷 기반의 적응적 멀티미디어 데이터 전송률추정방법

Publications (2)

Publication Number Publication Date
RU2005123415A RU2005123415A (ru) 2007-01-27
RU2305908C2 true RU2305908C2 (ru) 2007-09-10

Family

ID=36077276

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2005123415A RU2305908C2 (ru) 2004-07-23 2005-07-22 Адаптивный способ оценивания скорости передачи мультимедийных данных

Country Status (9)

Country Link
US (1) US7746780B2 (ru)
EP (1) EP1619840B1 (ru)
JP (1) JP4299275B2 (ru)
KR (1) KR100641159B1 (ru)
CN (1) CN1735075B (ru)
AT (1) ATE416539T1 (ru)
BR (1) BRPI0503015A (ru)
DE (1) DE602005011367D1 (ru)
RU (1) RU2305908C2 (ru)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2538947C1 (ru) * 2013-06-25 2015-01-10 Государственное казенное образовательное учреждение высшего профессионального образования Академия Федеральной службы охраны Российской Федерации (Академия ФСО России) Способ управления скоростью передачи видеопотока

Families Citing this family (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9138644B2 (en) 2002-12-10 2015-09-22 Sony Computer Entertainment America Llc System and method for accelerated machine switching
US8840475B2 (en) * 2002-12-10 2014-09-23 Ol2, Inc. Method for user session transitioning among streaming interactive video servers
US20090118019A1 (en) * 2002-12-10 2009-05-07 Onlive, Inc. System for streaming databases serving real-time applications used through streaming interactive video
US9314691B2 (en) 2002-12-10 2016-04-19 Sony Computer Entertainment America Llc System and method for compressing video frames or portions thereof based on feedback information from a client device
US8964830B2 (en) * 2002-12-10 2015-02-24 Ol2, Inc. System and method for multi-stream video compression using multiple encoding formats
US9108107B2 (en) * 2002-12-10 2015-08-18 Sony Computer Entertainment America Llc Hosting and broadcasting virtual events using streaming interactive video
US9077991B2 (en) 2002-12-10 2015-07-07 Sony Computer Entertainment America Llc System and method for utilizing forward error correction with video compression
US7660306B1 (en) 2006-01-12 2010-02-09 Chelsio Communications, Inc. Virtualizing the operation of intelligent network interface circuitry
US7660264B1 (en) 2005-12-19 2010-02-09 Chelsio Communications, Inc. Method for traffic schedulign in intelligent network interface circuitry
US7724658B1 (en) * 2005-08-31 2010-05-25 Chelsio Communications, Inc. Protocol offload transmit traffic management
GB2447469B (en) * 2007-03-14 2009-06-24 Motorola Inc Method and apparatus for handling interconnection transmissions
US8935406B1 (en) 2007-04-16 2015-01-13 Chelsio Communications, Inc. Network adaptor configured for connection establishment offload
US8060644B1 (en) 2007-05-11 2011-11-15 Chelsio Communications, Inc. Intelligent network adaptor with end-to-end flow control
US8589587B1 (en) 2007-05-11 2013-11-19 Chelsio Communications, Inc. Protocol offload in intelligent network adaptor, including application level signalling
US7821937B1 (en) * 2007-06-29 2010-10-26 Symantec Corporation Network protocol with damage loss resilient congestion control algorithm
KR101013630B1 (ko) * 2007-11-30 2011-02-10 주식회사 세아네트웍스 무선 통신 시스템에서 매크로 다이버시티와 멀티캐스트/브로드캐스트 서비스를 위한 서비스 제공 시스템 및 방법
CN101686383B (zh) * 2008-09-23 2013-05-01 Utc消防和保安美国有限公司 通过网络传输媒体的方法及系统
US8446452B2 (en) * 2008-11-07 2013-05-21 Magor Communications Corporation Video rate adaptation for congestion control
US8909261B1 (en) * 2008-12-16 2014-12-09 Sprint Communications Company L.P. Dynamic determination of file transmission chunk size for efficient media upload
US8009560B2 (en) * 2008-12-31 2011-08-30 Microsoft Corporation Detecting and managing congestion on a shared network link
JP5410601B2 (ja) 2009-06-12 2014-02-05 テレフオンアクチーボラゲット エル エム エリクソン(パブル) パケット交換網における遅延の監視
US8320364B2 (en) * 2009-12-15 2012-11-27 Hong Kong Applied Science And Technology Research Institute Co., Ltd. Control of bit-rate and packet duplication in a real-time media stream
JP5506362B2 (ja) * 2009-12-15 2014-05-28 キヤノン株式会社 送信装置、送信方法
JP5523130B2 (ja) * 2010-02-08 2014-06-18 キヤノン株式会社 通信装置、通信方法、及びプログラム
JP5565121B2 (ja) * 2010-06-09 2014-08-06 ソニー株式会社 通信処理装置、通信処理システム、通信処理方法及びプログラム
CN102752665B (zh) * 2012-06-28 2014-12-17 深圳市九洲电器有限公司 一种流媒体数据获取方法、装置及流媒体播放终端
GB2505956B (en) * 2012-09-18 2015-08-05 Canon Kk Method and apparatus for controlling the data rate of a data transmission between an emitter and a receiver
CN103944834B (zh) * 2013-01-22 2017-03-22 随锐科技股份有限公司 一种音视频转发控制方法及系统
EP3958512A1 (en) * 2013-07-31 2022-02-23 Assia Spe, Llc Method and apparatus for continuous access network monitoring and packet loss estimation
US9609040B2 (en) * 2014-02-21 2017-03-28 Dialogic Corporation Efficient bitrate adaptation in video communications over IP networks
US10097366B2 (en) * 2015-02-19 2018-10-09 Keysight Technologies Singapore (Holdings) Pte. Ltd. Methods, systems, and computer readable media for monitoring latency and/or time-based data locations of multicast communications
GB2535819B (en) 2015-07-31 2017-05-17 Imagination Tech Ltd Monitoring network conditions
US10454982B1 (en) 2016-03-18 2019-10-22 Audio Fusion Systems, Inc. Monitor mixing system that distributes real-time multichannel audio over a wireless digital network
US10397286B2 (en) * 2017-05-05 2019-08-27 At&T Intellectual Property I, L.P. Estimating network data streaming rate
US10382517B2 (en) 2017-06-09 2019-08-13 At&T Intellectual Property I, L.P. Estimating network data encoding rate
US10412463B2 (en) * 2017-07-07 2019-09-10 Verizon Patent And Licensing Inc. Resource based-video quality adjustment
KR102139379B1 (ko) * 2018-12-27 2020-07-29 울산과학기술원 서버와 무선단말 및 그 패킷 송수신 방법
US11303690B1 (en) 2021-03-08 2022-04-12 Tata Consultancy Services Limited Method and system for enhancing quality of experience (QOE) of video reception at receiver

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000269975A (ja) 1999-03-15 2000-09-29 Fuji Xerox Co Ltd データ転送装置
JP4180236B2 (ja) 1999-12-28 2008-11-12 株式会社エヌ・ティ・ティ・ドコモ ハンドオーバ制御方法及びシステム
JP2001320440A (ja) * 2000-05-02 2001-11-16 Sony Corp 通信装置及び方法
JP2002042789A (ja) 2000-07-21 2002-02-08 Matsushita Electric Ind Co Ltd 電池用電極の製造方法および製造装置
WO2002025878A1 (fr) 2000-09-22 2002-03-28 Matsushita Electric Industrial Co., Ltd. Procede de transmission/reception de donnees, dispositif de transmission, dispositif de reception, systeme de transmission/reception et programme
MXPA03003656A (es) 2000-10-26 2005-01-25 Wave7 Optics Inc Metodo y sistema para procesar paquetes corriente abajo de una red optica.
JP3699910B2 (ja) * 2000-10-31 2005-09-28 株式会社東芝 データ伝送装置、データ伝送方法及びプログラム
DE10108856C2 (de) * 2001-02-15 2003-04-24 Siemens Ag Verfahren und Anordnung zur Prüfung der Übertragungsqualität einer Sprachübertragung
JP3769468B2 (ja) 2001-03-21 2006-04-26 株式会社エヌ・ティ・ティ・ドコモ 通信品質制御方法、通信品質制御システム、パケット解析装置及びデータ送信端末装置
JP2003169090A (ja) * 2001-11-30 2003-06-13 Fujitsu Ltd 伝送システム
DE60216887T2 (de) * 2002-02-13 2007-04-05 Matsushita Electric Industrial Co., Ltd., Kadoma Verfahren zur dynamischen Übertragung von Datenpaketen unter Verwendung von RTP und RTCP Protokollen
US7099954B2 (en) 2002-06-27 2006-08-29 Microsoft Corporation Congestion control mechanism for streaming media
KR20040020639A (ko) 2002-08-31 2004-03-09 삼성전자주식회사 실시간 멀티미디어 데이터 생성율의 동적 제어방법 및 그장치
KR101054598B1 (ko) * 2002-10-29 2011-08-04 텔레폰악티에볼라겟엘엠에릭슨(펍) 무선 네트워크의 다중-사용자 서비스를 위한 리포팅

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SISALEM D. и др.: "The Loss-Delay Adjustment Algoritm: A TCP-friendly Adaptation Scheme", 08.07.1998, XP 002226884. *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2538947C1 (ru) * 2013-06-25 2015-01-10 Государственное казенное образовательное учреждение высшего профессионального образования Академия Федеральной службы охраны Российской Федерации (Академия ФСО России) Способ управления скоростью передачи видеопотока

Also Published As

Publication number Publication date
US20060018257A1 (en) 2006-01-26
KR20060008076A (ko) 2006-01-26
BRPI0503015A (pt) 2006-03-07
US7746780B2 (en) 2010-06-29
KR100641159B1 (ko) 2006-11-02
JP4299275B2 (ja) 2009-07-22
EP1619840B1 (en) 2008-12-03
RU2005123415A (ru) 2007-01-27
EP1619840A1 (en) 2006-01-25
CN1735075A (zh) 2006-02-15
JP2006042335A (ja) 2006-02-09
ATE416539T1 (de) 2008-12-15
DE602005011367D1 (de) 2009-01-15
CN1735075B (zh) 2012-09-05

Similar Documents

Publication Publication Date Title
RU2305908C2 (ru) Адаптивный способ оценивания скорости передачи мультимедийных данных
RU2304364C2 (ru) Устройство и способ для измерения времени задержки на двустороннее распространение для мультимедийных данных с переменной скоростью передачи битов
US10547661B2 (en) Transfer terminal and transfer method performed thereby
CN101909208B (zh) 一种适用于cdma2000的视频无线传输控制方法
EP1450514A1 (en) Server-based rate control in a multimedia streaming environment
EP1337061A1 (en) Method of dynamically transmitting data packets using RTP and RTCP protocols
CA2675965C (en) Dividing rtcp bandwidth between compound and non-compound rtcp packets
EA031556B1 (ru) Способ управления пропускной способностью для голосовой связи по интернет-протоколу (voip)
CN111669545A (zh) 一种改善视频传输延迟的方法及装置
US20070097987A1 (en) Feedback provision using general nack report blocks and loss rle report blocks
EP1687955B1 (en) Feedback provision using general nack report blocks and loss rle report blocks
KR102491033B1 (ko) 왕복 시간 추정
KR100931375B1 (ko) 개선된 파라미터 산출방법이 적용된 데이터 스트림 전송률 제어방법 및 데이터 스트리밍 서버
KR100698174B1 (ko) 네트워크 상에서 데이터의 유효 전송율 추정 방법 및데이터 전송 시스템
Lusilao-Zodi et al. RRB-SIMD: RTP rate-based SIMD protocol for media streaming applications over the Internet
Trad et al. TFMC: a TCP-Friendly Multiplexing Control Scheme for VoIP Flow Transmission
Singh Rate-control for conversational H. 264 video communication in heterogeneous networks
Papadimitriou An integrated smooth transmission control and temporal scaling scheme for MPEG-4 streaming video
Schulzrinne Transport protocols for multimedia
Afifi Adaptive Multiplexing Scheme for Voice Flow Transmission Across Best-Effort IP Networks

Legal Events

Date Code Title Description
MM4A The patent is invalid due to non-payment of fees

Effective date: 20180723