Программирование видео-приложений

[alexis031182]

...
Короче говоря,  следует сделать запасной вариант, но основным оставить опенгл, имхо.

++

[Vladimir]

Дело в том, что в самом начале разработки речь шла о системе камер на 16/32, причем вывод изображения в реальном времени с одной камеры или в покадровом со всех должен был осуществляться при одновременной записи со всех камер на винт. В общем-то ресурсы компа должны быть использованы по полной. А API? Это не серьезно!©

[alexis031182]

...
Это не серьезно!©

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

[alexis031182]

Кстати, я тут начал переводить V4L2 API документацию. Сделано пока мало, но если кому интересно, поглядывайте сюда время от времени.

[Vladimir]

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

Стоит ли, Саня, время терять? Аналоговому video - почти кирдык.  

[alexis031182]

Стоит ли, Саня, время терять? Аналоговому video - почти кирдык.  

А какая разница-то? Что цифровое, что аналоговое устройство управляются через одну и ту же API библиотеку. Причём в win'де такая же ситуация. Ну а что касаемо сетевых видеокамер, так их время в России ещё не наступило. Может позже.

[Vladimir]

А какая разница-то? Что цифровое, что аналоговое устройство управляются через одну и ту же API библиотеку.

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

Ну а что касаемо сетевых видеокамер, так их время в России ещё не наступило.

Ты ошибаешься. Наступило.

[nash]

После того, как инфа оцифрована, - да. Только вот зачем это делать в персоналке, тем более современные тв камеры - это уже по сути мини-комп. с морем сервисов.
В общем-то для построения тв системы практически любой сложности на рынке безопасности все есть. Уже давненько.  
Ты ошибаешься. Наступило.

Да дело в том, что существуют задачи, в которых необходимо специфически обрабатывать видео поток в реальном времени. Для таких случаев не очень удобно использовать самые совр. камеры, выдающие сжатый поток, их сервисы становятся ненужными, и готовые программные решения не подходят. Это узкоспециализированные программно-аппаратные комплексы. Вот как раз проект, тут обсуждаемый - это большое подспорье в таких делах. Он, конечно, скорее всего не будет использоваться по назначению, по скольку все-таки "для построения тв системы практически любой сложности на рынке безопасности все есть", но он может стать основой для построения новых систем. Подобных проектов в сети я не нашел и надеюсь, что он развиваться будет.

[Vladimir]

Да дело в том, что существуют задачи, в которых необходимо специфически обрабатывать видео поток в реальном времени.

Например?

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

Если речь об анализе изменений в кадре по отношению к предыдущему, то согласен.

Это узкоспециализированные программно-аппаратные комплексы. .

Программа изначально разрабатывалась под виндозу, причем использовался один вход видео в карте видеозахвата. Переключение сигналов осуществлялось вначале, в целях синхронизации, по фронту кадрового гасящего, который выделялся из сигнала в коммутаторе, затем от этого отказались, и "испорченные" поля просто тупо пропускались. Кстати, если память мне не изменяет, до DirectX использовались функции API для прорисовки кадров. Всякие TPicture, TPaint...
Несколько лет назад подобный подход был оправдан невысококими затратами на создание четырех-восьми камерной видеосистемы,  

Вот как раз проект, тут обсуждаемый - это большое подспорье в таких делах

Очень приятно это слышать.

Подобных проектов в сети я не нашел и надеюсь, что он развиваться будет.

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

[Vladimir]

Кстати, если камера всего одна, то вполне можно реализовать очень даже неплохой программный ZOOM.  

[nash]

Мне, например, нужно было накладывать на видео поток текст, меняющийся во времени, бмп и т.д. Т.е. на каждый кадр должны быть наложены специфические текстово-графические данные, которые приходя из других источников, к примеру rs-интерфейс. Т.е. наличие компа необходимо, как и доступ к несжатому кадру. В будущем возможно и нужен будет анализ изменений в кадре по отношению к предыдущему. Короче говоря, использование не самых современных камер/технологий иногда оправдано.

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

>>Кстати, если камера всего одна, то вполне можно реализовать очень даже неплохой программный ZOOM. smile.gif
Может быть cтоит сделать не одну большую программу, а набор утилит, показывающих разные возможности/способы работы с видео с точки зрения захвата/обработки?

[Vladimir]

В любом случае нужно обсудить ряд вопросов с "главным идеологом" проекта.
Саша, что скажешь? Не прочь вернуться к видео? Мне лично идея подуше.

[alexis031182]

Да дело в том, что существуют задачи, в которых необходимо специфически обрабатывать видео поток в реальном времени. Для таких случаев не очень удобно использовать самые совр. камеры, выдающие сжатый поток, их сервисы становятся ненужными, и готовые программные решения не подходят. Это узкоспециализированные программно-аппаратные комплексы. Вот как раз проект, тут обсуждаемый - это большое подспорье в таких делах. Он, конечно, скорее всего не будет использоваться по назначению, по скольку все-таки "для построения тв системы практически любой сложности на рынке безопасности все есть", но он может стать основой для построения новых систем.

Могу с вами согласиться. Как-то мне посчастливилось разрабатывать узкоспециализированное приложение для морга (    ), если выражаться точнее - для судмедэкспертизы. Задача состояла в том, чтобы изображение с видеокамеры, направленной на человеческий череп, совмещалось с имеющейся фотографией человека, ещё бывшего при жизни. Таким образом устанавливалась личность умершего. Конечно не могу сказать, что мне за этим процессом было приятно наблюдать, однако программа работала.

Подобных проектов в сети я не нашел и надеюсь, что он развиваться будет.

Развиваться? А собственно куда? Для серьёзной системы безопасности, скажем прямо, кишка тонка (ну или затраты времени и сил будут как минимум не соизмеримы с полученной пользой). Ну а что касается специфичных задач, так надо иметь эту задачу.

[alexis031182]

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

Это реализуется достаточно просто, если использовать формат видеопотока RGB, причём, на сколько я помню, это даже с помощью функций Qt проделать можно.

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

Как мне известно, уже существуют свободные программы, позволяющие анализировать разность кадров. Можно либо позаимствовать готовые решения, либо самим помозговать.

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

Всё-таки, основная цель должна быть озвучена.

[Vladimir]

Развиваться? А собственно куда? Для серьёзной системы безопасности, скажем прямо, кишка тонка (ну или затраты времени и сил будут как минимум не соизмеримы с полученной пользой).

Да не о системе безопасности речь идет, Саша.
Если я понял правильно, то просто нужен некий интерфейс для добавления в видеопоток сторонней информации. По сути кадр, как пиксельный массив со значениями RGB и А есть и  нужно лишь дать возможность его в цикле модифицировть. По моему так. Нет?

[alexis031182]

...
По моему так. Нет?

  Конкретики не хватает...

[Vladimir]

 Конкретики не хватает...

Ну а какая конкретика нужна?
Все и так понятно. Пока видео не обработано кодеком, с последовательностью кадров и самими кадрами можно делать все, что только душа пожелает. Об этом и речь.
Я думаю так. Кадры из буфера тащим в окно. Далее, имеем например текстовое поле плюс сервисы (фонты, размеры, цвет, координаты и пр.). Текст может перекочевывать в окно с видео. Далее, статичная картинка, тоже с набором функций по ее модификации и микшированию с потоком. Далее, видео из файла, например. Ну и так далее.  

[alexis031182]

...
Ну и так далее.  

Угу. И кому это нужно? Заниматься этим - лишь бы чем заниматься?.. Я вообще о другом. Подобные, да и любые другие задачи требуют конкретики: что собственно нужно, как это должно быть реализовано и уж только затем - как это должно работать. В любом другом случае получается хобби, то есть просто ради самого процесса. Лично мне такая программа не нужна, тебе, я думаю, тоже. Но. Если nash или кто-нибудь ещё захочет пообщаться на эту тему - почему нет. Я веду к тому, что решение задачи всё-таки интереснее, когда знаешь, что кому-нибудь это самое решение будет полезно. А не как обычно: поговорили и разошлись.

[Vladimir]

Угу. И кому это нужно? Заниматься этим - лишь бы чем заниматься?..

Не хочешь - не занимайся.
Ты ничего не понял, но может быть потому, что я плохо объяснил. Ты прекрасно знаешь, что мелкософт дал разработчикам видео приложений очень хороший инструментарий, реализованный в том числе на гибком использовании неких модулей-фильтров, динамично подключаемых к проекту библиотек. Впрочем, ты и сам подобный фильтр писал (switcher.ax, если забыл).
В Линуксе подобного бесплатного инструментария скорее всего нет. Жаль. Не все, что от Билла - плохо.

Я вообще о другом. Подобные, да и любые другие задачи требуют конкретики: что собственно нужно, как это должно быть реализовано и уж только затем - как это должно работать.

Тебя что, подряжает на работу кто-то? Какая задача? Какая конкретика? Да и вообще, не публиковал бы коды по захвату видео, так и вообще ни о чем говорить не нужно б было. Красота! Времени вагон!

В любом другом случае получается хобби, то есть просто ради самого процесса.

Не ради процесса, а ради удовольствия от того, что кому-то пользу принес. Хотя, ради справедливости следует отметить, что в нашей раше теперича это не в чести.

[alexis031182]

Не хочешь - не занимайся.

Я этого не говорил. Конечно же мне это интересно, но вот без идеи чё-то там конопатить ну не в кайф совсем.

Ты ничего не понял, но может быть потому, что я плохо объяснил. Ты прекрасно знаешь, что мелкософт дал разработчикам видео приложений очень хороший инструментарий, реализованный в том числе на гибком использовании неких модулей-фильтров, динамично подключаемых к проекту библиотек. Впрочем, ты и сам подобный фильтр писал (switcher.ax, если забыл).
В Линуксе подобного бесплатного инструментария скорее всего нет. Жаль. Не все, что от Билла - плохо.

А вот это уже по существу. То о чём ты говоришь graphbuilder, кажется, назывался. Однако польза его сомнительна для конечного пользователя была. Ты хочешь предложить реализовать что-либо подобное, но так чтобы интересно было для всех: программистов и пользователей? Это мне интересно.

Тебя что, подряжает на работу кто-то? Какая задача? Какая конкретика? Да и вообще, не публиковал бы коды по захвату видео, так и вообще ни о чем говорить не нужно б было. Красота! Времени вагон!

Просто нехочется в очередной раз недоделку сооружать. Одному скучно, в компании - веселее.

Не ради процесса, а ради удовольствия от того, что кому-то пользу принес. Хотя, ради справедливости следует отметить, что в нашей раше теперича это не в чести.

В чести, но не у всех.