Реализация пакета программ для улучшения качества

Реализация пакета программ для улучшения качества
видеоинформации средствами взаимодополняемых
источников.
А.А.Овсянников, аспирант мат-мех факультета СПбГУ
Актуальность проблемы.
В последние годы наблюдается стремительный рост развития мобильных
технологий. При этом следует учитывать, что при большом разнообразии
мобильных средств, растет и разобщённость аппаратных особенностей
каждого. В таких случаях появляется необходимость создавать огромное
количество форматов для видеоинформации, подходящих для определенных
моделей мобильных устройств. Такой подход не вполне удовлетворителен,
если учесть, что в некоторых случаях необходимо использовать
информацию, полученную об одном объекте или событии, но с большого
количества разнооснащенных источников. Но при этом стоит заметить, что
появляется возможность использования информации из таких источников
для ее качественного дополнения. Например, для повышения разрешения
видеоизображения на устройствах, не оснащенных необходимыми
аппаратными средствами. Либо дополнять видео геолокационными данными.
Помимо проблемы мультиформатности, существует так же проблема
передачи и хранения. Одним из основных способов передачи на сегодняшний
день является интернет, но его использование сопряжено с определенными
проблемами:
- Отсутствие связи.
Даже сегодня существуют области, в которых отсутствует связь по причине
удаленности от крупных населенных пунктов (так как рассматривается
только передача средствами мобильных или домашних сетей).
- Обрывы.
Некоторые мобильные сети имеют недостатки в защите от обрывов при
движении.
- Рост вероятности появления ошибок с увеличением объема передаваемых
данных.
Никак нельзя гарантировать 100% совпадение файла попавшего на источник
и файла полученного на приемник.
В связи с вышеизложенным, актуальна задача разработки комплекса
программ для оптимизации времени обработки, дополнения и использования
видеоинформации с учетом аппаратных средств устройства, а так же
создание общего формата.
Постановка задачи:
Целью является разработка системы для:
- успешного решения проблемы мультиформатности;
- создание единого формата хранения видеоинформации;
- улучшение качества видеоинформации
- минимизации ошибок при передаче.
Кроме того требуется разработать алгоритмы передачи больших объемов
данных средствами мобильных сетей, так как пропуская способность
некоторых видов связи (например EDGE ограничена).
За счет использования разнооснащенных мобильных устройств возможно
качественно улучшать видеоиноформацию.
Существующие системы обработки видеоинформации.
Статистика, основанная на исследовании Гатнера (Gartners) показывает, что
если в 2006 г. только 48% мобильных устройств было оснащено камерами, то
к 2010 г. их стало 86%[“ A Camera-based Mobile Data Channel: Capacity and
Analysis” Xu Liu, David Doermann, Huiping Li]. Такой рост может означать,
что в скором будущем многие технологии, основанные на использовании
специализированных устройств (камеры слежения, авторегистраторы и т.д.),
будут интегрированы на телефоны. Следует отметить, что использование
мобильных средств (устройств) в проблемах обработки и хранения
видеоинформации развита на сегодняшний момент в недостаточной степени.
Следовательно, для анализа можно рассматривать существующие системы
создания и обработки видеоинформации, такие как системы
видеонаблюдения.
VOCORD Phobos и VOCORD Tahion
В цифровых системах видеонаблюдения, в отличие от аналоговых, есть
возможность повлиять на качество изображения за счет применения методов
цифровой обработки изображения. Эти методы позволяют получать
изображение высокого качества при использовании не слишком хороших
камер или при неблагоприятных условиях съемки.
Специально для систем VOCORD Phobos и VOCORD Tahion разработан
аппаратно-программный комплекс, который решает задачи автоматической
регулировки параметров изображения.
АРУ «ЯК»
Одна из проблем, с которыми постоянно сталкиваются разработчики и
пользователи цифровых систем видео-наблюдения – ограниченный
динамический диапазон регистрируемого изображения. При этом для сцен с
широким динамическим диапазоном характерной чертой является потеря
деталей в затемненных или в ярких участках изображения. Не решают всех
проблем и встроенные в камеры стандартные средства автоматического
управления уровнем сигнала (АРУ).
Более того, наличие стандартных АРУ в камере может способствовать
развитию новых проблем, поскольку они только поддерживают среднее
значение сигнала, что при определенных условиях может ухудшить
изображение. Например, появление в поле зрения сильно освещенного
объекта приводит при использовании камер со стандартными АРУ к
ухудшению отображения плохо освещенных областей картинки. С этой
проблемой можно справляться при помощи настройки вручную, но это, вопервых, отвлечет оператора, что особенно скажется при работе с
многоканальными охранными системами, а также внесет определенный
субъективизм в настройку системы, а значит и в финальные показания.
Полученные результаты
На сегодняшний день разработана система Castarama. Это облачный сервис
(то есть хранение информации происходит не на самом устройстве, а на
сервере) позволяющий получать доступ к видеоинформации из любой точки
мира. Помимо этого была реализована возможность отправки видеосообщения между пользователями.
Видео дополняется данными о расположении за счет возможности получения
координат GPS модуля, встроенного в большинство мобильных устройств.
Так же реализована развлекательная часть. То есть существует возможность
записи музыкальных видео. Это стало возможно благодаря стриммингу
музыкального потока на клиентской части системы и склеивания на
серверной. На серверной стороне реализован следующий алгоритм: cервер
анализирует звуковую дорожку, разбивает ее на участки, на участках
анализирует локальные минимумы и максимумы АЧХ (Амплитудночастотная характеристика) и анализирует текст исходной песни. В итоге
получается смонтированный многопользовательский музыкальный видеоклип.
Таким образом, данный проект является начальным этапом, позволяющим
более близко ознакомится с работой над медиа-ресурсами и опробовать
некоторые алгоритмы передачи и хранения данных. Для реализации
функционала были разработаны алгоритмы успешно решающие проблемы:
- Отсутствие связи и обрывы
В такой ситуации происходит временное сохранение файла с дальнейшей
отправкой при появлении устойчивого канала связи.
Для реализации был использован Приемник широковещательных сообщений
(Broadcast receiver). Приемник широковещательных сообщений — это
компонент для получения внешних событий и реакции на них.
Инициализировать передачи могут другие приложения или службы. Класс
Broadcast Receiver является базовым для класса, в котором должны
происходить получение и обработка сообщений. Таким образом, каждые 15
минут проверялось состояние сети. При благоприятном изменении сети
создавалась сообщение системе, которое обрабатывалось BR и выполнялась
очередная попытка отправки файла.
- Рост вероятности появления ошибок с увеличением объема передаваемых
данных.
Для решения был реализован алгоритм порционной отправки файла.
Почему разбивается на части?
Если посылать данные непрерывно - любое искажение исходного файла или
разрыв соединения, потерянный или не вовремя пришедший пакет
потребует повторной полной отправки всего файла. В случае с фрагментами
- будет перезапрошено лишь несколько пакетов. Но при разбиении файла на
части увеличивается объем передаваемых данных - каждый пакет должен,
кроме полезной информации, содержать данные о самом файле и адреса
отправителя пакета, получателя пакета, контрольную сумму для проверки
целостности файла.
Так как рассматривается мобильная система, то сохранность файла может
быть нарушена. В такой ситуации применялся алгоритм, описанный выше
(BR).
Данный подход очень похож на решение при использовании вместо
мобильной системы ПК. Но, как говорилось ранее, Castarama является только
начальным этапом работы.
Рассматривая система была реализована (с клиентской стороны) посредством
стандартной связки Eclipse IDE и Android SDK с использованием сторонних
библиотек, нацеленных на создание и обработку по протоколу HTTP.
Обзор алгоритма
1. Отправка запроса на сервер.
На данном этапе клиент собирает данные, необходимые для
идентификации устройства: Mac-адрес, идентификационный номер
пользователя, геолокациооные данные, язык устройства и данные о
сессии. Сессия – это закодированная строка, необходимая для защиты и
для сохранения при неудачной отправке файла (благодаря сессии, даже
если отправка произошла гораздо позже запланированного времени,
сервер сможет восстановить необходимые для корректной работы
системы время создания видео-сообщения). Все это необходимо для
определения типа данных, которые необходимо отправить серверу
обратно. Существует три типа:
А) Обычная запись
Б) Запись музыкального видео
В) Видео-сообщение
2. Получение данных с сервера.
В зависимости от типа, сервер отсылает обратно: зарезервированный
номер в Базе Данных (регистрационный ключ); регистрационный ключ и
регистрационный номер музыкального файла (необходим для составления
ссылки для стримминга файла); регистрационный ключ, идентификационный
номер получателя соответственно. Все эти данные используются в имени
создаваемого файла. Это позволит избежать проблем распознования
сервером кусков файла при передаче (будет рассмотрено в шаге 6).
3. Настройка необходимых средств для записи и отправки.
Клиентской стороной производится настройка перед началом записи. В
зависимости от типа видео-сообщения происходит создание
необходимого файла-хранилища, настройка стримминга музыкального
файла и т.д.
4. Запись
Запись производится в зависимости от типа видео-сообщения
посредством камеры (камер) мобильного устройства.
5. Временное локальное сохранение
Так как вероятность описанных выше ошибок при передаче файла
является существенной проблемой, необходимо временно сохранить файл.
6. Отправка
Как говорилось ранее, файл подвергается разбиению на части и
происходит асинхронная (в независимых друг от друга потоках) отправка
на сервер. В случае неудачи (разрыв связи, нарушение целостности куска
файла) сервер присылает ответ, что произошла ошибка, с указанием кода
куска и кодом самой ошибки. В этом случае, создается задача для
Broadcast Receiver: создается сервис, который благодаря таймеру
повторяет попытки отправки. Так как на шаге 2 в имя файла были указаны
необходимые для идентификации данные, то исключаются потери. Но
возможно возникновение ситуации, когда ошибка сохранения происходит
на сервере. В этом случае, после нескольких неудачных попыток
отправки, сервер присылает определенный код ошибки,
сигнализирующий, что необходимо повторное получение данных,
описанных на шаге 2. Такая ситуация, конечно, малоприятна и требует
более тщательного анализа, но разработка более удовлетворительного
алгоритма еще только предстоит.