نرم افزار نظارت تصویری به نما

 یکی از اشکالاتی که در bc_cleanup هست اینه که رکوردهای قدیمی‌تر رو به صورت sequential از روی چند هارد پاک میکنه. یعنی اول میره سراغ هارد اول، بعد که کارش تموم شد میره سراغ هارد دوم و به همین ترتیب. این باعث میشه اگر به هر دلیل پاک کردن رکوردها از هارد اول طول بکشه هاردهای دیگه پر بشن و کسی نباشه به دادشون برسه. برای رفع این مشکل راهی که اندیشیدم multi-thread کردن bc_cleanup بود. الان وقتی bc_cleanup با سوییچهای ‎-np یا ‎-ds که اولی برای وقتی است که میخواهیم not paired events پاک بشن و دومی برای وقتی است که میخواهیم رکوردهای قدیمی‌تر برای cleanup شدن disk space پاک بشن صدا زده میشه این کار به صورت هم زمان توسط threadهای مختلف انجام میشه. یک اشکالی که این وسط هست که امیدوارم در محیط مشتری باعث بروز مشکل نشه اینه که اگر پاک کردن رکوردها از روی هاردی طول بکشه، به هر دلیل، مثل اینکه تعداد رکوردهای اون هارد خیلی بیشتر از هاردهای دیگه باشه، این باعث میشه از bc_cleanup تا تکمیل این پاک شدن خارج نشیم. با مثال بریم جلو مطلب بهتر روشن شه. مثلاً یه هاردی تعداد رکوردهای خیلی کمی برای پاک کردن د...

 وقتی سرور شما در فناپه و دارید دور کاری میکنید راههایی وجود داره که بتونید sourceهاتون رو edit و تغییرات داده شده رو تست کنید. یکیش اینه که به سرور ssh بزنید و با vi یا mcedit اونها رو پیمایش و ویرایش کنید. این البته بهترین راه نیست. چون اینها editorهای ساده‌ای هستند که قابلیتهای زیادی بهتون نمیدند. مثلاً نمیتونید با F12 برید سر definition یک function یا با Ctrl+Space براتون لیست آرگومانها رو بیاره تا بتونید اونها رو درست بزنید. یه راه دیگه اینه که روی سرور samba نصب کنید و اونها رو از طریق share ویندوزی در اختیار ویندوز قرار بدید و بعد روی ویندوز با Visual Studio اونها رو edit کنید. این روش باز بهتره، چون اونجا دیگه همه چیز دارید. مخصوصاً Visual Assist شما رو قادر میکنه به راحتی تمام پروژه رو زیر نظر داشته باشید و همه جای اون رو مورد توجه قرار بدید. منتها این روش مشکلاتی هم داره. در یک samba share معمولاً اشکالاتی نظیر تغییر permission فایلها به وجود میاد یا اینکه Visual Studio فایلها رو با EOL ویندوزی ذخیره میکنه و مشکل ساز میشه. اشکال دیگه هم اینه که دیگه روی دستگاه خودتون نمیت...

 خب، میبینم که هیچ رکوردی تولید نشده و در syslog هم bc_capture جز renew کردن subscription پیغامی نداده. یه نتیجه ساده میشه گرفت. درسته که دوربین گفته روش subscription policy رو هم پشتیبانی میکنه، اما احتمالاً اینطور نیست. میگه motion اتفاق افتاد از این طریق هم بهتون خبر میدم، اما خبری نداده. متأسفانه ODM گزینه‌ای نداره که بتونیم انتخاب کنیم از کدوم روش برای دریافت motion دوربین استفاده کن، و الا جهت اطمینان خیلی خوب بود اگر میذاشتم اونم یه امتحانی بکنه. اما از اونجایی که پیغام خطایی در syslog داده نشده به به نما اطمینان میکنم و تنها گزینه رو این میبینم که اشکالاتی که در به نما موقع گرفتن motion از روش pull point وجود داره رو رفع کنم. اینم کار سختیه. برای اینکه اون موقعی که header ب request داره درست میره همون تابعی صدا زده شده که نصفه نیمه میره. این مشکل رو فقط در مورد این دوربین داشته‌ام. خدا به خیر کنه. آیا در تنظیمات دوربین در این خصوص چیز مربوطی وجود داره که با تغییر دادنش بشه این اشکالات رو رفع کرد؟

 همونطور که انتظار داشتم ODM تونست از این دوربین motion رو بگیره. روشی هم که برای گرفتن motion استفاده کرده همون روش اول یعنی pull point هست. هم زمان که ODM بالا بود wireshark رو هم گذاشته بودم تو حالت ذخیره packetهایی که بین ODM و دوربین داشت رد و بدل میشد و یک dump خوب از این packetها تهیه شد. هدفم این بود که ببینم چرا به نما نتونسته با استفاده از روش اول از دوربین motion بگیره. بعد به نما رو اجرا کردم و packetهای رد و بدل شده بین به نما و دوربین رو dump گرفتم. با مقایسه بین این دو این اشکالات دیده شد: ODM مرتب Unsubscribe میکنه و مجدداً CreatePullPointSubscription رو صدا میزنه. این رو در مورد دوربینهای دیگه‌ای که از این روش برای گرفتن motion استفاده میکنند ندیده بودم. آیا پاسخ PullPoint نمیاد و به timeout میخوره که ODM چنین تصمیمی میگیره؟ پاسخ PullPoint یه خط در میون به Internal Server Error یعنی خطای 500 برخورده. در حالی که انتظار نمیره و خطایی در request وجود نداشته. آیا دوربین در ارائهٔ گزارش motion با استفاده از این روش خوب عمل نکرده؟ تا اینجا اشکالات مربوط به ODM بود. اما ب...

این دوربین با ip ب 192.168.11.141 و user & pass ب admin:@dmin1234 به من معرفی شد. خوشبختانه تغییراتی که در بخش onvif به نما داده‌ام در زمینه گرفتن تصویر دوربین از طریق onvif کار رو برام راحت کرده. اما برام عجیب بود که باز هم از این دوربین تصویری نمیگرفتم. پس از بررسی به این نتیجه رسیدم که در قسمت تنظیمات دوربین encoderی که احتمالاً به صورت default برای این دوربین در نظر گرفته شده از نوع H265ه و به نما هنوز این encoder رو پشتیبانی نمیکنه. با صحبتی که با آقای حسنی انجام دادم تغییر اون به H264 رو بلامانع دونستند و به این ترتیب تصویر دوربین به دست اومد. پس این به عنوان یک task به backlog اضافه میشه: پشتیبانی از H265 برای این کار لازمه نسخهٔ جدیدتر ffmpeg س reconfigure بشه. چون احتمالاً نسخهٔ قدیمی‌تری که فعلاً داریم ازش در به نما استفاده میکنیم قبل از ارائهٔ این encoder س update شده باشه. اگرم دیدم داره که همون رو میشه reconfigure کرد و مورد استفاده قرار داد. پیش نیازها باید دست بخورند و در صورت تغییر نسخه ffmpeg س sourceها هم. البته فعلاً این task در اولویت نیست. بعد از گرفتن تصویر ر...

 وقتی دوربین Avigilon اومد هیچ SDKیی همراهش نبود. نیاز بود motion رو از خود دوربین بگیریم و برای ارتباط برقرار کردن با اون تنها راه، استفاده از پروتکل Onvif بود. تقریباً یک ماه وقت گذاشتم و کلاس مستقلی برای ارتباط برقرار کردن با این دوربین نوشتم. کلاً چهار راه برای دریافت notification messageها از دوربین در دسته. از جمله اونها، چیزی که ما لازم داریم، دریافت وضعیت حرکت (motion state) است: pull point subscription policy pausable subscription manager interface بعضی از دوربینها موقعی که دارند تصویر رو به دست میدند یک data stream هم علاوه بر video stream و احیاناً audio stream حاوی اطلاعات حرکت و غیره رو با اون همراه میکنند. در مورد این دوربین روش دوم پیاده شده بود و هیچ کدی که بتونه چنین ارتباطی رو با دوربین برقرار کنه زده نشده بود. در کلاس avigilon camera این کد آماده شد و از اون به بعد تونستیم از این دوربین motion رو هم بگیریم. طبعاً اطلاعات مربوط به video stream url هم به صورت hard code در این کلاس قرار گرفت. گذشت تا نوبت به دوربین KDT رسید. این دوربین برای ارسال اطلاعات (meta data)...