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

• нет необходимости в отдельном регистраторе или плате захвата;
• помехоустойчивость;
• простая интеграция в существующую сеть;
• нет ограничения по расстоянию;
• наличие камер высокого разрешения;
• просмотр камеры прямо с самой камеры по http;
• наличие всевозможных настроек;
• и др.

Нас интересует способ получения изображений с таких камер, для этого надо знать а как вообще они их передают? На наше счастье камеры используют существующие стандарты, а не то, что взбредёт в голову китайскому разработчику. Подавляющее большинство камер используют один или несколько способов передачи видео, это в основном Motion JPEG по HTTP, Motion JPEG по RTSP или H264 по RTSP. Также многие камеры могут передавать звук, но он нас не интересует сейчас.

В этой статье я рассмотрю эти способы передачи изображений с сетевых камер, а также приведу пример захвата таких изображений всё на том же Python'е.

В первой своей статье «измерение расстояния до объекта и его скорости» я рассмотрел захват изображений с веб-камер через Video4Linux2 и через DirectX. В следующей статье «захват видео с сетевых камер, часть 1» я рассмотрел как работать с сетевыми Motion-JPEG камерами. Сейчас я поведаю Вам о захвате изображений с сетевых RTSP камер, в частности поток Motion-JPEG по RTSP.

Задача эта более сложная нежели Motion-JPEG по HTTP, так как необходимо больше действий, больше подключений, но взамен мы получаем большую гибкость, скорость, функциональность и даже некую универсальность. Честно говоря, RTSP для простых задач избыточен, но я не сомневаюсь, что найдутся ситуации, где он будет необходим.

Наконец, продвижение вперёд. Всё, теперь домашние не посмеют назвать робота Митю «радиоуправляемой машинкой»!

Оказалось непросто найти относительно лёгкий и работающий способ передачи видео и аудио потоков от Android-гаджета к удалённому управляющему приложению на ПК. Без этого шага я категорически не хотел двигаться дальше, поэтому довольно надолго завяз в своём упрямстве.

Предисловие

Не так давно, возникла необходимость захвата видео с web камеры и передавать его по сети используя .Net.
Так как с подобной задачей я столкнулся впервые, то первым делом начал искать информацию по этому вопросу.
Как выяснилось, что в чистом .Net нет поддержки работы с web камерами. Перебрав несколько различных библиотек, свой выбор остановил на Aforge.net.

Aforge.net — это фреймворк для решения целого ряда задач, из которого нам понадобится библиотеки AForge.Video.

Захват изображения

Для захвата видео с устройства видео ввода существует класс AForge.Video.DirectShow.VideoCaptureDevice. Ему необходимо задать моникер устройства с которого будет происходить захват. Так же необходимо задать обработчик события NewFrame. Это событие возникает каждый раз, когда с устройства будет получен новый кадр, который и передается в обработчик в виде объекта Bitmap, где его уже можно обработать:

private void VideoSourceNewFrame(object sender, AForge.Video.NewFrameEventArgs eventArgs)
{
    var img = (Image) eventArgs.Frame;
    using (var ms=new MemoryStream())
    {
        img.Save(ms,ImageFormat.Jpeg);
       //Сохраняем изображение в массив байт, для последующего формирования mjpeg
        _bufImage = ms.ToArray();
    }
}

Материал статьи отражает личный опыт автора и не претендует на научную точность. Буду рад любым исправлениям и дополнениям. Для тех, кто не хочет читать дальше, правильный ответ на главный вопрос: MJPEG.

Вступление

Клиенты часто предпочитают архаичные способы передачи проектных материалов и случаи, когда 5-минутный фильм присылают вложением по почте, сжатым до 20 МБ, не являются редкостью. Материал для ознакомления становится материалом для работы, что влечёт за собой ряд неочевидных проблем, основные из которых — низкая детализация картинки (вызванная чрезмерным сжатием) и использование видео кодеков, которые не предназначены для аудиомонтажа.

Низкая детализация, пикселизация и общая размытость картинки затрудняют работу звукорежиссёра на самом начальном этапе, когда происходит оценка сюжета и визуальных элементов фильма, которые могут быть озвучены. Отсюда возникает такая проблема, как эстетическое несоответствие, когда, например, пластиковый (по замыслу) объект озвучивается как металлический или стеклянный.

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

В этой статье я расскажу о том, как можно захватывать аналоговый черно-белый видеосигнал с помощью платы STM32F4-DISCOVERY, и об особенностях передачи его на компьютер при помощи USB.

Не секрет, что при управлении летательными аппаратами часто используется передача видео с самого аппарата на землю. Обычно такую возможность предоставляют производители самих БПЛА. Однако что же делать, если дрон собран своими руками?

Перед нами и нашими швейцарскими партнёрами из компании Helvetis встала задача транслировать видео в режиме реального времени с web-камеры с маломощного embedded-устройства на дроне по WiFi на Windows-планшет. В идеале бы нам хотелось:

• задержку < 0.3с;
• низкую загрузку CPU на embedded-системе (меньше 10% на одно ядро);
• разрешение хотя бы 480p (лучше 720p).

Казалось бы, что может пойти не так?

Logitech C920 — одна из веб-камер, которые начинают глючить после установки обновления Windows 10 Anniversary Update

На форуме техподдержки Windows многочисленные пользователи сообщают о проблемах с веб-камерой после установки последнего обновления Anniversary Update (Windows 10 version 1607, OS Build 14393.10 'anniversary). После установки апдейта веб-камеры больше не могут передавать видео, закодированное в MJPEG или H.264, а работают только в режиме передачи несжатого видео YUV.

Начинают глючить Skype в режиме HD-видео, Open Broadcaster Software (OBS), различный софт для видеонаблюдения (CCTV) и др. Проблема подтверждена для множества моделей USB веб-камер, в том числе для очень популярных Logitech C920 и C930e.

Возникла у меня необходимость выводить дашборд с мониторингом на несколько экранов в офисе. В распоряжении имеется несколько стареньких Raspberry Pi Model B+ и гипервизор с практически неограниченным количеством ресурсов.

По видимому Raspberry Pi Model B+ не обладает достаточной произвольностью чтобы держать постоянно запущенным браузер и отрисовывать большое количество графики в нем, из-за чего бывает, что страница частично глючит и часто вылетает.

Нашлось достаточно простое и элегантное решение, которым я и хочу с вами поделиться.