Dual stream что это
Двойной поток (Dual Stream) H.264/Mjpeg: что это?
Камеры видеонаблюдения, используемые в настоящее время, способны передавать изображение в мегапиксельном разрешении. Аналоговые системы значительно повысили качество «картинки» по сравнению с моделями прошлых лет. Лидером тем не менее остаются сетевые решения – IP-камеры. Технология двойного потока (Dual Stream) H.264/Mjpeg позволяет снизить нагрузку на сеть при передаче данных, обеспечить приемлемое качество просмотра видео в реальном времени, создать максимально подробный архив.
Применение технологии подразумевает искусственное ухудшение качества за счет сжатия видеоряда в формате, уменьшающем его размер до минимума. Второй поток при этом остается в прежнем качестве (мегапиксельном – в случае с IP-системой) и при необходимости записывается отдельно.
Преимущества двойного потока:
Сокращается нагрузка на сеть, уменьшается размер исходящего трафика;
Удастся удаленно просматривать видео в реальном времени – например, с мобильного телефона;
Оператор видеонаблюдения будет просматривать на мониторе «картинку» в качестве, достаточном для определения определенных ситуаций – проникновения, пожара, конфликта между сотрудником и клиентом и т.д.;
Запись данных даже с нескольких камер (на крупных объектах их может быть не один десяток) получится сохранить с экономией свободного места на жестком диске или удаленном облачном хранилище;
Удастся установить большое число устройств слежения с функцией одновременного вывода изображения с них на экран/монитор.
Использование одновременно двух форматов (H.264/Mjpeg) помогает избежать проблем с масштабированием системы, передачей данных по локальной сети или интернету.
Где используется
Приведем несколько вариантов объектов, где используется Dual Stream:
Крупный автовокзал, жд-вокзал;
Крупный Производственный комплекс;
Иной объект с большим числом камер либо при постановке задачи передачи информации на удаленное устройство без задержек и искажений.
Таким образом, если у вас смонтированы 1-2 цифровые видеокамеры и данные просто записываются на видеосервер, потребность в разделении потока отсутствует. Это же касается случаев, когда происходит одновременный вывод изображения на экран монитора или телевизора: оператор будет видеть все в хорошем качестве, его искусственное снижение не производится. Если же вам требуется расширить систему, настроить удаленный доступ к камере по интернету, отсутствие поддержки Dual Stream H.264/Mjpeg приводит к следующим эффектам:
Задержки при отображении видео. Происходит «подтормаживание», когда текущий кадр не соответствует реальному положению дел;
Проблемам с работой принимающего устройства;
Нарушению функционирования компьютерной сети на объекте – она имеет граничный показатель данных, передаваемых в единицу времени. Когда в сеть помимо устройств наблюдения подключена иная действующая аппаратура, начинаются сбои, мешающие работе.
Производитель указывает в ключевых характеристиках камер возможность поддержки технологии «Двойной поток». Необходимость в ней следует учесть еще на этапе проектирования системы с учетом общего числа элементов, разрешения устройств и потребностей пользователя.
Пример работы
Рассмотрим пример работы оборудования с технологией Dual Stream:
Камера фиксирует происходящее в поле зрения;
Происходит передача информации на сервер;
Подключенный к нему монитор получает поток в высоком качестве;
В случае наличия соответствующих настроек, выделяется поток меньшего разрешения с доступом к нему с телефона или планшета заказчика;
Данные «запоминаются» жестким диском в изначальном разрешении для последующего детального просмотра.
С увеличением разрешения IP-камер и их распространением на крупных объектах, потребность в делении потоков стала фактом, с которым приходится считаться как владельцу оборудования, так и производителю.
Система видеонаблюдения. Два потока
Двухпоточность позволяет поддерживать для каждой подключенной аналоговой или IP-камеры два видеопотока с различным разрешением. Основной видеопоток при этом передается в качестве, установленном пользователем, а второстепенный − в наименьшем качестве.
Основным преимуществом для пользователя является снижение нагрузки на центральный процессор сервера системы видеонаблюдения «Линия». Пользователи получают возможность увеличить количество камер на одном уже установленном на объекте сервере. Дополнительная модернизация самого видеосервера при этом не требуется. Таким образом, клиент получает экономию ресурсов при расширении системы видеонаблюдения «Линия» или построении новой.
Еще одно преимущество заключается в совместимости со всеми камерами, интегрированными с системой видеонаблюдения «Линия». Ряд моделей IP-камер передает второстепенный поток для отображения на общей сетке видов самостоятельно. Если IP-камера не поддерживает второй поток, а также в случае использования аналоговых камер, система видеонаблюдения «Линия» сама перекодирует основной поток в видеопоток с минимальным разрешением.
Ранее для системы видеонаблюдения, включающей в себя 16 IP-камер с разрешением 2Mpx, необходим был сервер на базе Intel Core i7-4930K* процессора и удаленное рабочее место с процессором Intel Core i7-3770*. При этом данная конфигурация обеспечивала работу камер со скоростью изображения 12 кадров в секунду.
Задействовав двухпоточность, пользователю будет достаточно компьютера с процессором Intel Core i3-3240*. При этом скорость передачи изображения повышается до 25 кадров в секунду.
При этом запись в архив ведется в максимальном качестве.
Поток в видеонаблюдении: основной и дополнительный, что это?
Концепция многопоточности была впервые разработана Hikvision и использовалась в цифровых видеорегистраторах для уменьшения нагрузки при удаленном просмотре видеонаблюдения. Сегодня, эта технология используется в видеорегистраторах, видеосерверах, Ip камерах у всех известных производителей. Данную технологию так же называют двухпоточной: основной поток служит для передачи видео с максимальным качеством, а дополнительный поток (субпоток) имеет заведомо более низкое разрешение, иногда и количество кадров.
Зачем это нужно? Чтобы ответить на этот вопрос разберем основной и дополнительный (субпоток) более подробно.
Основной поток в видеонаблюдении, что это?
Его иногда называют Main (главный). Обычно в качестве основного потока используется максимальное разрешение видеокамеры. Именно в таком виде оно записывается на жесткий диск видеорегистратора, компьютера или карту памяти. Основной видеопоток обеспечивает потоковое видео в реальном времени: 24, 30 или 60 кадров/секунду. Для удешевления стоимости камер видеонаблюдения иногда производитель ставит на них более слабый процессор, в итоге видеокамера не способна выдавать 24 к/с при максимальном разрешении. В таких камерах можно увеличить количество кадров уменьшив разрешение. Эти настройки можно в любое время изменить выставив нужные нам значения. Меньшее количество кадров отлично подойдет для камеры видеонаблюдения, которой не нужно снимать динамичные сцены и архив записи с такой камеры будет занимать существенно меньше места на жестом диске. Основной поток с камеры мы можем наблюдать, когда на регистраторе разворачиваем картинку с камеры на весь экран.
Тройной поток.
Помимо двухпоточной технологии существуют IP-камеры, поддерживающие работу с тройным и более потоков. Тройной видеопоток означает, что IP-камера видеонаблюдения может одновременно выводить три разных видеопотока, каждый из которых может быть настроен на разное разрешение, частоту кадров, битрейт и кодек сжатия. Что нам это дает? Все очень просто, тройной поток предоставляет пользователю большую гибкость, позволяя одновременно транслировать разные видеопотоки данных, каждый из которых конкретно для своей цели.
Применение тройного потока в видеонаблюдении.
— Основной. Максимальное качество. Служит для записи в архив
— Дополнительный. Среднее качество. Служит для отображения видео в многокамерном режиме на рабочем месте оператора, также его можно использовать для детекции движения и для просмотра камер в локальной сети предприятия.
— Третий. Настраивается на ваш выбор, например: максимальное качество и низкое значение fps (4-5 к/с) или низкое качество в реальном времени.
Автор: Дмитрий Самохвалов, технический редактор компании Rucam-Video.
Какой бывает HTML5-стриминг (и почему mp4-стриминга не существует)
Нередко клиенты спрашивают, умеет ли наш сервер «mp4-стриминг в HTML5». В 99% случаев спрашивающий не понимает о чём говорит. В этом сложно винить клиентов: из-за путаницы с терминами, технической сложности и большого разнообразия вариантов стриминга запутаться очень легко.
В этой статье мы расскажем, какой бывает HTML5-стриминг, какие варианты хорошие, и почему, чёрт побери, нельзя говорить «mp4-стриминг».
▍Термины
HTML5-видео — это когда вы вставляете в веб-страницу тег и указываете ему какой-то src. HTML5-стриминг — это то же HTML5-видео, но когда в src не готовый файл, а постоянно обновляющийся видеопоток. Ролик на Ютубе — это HTML5-видео, трансляция в Твитче — HTML5-стриминг.
Тегу неважно, как видеопоток формируется и передаётся, и сможет ли браузер его проиграть. Главное, чтобы в src была ссылка на какой-то видеопоток. Говоря техническим языком, спецификация ничего не говорит о том, какие протоколы, транспорты и кодеки поддерживаются в HTML5-видео.
Протокол — это то, как два участника видеосвязи (почти всегда это клиент и сервер) обмениваются данными с целью получения данных. Клиентом называют того, кто приходит к серверу и инициирует сессию связи. Видеопоток может течь от сервера к клиенту (тогда это обычное проигрывание) или от клиента к серверу (тогда это публикация). Даже когда гигантский шкаф, жрущий электричество как многоквартирный дом приходит к маленькой IP-камере, то она будет сервером, а этот шкаф клиентом.
Протокол обычно подразумевает хотя бы команду Play (начать проигрывание), но иногда есть и расширенные варианты: пауза, продолжение, публикация, перемотка и т. п.
Примеры протоколов: RTSP, RTMP, HTTP, HLS, IGMP.
Транспорт, или транспортный контейнер, или контейнер — это то, как сжатое видео упаковывается в байты для передачи от одного участника к другому (по какому-то протоколу).
Примеры контейнеров: MPEG-TS, RTMP, RTP.
| Обратите внимание, что RTMP оказался и в протоколах, и в транспортах. Это потому, что в описании RTMP есть спецификация и того, что должны слать друг другу стороны, чтобы видео потекло (т. е. протокол), и того, как упаковывать видео (т. е. транспорт). Так бывает не всегда. Например в протоколе RTSP видео упаковывается в транспорт RTP. |
Кодек — многозначный термин. Здесь он означает способ сжать сырое видео. Разница между кодеком и транспортом в том, что кодек — это про подготовку видео, а транспорт — про передачу видео по протоколу. Видео, сжатое одним кодеком, можно пересылать по разными протоколам и разными транспортами. Большинство видеостриминговых серверов не залезают глубже кодированного видео и оперируют только протоколами и транспортами.
Примеры кодеков: h264, aac, mp3.
| Из-за того, что термин многозначный, возникает путаница с названиями. Например, H.264 — это стандарт того, как упаковать поток огромных сырых видеокадров в очень мало байтов, libx264 — это библиотека для сжатия по этому стандарту, а ещё есть одноимённый софт под Винду, который умеет декодировать h264 и проигрывать его на экране. |
Итак, в спецификации HTML5 не описаны протоколы, транспорты и кодеки. Поэтому авторы браузеров сами выбирают, что поддерживать, а под «HTML5-стримингом» подразумевают разные вещи.
При этом есть комбинации, которые поддерживаются значительной частью браузеров. Рассмотрим самые перспективные.
HLS — это h264-видео и aac- или mp3-аудио, упакованное в транспорт MPEG-TS. Поток разбивается на сегменты, описанные в m3u8-плейлистах, и раздается по HTTP. HLS поддерживает мультибитрейтные потоки, Live/VOD. Вариант очень простой, но в то же время имеет много деталей, из-за чего на разных устройствах работает по-разному.
Разработали HLS в Эппле, поэтому изначально он работал только в Сафари на iOS и MacOS. Даже Сафари на Windows не умел играть HLS (когда еще была версия под Win).
Тем не менее, сейчас HLS умеют проигрывать все телевизионные приставки и даже почти все устройства на Андроиде.
Но не всё гладко. Производители сторонних плееров плюнули на стандарт Эппла в части донесения разных аудиодорожек и добавили проигрывание всего что есть в обычном MPEG-TS: mpeg2 video, mpeg2 audio и т. п. Из-за этого приходится отдавать разные форматы плейлистов для разных плееров.
▍MPEG-DASH
MPEG-DASH — обычно это h264/h265-видео и aac-аудио, упакованное в транспорт mp4, или vp8/vp9, упакованное в WebM, хотя стандарт и не привязан к конкретным кодекам, протоколам и транспортам. Как и в HLS, поток может разбиваться на сегменты, но это необязательно. Вместо плейлистов — MPD-манифест в XML.
MPEG-DASH во многом похож на HLS. Возможно, он даже популярнее, ведь такие гиганты как Ютуб и Нетфликс уже несколько лет используют его как основной способ раздачи контента.
MPEG-DASH хорош тем, что в большинстве браузеров работает нативно, через MSE (о том, что это такое, — чуть ниже). Для него даже нет реализации на Флеше — это честный, бескомпромиссный HTML5.
Определенно, MPEG-DASH — самый настоящий HTML5-стриминг, за ним будущее.
Когда стало ясно, что Флеш всё-таки умрёт (после сотни ложных похорон), ребром встал вопрос о том, что придёт ему на смену. Хорошо было бы получить в браузерах возможность проигрывать видео по качеству и удобству близко к тому, что умеет Флеш (а он это делает всё-таки хорошо).
Во Флеше давно появился очень удобный механизм для универсального проигрывания разных вариантов — appendBytes. Суть в том, что пользовательский код сам как хочет скачивает кадры сжатого видео, упаковывает в оговоренный контейнер (с Флешем это flv) и засовывает в видеопроигрыватель. Т. е. протокол и транспорт реализуются в пользовательском коде, запускаемом в браузере.
MSE (Media Sources Extensions) — это расширение спецификации HTML5, которое позволяет делать то же, что делает appendBytes во Флеше. К сожалению, MSE намного сложнее как в понимании, так и в реализации.
MPEG-DASH, созданный на его базе, ещё хитрее, поэтому работать с ними то ещё удовольствие: тонны XML, парсинг бинарных контейнеров в Яваскрипте, непродуманные на этапе дизайна вопросы нарезки на сегменты — всё как мы любим, всё что нужно для единой безглючной реализации во всех браузерах.
Интересно, что MSE работает не только с MPEG-DASH, но и с HLS. Существует реализация hls.js, которая скачивает HLS-плейлисты, скачивает MPEG-TS-сегменты, перепаковывает их в нужный для MSE формат и играет через MSE. Эппл даже сделала шаг в сторону совместимости с MPEG-DASH — использование mp4-контейнеров в HLS.
К концу 2017 года Флеш скорее всего умрёт окончательно, и уже сегодня можно смело начинать проект с MPEG-DASH.
▍WebRTC
Во Флеше была сделана годная попытка в одной технологии реализовать и риалтайм-общение, и массовый броадкастинг. К сожалению, в HTML5 так не вышло. Для просмотра трансляций у нас есть MSE, а для видеозвонков — WebRTC.
WebRTC — это SIP в браузере: способ организовать аудио- и видеоканал и канал данных между двумя браузерами при посредничестве сервера.
Технология не предназначена для стриминга, но в принципе может и его, так что было бы неправильно забыть про него. WebRTC тоже считается HTML5, потому что вроде как ничего кроме Яваскрипта в браузере не требует. Зато требует наличия последних версий обоих популярных браузеров, а с Эджем пока вообще не совместимо.
Путаницу в понимании WebRTC вносит его использование в торрент-доставке телевидения. Суть в том, что браузеры через WebRTC организуют сеть каналов данных, а дальше по этой сети раздаются HLS- или MSE-сегменты видео, а проигрывание происходит через Флеш или MSE. Т. е. WebRTC — для доставки, MSE — для проигрывания. Важно не путать это с использованием WebRTC для проигрывания видео.
▍Так что там с mp4-стримингом?
Любой современный браузер скорее всего сможет по протоколу HTTP запросить файл, упакованный в транспорт mp4 и содержащий внутри видео, сжатое кодеком h264/aac. И даже попытаться проиграть его. Это самый удобный, понятный и стандартный вариант проигрывания файлов. Лежит себе файлик на диске, nginx его отдает. Код, проигрывающий mp4 в браузерах достаточно хорош. Например, он умеет даже скачивать куски видео по необходимости (в отличие от Флеш-плеера, который скачивает видео целиком).
Вокруг h264 сложилось немало шумихи по поводу его «закрытости» и «несвободности». Так что есть «открытая» альтернатива, которую форсит Гугл — видеокодеки vp8 и vp9, упакованные в транспорт WebM. WebM — это подмножество транспорта mkv (a. k. a. Матрёшка), который очень похож на mp4 по сути, но отличается от него своей «бинарностью».
Именно отсюда растут ноги у такого явления как «mp4-стриминг», который устроен как WebM. Дело в том что в обычном mp4 в самом начале указывается размер всего контейнера. Поэтому, если мы хотим отдать по обычному mp4 прямой эфир, у нас ничего не получится. А чтобы всё-таки получилось и можно было создавать mp4 без фиксированного конца, придуман следующий ход: сначала пишется mp4 без кадров, а потом в конце подписываются блоками по несколько секунд фрагменты с кадрами. Это называется mp4 fragmented, или mp4 streaming.
По сути это никакой не стриминг, а костыль, позволяющий создать его видимость. Mp4 — отличный формат для скачивания видео, но негодный для стриминга, так что про него можно просто забыть и никогда не использовать термин «mp4-стриминг».
Dual stream что это
Так вот, принявшись за дело я обнаружил, что WMV файл содержит не один видеопоток, а два, которые правильно называются WMV Dual Stream. Преимущество его в том, что на обычных проигрывателях такое видео воспроизводится как обычное 2D (только левый ракурс), а при включении функции 3D на оборудовании или специальных 3D проигрывателях подключается дополнительный поток, создающий стереоизображение.
Покопавшись поглубже нашёл Windows Media Stereo Muxer, с помощью которого 2 отдельных потока сливают в один файл, но вот Windows Media Stereo DEmuxer мне найти так и не удалось ( сложность в том, что для wmv нет замечательного MKVtoolnixа для работы с потоками). И даже официальный Windows Media Encoder не распознал 2 потока, открыв лишь первый из них, как и все остальные конвертеры. Впрочем, создан Windows Media Stereo Muxer не в Microsoft. Разработчиком является 3dtv, известная своим Stereoscopic Player.
Но мне всё-таки удалось разбить эти видеопотоки инструментами 3dtv в редакторе GraphStudio (GraphEdit) и заново склеить в анафорфную стереопару (вертикальную или горизонтальную. P.S. Не путать с анаглифом, хотя и в него тоже можно кодировать). Подробнее об этом расскажу немного позже.
 |  |
| Oleggg10 | Дата: Суббота, 11.01.2014, 10:43 | Сообщение # 2 | |
| Итак, нам нужны такие инструменты: 1. Базовый набор кодеков в системе (я устанавливал кодеки по отдельности в меру необходимости, но лучше использовать сборку K-Lite) Конвертирование можно производить на этапе разделения видеопотоков в GraphStudio или на этапе сборки Stereo Movie Maker. Я выбрал нечто среднее, т.к. GraphStudio прямым потоком Mux’инга создаёт видео размером 5 Гб 1 минута на 1 поток, соответственно для 1 часа нужен свободный объём на HDD в 600 Гб. Ну и дальнейшая работа с таким видео слегка затруднительна. Поэтому я использовал wmv encoder, который был в системе, т.к. все вышесказанные программы используют внешние кодеки. Именно по этому может потребоваться установка Windows Media Encoder или K-Lite. Можно обойтись и прочими различными кодеками, но мне так и не удалось это сделать, упираясь на различные ограничения старого и нового софта (некоторые программы работают только с AVI, некоторые только с WMV или MKV). Так вот, настроив GraphStudio должным образом (см. снимки ниже), я добился перекодировки с минимальной потерей качества и сравнительно небольшим размером потоков на выходе (0,6 Гб/1 минута/1 поток). И уже с этими потоками производил склейку в анаморфную вертикальную/горизонтальную стереопару средствами Stereo Movie Maker, при этом выбирая нужное качество, размер и контейнер на выходе. | ||
|
