МЕНЮ
Технологии: Видео по IP/Internet
Производитель: VideoFlow

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

Отправка данных через Интернет часто приводит к потере пакетов, например, когда один из сетевых узлов на пути между передатчиком и приемником перегружен. Пакеты могут быть потеряны из-за проблем физического соединения, в результате которого биты переключаются с «1» на «0» (или наоборот). Однобитовая ошибка в пакете приведет к тому, что весь пакет будет отброшен первым получающим сетевым узлом.

Протокол управления передачей (TCP) решает проблему восстановления потери пакетов, используя механизм автоматического приема запроса (ARQ). ARQ требует, чтобы получатель отправил подтверждение отправителю для каждого полученного пакета. Если отправитель не получает подтверждение в течение заранее определенного времени, он будет повторно передавать пакет. Протоколы на основе подтверждения, такие как TCP, решают проблему потери пакетов, но за счет более низкой скорости передачи данных по сравнению с ненадежным протоколом данных (UDP) и, в частности, при в сетях, подверженных ошибкам, таких как Интернет, сотовая связь, радиорелейные сети и WiFi.

Поскольку качество видео напрямую зависит от скорости передачи видео, индустрия профессионального вещания использует UDP и особенно RTP (протокол реального времени) для доставки видео по пакетным сетям. Однако UDP / RTP не включает такой механизм, как ARQ для восстановления потерянных пакетов. Потеря пакета может быть однократным событием потери пакета или событием групповой потери пакетов. Поскольку каждый IP-пакет содержит до 7 MPEG-пакетов, влияние потери одного IP-пакета на качество видео является высоким. Поэтому используется несколько технологий восстановления пакетов, включая прямое исправление ошибок на основе XOR (FEC) и избыточные данные (коды Raptor). Эти технологии предназначены для восстановления потерянных пакетов путем отправки избыточной информации, которая может использоваться получателем для восстановления потерянных пакетов.

Использование технологии исправления ошибок важно, но какую технологию использовать?

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

  HiddenLimitationFEC01  HiddenLimitationFEC02

FEC Технологии

Три основные технологии FEC, используемые сейчас в индустрии вещания: Pro MPEG FEC (COP3R2), SMPTE 2022 и коды Digital Fountain’s Raptor. Pro MPEG FEC определяет наиболее эффективный XOR FEC для строк / столбцов для потоков IP-видео. SMPTE 2022 также использует FEC на основе XOR, как Pro MPEG FEC, но может использовать матрицы большего размера для лучшего восстановления потери пакетов. Коды Raptor Digital Fountain используются 3GPP для мобильной сотовой беспроводной широковещательной и многоадресной передачи, а также стандартами DVB-H для передачи данных IP на портативные устройства. Коды Raptor более эффективны, чем Pro MPEG FEC и FEC SMPTE на основе XOR, следовательно, требующий меньшего количества избыточных данных.

Скрытые ограничения FEC

Защита от дрожания пакетов и колебаний битрейта

Восстановление потери пакетов является обязательным, но дрожание пакетов, скорее всего, будет основной причиной для большинства пакетов, объявленных потерянными декодером просто потому, что они прибыли слишком поздно. Pro MPEG FEC, SMPTE 2022 и коды Raptor не могут защитить от потери пакетов, вызванной джиттером пакетов и / или колебаниями скорости передачи данных. Хороший пример эффекта дрожания пакетов - это пилотный проект, который у нас был в Европейской высшей баскетбольной лиге, где игра транслировалась через спутник Ka-диапазона. Спутник Ka-диапазона обеспечивает очень хорошую скорость передачи битов с потерями пакетов менее 0,1%, но измеренное дрожание пакетов достигло 1,6 секунды! Такое же явление наблюдалось в сотовых сетях и WiFi-каналах. В этих сценариях FEC не смог защитить качество видео. По этой причине в индустрии вещания принято добавлять 20% защитную полосу битрейта, чтобы попытаться поглотить джиттер пакетов и флуктуации битрейта. К сожалению, добавляя «грубую силу», дополнительная скорость передачи данных не может защитить от непредсказуемой мгновенной величины дрожания пакетов и колебаний скорости передачи данных в неуправляемых сетях.

Накладные расходы дороги

Коды Pro MPEG FEC, SMPTE 2022 и Raptor требуют постоянной отправки информации о восстановлении, даже если потеря пакетов вообще отсутствует. Это бесполезная трата пропускной способности канала, которая может быть использована либо для увеличения скорости передачи видео (следовательно, для повышения качества видео), либо для снижения стоимости при использовании канала передачи с более низкой скоростью передачи. Исходя из нашего опыта, матрица 25x4 Pro MPEG FEC может защитить от потери пакетов до 25 пакетов. Матрица 25x4 защищает 100 видео пакетов, но требует приема 129 пакетов, состоящих из 100 видео пакетов, 25 пакетов Row-FEC и 4 пакетов Column-FEC. Издержки полосы пропускания будут постоянно 29% независимо от того, есть ошибки или нет. SMPTE 2022 будет использовать 50 пакетов FEC для тех же 100 видео пакетов; накладные расходы 50%. Для кодов Raptor Digital Fountain потребуется всего 26 дополнительных пакетов для восстановления пакета из 25 потерянных пакетов; 26% накладных расходов. Вместе с защитным диапазоном 20% скорости передачи битов общая накладная скорость передачи достигает 50%! Затраты становятся проблемой при трансляции через дорогие соединения, которые могут быть чувствительными к погодным условиям, использованию и т. д. А что если есть технология, которая требует не более 5-10% накладных расходов?

Живое видео определяется низкой задержкой между отправителем и получателем

Как упоминалось ранее в этой статье, Pro MPEG FEC потребует добавления 29 пакетов для защиты потока в 100 пакетов в секунду. Способ отправки пакетов FEC требует получения как потоковых пакетов, так и пакетов FEC до завершения построения матрицы строк / столбцов FEC. Это означает, что получатель сможет начать восстановление потерянного пакета только после получения всех пакетов (в нашем примере 129 пакетов).

Ожидание прибытия пакетов для построения матрицы FEC увеличивает задержку на пути между отправителем и получателем. В каналах с низкой скоростью передачи эта дополнительная задержка может быть значительной и достигать 0,5–1 секунды в зависимости от скорости и качества линии. Задержка, добавляемая SMPTE2022, будет значительно выше, чем задержка, добавляемая Pro MPEG FEC, поскольку SMPTE2022 использует более крупные матрицы строк / столбцов FEC для лучшей защиты. Коды Raptor не отличаются в этом отношении дополнительной задержкой, аналогичной Pro MPEG FEC.

Основным недостатком FEC является уязвимость к потере пакетов

Статистика потерянных пакетов работает против способности матрицы FEC восстанавливать пакеты. Вероятность того, что матрица FEC не разрешится, возрастает выше 5% потерь пакетов. Причина заключается в перестановках потерянных пакетов, которые будут препятствовать разрешению матрицы FEC. Давайте возьмем в качестве примера статистику потери пакетов в Интернете. Хорошее Интернет-соединение имеет потерю пакетов 1% -2%. Тем не менее, будут случаи, когда потеря пакетов увеличится до 5% с пиковыми значениями 7-10% в трудные часы, например, перед тем, как люди уходят на работу, когда они выходят на обед, когда возвращаются домой, и вечером, когда общение с друзьями, загрузка новых фотографий в Instagram или просмотр видео на YouTube. Сети, такие как сотовая связь, Wi-Fi и спутниковая связь, также чувствительны к погодным условиям, использованию и географии среди других факторов, поэтому коэффициенты потери пакетов варьируются и могут достигать более 10%. Например, в пилотной программе VideoFlow с европейской высшей баскетбольной лигой произошел сильный гром над местом событий разразился шторм, вызвавший серьезную потерю пакетов на спутниковом канале связи.

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

Каждый пакет FEC строки может исправить один потерянный пакет подряд; FEC-пакет каждого столбца может исправить один потерянный пакет в столбце.

В простых примерах используется матрица FEC 4 x 4 строки / столбца. Матрица 4 x 4 FEC будет генерировать 8 пакетов FEC - 4 пакета для строк и 4 пакета для столбцов. Видеопакеты обозначены как «V», потерянные пакеты «L», восстановленные пакеты «R» и пакеты FEC «FEC».

Ниже приведен пример успешного восстановления пакета FEC.

HiddenLimitationFEC1

На рисунке 1 выше мы видим пример успешного восстановления пакета FEC.

На рисунке 1 выше показаны две матрицы. Матрица слева - это матрица FEC, упорядоченная приемником. Матрица справа - это матрица FEC после попытки восстановления пакета. Алгоритм начинается с сканирования строк в первую очередь. Если есть один потерянный пакет, то пакеты восстанавливаются. Если потерян более одного пакета, строка пропускается до завершения сканирования всех строк. После завершения сканирования строк алгоритм продолжает сканирование столбцов. Обратите внимание, что некоторые из потерянных пакетов были восстановлены при сканировании строк (R1 и R5), следовательно, возможно восстановить потерянные пакеты L13 и L14. Когда поиск по столбцам завершен, алгоритм продолжает сканирование строк. Теперь, когда пакеты L13, L14, L12 восстановлены (R13, R14, R12), сканирование строк может завершить восстановление потерянных пакетов L12 и L15. В этом примере для восстановления 7 потерянных пакетов потребовался алгоритм 7 итераций.

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

HiddenLimitationFEC2

Рисунок 2: Пример 2 - Статистика потери пакетов приводит к нерешенной матрице FEC

Потерянный пакет L11 не может быть восстановлен, поскольку были потеряны как пакеты FEC строки, так и столбцы FEC. Тот же коэффициент потери пакетов, другая статистика потерь и FEC не удалось восстановить все потерянные пакеты.

Один и тот же алгоритм строки / столбца используется только в этот раз, потерянный пакет L11 не может быть восстановлен, поскольку были потеряны как пакеты FEC строки, так и столбцы FEC. Тот же коэффициент потери пакетов, другая статистика потерь и FEC не удалось восстановить все потерянные пакеты.

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

HiddenLimitationFEC3


Рисунок 3: Пример 3 - Неразрешенная матрица FEC, несмотря на получение всех пакетов FEC.

Мы видим, что пакеты L10, L11, L14 и L15 были потеряны. Пакет отбрасывает пакеты в таком порядке, что ни пакеты FEC столбца, ни пакеты FEC строки не могут восстановить потерянные пакеты, поскольку в каждой строке и столбце имеется более одного потерянного пакета. В отличие от примера 2, который не имеет решения, большая матрица FEC могла бы разрешить ее в этом примере, но за счет более высоких накладных расходов.

Технология VideoFlow

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

Это все о джиттере

Хотя существует много сценариев, основной причиной раздражающего качества видео является дрожание пакетов, а не потеря пакетов. VideoFlow разработал технологию, которая фиксирует скорость потока в потоке либо с помощью информации PCR (наиболее точной), либо путем измерения скорости передачи пакетов (менее точной). Блокировка скорости потока позволяет воспроизводить видео пакеты без дрожания за счет задержки всего 0,5-1 сек. С точки зрения этого решения, декодер обнаруживает незначительное дрожание с задержкой. Задержка может быть установлена на уровне 20 мсек или 15 мсек, в зависимости от поведения сетей и / или требований приложений. Теперь, когда установлен буфер для устранения дрожания, решение VideoFlow использует тот же буфер для восстановления пакетов, отброшенных сетью без дополнительной задержки.

Используйте преимущества ARQ

Решение VideoFlow использует протокол ARQ. ARQ требует связи между получателем и отправителем, посредством которой получатель уведомляет отправителя о любом потерянном пакете. Получив запрос от получателя, отправитель повторно передает эти пакеты получателю. Преимущество ARQ перед FEC просто. Поскольку отправитель повторно отправляет только потерянные пакеты, издержки на скорость передачи пропорциональны потере пакетов в сети. Например, потеря 0,1% пакета добавит только 0,1% накладных расходов к потоку видеопакетов, в то время как потеря 7% пакетов добавит только 7% накладных расходов к потоку видеопакетов (сравните их с 50% накладных расходов при использовании Pro MPEG FEC). Поскольку повторно отправленные пакеты также могут быть отброшены сетью, фактические издержки могут быть немного выше. Это также означает, что могут существовать сетевые условия, при которых будет происходить более одного запроса на повторную отправку потерянного пакета. По этой причине технология VideoFlow отправляет запрос на потерянные пакеты таким образом, чтобы минимизировать количество повторных передач пакетов. Кроме того, на основе интегрированного анализа в реальном времени технология VideoFlow быстро идентифицирует получение пакета восстановления от отправителя и быстро прекращает отправку запросов отправителю, чтобы избежать дополнительных повторных передач. В некоторых случаях, когда условия сети плохие, может быть оказаться целесообразным отказаться от запросов в пользу общего улучшения качества видео, высвободив скорость передачи битов для видеопотока за счет потока восстановления пакетов за счет локального сбоя с качеством видео.

Потеря пакета может быть объявлена приемником либо потому, что он был отброшен сетью, либо потому, что он опоздал. Нормальное поведение неуправляемых сетей включает в себя сочетание дрожания пакетов, колебаний скорости передачи данных и потери пакетов. Поэтому технология VideoFlow включает механизм, который добавляет льготное время для времени прибытия пакета в приемник. Этот механизм уменьшает количество запросов пакетов к отправителю из-за дрожания, поскольку он позволяет некоторым поздним пакетам прибыть до того, как приемник VideoFlow объявит их потерянными. На передающей стороне передатчик VideoFlow назначает приоритеты отправляемым пакетам восстановления так, чтобы пакеты с более старыми временными метками были ускорены, чтобы гарантировать, что они будут приняты декодером до истечения времени представления.

Заключение

Коды Pro MPEG FEC, SMPTE 2022 и Raptor могут обеспечить разумную защиту от потери пакетов. К сожалению, накладные расходы, требуемые для достижения этой защиты, являются постоянными и довольно высокими в диапазоне от 26% до 70% скорости передачи видео. SMPTE 2022 и Pro MPEG FEC, в частности, начнут испытывать проблемы при восстановлении пакетов с потерей пакетов выше 5%, так как пакеты FEC или видеопакеты могут быть отброшены способом, запрещающим разрешение матрицы FEC, необходимой для восстановления потерянных пакетов. Ни одна из технологий исправления ошибок не может компенсировать дрожание, поэтому во многих сетях FEC просто не защищает качество видео. Эмпирическое правило о добавлении 20% накладных расходов на скорость передачи данных для обработки дрожания или колебаний скорости передачи данных ставится под сомнение при доставке видео по неуправляемым сетям.

Технология VideoFlow лучше подходит для защиты качества живого видео в неуправляемых сетях. Он может привязываться к скорости передачи видео и точно воспроизводить ее, что устраняет дрожание с помощью небольшого буфера (низкая задержка). Функция восстановления пакетов использует этот буфер для восстановления потерянных пакетов с использованием ARQ, добавляя очень небольшие издержки без дополнительной задержки. Эта технология обеспечивает полную и надежную защиту видео в реальном времени с минимальными накладными расходами, требуемыми FEC.

Adi Rozenberg, CTO, VideoFlow

Онлайн заявка

Отправьте нам заявку или просто позвоните: +7 (495) 012-54-60

Введите имя

Введите номер телефона

Введите E-mail

Invalid Input

Нажмите кнопку "Отправить запрос", вы подтверждаете согласие с нашей Политикой конфиденциальности

URL страницы
Invalid Input