| Вопрос: IP camera +VB.NET | Добавлено: 24.01.11 02:54 |
Автор вопроса:  ВВВ
|
| приветствую. есть IP camera, как прочитать видеопоток с адреса ее вебсервера? поток доступен в виде http://192.168.2.178/videostream.cgi - отображается на html странице. а как его на форму отобразить? желательно кусочек кода :-) |
| Ответы | Всего ответов: 52 |
|
Номер ответа: 1 Автор ответа:  AgentFire ICQ: 192496851 Вопросов: 75 Ответов: 3178 |
Профиль | | #1 | Добавлено: 24.01.11 09:49 |
| а мы должны угадать что за камера и т.п.? | ||
|
Номер ответа: 2 Автор ответа: ВВВ Вопросов: 1 Ответов: 16 |
Профиль | | #2 | Добавлено: 24.01.11 11:34 |
а разницы особой нет - у них есть встроенный вебсервер. камера http://www.foscam.com/Products_List.asp?id=128 SDK-
|
||
|
Номер ответа: 3 Автор ответа: ВВВВопросов: 1 Ответов: 16 |
Профиль | | #3 | Добавлено: 24.01.11 11:36 |
| IP камеры отличаются только потоком (2 типа)и путь в каталоге вебсервера. вопрос- как средствами vb.net показать видеопоток на форме? | ||
|
Номер ответа: 4 Автор ответа: AgentFireICQ: 192496851 Вопросов: 75 Ответов: 3178 |
Профиль | | #4 | Добавлено: 24.01.11 13:48 |
| DirectShow | ||
|
Номер ответа: 5 Автор ответа: EROSВопросов: 58 Ответов: 4255  |
Профиль | | #5 | Добавлено: 24.01.11 14:21 |
|
если видео поток не кривой,то надо юзать directshow и строить граф фильтров. Я работал с axis у них h264 идет кривой и ни один кодек его не понимает, поэтому я использовал mjpeg. В целом я делал следующим образом:
1. Получение данных (HttpWebRequest) - тут просто коннект к камере по url с передачей логина и пароля и получения Stream 2. Полученные байты парсил в соответствии с протоколом на кадры (Bitmap) 3. Полученные картинки отрисовывал в окне через GDI+ Недостатки: 1. MJPEG - это тупо набор картинок через разделитель.. как следствие - большой трафик. H264 гораздо менее прожорлив но качество изображения хуже 2. Поскольку работа с графикой и большим количество картинок, надо быть очень внимательным к написанию кода и своевременно удалять все создаваемые объекты. GC тут мало чем поможет 3. GDI всю отрисовку делает за счет процессора без использования возможностей видеокарты (в отличии от OpenGL,DirectX) в итоге мы имеем достаточно серьезную нагрузку на процессор. На слабых компах может доходить до 50%. (это я говорю только об отрисовки без учета ресайза и прочей постобработке) |
||
|
Номер ответа: 6 Автор ответа: VβÐUηìtВопросов: 246 Ответов: 3333 |
Web-сайт: Профиль | | #6 | Добавлено: 24.01.11 15:46 |
|
EROS пишет:
H264 гораздо менее прожорлив но качество изображения хуже Да. Только попытаться все-таки как-то кошерно схавать этотваш H264 сигнал доставляет море удовольствия. Знакомый раста с тяжелейшим затрахиванием за 4 месяца освоил тонны левого говнокода на C++, и в итоге сделал хорошую, годную обертку, которая оборачивает вещание в сеть в MP4, MPEG2 и H264. Теперь это выглядит где-то так:
Под этой оберткой скрывается море говна на шарпе, половина этого говна оборачивает еще большую кучу говна на C++ и даже на голом C. Но работает. Но это очень мутарная херь. Вот. GDI всю отрисовку делает за счет процессора без использования возможностей видеокарты (в отличии от OpenGL,DirectX) в итоге мы имеем достаточно серьезную нагрузку на процессор. На слабых компах может доходить до 50%. (это я говорю только об отрисовки без учета ресайза и прочей постобработке) Всю картинку можно не трогать, а брать только кусок памяти прямо внутри графа никуда не копируя, подсовывать сишарпу как битмап, делать от него графикс и рисовать прямо на этой памяти всеми вашими дотнетовскими бонусами, потом дальше отдавать в граф, куда оно там пойдет. Для ресайзов есть всякие сиплюсные быстрые SSE MMX байтовые алгоритмы, которые можно одолжить у VirtualDub и небольшим движением руки подрубить дотнету. А вот если "брать полученные картинки и отрисовывать в окне через GDI+" - вот это весело. Очень весело. Пришли мне фотку своего лица, когда посмотришь на нагрузку. Превью лучше делать либо по-старому, тобишь через эти ваши директиксовые поверхности, либо извратно-поновому - брать WritableBitmap из WPF, или как там его и пихать ему в память полученное изображение с помощью банального memcpy. В результате получаем ImageSource, который можно подсунуть любому элементу в WPF, начиная от прямоугольника заканичвая... чем нибудь. Тогда жрать неочень много будет. Зато можно будет невозобранно масштабировать, вращать, допиливать эффект с анимациями и контрастностями, практически не теряя производительности. Способ про WPF проверен лично мной, я гарантирую, что он очень хороший. Только надо ненакосячить.
Кстати, народ, кто-нибудь все-таки знает, как сделать RenderToBitmap у WPF? Только не тот, который все рисует видеокартой, потом выкидывает нахер, и перерисовывает процессором, а чтобы так: даешь команду WPF, он рисует все видеокартой, и потом копирует нарисованный результат из памяти видеокарты тебе. Кроме какого-то говнохака, который елеработает через подмены адресов функций у директикса, ничего не нашел. ??? |
||
|
Номер ответа: 7 Автор ответа: EROSВопросов: 58 Ответов: 4255 |
Профиль | | #7 | Добавлено: 24.01.11 16:47 |
|
Знакомый раста с тяжелейшим затрахиванием за 4 месяца освоил тонны левого говнокода на C++
ну у нас это сделали за пару дней при помощи ffmpeg без всякого напряга. Очень весело. Пришли мне фотку своего лица, когда посмотришь на нагрузку.
Ты, наверное, думаешь открытие сделал? Так чтоб ты знал - это баян(я о нагрузке писал выше).. На WinForms давно и успешно юзаю SetDIBitsToDevice Для ресайзов есть всякие сиплюсные быстрые SSE MMX байтовые алгоритмы, которые можно одолжить у VirtualDub и небольшим движением руки подрубить дотнету.
Очередное извращение? WPF сам спокойно ресайзит без проблем. либо извратно-поновому - брать WritableBitmap из WPF
Единственно полезная для ТС информация, при условии что он будет делать на WPF |
||
|
Номер ответа: 8 Автор ответа: VβÐUηìtВопросов: 246 Ответов: 3333 |
Web-сайт: Профиль | | #8 | Добавлено: 24.01.11 22:21 |
|
EROS пишет:
ну у нас это сделали за пару дней при помощи ffmpeg без всякого напряга. Ну вообще тонны левого говнокода - это и есть ffmpeg. Задача была сделать нормальную обертку для дальшейшей работы. EROS пишет:
Ты, наверное, думаешь открытие сделал? Нет, не думаю. EROS пишет:
Очередное извращение? WPF сам спокойно ресайзит без проблем. ЭТо если ты на экран будешь видео отображать. А если тебе надо его будет выводить на какой-нибудь конвертер или в сеть, то придется пользоваться стандартным Г. Чтобы ресайзить WPF'ом в конвеере обработки изображения, нужно не только уметь засовывать видео в видеокарту, но и наоборот. Я как раз над этой проблемой бьюсь. |
||
|
Номер ответа: 9 Автор ответа: ВВВВопросов: 1 Ответов: 16 |
Профиль | | #9 | Добавлено: 25.01.11 11:12 |
|
спасибо всем откликнувшимся
EROS пишет:
2. Полученные байты парсил в соответствии с протоколом на кадры (Bitmap) можно этот момент подробнее осветить? |
||
|
Номер ответа: 10 Автор ответа: AgentFireICQ: 192496851 Вопросов: 75 Ответов: 3178 |
Профиль | | #10 | Добавлено: 25.01.11 11:20 |
|
Igor Rubas пишет:
a) Bitmap.FromStream(stream)
можно этот момент подробнее осветить? b) new io.memorystream(bytes()) ? |
||
|
Номер ответа: 11 Автор ответа: VβÐUηìtВопросов: 246 Ответов: 3333 |
Web-сайт: Профиль | | #11 | Добавлено: 25.01.11 13:04 |
|
Igor Rubas пишет:
можно этот момент подробнее осветить? Ну в данном случае у тебя H264, и тебе надо его декодировать. Тебе нужен алгоритм декодирования H264. Можешь взять какой-нибудь кодек, запилить граф DirectShow из трех (или более, если звук) элементов и просто гнать информацию через него. На выходе получшь свои кадры. А можешь обмазаться исходниками ffmpeg и делать свой. Кстати, народ, как там по поводу Microsoft Expression Encoder? Его ковырять нет времени, чувствую что что-то очень банальное и нихера нефункциональное. Кто нибудь пробовал? |
||
|
Номер ответа: 12 Автор ответа: EROSВопросов: 58 Ответов: 4255 |
Профиль | | #12 | Добавлено: 25.01.11 13:25 |
|
Ну в данном случае у тебя H264
а почему не MJPEG? Откуда уверенность что у него H264? Тебе нужен алгоритм декодирования H264. Можешь взять какой-нибудь кодек, запилить граф DirectShow из трех (или более, если звук) элементов и просто гнать информацию через него.
Для построения графа нужен так называемый Source FIlter. Какой из фильтров ты использовал чтоб тянуть данные с камеры? з.ы. я бы хотел взглянуть на твой код построения графа. |
||
|
Номер ответа: 13 Автор ответа: VβÐUηìtВопросов: 246 Ответов: 3333 |
Web-сайт: Профиль | | #13 | Добавлено: 25.01.11 13:56 |
|
EROS пишет:
код построения графа. Кода на DirectShow нет, ибо мы пользуемся нашей же трехуровневой оберткой над ним. Скорость создания ПО для обработки видео возрастает в 100 раз. Если же писать на DirectShow, то по-моему примерно это должно выглядить примерно так: создается нуль-источник, тобишь твой SourceFilter, который просто выдает пустые байты, за него цепляется фильтр с переписанным нутром, который байты заменяет на данные с сети. Данные с сети берутся с помощью ffmpeg, обработанного напилиником. Дальше цепляем декодер (хотя можно его взять и того же ffmpeg и все делать на месте), сплиттер, аудио в обход, дальше уже зависит от задачи. Алсо, благодяря DirectShow и "аудио в обход" часто начинается очень веселый бонус по имени рассинхрон по звуку. Если ты хаваешь данные с какой-нибудь убогой плат DeckLink, которая место того, чтобы класть аудио и видео вместе и в очередь, дает их отдельно, да еще и вдобавок на разное время (o_O), то точно начнетя, я гарантирую это. Причем вполне можешь обнаружить это отставание на секунду спустя двухсуточной работы программы. Поэтому в обертке практически все заменено на свое, а DirectShow подсовываются пустые фильтры, которые на каждый фрейм вызывают обернутый сиплюсный код. Если что-то про DirectShow написал неверно, можешь написать стену текста про то как я его незнаю, мне похер, ибо я уже на нем не пишу. Он не нужен. EROS пишет:
а почему не MJPEG? Откуда уверенность что у него H264? Ну пусь MJPEG, я ничего не доказываю. Пусь хоть свой формат. Мне так же похер. EROS пишет:
Какой из фильтров ты использовал чтоб тянуть данные с камеры? Стандартные фильтры унылое говно. Сейчас мы пишем прием/вещание в сеть, и есть большой перечен доказательств, что стандартные фильтры - унылое говно. Хотя, с другой стороны, у нас может, требования несколько высокие. Ибо фильтр считается унылым говно не только если вешает всю систему, программу или падает в синий экран, но и если поддтормаживает/подвисает в начале. Короче, должен работать, чтобы ни малейшего дергания. Телеканал как-никак. Смекаешь? |
||
|
Номер ответа: 14 Автор ответа: EROSВопросов: 58 Ответов: 4255 |
Профиль | | #14 | Добавлено: 25.01.11 14:21 |
|
Звук меня не интересует, у меня задача только отображать видео.
По поводу графа есть пара нюансов, которые хотелось бы прояснить.. з.ы. вылези в аську или дай скайп |
||
|
Номер ответа: 15 Автор ответа: EROSВопросов: 58 Ответов: 4255 |
Профиль | | #15 | Добавлено: 25.01.11 14:33 |
|
Igor Rubas пишет:
можно этот момент подробнее осветить? А тут освещать особо нечего. Находишь в сети описание протокола mjpeg. Куришь его до просветления, после чего понимаешь что это по сути набор картинок разделенных маркерами начала и конца кадра(картинки в формате Jpg). А дальше все просто: 1. Создается буфер размеров в 2-3 кадра 2. Полученный с камеры поток пишешь в буфер. 3. После каждой полученной порции данных ищешь маркер начала кадра. - если нашел, все что перед ним удаляется и содержимое буфера сдвигается в начало - если нет то получаешь следующую порцию данных и снова дописываешь в буфер 4. После того как у тебя есть индекс начала кадра так же после каждой порции данных ищешь маркер конца кадра. - если нашел, то вырезаешь из буфера часть байт.. от маркера начала до маркера конца кадра. Затем используя MemoryStream создаешь свой стрим а из него через Bitmap.FromStream(stream) получаешь свою картинку, которую уже будешь отрисовыват как угодно.. 5. после того как обработал картинку остаток буфера сдвигается в начало и все повторяется сначала. |
||