Форум VideoNet

Предпочтительнее ли для Вас потоковое или покадровое сжатие ?

Мне лично безразлично пока.
Ещё не было клиентов, которые вообще задавали вопрос про потоковое или покадровое сжатие, но интересны тенденции в общем.

я на это вообще внимания не обращаю... гораздо важнее другие факторы, а качество картинки оценивается визуально, если устраивает, то какая разница как она жмется!

Уважаемый автор опроса, а что на самом деле вас интересует? Даже не так, а вот как: "Что вы на самом деле хотели узнать от аудитории форума создавая этот опрос?".

Как правильно заметил mikle, это похоже на "Кит" и "Слон". Вам нравится "горячее" или "холодное". Все зависит от контекста и пережевано уже тысячи раз.

Есть преимущества у каждого метода компрессии, все зависит от того, какое из преимуществ хочется использовать. Выбирать, т.е. сравнивать, нужно на основании определенных характеристик и требований в конкретной ситуации (IMHO).

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

Может это уже и пережевывалось много раз, ну тогда просто дайте ссылку на эти обсуждения, будет нам полезно почитать.

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

Вот здесь и находится (IMHO) ключ к разгадке вашго вопроса "насколько потребителям важно..." Почему им важно??? По какому параметру "важно"?
Потребителям важно, чтобы их потребности были удовлетворены. Далее вопрос будет о потребностях, или "почему им важно" то или иное.

P.S. В общем случае компрессоры использующие и временную и пространственную избыточность изображения обеспечат обеспечат больший коэфициент сжатия чем компрессоры использующие только пространственную избыточность. Базовая ценность компрессора, то собственно для чего он создан - уменьшение объема хранимой (передаваемой и т.д.) полезной информации.

Господа разработчики, помнится в прошлом веке VideoNet использовал покадровое сжатие DeltaMJpeg, может стоит его реанимировать, подточить и как ни будь приладить к 8 версии.
Кому нужно покадровое сжатие будет использовать –покадровое, кому надо качественную запись-DVPack 2

del

Vycheslav писал(а):Господа разработчики, помнится в прошлом веке VideoNet использовал покадровое сжатие DeltaMJpeg, может стоит его реанимировать, подточить и как ни будь приладить к 8 версии.
Кому нужно покадровое сжатие будет использовать –покадровое, кому надо качественную запись-DVPack 2

точно? вроде ведь DVPack 1.42 и раньше был и сейчас есть

данная тема была разделена.

dr0m0k писал(а):

Vycheslav писал(а):Господа разработчики, помнится в прошлом веке VideoNet использовал покадровое сжатие DeltaMJpeg

точно? вроде ведь DVPack 1.42 и раньше был и сейчас есть

2000г. VideoNet 6.0, использовал формат сжатия видео DeltaMJpeg
Следующая версия VideoNet 7.0- формат сжатия видео h.261+, DVPack 1.42 появился чуть позже

ааа - речь еще про 6.0... стремненькая софтинка была, если честно
я начал продавать VN с версии 7

ru_steve писал(а):

Vycheslav писал(а):Межкадровое сжатие, если каждый кадр будет опорным, получится запись без сжатия

Если каждый кадр (например, в кодеке DvPack 1.42 или DvPack2) сделать опорным - сжатие, конечно же, будет. Но степень сжатия (и, соответственно, глубина архива) будет существенно ниже, чем при использовании всех возможностей кодека.

Н..да, учится ни когда не поздно , делюсь результатом повышения квалификации, может кому пригодится
Форматы сжатия MPEG сжимают только опорные кадры – I-кадры (Intra frame – внутренний кадр). В промежутки между ними включаются кадры, содержащие только изменения между двумя соседними I-кадрами – P-кадры (Predicted frame – прогнозируемый кадр). Для того чтобы сократить потери информации между I-кадром и P-кадром, вводятся так называемые B-кадры (Bidirectional frame – двунаправленный кадр). В них содержится информация, которая берется из предшествующего и последующего кадров. При кодировании в форматах сжатия MPEG формируется цепочка кадров разных типов. Типичная последовательность кадров выглядит следующим образом: IBBPBBIBBPBBIBB… Соответственно, последовательность кадров в соответствии с их номерами будет воспроизводиться в следующем порядке: 1423765…

del

Vibat! Теоритически существует гораздо больше вещей, чем встречается на практике, поэтому они и называются по разному

Используя JPEG (любой версии, хоть JPEG2000) достигается сжатие, за счет удаления из изображения высокочастотных составляющих. Чем больше высоких частот удалено - тем меньше размер. Если на заднем плане будет находиться "теоритический_достаточно_высокочастотный_человек", то мы его не увидим после сжатия.

Все, что построено на Wavelet-преобразовании, использует принципиально схожий принцип удаления из изображения частотных составляющих (при этом в JPEG используются конечные блоки, как правило 8*8, то в wavelet искажения, опять же теоритически, могут быть бесконечны, т.к. работа ведется не по блоку, а по всему изображению).

Теоритически, мы всегда можем получить ситуацию, что чего-то не увидим, если мы используем алгоритмы сжатия с потерями.

Алгортимы сжатия без потерь (пример ZIP), лишены этого недостатка. Мое мнение по поводу того, что выбирает потребитель в большинстве случаев - потоковое видео. Пример - посмотрите в какую сторону развивается обработка видео в целом по рынку.
В видео системах преимущественно поток (даже китайцы пытаются приладить H.264 LP).
Все согласны с тем, что за IP устройствами будущее? Куда и как развиваются IP-камеры с точки зрения сжатия? Добавление/замена JPEG (сравнительно не ресурсоемкого алгоритма) на потоковые алгоритмы MPEG4/H.264 (сравнительно более ресурсоемкие).
Все это делается потому, что потребитель выбирает то, что ему нужно/выгодно

Vibat писал(а):Давай откинем всю теорию. Решим главное.
Возможна ли потеря видеоинформации при сжатии MPEG ?
Ну например - человек на заднем плане.
Теоретически понятно - один шанс из тысячи. Может этот человек на заднем плане просто исчезнуть в кадре из-за формата сжатия?

Vibat. Потеря информации не просто возможна - она всегда есть. Это краеугольный камень алгоритмов сжатия с потерями (хоть покадрового, хоть межкадрового). Все они базируются на психоаудиовизуальной модели восприятия человека. То есть Ваше (моё) серое вещество само по-себе восстанавливает знакомые Вам (мне) образы и звуки. Вы (я) не заметите отсутствия информации. 99% (цифра от фонаря) людей её не заметят, но инструментально её там не будет. В этом и заключается совершенство алгоритмов кодеров с потерями - сделать так, что-бы при заданных первоначальных условиях (коэф. сжатия, скорость, ресурсоёмкость и бла бла бла) как можно меньше людей заметили-бы неизбежные искажения от отсутствия первоначальной информации.
Сжатие без потерь. Lossless. Вся информация остаётся, используются другие алгоритмы. Чистая высшая математика. Ноооо. Коэф. сжатия низок и очень сильно варьируется. В дело вступает энтропия. Состояние хаоса. Сжимать без потерь больше какого-то конечного значения, определяемого энтропией информации невозможно, а в нашем случае просто неприемлимо. Это для "Хаббла" и иже с ним.
А в нашем случае и в Вашем примере человечек может запросто исчезнуть, если его угловые размеры будут "определены" кодером, как избыточная (высокочастотная составляющая, как написал BigMax) информация.

del

Vibat писал(а): Не совсем убедительно. Увидим - но плохо. Ошибки орфограф...

Сорри за ошибки. Орфография пала жертвой скорости набора текста

По теме: убедительно или нет, не мне судить. Это, как правильно заметил mikle, чистейшая высшая математика. Убеждают/обучают этому предмету в ВУЗах.

del

Vibat писал(а):т.е. хотите сказать, что при любом сжатии, потоковым или покадровым, с равной долей вероятности, человечек на заднем плане может пропасть (или не пропасть) ?
а вообще довод "железный" (про ВУЗЫ), теперь то все всем стало ясно.

Упорный Вы человек
Может, может. Всё зависит от алгоритма, от настроек, от конкретной ситуации и не с равной долей, а с вероятностной. Также возможно вживление несуществующей информации со всеми вытекающими... Цифра, - это не аналог и лакуны, при грамотном подходе, выделить сложно.
Поэтому и появляются сообщения: "Лицо - похожее на ......", "Голос похожий на .....".
Радует то, что в оперативном плане всё заслуживает доверия.