интересные соревнования с борьбой за минимальный архив... т.е. важнее килобайты чем результат качества изображения, которое нужно получить? И чему здесь проектировщики учатся? Чтобы при расчетах выставлять минимальный размер потока на Н.264, и потом с гордостью смотреть на спецификацию, в которой один сервер с двумя жесткими дисками? Мега-экономия, приводящая к плачевному результату......
так все-таки хочется разобраться что к чему, это же законно
почитали про кодеки. И сравнивая -
http://en.wikipedia.org/wiki/Motion_JPEG и
http://en.wikipedia.org/wiki/JPEG2000 приношу извинения, что на английском, т.к. в русском переводе описание достаточно уменьшенное
и обращая внимание на функцию
"
Progressive transmission by pixel and resolution accuracy. These features are more commonly known as progressive decoding and signal-to-noise ratio (SNR) scalability. JPEG 2000 provides efficient code-stream organizations which are progressive by pixel accuracy and by image resolution (or by image size). This way, after a smaller part of the whole file has been received, the viewer can see a lower quality version of the final picture. The quality then improves progressively through downloading more data bits from the source. The 1992 JPEG standard also has a progressive transmission feature but it is rarely used"
как раз-таки и отвещающую за адаптацию под канал и разрешение монитора, имеющуюся в наличии у JPEG2000, но не у MJPEG. Т.е. у JPEG2000 адаптацию без ухудшения качества позволяет делать сам кодек, у MJPEG такой функции не указано. Допускаем, что это можно сделать на программном уровне в самом ПО системы видеонаблюдения
Есть несколько вопросов по выводам:
1. - Таким образом на экран выводятся 100 камер с разрешением 19,2х10,8 пикселей
Т.е. мы будем иметь изображение от камеры на экране с заведомо заниженным до предела разрешением?
Исходное разрешение камеры 2560х1920, а мы выводим 19,2х10,8 ?как я понимаю речь идет об вот этом пункте из руководства пользователя -
"8.4.1.4 Компрессирование и декомпрессирование видеосигнала
где написано:
Программное компрессирование видеосигнала – это процедура программной обработки оцифрованного видеопотока, производимая с целью уменьшения его объема. Компрессирование выполняется в соответствии со специализированным программным алгоритмом.
В программе «Интеллект» для компрессирования видеосигналов с плат видеоввода используется специально разработанный алгоритм MotionWavelet. Использование данного алгоритма позволяет уменьшить объемы видеопотоков в несколько десятков крат (от 5 до 30-ти, в зависимости от характеристик видеосигнала и степени компрессирования). Для компрессирования видеосигналов с IP-устройств используются разработанные производителями данных устройств или стандартные (например, MPEG4) алгоритмы.
Уменьшение объема видеопотока при компрессировании видеосигнала достигается за счет ухудшения его качества. В связи с этим в программном комплексе «Интеллект» компрессирование видеосигнала выполняется только в режимах записи на диск и передачи на Рабочие места. Перед отображением на монитор, установленный на Сервере, компрессирование видеосигнала не производится.
Для отображения на мониторе компрессированнного видеосигнала предварительно производится его декомпрессирование. Декомпрессирование автоматически выполняется при отображении видеосигналов (как в реальном времени, так и при воспроизведении видеозаписей из архива Сервера) на Рабочих местах и при воспроизведении видеозаписей на Сервере."
Т.е. подводя итог: вывести большее количество камер на экран мы можем путем уменьшения качества изображения.
В этом случае при попытке развернуть одну камеру на экран у пользователя будут размытые квадраты?2. по ссылке на тест - в кодеке H.264 на Примере 1: Загрузка процессора 95%., 7 камер на экране, разрешение каждой 1920х1080.
Т.е. только 7 камер на одну рабочую станцию и нагрузка под завязку?
И для 100 камер, чтобы не происходило ухудшения качества выводимого изображения нужно будет 15 станций?3. Если же брать удаленное рабочее место (УРМ), то надо использовать кодек с технологией Scalable-Video-Coding (т.е. допустим наш Motion Wavelet или новейший H.264 SVC, ну или конечно же восхваляемый специалистом Jpeg 2000). Данные кодеки фактически подстраиваются под канал передачи данных автоматически. Т.е. надо использовать или оборудование с такими кодеками или перекодировать тот же H.264 сервером "на лету" в Motion Wavelet.
Можно поподробнее как будет происходить декодирование H.264 в Motion Wavelet?
Какие при этом доступны возможности преобразования (разрешение, скорость кадров, уровень сжатия)?
И какие модели камер с Н.264 SVC поддерживаются на сегодняшний день в ITV?4. Есть еще один "хитрый" способ: использовать тот же MJPEG ( повторюсь, присутствует практически в каждой камере) но его декодирование делать не на УРМе а на Сервере, т.е. посылать от Удаленного рабочего места к серверу информацию, сколько камер и какого размера выводится на экран (буквально несколько сотен байт информации). Далее все как описано выше. Сервер (в "Интеллекте" он называется Ядро) самостоятельно декодирует поток под нужное разрешение и пуляет его в сеть. Таким образом частичная декомпрессия осуществляется не на УРМе, а на сервере. Т.е. нагрузка на сеть и на УРМ копеечная. А поскольку сам сервер "слепой", т.е. без вывода на мониторы, то и ему справиться с такой задачей не представляет труда.
Здесь речь идет о компрессировании/декомпрессировании?
Т.е. в окне с одновременным выводом большого количества камер выводим 19,2х10,8, при попытке увеличить - разрешение не изменится?5. Ну и наконец 3-й вариант: когда у нас 100 миллионов УРМ-ов в системе а сервер бедолага один и ему не хватает ресурсов под каждый УРМ перекодировать поток. ОК. Используем двухпотоковость камеры. Т.е. как только выводим камеру на полный экран, УРМ посылает запрос серверу на 1-й поток и получает его от сервера. При этом все что не выводится на экран в данный момент в сеть не передается и ее не грузит. Как только мы хотим понтануться перед Заказчикам и вывести 140 камер на экран: УРМ посылает запрос на второй поток от каждой камеры и Сервер выдает нам его в сеть. При этом не грузится не только УРМ и сеть но и сам сервер, т.к. он ничего не перекодирует вообще. Таким образом исходя из того что эти самые потоки первый и второй мы можем выставить в настройках софта самостоятельно при настройке системы исходя из того какого размера у нас мониторы и сколько камер в максимуме на них можно вывести чтобы хоть что-то там рассмотреть мы получаем отличную работоспособную систему на слабых серверах, на слабых Урмах, без нагрузки на сеть без всяких там Jpeg2000.
Ну и наконец здесь - во-первых, камера должна поддерживать два потока.
Во-вторых потоки от камер сервер должен пропустить через себя и не будем забывать, что пропускная способность сервера тоже ограничена его аппаратными возможностями.
И сервер формирует мультикастовый поток для всех 100 миллионов клиентов одновременно?
Или для каждого клиента формируется отдельный поток? Потому что каждый клиент может смотреть требуемые ему камеры и переключаться потоки будут абсолютно непредсказуемо.
Данная функция реализуется через видеошлюз в ITV?
