К чему приводит борьба за канал
Дата публикации: 08.12.2014

RTP-корректор. Выносим мусор из видеоизображения

Хоть мы и резко против потоковых кодеков, идем на поводу заказчиков, и новая версия с ними дружит. Но, чтобы заставить хорошо работать то, что по природе своей хорошо работать не может, приходится изощряться, придумывать, так сказать, новенькие технологии.

Началось наше падение в эту сторону с одного слезного заказа. В госкомпании стояла не наша сетевая видеосистема, принимавшая видео по RTSP, и, в общем-то, всё устраивало. Если бы не ее генеральский эффект: она отказывалась нормально работать при визите высокого начальства. Каждый раз, когда на объекте проходили маневры, и руководство садилось за монитор, чтобы их посмотреть, видеоизображение с камер как будто чувствовало тяжелый начальственный взгляд – и рассыпалось на части. Вот такая вот жалобная история.

Нас пригласили как специалистов помочь справиться с мистикой. Но всё оказалось закономерным. Так устроены протоколы потоковых кодеков, в частности H.264. Когда перед камерами мало экшена, они показывают хорошую картинку, когда начинается движуха по всему кадру – они затыкаются, потому что канал был просчитан исходя их спокойного состояния. Чем больше объем новизны в изображении, тем больше требуется ширина канала, Ето закон физики!

 Вот эту камеру сдавали при пустой стоянке и когда людей не было. Сдали, видимо, с премией, т.к. канал был вообще на уровне модема. Статическое изображение шло отлично, а вот любое появление движения превращает картинку в жанр кубизма.

А теперь что-то изменить физически нельзя, потому что каналы уже проложены, камеры уже поставлены и, о горе, они не поддерживают MJPEG. Мы, конечно, предложили поменять софт на наш, но куда деваться от закона физики? Поэтому нам пришлось разработать свой механизм работы с потоковыми кодеками, но не хочется даже называть это технологией, Спецлаб-RTP. Учитывая слезность и цену заказа, мы вложились, если не в изменение закона физики, то в его красивую обертку.  

Кассандра, кроме правильных кодеков, поддерживает и получение видео по RTSP, но при этом и может контролировать качество видеопотоков, внося свои правки, по большей части удаление мусора, который скапливается при прореживании кадров.

Кстати, фраза «контролировать RTP» – тоже, на первый слух и взгляд анормальна, этот протокол отличается от тех, где каждый сетевой пакет подтверждается пометкой о доставке и контрольной сумой, своей неконтролируемостью. Передатчик пуляет, как вздумается – приемник принимает, что поймает. На первый взгляд, нет никаких проблем: чего-то поймали и хорошо. Если бы не потоковый кодек. Он пуляет по большей части изменения по кадру, а не сами кадры. Вот и ловит такая система при проседании канала сплошные бракозябры.

Это только когда никого нет или активность минимальна, картинка выглядит четкой и быстроменяющейся. Если на объекте что-то случится и пойдет детекция по всему кадру, то вместо видеоизображения, вы можете видеть замыливание или переливающиеся квадратики то в одной, то в другой части кадра. А, если и по другим камерам пойдет активность, то все они начнут влиять друг на друга, деля единственный канал. В результате вы не увидите ничего. Тем не менее, большинство других разработчиков предлагает именно этот вариант работы. Мы не против и тоже поддерживаем потоковые кодеки, только предупреждаем о последствиях.

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

Все, что мы можем сделать на приемном конце, это отслеживать, что к нам пришло: ключевой кадр или его изменение. При этом надо еще и учесть, что в цепочке изменений пропущен или не пропущен какой-либо кадр. Такое можно произвести лишь по анализу самого изображения. Наши программисты фактически написали новый протокол SL-RTP, который имеет механизм видеодетекции.  Если между ключевыми кадрами обнаруживается брешь, мы выкидываем всю бесполезную последовательность кадров с изменениями. Именно они замусоривают изображение. При этом на экран пользователя поступают только качественные кадры.   

Некоторые разработчики камер сейчас скажут, что колесо изобретено давно, и подстраиваться к качеству канала протокол RTSP умеет, уменьшая свой битрейт – качество видео. И все бы ничего, если бы у вас была только одна камера.

Но вы не сможете нормально смотреть даже плохое качество. Когда таких потоков много в одном узком канальчике, все они начинают бороться за пространство. Сначала всем камерам хорошо (активности нет), они измеряют пропускную способность и дают максимум качества. Как только начинается движение, они регистрируют некоторое уменьшение канала за счет отбора ресурса другими камерами. Начинается снижение своего качества. Но т.к. камер много, то оценка пропускной способности всегда неверна, т.к. никто не знает, сколько съедят другие камеры. Снижение на небольшое значение качества естественно сразу выдает провал, т.к. реально канал падает сильнее. Тогда камеры пытаются как можно больше занизить качество. При этом сразу появляется дополнительный ресурс. На его величину все камеры повышают качество, что опять идет в завал канала. И так бесконечно.

И видеонаблюдение переходи в режим далекой скаковой лошади: то появляется плохое, но понятное изображение, то совсем никакое. Мы такую работу называем: то потухнет – то погаснет.

Например, у вас каждую секунду есть 50 яблок, десять человек увидели эти 50 яблок и запросили у вас, скажем по 25 яблок каждый, а они между собой не общаются, каждый думает, что он у вас один единственный. Но 250 у вас нет, вы отдали только 50 на всех, каждый получил по 2,5 яблока. Тогда в следующую секунду они запросили только по 2 яблока. Вы отдали 40 и показали, что 10 еще осталось. Тогда каждый запросил по 12 яблок. И опять не хватило. Запросы идут неодновременно, постоянно то появляется, то обрывается сеть. Изменение битрейта не поспевает за определением пропускной способности. Вы видите чехарду из растекающихся квадратиков. 

По сути это то, что мы наблюдали в аэропорте Домодедово, когда прогремел террористический взрыв. Установленная там система видеонаблюдения записала только квадратики. Откуда тогда видеозапись взрыва? – спросите вы. Напротив стоял банкомат с камерой, работающей на протоколе покадрового кодека MJPEG.     

По сути, мы не предлагаем какой-то полезной технологии, мы просто нивелируем проблемы, на которые постоянно натыкается пользователь с очень популярным протоколом RTP.

Однако это не значит, что он совсем вреден. Есть отдельные варианты построения систем видеонаблюдения, где такой протокол очень даже полезен. Но это обычно очень передовые и высокотехнологичные системы, практически не встречающиеся на рынке. Тем не менее, мы вам о них расскажем.

 

Разработано в СпецЛаб

Поднимаем видеотяжести на новый уровень
Второй канал HD-SDI с другим разрешением. То, что пока не могут камеры, делает новая версия GOALcity
И высокое качество получить, и канал не завалить
Алгоритм "Спецлаб - Большие потоки". Как запихать в узкий канал много широких потоков видео?