LabVIEW Portal

Итак, проблема. Начиная с какого-то момента работы (минут 20) приложения происходит следующий сбой: визуально картинка замирает и начинает размываться и съезжать вниз. Это было замечено еще вчера. Сегодня подтвердилось. Причем высчитанный FrameRate не меняется, но такое ощущение, что эвент не успевает выполняться и накапливается - нажатие на кнопку стоп (событие обрабатывается в этой-же структуре) отрабатывается с сильным запаздыванием, пропорциональным времени между началом сбоя и нажатием на кнопку. Загрузка процессора, как и было, в районе 20%. Возможно, это может быть связано, что камера выдает изображение с частотой не больше 20 Fps. А VLC работает с 25 Fps, на что указывает график.
Upd. сбой на 40 минутах.

Borjomy_1 писал(а):такое ощущение, что эвент не успевает выполняться и накапливается

Что показывает Эвент Инспектор?

А ничего... Desktop Execution Trace Toolkit падает на запуске. Переставлять все это хозяйство у меня сейчас нет времени...
Upd. Поведение разное. Иногда останавливается сразу. Странно другое. Параметр, передаваемый эвенту, фактически является константой. Его значение не меняется. Но картинка искажается.

Borjomy_1 писал(а):Странно другое. Параметр, передаваемый эвенту, фактически является константой. Его значение не меняется. Но картинка искажается.

Он и не должен меняться, ведь это указатель на буфер, который мы выделили при инициализации (DSNewPtr). А вот сам буфер меняется, и что там находится, зависит полностью от libvlc. Наскольно я понял из прошлых тестов, если есть пропуск кадров, то необработанные эвенты через какое-то время удаляются из очереди и никакого влияния на дальнейшую работу не оказывают. Но все тесты были кратковременными, уж точно не по 40 минут.

Попробуйте запустить тот же самый поток с тем же лимитом кэширования в самом VLC и оставьте на длительное время. Если возникнет та же ситуация, то виноват VLC. Если же нет, то вина ложится на libvlc, либо на архитектуру программы в .

В своё время я рассматривал VLC как альтернативу для работы с IP-камерами, думал так же прикрутить это дело в . Но пришлось отказаться от такого решения по следующим причинам:
1) задержка кэширования - требовалось практически реальное время наблюдения за объектом, что с задержкой около 1 сек. оказалось недопустимым;
2) артефакты при воспроизведении, например эффект "молочной пленки", типа как на рисунке здесь: кадр виден через эту пленку, через какое-то время проясняется и так до следующего раза.

В своё время я рассматривал VLC как альтернативу для работы с IP-камерами, думал так же прикрутить это дело в .

а какая другая альтернатива? Мне Ni-Max не удалось заставить хотя-бы опознать ни одну из двух IP камер разных производителей.

Ситуация с искажением изображения возникает также при большой нагрузке на процессор. Может быть, что сбивается lock/unlock (не разблокирован, когда приходит новый кадр). Сейчас буфер установлен 1000мс

Upd.
Вынес перенос кадра из буфера на картинку из эвента через очередь, что гарантирует непропуск кадров. Вместе с обработкой кадра загрузка уменьшилась до 16%. Но с другой стороны, есть риск лавинообразного потребления памяти при проблемах на приеме из очереди.


Накопились вопросы.
Можно ли как-то регулировать число кадров в сек в библиотеке VLC? У камеры 20 кадров. По последней картинке видно, что эта частота при получении кадра скачет. Преимущественно 25, реже 12.5 и еще реже 20 и ~32. Если подключить камеру (другую) с частотой 25 кадров, то и частота при получении кадра очень стабильно держится на этой отметке. Подозреваю, что сбои картинки связаны с высокой волатильностью частоты возникновения события при несовпадающих частотах.

Borjomy_1 писал(а):а какая другая альтернатива?

Тот софт, что предоставляет разработчик/поставщик камеры. В моём случае это были мало-мальские компоненты ActiveX, которые работали без задержек, в отличие от VLC. Если вы рассматриваете другие плееры, то скажу, что это бесполезно: остальные хуже, чем VLC, у некоторых задержка составляет и 3 сек, а некоторые постоянно глючат.

Borjomy_1 писал(а):Может быть, что сбивается lock/unlock (не разблокирован, когда приходит новый кадр).

Они так названы по другой причине: чтобы не возникало одновременного доступа к буферу (VLC пишет, а кто-то читает) в lock ставится мьютекс, а в unlock снимается. В данном случае я не стал запариваться с мьютексами, а просто передаю указатель на буфер в (PostLVUserEvent) в unlock'е, что должно гарантировать, что буфер свежий и можно его прочитать. Если есть желание, могу сделать генерацию рандомного буфера на каждом рендеринге. Вот здесь, например, вообще поток генерации кадров и поток чтения никак не связаны, так что по логике вещей чтение может совпасть с записью в буфер. Но судя по всему у автора статьи всё прекрасно работает. Можно и такой вариант попробовать тоже, я уже предлагал - вместо Event'а используется While с фиксированной задержкой и в нём выполняется постоянно MoveBlock. Если согласны, то я перекомпилирую callback. Или можете сами это сделать в MSVS.

Если подключить камеру (другую) с частотой 25 кадров, то и частота при получении кадра очень стабильно держится на этой отметке.

А в самом плеере не проверяли работу камеры? И как работают обе камеры в сравнении друг с другом? Будут ли такие искажения?

вместо Event'а используется While с фиксированной задержкой и в нём выполняется постоянно MoveBlock.

Пробовал ))) Не прошло. Считывается пустой буфер.

А в самом плеере не проверяли работу камеры? И как работают обе камеры в сравнении друг с другом?

Визуально все воспроизводится примерно одинаково. Имеется только инструментальный разброс по времени получения кадра.

Borjomy_1 писал(а):Считывается пустой буфер.

Я же написал:

dadreamer писал(а):Если согласны, то я перекомпилирую callback. Или можете сами это сделать в MSVS.

Borjomy_1 писал(а):Визуально все воспроизводится примерно одинаково.

Т.е., проблемы чисто в , а в остальном всё ОК.

Хм.. следующий шаг в сторону допила )))) - это функция, аналогичная по принципу TCP Read (чтение кадра с таймаутом). Т.е внутри dll-ки поток, который запускается на ожидание события получения кадра. Но я не настаиваю, это как идея.

Borjomy_1, а как в этом случае синхронизировать с ? Я честно говоря так и не понял, почему эвент со стороны не "взлетел"... А вдруг ожидание в DLL тоже не заработает. Да и внутри DLL бедный функционал в плане механизмов синхронизации . Не поддерживаются ни очереди, ни нотифаеры, ни семафоры, есть лишь функция Occur, так что придётся возиться с WinAPI. Может, схемку накидаете, как это всё должно выглядеть.

Мужчины помогите!

Сейчас реализую проект в котором нужна запись стрима с видеопотока и просто подключение к камере.

Обычное подключение к камере реализовал достаточно быстро, использовав самый первый пример в этой теме (через ActiveX).

А вот второй вариант что-то не выходит. Скачал ваши примеры VLC - Save Stream и VLC_Callbacks. В обоих случаях выводится одна и таже ошибка (Код 15, Call Library Function Node in VLC). Появляется она во время вызова функции libvlc_media_new_location. Видеопоток есть и он исправен (проверено через VLC, D-link, Mydlink, KMP player)

На данный момент использую камеру DCS - 930L.

Mad!sson писал(а):libvlc_media_new_location

Может, адрес канала неверно указали? И проверьте путь к вашему VLC. Что выдает инструмент VLC - Get Program Location (path).vi? Должно быть что-то типа C:\Program Files (x86)\VideoLAN\VLC\vlc.exe. И не мешайте в одной программе ActiveX с DLL, используйте что-то одно.

И, случаем, у вас LabVIEW не x64? Если так, то нужно использовать 64-битную библиотеку libvlc и делать 64-битный callback.

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

У меня, кстати, на работе с BGRA почему-то не захотело работать - тупо черный экран вместо изображения. (LV 2013). Хотя дома прекрасно работает на LV 2013 и на LV 2014. Помню, что у меня раньше тоже были какие-то проблемы, пришлось использовать RGBA и мат. обработку.

Адрес канала указываю один и тот же. Для VLC плеера и VLC ActiveX в Labview. Грубо говоря не подключается именно в ваших примерах (конечно я их не коим образом не изменял, кроме путей к библиотекам). Перед libvlc_media_new_location стоит функция libvlc_new, там все нормально проходит.

У меня ощущение, что все таки проблема в самом потоке либо что-то я не так задаю. Сам поток прописан таким образом - http://admin:welovemvk@192.168.1.45/vid ... lution=VGA. Может в этом проблема?

Labview 2013 32 bit. Путь к библиотеке - c:\Program Files (x86)\VideoLAN\VLC\libvlc.dll. VLC - 1.0.5.