Введение Когда мы говорим о передаче видео по сети, мы в основном говорим о видеокодеках и разрешении.
Вообще-то о передаче видео мало что было слышно.
Здесь хотелось бы пролить свет на проблему борьбы с сетевыми потерями при передаче видео посредством видеоконференцсвязи.
Почему потери так важны? Да потому что нельзя просто так пропустить хотя бы один видеопакет (в отличие от аудио), потому что.
Любой приличный видеокодек основан на том, что последовательные кадры мало чем отличаются и достаточно закодировать и передать только разницу между кадрами.
Получается, что (почти) любой кадр зависит от предыдущих.
А картина разваливается, когда есть потери( хотя некоторым это даже нравится ).
Почему видеоконференция? Потому что там очень жесткое ограничение на реальное время, потому что задержка в 500мс на круг (туда и обратно) уже начинает раздражать пользователей.
Какие существуют методы борьбы с потерей видеопакетов? Здесь мы рассмотрим самый распространенный вариант — передачу мультимедиа по протоколу RTP поверх UDP. RTP и UDP Мультимедийные данные в реальном времени обычно передаются с использованием протокола RTP ( РФК 3550 ).
Здесь нам важно знать о нем три вещи:
- Пакеты пронумерованы по порядку.
Таким образом, любой пробел в порядковом номере означает потерю (хотя это также может означать задержку пакета — здесь разница может быть очень незначительной).
- Помимо пакетов RTP, стандарт предоставляет еще и служебные пакеты RTCP, с которыми можно делать что угодно (см.
ниже).
- Как правило, RTP реализуется поверх UDP. Это гарантирует, что каждая отдельная посылка будет доставлена как можно быстрее.
Немного подробнее о TCP написано ниже.
Столь многие методы восстановления единичных/несколько ошибок в сигнале (популярные, например, в DVB) здесь не работают. Борьбу с потерями мы рассмотрим в исторической перспективе (к счастью, технология ВКС достаточно молода и ни один метод еще не устарел полностью).
Пассивные методы
Разделение видеопотока на независимые части Первым успешным видеокодеком для онлайн-конференций стал H.263. В нем были хорошо разработаны основные пассивные методы борьбы с потерями.Самый простой из них — разбить видео на части, которые будут независимы друг от друга.
Таким образом, потеря пакета одного куска не влияет на декодирование остальных.
Вам нужно разбить его на части не только во времени, но и в пространстве.
Тайминг состоит из периодической (обычно каждые 2 с) генерации ключевого кадра.
Это кадр, который не зависит от всей предыдущей истории, а потому кодируется значительно (~5-10 раз) хуже обычного кадра.
Без генерации ключевых кадров, при любом количестве потерь, картинка рано или поздно развалится.
Рамку также можно разделить в пространстве.
Для этого H.263 использует блоки GOB, а H.264 — срезы.
По сути, это одно и то же — куски кадра, кодировка которых не зависит друг от друга.
Но для корректной работы необходимо также обеспечить независимость каждого среза от других срезов предыдущих кадров.
Получается, что параллельно кодируется несколько видеопоследовательностей, из которых на выходе геометрически собирается итоговое изображение.
Это, конечно, сильно портит качество кодирования (или увеличивает битрейт, что по сути одно и то же).
Зависимости между срезами двух последовательных изображений.
Оранжевым цветом обозначены области, которые можно было бы предсказать на основе предыдущего изображения, если бы не ограничения на фрагменты (что означает, что эти области можно было бы сжимать в 5–10 раз более эффективно).
Здесь важно отметить, что если генерация ключевых кадров — стандартная процедура (например, первый кадр всегда является ключевым), то обеспечение истинной независимости срезов — весьма нетривиальная задача, которая может потребовать переделки кодера (и никто знает, где вы взяли энкодер и насколько сложно его переделать).
Восстановление ошибок 
Пример восстановления одного потерянного фрагмента (пакета)
Если потеря уже произошла, можно попытаться максимально восстановить утерянные данные, используя имеющиеся данные (устойчивость к ошибкам).
Существует один стандартный метод, присущий кодеку H.263: потерянная ГБ восстанавливается посредством линейной интерполяции окружающих ГБ.
Но в общем случае картина более сложная и ошибка декодирования распространяется с каждым новым кадром (поскольку новые кадры могут содержать ссылки на поврежденные участки предыдущего кадра), поэтому придется использовать сложные механизмы для разумного прикрытия поврежденных участков.
.
В общем, работы здесь очень много, и через 2 секунды придет ключевой кадр и обновит все изображение, так что хорошие реализации этого метода, похоже, существуют только в воображении разработчиков.
Прямое исправление ошибок Еще один хороший метод борьбы с потерями — использовать избыточные данные, т.е.
отправлять больше, чем необходимо.
Но простое дублирование здесь выглядит не очень хорошо именно потому, что есть методы, которые лучше по всем параметрам.
Это называется FEC ( RFC 5109 ) и устроен следующим образом.
Выбирается группа медиа- (информационных) пакетов заданного размера (например, 5) и на их основе распознаются несколько (примерно одинаковых или меньше) FEC-пакетов.
Легко гарантировать, что пакет FEC восстанавливает любой пакет из информационной группы (коды четности, например РФК 6015 ).
Добиться этого несколько сложнее, но возможно.
Н Пакеты FEC восстановлены.
Н информационные по групповым потерям (например, коды Рида-Соломона, RFC 5510 ).
В целом метод эффективный, часто легко реализуемый, но очень дорогой с точки зрения канала связи.
Активные методы
Повторные запросы пакетов и ключевых кадров С развитием видеоконференций быстро стало ясно, что пассивные методы не принесут многого.Мы стали использовать активные методы, которые по своей сути очевидны — нужно повторно отправить потерянные пакеты.
Существует три разных запроса:
- Повторный запрос пакета (NACK – отрицательное подтверждение).
Потерял пакет - запросил еще раз - получил - раскодировал.
- Запрос ключевого кадра (FIR – полный внутрикадровый запрос).
Если декодер понимает, что все шло плохо и долго, можно сразу запросить ключевой кадр, который сотрет всю историю и можно будет начать декодирование с нуля.
- Запрос на обновление определенной области кадра.
Декодер может сообщить кодеру, что какой-то пакет потерян.
На основе этой информации кодер вычисляет, насколько ошибка распространилась по кадру, и тем или иным образом обновляет поврежденную область.
Как это реализовать, понятно только теоретически; Никакой практической реализации я не видел.
Но на практике есть RTCP-пакеты — значит, их можно использовать.
Существует как минимум три стандарта отправки таких запросов:
- РФК 2032 .
Фактически это стандарт упаковки потоков кодека H.261 в пакеты RTP. Но этот стандарт предусматривает и повторные запросы первых двух типов.
Этот стандарт устарел и заменен на RFC 4587 , что предполагает игнорировать такие пакеты.
- RFC 4585 .
Текущий стандарт. Предоставляет все три варианта и даже больше.
На практике используются NACK и FIR.
- RFC 5104 .
Также действующий стандарт. Частично дублирует RFC 4585 (но не совместим с ним) плюс куча другого функционала.
И не потому, что сложно сформировать запрос или повторно отправить пакет (хотя поддержка трёх стандартов одновременно несколько усложняет вопрос).
А потому, что здесь нужно контролировать происходящее, чтобы повторные запросы не были слишком ранними (когда «потерянный» пакет просто не успел прийти) или слишком запоздалыми (когда уже пора было бы выводить картинку на долгий срок).
давно).
Ну а в случае временных серьезных проблем в сети пассивные методы восстанавливают связь в течение 2 секунд (приход ключевого кадра), а наивная реализация повторных запросов может легко перегрузить сеть и никогда не восстановиться (это примерно то, как видео в скайпе зависло несколько лет назад).
Пример зависания видео после 3-х секундного отключения при наивной реализации повторных запросов.
Но эти методы, если их правильно реализовать, также гораздо более качественны.
Нет необходимости снижать качество путем генерации ключевых кадров, нарезки или освобождения места для пакетов FEC. В общем, вы можете добиться очень небольших накладных расходов на битрейт с теми же результатами, что и «дорогие» пассивные методы.
TCP Стало более-менее понятно, почему не используется протокол TCP. Это самый наивный метод повторного запроса пакетов без серьезного контроля над ним.
Кроме того, там предусмотрен только перезапрос пакетов, а перезапрос ключевых кадров в любом случае придется реализовать поверх.
Интеллектуальные методы
Мы пока коснулись только борьбы с потерями.А как насчет ширины канала? Да — ширина канала важна, и она в конечном итоге проявляется в тех же потерях (плюс увеличение времени доставки пакетов).
Если видеокодек настроен на битрейт, превышающий ширину канала связи, то бороться с потерями в этом случае — бессмысленное занятие.
В этом случае необходимо уменьшить битрейт кодека.
Вот здесь и начинаются все хитрости.
Как определить какой битрейт выставить? Основные идеи заключаются в следующем:
- Необходимо точно и оперативно отслеживать текущую ситуацию в сети.
Например, через RTCP XR ( RFC 3611 ) вы можете получить отчет о доставленных пакетах и их задержках.
- Если условия ухудшаются, сбросьте битрейт (что такое ухудшение условий? Как быстро сбросить?).
- Когда условия нормализуются, можно приступать к тестированию верхнего предела битрейта.
Чтобы картинка не разваливалась, можно, например, включить FEC и поднять битрейт. В случае возникновения проблем FEC сохранит правильность изображения.
У каждого серьезного производителя есть свое фирменное решение.
И именно развитие этой технологии является сегодня главным конкурентным преимуществом систем видеоконференцсвязи.
Кстати, стандартный 3ГПП ТС 26.114 (один из основных стандартов построения промышленных VoIP-сетей) утверждает, что содержит описание аналогичного алгоритма для аудио.
Не совсем понятно, насколько хорош описанный алгоритм, но для видео он не подходит. 
Конечный автомат алгоритма сетевой адаптации, изображенный художником (из 3GPP TS 26.114)
Теги: #voip #voip #rtp #стриминг видео #Разработка систем связи
-
Должен Ли Я Перенести Порт Ssh 22 Или Нет?
19 Oct, 24 -
Teamlab – Перезагрузка
19 Oct, 24 -
Ваш Компьютер Надежен?
19 Oct, 24 -
Поиск Подписчиков Google
19 Oct, 24 -
Редактор Недельного Расписания
19 Oct, 24 -
Квинтура Идет В Школу
19 Oct, 24
