مصطلحات كاميرات المراقبة CCTV: كيف تقرأ ورقة المواصفات

إذا طلبت يوماً عرض سعر لكاميرات مراقبة لبيتك أو لمكتب شركتك، فأغلب الظن أنه وصلك جدول فيه سطور مثل «8 كاميرات 4MP بعدسة 2.8mm وإضاءة IR لمسافة 30 متراً، وضغط H.265+، ومسجل NVR بثمان قنوات PoE وقرص 4TB، ودعم ONVIF وP2P»، ثم سعر في آخر الجدول. وأنت تقرأ السطر كاملاً ولا تعرف أي رقم فيه مهم وأي رقم دعاية، ولا تعرف هل 4MP تكفي لترى وجه من يدخل من الباب، ولا كم يوماً سوف يحفظ هذا القرص، ولا هل تستطيع أن تسجل هذه الكاميرات يوماً ما على سيرفرك ببرنامج مثل Frigate بدل جهاز الشركة. والمشكلة أن المورد يعرف هذه المصطلحات جيداً، وأنت توقع على العرض وتكتشف المعنى بعد التركيب.

وفي مقال أنواع كاميرات المراقبة وكيف تختار بينها تكلمنا عن أشكال الكاميرات وطرق تغذيتها بالكهرباء، أما هذا المقال فهو قاموس عملي لكل سطر تقابله في عرض السعر وفي ورقة مواصفات الكاميرا Datasheet، وكل مصطلح فيه نشرحه بثلاثة أسئلة: ماذا يعني، ولماذا يهمك، وما السؤال الذي تسأله للمورد قبل أن توقع. ولن نكتفي بالكلام، فسوف نصنع كاميرا وهمية على Docker من مقطع تصوير حقيقي لكاميرا مراقبة، ونتكلم معها بالبروتوكول نفسه الذي يتكلم به أي مسجل، ونقيس أرقامها بأنفسنا.

وسوف نناقش في هذا المقال ما يلي:

• أجزاء نظام المراقبة الأربعة: الكاميرا والشبكة والمسجل NVR أو DVR والمشاهدة، وأين يقع كل مصطلح منها.
• الدقة Resolution والميجابكسل، ولماذا السؤال الحقيقي هو كثافة البكسل Pixels per Metre ومستويات DORI.
• العدسة Lens والبعد البؤري Focal Length وزاوية الرؤية، والعدسة المتغيرة Varifocal.
• الإضاءة: الرؤية الليلية IR والمدى الديناميكي WDR وحجم الحساس Sensor.
• الفيديو نفسه: عدد الإطارات FPS والضغط Codec ومعدل البت Bitrate والإطار المفتاحي I-Frame، مع تجربة تقيس أثر كل منها.
• كيف يطلب المسجل الفيديو من الكاميرا: RTSP وRTP وONVIF، مع جلسة حقيقية نكتبها بأيدينا.
• الكهرباء والحماية: PoE وIP67 وIK10 والحرارة، والتحليلات Analytics، والخدمات السحابية P2P.
• كيف تقرأ ورقة المواصفات سطراً سطراً، وقائمة الأسئلة التي ترسلها للمورد.

أجزاء نظام المراقبة: أين يقع كل مصطلح؟

قبل أن ندخل في المصطلحات واحداً واحداً، لنضع النظام كله في صورة واحدة، لأن أغلب الحيرة في عروض الأسعار سببها أن السطور تخلط بين أجزاء مختلفة، فسطر يصف الكاميرا، وسطر يصف المسجل، وسطر يصف الشبكة، وسطر يصف برنامجاً على هاتفك، وكلها مكتوبة بنفس الطريقة. والصورة التالية تبين الأجزاء الأربعة بالترتيب الذي يمر به الفيديو:

1. الكاميرا IP Camera: حاسوب صغير فيه حساس صورة Sensor وعدسة Lens وشريحة تضغط الفيديو، وتحدد جودة الصورة والمساحة التي تأخذها، وكل مصطلحات الصورة والإضاءة والضغط تخصها.
2. الشبكة Network: الكابلات وال Switch الذي يغذي الكاميرات بالكهرباء عبر PoE، وهي المكان الذي تعزل فيه الكاميرات عن بقية الأجهزة، وقد شرحنا الفرق بين أجهزة الشبكة في المودم والراوتر والسويتش.
3. المسجل Recorder: يأخذ الفيديو من الكاميرات ويحفظه على أقراص بحسب مدة الاحتفاظ Retention، وقد يكون جهازاً جاهزاً اسمه NVR، أو برنامج إدارة فيديو Video Management System واختصاراً VMS يعمل على سيرفر، مثل Frigate.
4. المشاهدة Viewing: الشاشة في غرفة الحارس، أو تطبيق الهاتف، أو المتصفح، وهي التي تقرر كيف تصل إلى النظام من خارج المكان، وهل يمر الفيديو عبر خوادم الشركة المصنعة أم لا.

وبجانب هذه الأجزاء الأربعة هناك طبقة خامسة تسمعها كثيراً في العروض الحديثة وهي التحليلات Analytics، أي أن يفهم النظام ما في الصورة، مثل أن يفرق بين شخص يمشي وظل شجرة يتحرك، وقد تكون داخل الكاميرا نفسها، أو داخل المسجل، أو في برنامج على السيرفر، وسوف نعود إليها في آخر المقال.

DVR وNVR وHVR وVMS: أسماء المسجلات

اسم المسجل في عرض السعر يخبرك نوع الكاميرات التي يقبلها، وهذا قرار لا يمكن تغييره بسهولة بعد مد الكابلات:

• المسجل الرقمي DVR: اختصار Digital Video Recorder، ويستقبل إشارة تناظرية Analog من كاميرات على كابل محوري Coaxial، ثم يحولها هو إلى فيديو رقمي ويضغطها، وتسمع معه أسماء أنظمة الفيديو التناظري عالي الدقة مثل AHD وHD-TVI وHD-CVI، وكل منها نظام من شركة مختلفة.
• مسجل الشبكة NVR: اختصار Network Video Recorder، ويستقبل فيديو مضغوطاً جاهزاً من كاميرات شبكية IP عبر الشبكة، فلا يحول شيئاً وإنما يحفظ ما يصله، وكثير منه فيه منافذ PoE مدمجة توصل بها الكاميرات مباشرة.
• المسجل الهجين HVR أو XVR: يقبل النوعين معاً، وهو مفيد عندما تريد أن تبقي كاميرات تناظرية قديمة وتضيف كاميرات شبكية جديدة.
• برنامج إدارة الفيديو VMS: برنامج وليس جهازاً، يعمل على سيرفر أو حاسوب، ويقوم بعمل NVR وأكثر، مثل البحث في الأحداث وإدارة الصلاحيات والتكامل مع أنظمة أخرى.

والقاعدة العملية لمن يريد أن يملك تسجيلاته: اختر كاميرات شبكية IP، والسبب أن الكاميرا الشبكية تتكلم بروتوكولاً مفتوحاً تفهمه كل المسجلات والبرامج كما سنرى، فإذا تعطل جهاز NVR بعد خمس سنوات أو أردت الانتقال إلى برنامج على سيرفرك، فالكاميرات نفسها تبقى صالحة.

الدقة Resolution: ماذا تعني 4MP فعلاً؟

أول رقم تراه في أي كاميرا هو الدقة، وتكتب بالميجابكسل Megapixel واختصاراً MP، وهي عدد النقاط في الصورة الواحدة، والجدول التالي يربط الأسماء التجارية بالأبعاد الحقيقية التي تراها في إعدادات الكاميرا:

ولاحظ أن الذي يهمك في المراقبة غالباً هو عدد البكسلات الأفقية وليس العدد الكلي، والسبب أن المشهد يتوزع عرضاً على هذه البكسلات، فكاميرا 4MP ليست ضعف كاميرا 2MP في التفاصيل كما يوحي الرقم، وإنما فيها 2560 بكسلاً أفقياً مقابل 1920، أي زيادة بنحو الثلث فقط في كل اتجاه. وكل زيادة في الدقة لها ثمن في معدل البت والمساحة وقدرة المسجل، وفي الأداء الليلي أيضاً، لأن الحساس بنفس الحجم الذي يحمل بكسلات أكثر يعطي كل بكسل ضوءاً أقل.

كثافة البكسل Pixels per Metre ومستويات DORI

وهنا السؤال الذي يجب أن تسأله بدل «كم ميجابكسل؟»: كم بكسلاً يقع على كل متر من المشهد في المكان الذي يهمني؟ فالكاميرا نفسها بدقة 1920 بكسلاً تعطيك وجهاً واضحاً إذا كانت تنظر إلى باب عرضه مترين، وتعطيك نقاطاً لا تعرف منها أحداً إذا كانت تنظر إلى موقف سيارات عرضه أربعون متراً، والمعادلة بسيطة: تقسم عدد البكسلات الأفقية على عرض المشهد بالمتر عند المسافة التي يقف فيها الشخص، فتحصل على كثافة البكسل Pixels per Metre، واختصاراً px/m أو PPM.

ولكي لا يبقى السؤال «هل هذا يكفي؟» بالإحساس، يعرف المعيار الدولي IEC 62676-4 الخاص بتطبيق أنظمة المراقبة مستويات للغرض من الصورة، وتسمى اختصاراً DORI من الحروف الأولى لكلماتها، وتنقل صفحة الشرح عند TP-Link Omada قيمها كما يلي: الاكتشاف Detection عند 25 بكسلاً للمتر، أي أن ترى أن هناك شخصاً أو سيارة، ثم المراقبة Observation عند 62 بكسلاً، أي أن ترى ماذا يفعل وما حوله، ثم التمييز Recognition عند 125 بكسلاً، أي أن تعرف بثقة أن هذا الشخص هو نفسه الذي رأيته من قبل، ثم التحقق من الهوية Identification عند 250 بكسلاً، أي أن تثبت من هو بالتحديد. والصورة التالية تحسب أعرض مشهد يسمح به كل مستوى لكاميرتين بدقتين مختلفتين:

في الحساب أعلاه لاحظ التالي:

• الأرقام قسمة بسيطة، فكاميرا بعرض 1920 بكسلاً تعطي 250 بكسلاً للمتر إذا كان عرض المشهد 7.7 أمتار فقط، ولذلك الكاميرا التي يعدك المورد أنها «ترى وجوه الداخلين» يجب أن تكون قريبة من الباب أو بعدسة ضيقة، وليست كاميرا واسعة على السقف تغطي الصالة كلها.
• الانتقال من 2MP إلى 4MP يرفع عرض المشهد المسموح لكل مستوى بنحو الثلث فقط، ومن 7.7 أمتار إلى 10.2 أمتار في مستوى الهوية، وهذا تحسن حقيقي، ولكنه ليس بديلاً عن وضع الكاميرا في المكان الصحيح.
• هذه القيم تفترض صورة واضحة، أما الضغط العالي والإضاءة الضعيفة والحركة السريعة فكلها تنقص التفاصيل الفعلية عن الحساب، لذلك اعتبر هذه الأرقام حداً أدنى وليست ضماناً.

والمثال الحقيقي التالي يبين الفكرة بأوضح من أي حساب، وهو من تسجيل كاميرا PTZ في موقف سيارات منشور في الملكية العامة، وهو نفسه المقطع الذي سوف نستخدمه في التجربة. ففي الصورة اليمنى المشهد الواسع للموقف كله، وفي الوسط قربت الكاميرا عدستها نحو عمود في طرف الموقف، وفي اليسار قربتها أكثر حتى ظهرت لوحة سيارة معلقة على العمود يمكن قراءتها، ويذكر وصف المقطع أن العمود يبعد 360 قدماً عن الكاميرا، أي قرابة 110 أمتار:

والدرس أن الدقة لم تتغير بين اللقطات الثلاث، وإنما تغير عرض المشهد، فاللوحة في الصورة الواسعة تأخذ بضعة بكسلات فقط، وفي اللقطة الأخيرة تأخذ مئات البكسلات، وهذا ما تفعله العدسة، وهو موضوع القسم التالي.

العدسة Lens والبعد البؤري Focal Length

السطر الثاني في أي ورقة مواصفات هو العدسة، ويكتب غالباً بالمليمتر، مثل 2.8mm أو 4mm أو 6mm، وهذا الرقم هو البعد البؤري Focal Length، وهو الذي يحدد زاوية الرؤية Field of View: كلما صغر الرقم اتسعت الزاوية ورأيت مشهداً أعرض بتفاصيل أقل، وكلما كبر ضاقت الزاوية ورأيت مشهداً أضيق بتفاصيل أكثر. والزاوية الأفقية تعتمد أيضاً على عرض الحساس، وحسابها التقريبي 2 × atan(عرض الحساس ÷ (2 × البعد البؤري))، والصورة التالية تطبق هذا الحساب على حساس عرضه 5.6 ملم كمثال، وعلى كاميرا بدقة 1920 بكسلاً تنظر إلى شخص على بعد 10 أمتار:

في الحساب أعلاه لاحظ أن العدسة 2.8 ملم التي تأتي مع أغلب الكاميرات الاقتصادية تعطيك زاوية واسعة تقارب 90 درجة، وهي ممتازة لتغطية غرفة كاملة من زاوية السقف، ولكنها على بعد 10 أمتار لا تتجاوز مستوى المراقبة، أي أنك سترى أن شخصاً دخل وماذا فعل، ولن تعرف من هو. ولذلك التصميم الصحيح يجمع نوعين: كاميرا واسعة تعطيك الصورة العامة، وكاميرا ضيقة على نقطة لا بد أن يمر منها كل شخص، مثل الباب أو البوابة أو صندوق الدفع، وهذه هي التي تعطيك الوجه واللوحة.

العدسة الثابتة Fixed والمتغيرة Varifocal وPTZ

• العدسة الثابتة Fixed Lens: بعد بؤري واحد لا يتغير، وهي الأرخص والأبسط، ويجب أن تختار رقمها قبل الشراء بناءً على المسافة والعرض الذي تحتاجه.
• العدسة المتغيرة Varifocal Lens: تستطيع أن تغير بعدها البؤري ضمن مدى، مثل 2.8 إلى 12 ملم، ثم تعيد ضبط التركيز Focus، وفي الكاميرات الحديثة يكون ذلك بمحرك من صفحة الإعدادات، ويكتب في الورقة Motorized Varifocal، وهي الخيار الأنسب عندما لا تعرف المسافة بدقة قبل التركيب.
• كاميرا PTZ: تدور وتميل وتقرب الصورة بعدسة تقريب بصري Optical Zoom وهي تعمل، كما في لقطات موقف السيارات أعلاه، ولكنها في كل لحظة تنظر إلى جزء واحد فقط من المشهد.

والصورة التالية لعدسة متغيرة من النوع الذي يركب في كاميرات المراقبة، وفيها ثلاث لقطات لنفس العدسة: عند 2.8 ملم والصورة واضحة، ثم عند 12 ملم دون إعادة التركيز فأصبحت الصورة ضبابية، ثم عند 12 ملم بعد إعادة التركيز:

ولاحظ في الصورة المقبضين الصغيرين على جانبي العدسة، فأحدهما للتقريب Zoom والآخر للتركيز Focus، وهذا هو النوع اليدوي الذي يضبطه الفني على السلم ثم يغلق الكاميرا، فإذا تحرك أحدهما مع الحرارة أو الاهتزاز بعد أشهر ضاعت الصورة، وهذا سبب إضافي لتفضيل النوع المزود بمحرك إذا كانت الكاميرا في مكان يصعب الوصول إليه.

الإضاءة: IR وWDR وحجم الحساس Sensor

أغلب الحوادث التي تشتري الكاميرا من أجلها تقع في الليل، أو عند باب تدخل منه الشمس، وفي الحالتين يتعطل الحساب الجميل للبكسلات إذا لم تكن الكاميرا قادرة على التعامل مع الضوء، لذلك اقرأ هذه السطور بعناية:

• الإضاءة تحت الحمراء Infrared أو IR: مصابيح LED حول العدسة تضيء المشهد بضوء لا تراه العين وتراه الكاميرا، فتصبح الصورة بالأبيض والأسود في الليل، والرقم المكتوب مثل «IR 30m» هو المسافة التي يصل إليها هذا الضوء بحسب الشركة، وليس المسافة التي تتعرف فيها على الوجوه، فالتعرف يحكمه حساب البكسلات السابق.
• مرشح الأشعة تحت الحمراء ICR: مرشح ميكانيكي يتحرك أمام الحساس، يمنع الأشعة تحت الحمراء في النهار حتى تبقى الألوان طبيعية، ويرتفع في الليل حتى يرى الحساس ضوء IR، وتسمع صوت حركته عند الغروب، وهذا هو معنى Day/Night في الورقة.
• الرؤية الليلية بالألوان: تسميها كل شركة باسم تجاري، وهي حساس أكثر حساسية مع عدسة تدخل ضوءاً أكثر، أو مصباح أبيض صغير يضيء عند الحركة، وتفيدك عندما تحتاج لون السيارة أو الملابس.
• المدى الديناميكي الواسع WDR: اختصار Wide Dynamic Range، وهو قدرة الكاميرا على إظهار الأجزاء المظلمة والمضيئة في نفس الصورة، مثل شخص يقف عند باب زجاجي والشمس خلفه، فبدون WDR يظهر الشخص ظلاً أسود، ويكتب بالديسيبل مثل 120 dB، والفرق مهم بين WDR الحقيقي في الحساس والمعالجة الرقمية فقط التي تكتب أحياناً DWDR.
• حجم الحساس Sensor Size: يكتب بصيغة غريبة موروثة من أنابيب التصوير القديمة، مثل 1/2.8 أو 1/1.8 بوصة، والقاعدة أن الرقم الأكبر بعد الكسر أصغر، فحساس 1/1.8 أكبر من 1/2.8، والحساس الأكبر يجمع ضوءاً أكثر لكل بكسل، فيعطي صورة ليلية أنظف بنفس الدقة.

وتذكر أن ضوء IR ينعكس على أي سطح قريب من العدسة، فإذا ركبت كاميرا Dome قريبة من جدار أو تحت سقف بارز، أو تركت عليها الغشاء البلاستيكي، فقد تعطيك صورة ليلية بيضاء ضبابية، وهذا من أكثر الأخطاء التي يكتشفها الناس في أول ليلة.

الفيديو نفسه: FPS والضغط Codec ومعدل البت Bitrate

الكاميرا لا ترسل صوراً منفصلة، وإنما ترسل فيديو مضغوطاً، وثلاثة أرقام في الورقة تحدد حجم هذا الفيديو، وبالتالي المساحة التي تحتاجها على القرص والسعة التي يأخذها من الشبكة، وقد شرحنا أساس هذه المفاهيم في مفاهيم الفيديو للمبتدئين، وهنا نركز على ما يخص المراقبة:

• عدد الإطارات في الثانية FPS: اختصار Frames Per Second، والسينما تعمل بنحو 24 إطاراً، أما المراقبة فلا تحتاج حركة ناعمة، والمهم ألا تفوتك اللحظة التي يعبر فيها شخص، لذلك 10 إلى 15 إطاراً تكفي أغلب الكاميرات، والرقم المكتوب في الورقة مثل «25/30 fps» هو الحد الأعلى الذي تستطيعه الكاميرا، وأنت الذي تختار من الإعدادات.
• الضغط Codec: الطريقة التي تقلل بها الكاميرا حجم الفيديو، والمعياران المنتشران هما H.264 وH.265 من الاتحاد الدولي للاتصالات ITU، والثاني مصمم ليعطي حجماً أصغر بنفس الجودة مقابل جهد أكبر في الضغط وفكه. أما الأسماء مثل H.265+ أو Smart Codec فهي إضافات خاصة بكل شركة تخفض معدل البت عندما يكون المشهد ساكناً، وتعمل جيداً مع مسجل نفس الشركة، وقد لا يفهمها برنامج آخر بنفس الكفاءة، لذلك اسأل هل يمكن تعطيلها.
• معدل البت Bitrate: كمية البيانات في الثانية، ويقاس بالكيلوبت أو الميجابت في الثانية، وهو الرقم الذي يحدد المساحة مباشرة. وتعطيك الكاميرا عادة طريقتين: معدل ثابت CBR، أي Constant Bitrate، يبقى قريباً من الرقم الذي تحدده مهما كان المشهد، ومعدل متغير VBR، أي Variable Bitrate، يرتفع مع الحركة وينخفض مع السكون حتى حد أعلى تحدده أنت.

البث الرئيسي Main Stream والبث الفرعي Sub Stream

أغلب الكاميرات الشبكية لا ترسل بثاً واحداً، وإنما بثين أو ثلاثة في نفس الوقت، كل منها بإعدادات مختلفة: بث رئيسي Main Stream بالدقة الكاملة يستخدم للتسجيل، وبث فرعي Sub Stream بدقة منخفضة وإطارات أقل يستخدم لعرض عدة كاميرات على شاشة واحدة، وعلى الهاتف عبر اتصال ضعيف، ولتحليل الصورة. والسبب بسيط: شاشة تعرض ست عشرة كاميرا في مربعات صغيرة لا تستفيد من 4MP في كل مربع، والمسجل الذي يفك ضغط ست عشرة بثاً بدقة كاملة يحتاج قدرة كبيرة دون فائدة، وقد رأينا في دليل Frigate أن تشغيل الكشف على البث الفرعي هو أبسط تسريع على الإطلاق.

الإطار المفتاحي I-Frame ومجموعة الصور GOP

والمصطلح الذي لا يكتب في عروض الأسعار، ويؤثر في المساحة أكثر مما يتوقع الناس، هو المسافة بين الإطارات المفتاحية. فالضاغط لا يحفظ كل إطار كصورة كاملة، وإنما يحفظ صورة كاملة كل فترة تسمى الإطار المفتاحي I-Frame، ثم يحفظ بعدها إطارات من نوع P لا تحمل إلا الفرق عن الإطار الذي قبلها، والمجموعة من إطار مفتاحي إلى الذي بعده تسمى مجموعة الصور Group of Pictures واختصاراً GOP، وفي إعدادات الكاميرا تجدها باسم I-Frame Interval. وفي كاميرا مراقبة ثابتة يكون أغلب المشهد ساكناً، فالإطار P صغير جداً، والإطار المفتاحي هو الذي يأخذ أغلب البايتات، لذلك كلما تقاربت الإطارات المفتاحية زاد الحجم. وفي المقابل لا يستطيع المسجل أو المشغل أن يبدأ عرض الفيديو إلا من إطار مفتاحي، فإذا كانت المسافة بينها عشر ثوان فقد تضغط على مقطع وتنتظر حتى تظهر الصورة، وقد شرحنا الفكرة من جهة البث في قسم GOP من مقال مفاهيم الفيديو، وسوف نقيس أثرها بالأرقام في التجربة.

كيف يطلب المسجل الفيديو من الكاميرا؟ RTSP وRTP وONVIF

هذا هو القسم الذي يقرر هل كاميرتك حرة أم مقيدة بمسجل شركتها، فالكاميرا التي تتكلم بروتوكولات مفتوحة تعمل مع أي برنامج، والتي لا تتكلمها تبقى مع تطبيق الشركة فقط، وهناك ثلاثة أسماء يجب أن تعرفها:

• بروتوكول RTSP: اختصار Real Time Streaming Protocol، وهو لغة التحكم بين المسجل والكاميرا، يطلب بها المسجل وصف البث ثم يجهز قناة النقل ثم يطلب البدء، تماماً كما تتحكم في مشغل فيديو، وقد عرف أول مرة في RFC 2326 سنة 1998، ثم جاء الإصدار الثاني في RFC 7826 في ديسمبر 2016، ومنفذه الافتراضي 554، وأغلب الكاميرات ما زالت تتكلم الإصدار الأول.
• بروتوكول RTP: اختصار Real-time Transport Protocol ومعرف في RFC 3550، وهو الذي يحمل الفيديو نفسه في حزم، فكل حزمة فيها رقم تسلسل وطابع زمني يرتب به المسجل الحزم ويعرف ما ضاع منها، ومعه بروتوكول RTCP الذي يرسل تقارير عن جودة النقل. وRTSP يتحكم، وRTP ينقل، والفرق مثل الفرق بين جهاز التحكم والشاشة.
• معيار ONVIF: معيار تضعه منظمة ONVIF حتى تتفاهم أجهزة الشركات المختلفة، ويغطي اكتشاف الكاميرا في الشبكة، وقراءة إعداداتها وتغييرها، وأحداثها، والتحكم في PTZ، وإعطاء المسجل عنوان RTSP الصحيح، ويقسم إلى ملفات Profiles، فصفحة Profile S تقول إنه للبث الأساسي وإن إيقافه جار وآخر موعد لتقديم منتجات جديدة للمطابقة عليه 31 مارس 2027، وصفحة Profile T تقول إنه للبث المتقدم ويشمل H.264 وH.265 وأحداث الحركة والعبث والبث عبر HTTPS.

والصورة التالية تبين جلسة RTSP كاملة بالترتيب، مع ما يسبقها من ONVIF، والقيم فيها من التجربة التي سوف نجريها بعد قليل:

في المخطط أعلاه لاحظ التالي:

• الاكتشاف في ONVIF يعتمد على معيار WS-Discovery، حيث يرسل البرنامج رسالة بحث إلى عنوان جماعي Multicast على المنفذ 3702، فترد الكاميرات الموجودة في نفس الشبكة، وهذا يعني أن الاكتشاف لا يعبر من شبكة إلى أخرى إذا عزلت الكاميرات في VLAN، وهذا ليس عيباً، فتضيف الكاميرا بعنوانها يدوياً.
• المسجل لا يحتاج ONVIF حتى يسجل، فيكفيه عنوان RTSP صحيح، وهذا ما يستخدمه Frigate، لذلك السؤال الأهم للمورد: هل تعطي الكاميرا بث RTSP، وما مساره للبث الرئيسي والفرعي؟
• الرد على DESCRIBE مكتوب بلغة وصف الجلسات SDP المعرفة في RFC 8866، وفيه نوع الضغط وإعدادات فك الضغط التي يحتاجها المسجل قبل أول إطار.
• RTSP العادي غير مشفر، وكلمة مرور الكاميرا تمر فيه، لذلك مكان الكاميرات شبكة معزولة لا يصل إليها إلا المسجل، وهذا موضوع مقال مخطط عن تأمين الكاميرات في مرحلة الكاميرات.

الخدمة السحابية P2P ورمز QR

وفي كثير من العروض سطر يقول «P2P» أو «Cloud» أو «مشاهدة من الجوال بمسح رمز QR»، ومعناه أن الكاميرا أو المسجل يفتح اتصالاً دائماً من داخل شبكتك إلى خوادم الشركة المصنعة، فيمر عبره الفيديو إلى تطبيق الهاتف دون أن تفتح أي منفذ في ال Router. وهذه الطريقة مريحة جداً، ولكنها تعني أن جهازاً يرى داخل بيتك أو مكتبك متصل طوال الوقت بخادم لا تعرف أين هو ومن يديره، وأن أمان تسجيلاتك صار مرتبطاً بأمان حسابك عند تلك الشركة. والبديل الذي ننصح به أن تعطل P2P وUPnP، وتصل إلى النظام من الخارج عبر شبكة خاصة VPN كما شرحنا في ما هو VPN؟، وتأكد قبل الشراء أن الكاميرا تعمل كاملة دون حساب سحابي، لأن بعض الكاميرات الرخيصة لا تكمل إعدادها الأول إلا عبر التطبيق.

الكهرباء والحماية: PoE وIP67 وIK10 والحرارة

هذه السطور لا تغير جودة الصورة، ولكنها تقرر هل تعمل الكاميرا بعد سنة في مكانها:

• التغذية عبر الشبكة PoE: اختصار Power over Ethernet، أي أن الكابل الواحد يحمل الكهرباء والبيانات من Switch يدعم PoE أو من منافذ المسجل نفسه، وتذكر وثائق Extreme Networks أن المعيار 802.3af أقصاه 15.4 واط و802.3at المعروف باسم PoE+ أقصاه 25.5 واط، والمعيار الأحدث 802.3bt أعلى منهما. والسؤال العملي هو استهلاك الكاميرا المكتوب في الورقة، مثل «max 6.5 W»، ثم مجموع استهلاك كل الكاميرات مقارنة بميزانية الطاقة PoE Budget في ال Switch، لأن ال Switch الذي فيه ثمانية منافذ PoE قد لا يغذيها كلها بأقصى استهلاك في نفس الوقت، وتذكر أن الإضاءة الليلية IR والسخانات ومحركات PTZ ترفع الاستهلاك في الليل.
• الحماية من الغبار والماء IP: رمز من رقمين يعرفه المعيار IEC 60529، الرقم الأول للحماية من الأجسام الصلبة والغبار، والثاني للحماية من الماء، فالكاميرا المكتوب عليها IP67 محكمة ضد الغبار وتتحمل الغمر المؤقت في الماء، وهذا ما تحتاجه أي كاميرا خارجية في بيئة يكثر فيها الغبار.
• الحماية من الصدمات IK: رمز من المعيار IEC 62262 يصف مقاومة الغلاف للضرب، والرقم الأعلى يعني مقاومة أكبر، وتراه في كاميرات Dome التي تركب في متناول اليد، مثل المداخل ومواقف السيارات.
• حرارة التشغيل Operating Temperature: مدى مثل «-30 إلى +60 درجة»، وهو رقم يستحق الانتباه إذا كانت الكاميرا ستعمل تحت شمس الصيف مباشرة، لأن حرارة الغلاف المعدني الأسود في الشمس أعلى بكثير من حرارة الجو.

التحليلات Analytics: من كشف الحركة إلى تصنيف الأجسام

أقدم تحليل وأرخصه هو كشف الحركة Motion Detection، ويقارن كل إطار بالذي قبله، فإذا تغير عدد كاف من البكسلات أطلق تنبيهاً، ومشكلته المعروفة أنه لا يفرق بين لص وظل شجرة أو قطة أو تغير الضوء عند الغروب، فتصلك عشرات التنبيهات في اليوم حتى تتجاهلها كلها. ثم جاءت قواعد أذكى قليلاً مثل عبور الخط Line Crossing ودخول منطقة Intrusion Detection، وهي ترسم خطاً أو منطقة في الصورة وتنبهك عندما يعبرها شيء. ثم جاء تصنيف الأجسام بالذكاء الاصطناعي Object Classification، حيث يشغل نموذج يفرق بين شخص وسيارة وحيوان، فيقل الإزعاج كثيراً، وقد يكون هذا النموذج داخل الكاميرا، وتكتبه الشركات بأسماء تجارية مثل «Human and Vehicle Detection»، أو داخل المسجل، أو على سيرفرك كما يفعل Frigate. وفوقها تحليلات متخصصة مثل قراءة لوحات السيارات LPR أو ANPR، وقد بنينا مشروعاً كاملاً بها في بوابة تفتح تلقائياً بقراءة لوحة السيارة، والتعرف على الوجوه الذي تحكمه قيود قانونية جدية في كثير من البلدان.

والسؤال الذي تسأله هنا: أين تعمل هذه التحليلات، وهل تصل أحداثها إلى برنامجك؟ فالتحليل داخل الكاميرا لا يستهلك شيئاً من سيرفرك، ولكن أحداثه قد لا تصل إلا إلى مسجل نفس الشركة، إلا إذا كانت الكاميرا تدعم إرسالها بمعيار مفتوح مثل أحداث ONVIF.

تجربة عملية: كاميرا وهمية نتكلم معها بالبروتوكول نفسه

الآن سوف نتحقق من كل ما سبق بأيدينا، دون أن نشتري كاميرا. والفكرة أن الكاميرا الشبكية من جهة الشبكة ليست إلا خادماً يتكلم RTSP ويرسل فيديو مضغوطاً بإعدادات معينة، لذلك نشغل خادم البث المفتوح المصدر MediaMTX، ونجعله ينشر ثلاثة ملفات فيديو في حلقة لا تنتهي، كل منها بإعدادات بث حقيقي من كاميرا: بث رئيسي بدقة 1920×1080 و15 إطاراً في الثانية بضغط H.264 بمعدل 4 ميجابت، وبث فرعي بدقة 640×360 و10 إطارات بمعدل 512 كيلوبت، وبث رئيسي آخر بضغط H.265 بمعدل 2 ميجابت. والفيديو هو أول 150 ثانية من تسجيل كاميرا مراقبة لموقف سيارات منشور في الملكية العامة، أي مشهد كاميرا حقيقي ثابت فيه سيارات تتحرك وأشخاص يمشون.

تجهيز الملفات

الكاميرا الحقيقية تضغط الفيديو بشريحة مخصصة داخلها، ثم ترسل ما ضغطته كما هو، لذلك نضغط الملفات مرة واحدة مقدماً بأداة ffmpeg، ثم ننشرها دون إعادة ضغط. أنشئ مجلداً اسمه media وضع فيه المقطع باسم parking.webm، ثم شغل الأمر التالي:

docker run --rm --name scv-encode -v "$PWD/media:/m" --entrypoint sh \
  bluenviron/mediamtx:1.21.1-ffmpeg -c '
cd /m
ffmpeg -v error -y -t 150 -i parking.webm -an -vf scale=1920:1080,fps=15 -c:v libx264 -preset medium \
  -profile:v main -bf 0 -g 30 -keyint_min 30 -sc_threshold 0 -b:v 4000k -maxrate 4000k -bufsize 8000k cam-main-h264.mp4
ffmpeg -v error -y -t 150 -i parking.webm -an -vf scale=640:360,fps=10 -c:v libx264 -preset medium \
  -profile:v main -bf 0 -g 20 -keyint_min 20 -sc_threshold 0 -b:v 512k -maxrate 512k -bufsize 1024k cam-sub-h264.mp4
ffmpeg -v error -y -t 150 -i parking.webm -an -vf scale=1920:1080,fps=15 -c:v libx265 -preset fast -tag:v hvc1 \
  -x265-params bframes=0:keyint=30:min-keyint=30:scenecut=0:vbv-maxrate=2000:vbv-bufsize=4000:log-level=error \
  -b:v 2000k cam-main-h265.mp4'

في الأوامر أعلاه لاحظ التالي:

• -g 30 مع 15 إطاراً في الثانية تعني إطاراً مفتاحياً كل ثانيتين في البث الرئيسي، و-g 20 مع 10 إطارات تعني الشيء نفسه في البث الفرعي، و-sc_threshold 0 يمنع ffmpeg من إضافة إطارات مفتاحية عند تغير المشهد، فتبقى المسافة ثابتة كما في الكاميرات.
• -bf 0 يلغي الإطارات من نوع B التي تعتمد على إطار بعدها، والسبب أن كاميرات المراقبة لا تستخدمها غالباً لأنها تضيف تأخيراً، وفي محاولتنا الأولى تركناها فظهرت في المسجل رسائل reference picture missing عند الالتحاق بالبث في منتصفه.
• -b:v مع -maxrate و-bufsize هي نفس فكرة معدل البت مع حد أعلى التي تجدها في صفحة إعدادات الكاميرا.
• ضغط H.265 على المعالج بطيء، فقد أخذ هذا الأمر على جهاز التجربة عدة دقائق للمقطع وحده، والكاميرا تفعل نفس العمل في الوقت الحقيقي بشريحتها، وهذا يبين لماذا لا يعيد المسجل ضغط الفيديو وإنما يحفظه كما يصله.

ثم ملف mediamtx.yml الذي يحول الملفات الثلاثة إلى كاميرا:

# A fake IP camera: three pre-encoded files of a public-domain parking-lot CCTV clip are read
# in a loop and published over RTSP without re-encoding (-c copy), the way a camera publishes
# what its encoder chip produced.
paths:
  main:
    runOnInit: ffmpeg -re -stream_loop -1 -i /samples/cam-main-h264.mp4 -c copy -f rtsp rtsp://localhost:8554/main
    runOnInitRestart: yes
  sub:
    runOnInit: ffmpeg -re -stream_loop -1 -i /samples/cam-sub-h264.mp4 -c copy -f rtsp rtsp://localhost:8554/sub
    runOnInitRestart: yes
  main265:
    runOnInit: ffmpeg -re -stream_loop -1 -i /samples/cam-main-h265.mp4 -c copy -f rtsp rtsp://localhost:8554/main265
    runOnInitRestart: yes

ولاحظ أن -re تجعل ffmpeg يرسل الملف بسرعته الطبيعية كأنه بث حي، و-stream_loop -1 تعيده من البداية كلما انتهى، و-c copy تنشره كما هو دون أي إعادة ضغط. ثم نشغل الكاميرا الوهمية على شبكة Docker خاصة، وننشر منفذها على 127.0.0.1 فقط:

docker network create scv-net
docker run -d --name scv-cam --network scv-net -p 127.0.0.1:19170:8554 \
  -v "$PWD/mediamtx.yml:/mediamtx.yml:ro" -v "$PWD/media:/samples:ro" \
  bluenviron/mediamtx:1.21.1-ffmpeg
docker logs scv-cam 2>&1 | grep -E "MediaMTX v|is publishing"

والمخرج سوف يكون كما يلي:

2026/10/28 09:14:24 INF MediaMTX v1.21.1, linux, amd64
2026/10/28 09:14:25 INF [RTSP] [session e1a53ef7] is publishing to path 'sub'
2026/10/28 09:14:25 INF [RTSP] [session c99835fc] is publishing to path 'main265'
2026/10/28 09:14:25 INF [RTSP] [session 2d90e441] is publishing to path 'main'

وإذا كنت تعمل على Windows مع Git Bash كما في جهاز التجربة، فضع MSYS_NO_PATHCONV=1 قبل أوامر docker التي فيها مسارات تبدأ ب /، واستخدم $(pwd -W) بدل $PWD، وإلا حول Git Bash المسار إلى مسار Windows قبل أن يصل إلى Docker.

نكتب جلسة RTSP بأيدينا

RTSP بروتوكول نصي يشبه HTTP، لذلك نستطيع أن نكتب طلباته بأيدينا ونرسلها بأداة nc ونقرأ الرد كما هو، دون أي برنامج مسجل. والسكربت التالي rtsp-talk.sh يرسل الطلب OPTIONS، ثم DESCRIBE للبث الرئيسي، ثم لبث H.265، ثم لمسار مكتوب خطأ:

# Speak RTSP by hand: OPTIONS, then DESCRIBE on the main stream, the H.265 stream and a misspelled path.
for req in "OPTIONS rtsp://scv-cam:8554/main" "DESCRIBE rtsp://scv-cam:8554/main" "DESCRIBE rtsp://scv-cam:8554/main265" "DESCRIBE rtsp://scv-cam:8554/mian"; do
  echo "### $req"
  printf '%s RTSP/1.0\r\nCSeq: 1\r\nAccept: application/sdp\r\n\r\n' "$req" | nc -w 2 scv-cam 8554 | tr -d '\r'
  echo
done

ونشغله من Container مؤقت على نفس الشبكة، فيصل إلى الكاميرا باسمها scv-cam كما يصل المسجل:

docker run --rm --name scv-probe --network scv-net -v "$PWD:/lab" --entrypoint sh \
  bluenviron/mediamtx:1.21.1-ffmpeg /lab/rtsp-talk.sh

والمخرج سوف يكون كما يلي:

### OPTIONS rtsp://scv-cam:8554/main
RTSP/1.0 200 OK
CSeq: 1
Public: DESCRIBE, ANNOUNCE, SETUP, PLAY, RECORD, PAUSE, GET_PARAMETER, TEARDOWN
Server: gortsplib


### DESCRIBE rtsp://scv-cam:8554/main
RTSP/1.0 200 OK
CSeq: 1
Content-Base: rtsp://scv-cam:8554/main/
Content-Length: 263
Content-Type: application/sdp
Server: gortsplib

v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 0.0.0.0
t=0 0
m=video 0 RTP/AVP 96
a=control:trackID=0
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1; profile-level-id=4D4028; sprop-parameter-sets=Z01AKNkAeAIn5cBagICAoAAAAwAgAAADA8HjBkk=,aOvMsg==

### DESCRIBE rtsp://scv-cam:8554/main265
RTSP/1.0 200 OK
CSeq: 1
Content-Base: rtsp://scv-cam:8554/main265/
Content-Length: 288
Content-Type: application/sdp
Server: gortsplib

v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 0.0.0.0
t=0 0
m=video 0 RTP/AVP 96
a=control:trackID=0
a=rtpmap:96 H265/90000
a=fmtp:96 sprop-pps=RAHBcrQiQA==; sprop-sps=QgEBAWAAAAMAkAAAAwAAAwB4oAPAgBDllkqSTK8BagICAggAAAMACAAAAwB4QA==; sprop-vps=QAEMAf//AWAAAAMAkAAAAwAAAwB4koCQ

### DESCRIBE rtsp://scv-cam:8554/mian
RTSP/1.0 400 Bad Request
CSeq: 1
Server: gortsplib

في المخرج أعلاه لاحظ التالي:

• الرد على OPTIONS يعدد الطلبات التي يفهمها الخادم في السطر Public، والرقم CSeq رقم تسلسل يعيده الخادم كما أرسلناه، فيعرف به المسجل أي رد يخص أي طلب، تماماً كما في RFC 2326. والسطر Server: gortsplib هو اسم مكتبة RTSP داخل MediaMTX، والكاميرا الحقيقية تكتب هنا اسم برنامجها أحياناً، وهذه معلومة يقرؤها المخترق أيضاً.
• الرد على DESCRIBE هو وصف SDP، والسطر m=video 0 RTP/AVP 96 يقول إن هناك مساراً واحداً للفيديو ينقل عبر RTP برقم نوع حمولة ديناميكي 96، والسطر a=rtpmap:96 H264/90000 يقول إن هذا الرقم يعني H.264 بساعة 90 ألف نبضة في الثانية تحسب بها الطوابع الزمنية لكل إطار.
• السطر a=fmtp يحمل إعدادات فك الضغط مشفرة بصيغة Base64، فقيمة profile-level-id=4D4028 تعني H.264 بملف Main ومستوى 4.0، كما تشرح RFC 6184، وsprop-parameter-sets هي إعدادات SPS وPPS التي يحتاجها المسجل قبل أن يفك أول إطار.
• بث H.265 يصف نفسه بالسطر H265/90000، ويحمل ثلاث مجموعات إعدادات VPS وSPS وPPS كما تعرفها RFC 7798، فإذا كان المسجل أو المتصفح لا يدعم H.265 فهذا هو السطر الذي يكشف السبب.
• المسار المكتوب خطأ /mian أعطى 400 Bad Request، وكاميرات أخرى تعطي 404 Not Found لنفس الخطأ، أما الخطأ في كلمة المرور فيعطي 401 Unauthorized، لذلك رمز الرد أول شيء تقرؤه عندما لا يظهر الفيديو.

وبعد DESCRIBE يرسل أي مسجل حقيقي SETUP ليتفق مع الكاميرا على طريقة النقل، إما حزم UDP على منافذ منفصلة، أو داخل نفس اتصال TCP بطريقة تسمى Interleaved، ثم PLAY لتبدأ حزم RTP بالتدفق، وهذا ما يفعله ffprobe وffmpeg في الخطوة التالية. واختيار TCP أكثر ثباتاً عبر شبكات فيها فقد للحزم أو جدار ناري Firewall بين المسجل والكاميرا، ولذلك تجد خياراً مثل -rtsp_transport tcp في ffmpeg وفي إعدادات أغلب المسجلات.

نقيس البثوث الثلاثة كما يقيسها المسجل

الآن نفعل ما يفعله أي مسجل: نسأل كل بث عن نفسه بأداة ffprobe، ثم نسجل دقيقة من كل بث دون إعادة ضغط بالخيار -c copy، ثم نقيس الحجم ومعدل البت ونعد الإطارات بحسب نوعها. السكربت measure.sh:

# 1) What does each stream say about itself?  2) Record 60 s of each stream as an NVR would (-c copy),
# then measure size, bitrate and the distance between key frames (I-frames).
cd /work
for s in main sub main265; do
  echo "### ffprobe $s"
  ffprobe -v error -rtsp_transport tcp -show_entries stream=codec_name,profile,width,height,avg_frame_rate -of default=nw=1 rtsp://scv-cam:8554/$s
done
for s in main sub main265; do
  ffmpeg -v error -y -rtsp_transport tcp -i rtsp://scv-cam:8554/$s -t 60 -c copy rec-$s.mp4 &
done
wait
for s in main sub main265; do
  echo "### rec-$s.mp4"
  ffprobe -v error -show_entries format=duration,size,bit_rate -of default=nw=1 rec-$s.mp4
  ffprobe -v error -select_streams v:0 -show_entries frame=pict_type -of csv=p=0 rec-$s.mp4 | sort | uniq -c
done

mkdir -p work
docker run --rm --name scv-probe --network scv-net -v "$PWD:/lab" -v "$PWD/work:/work" \
  --entrypoint sh bluenviron/mediamtx:1.21.1-ffmpeg /lab/measure.sh

والمخرج سوف يكون كما يلي، وقد اختصرنا رسائل التحذير المتكررة في البث الثالث إلى أول سطرين منها:

### ffprobe main
codec_name=h264
profile=Main
width=1920
height=1080
avg_frame_rate=15/1
### ffprobe sub
codec_name=h264
profile=Main
width=640
height=360
avg_frame_rate=10/1
### ffprobe main265
codec_name=hevc
profile=Main
width=1920
height=1080
avg_frame_rate=15/1
### rec-main.mp4
duration=58.800000
size=27032661
bit_rate=3677913
     24 I
    779 P
### rec-sub.mp4
duration=58.900000
size=3791026
bit_rate=514910
     30 I
    558 P
### rec-main265.mp4
duration=56.800000
size=13940656
bit_rate=1963472
[hevc @ 0x7f579554c900] Could not find ref with POC 13
[hevc @ 0x7f579554c900] Error constructing the frame RPS.
     27 I
    736 P

في المخرج أعلاه لاحظ التالي:

• ffprobe عرف الدقة وعدد الإطارات والضغط لكل بث دون أن نخبره بشيء، وهذه هي الخطوة الأولى مع أي كاميرا حقيقية قبل أن تضيفها إلى أي مسجل، فإذا لم يعمل ffprobe مع عنوانها فلن يعمل أي برنامج آخر.
• البث الرئيسي سجل 27.03 ميجابايت في 58.8 ثانية، أي 3.68 ميجابت في الثانية، وهو أقل قليلاً من 4 ميجابت التي ضبطناها لأن المشهد ساكن في أغلبه، وبهذا المعدل تأخذ الكاميرا الواحدة قرابة 39.7 جيجابايت في اليوم من التسجيل المستمر.
• البث الفرعي 0.51 ميجابت في الثانية، أي قرابة 5.6 جيجابايت في اليوم، أي سبع البث الرئيسي تقريباً، وهذا هو سبب استخدامه للعرض والتحليل.
• بث H.265 بنفس الدقة والإطارات أعطى 1.96 ميجابت في الثانية، أي قرابة 21.2 جيجابايت في اليوم، وهو نصف H.264 لأننا ضبطناه بنصف المعدل، والسؤال الحقيقي هو هل الجودة متساوية، وهذا ما سوف نقيسه في المقال القادم عن تخزين التسجيلات.
• في البث الفرعي 30 إطاراً مفتاحياً في 58.9 ثانية، أي إطار كل ثانيتين كما ضبطناه بالضبط، وفي البث الرئيسي 24 إطاراً مفتاحياً و779 إطاراً من نوع P ولا يوجد أي إطار B، وهذا يعني أن 97% من الإطارات ليست صوراً كاملة.
• رسائل Could not find ref في بث H.265 سببها أن التسجيل بدأ في منتصف مجموعة صور، فالإطارات الأولى من نوع P تشير إلى إطار مفتاحي لم يصل إلينا، ولا يمكن فكها حتى يأتي الإطار المفتاحي التالي، وهذا ما يحدث في كل مسجل عند بداية كل تسجيل، ولذلك يحتفظ المسجل الجيد بثوان قبل الحدث Pre-capture حتى لا تضيع بداية المقطع.

ماذا يحدث إذا قربنا الإطارات المفتاحية؟

الآن نجرب الإعداد الذي لا يذكره أحد في عرض السعر، فنأخذ نفس الستين ثانية من المقطع ونضغطها ثلاث مرات بنفس الدقة والإطارات ونفس الجودة المستهدفة، أي ضغط بجودة ثابتة CRF 23 كما يفعل VBR في الكاميرات، ولا نغير إلا المسافة بين الإطارات المفتاحية: نصف ثانية، ثم ثانيتين، ثم خمس ثوان. السكربت gop.sh:

# Same 60 s of the parking-lot clip, same quality target (CRF 23, 1080p, 15 fps, no B-frames);
# only the distance between key frames (GOP) changes: 0.5 s, 2 s, 5 s.
cd /work
for g in 8 30 75; do
  ffmpeg -v error -y -t 60 -i /samples/parking.webm -an -vf scale=1920:1080,fps=15 \
    -c:v libx264 -preset veryfast -bf 0 -crf 23 -g $g -keyint_min $g -sc_threshold 0 gop-$g.mp4
  kbps=$(ffprobe -v error -show_entries format=bit_rate -of csv=p=0 gop-$g.mp4)
  iframes=$(ffprobe -v error -select_streams v:0 -show_entries frame=pict_type -of csv=p=0 gop-$g.mp4 | grep -c I)
  printf 'GOP %3d frames (%.1f s): %5d kbps, %3d I-frames, %5.1f GB per day\n' $g $(echo "$g/15" | bc -l) $((kbps/1000)) $iframes $(echo "$kbps*86400/8/1000000000" | bc -l)
done

docker run --rm --name scv-gop -v "$PWD:/lab" -v "$PWD/work:/work" -v "$PWD/media:/samples:ro" \
  --entrypoint sh bluenviron/mediamtx:1.21.1-ffmpeg /lab/gop.sh

والمخرج سوف يكون كما يلي:

GOP   8 frames (0.5 s):  4581 kbps, 113 I-frames,  49.5 GB per day
GOP  30 frames (2.0 s):  2366 kbps,  30 I-frames,  25.6 GB per day
GOP  75 frames (5.0 s):  1820 kbps,  12 I-frames,  19.7 GB per day

والصورة التالية تبين النتيجة مع فكرة الإطارات نفسها:

في المخرج أعلاه لاحظ التالي:

• الانتقال من إطار مفتاحي كل ثانيتين إلى إطار كل نصف ثانية رفع معدل البت من 2366 إلى 4581 كيلوبت، أي قرابة الضعف، دون أي تحسن في الصورة، والسبب أن كل إطار مفتاحي صورة كاملة، وفي مشهد ساكن كهذا تكون الإطارات P صغيرة جداً، فيصبح عدد الإطارات المفتاحية هو الذي يحدد الحجم.
• الانتقال إلى إطار كل خمس ثوان وفر 23% أخرى فقط، أي أن الفائدة تقل كلما ابتعدت الإطارات، بينما الثمن يزيد: فالمسجل لا يبدأ التسجيل ولا القفز في الفيديو إلا من إطار مفتاحي، وإذا تلفت حزمة في الطريق بقي أثرها ظاهراً حتى الإطار المفتاحي التالي.
• القيمة المعقولة لأغلب الكاميرات أن تكون المسافة بين ثانية وثانيتين، أي أن يكون I-Frame Interval مساوياً لعدد الإطارات في الثانية أو ضعفه، وإذا وجدت كاميرا مضبوطة على إطار مفتاحي في كل ثانية ب 30 إطاراً وأنت لا تحتاج إلا 15، فالتعديل وحده قد يوفر جزءاً كبيراً من القرص.
• هذه أرقام مشهد واحد ثابت نسبياً، والمشهد المزدحم بالحركة يغير النسب، لأن الإطارات P فيه تكبر، وهذا ما سوف نقيسه بالتفصيل في مقال تخزين التسجيلات.

حذف التجربة

docker rm -f scv-cam
docker network rm scv-net
rm -rf work

ورقة المواصفات Datasheet سطراً سطراً

بعد كل ما سبق نستطيع أن نقرأ ورقة مواصفات كاملة، والصورة التالية مثال يجمع السطور الشائعة في أوراق كاميرات 4MP، مع معنى كل سطر لك:

وفي الورقة أعلاه لاحظ ثلاثة أمور: أن الدقة والعدسة سطران منفصلان ولكنهما يجيبان معاً عن سؤال واحد هو كثافة البكسل عند الهدف، فلا تقرأ أحدهما دون الآخر، وأن مدى IR ومدى الرؤية ليسا شيئاً واحداً، وأن سطر Protocols هو الذي يقرر هل تبقى هذه الكاميرا معك إذا غيرت المسجل، فإذا لم تجد فيه RTSP أو ONVIF فاسأل عنه قبل أي شيء آخر.

أخطاء شائعة عند قراءة العروض

• اختيار الكاميرا بالميجابكسل فقط، ثم وضعها بعدسة 2.8 ملم على بعد 15 متراً من البوابة، فلا تعطي وجهاً ولا لوحة، والحل أن تحسب كثافة البكسل عند المكان الذي يهمك.
• اعتبار مدى IR مدى للتعرف، فالكاميرا المكتوب عليها 30 متراً قد تضيء الشخص على 30 متراً، ولكنها لا تعطيك وجهه إلا على مسافة أقصر بكثير.
• ترك الإعدادات الافتراضية للإطارات والإطار المفتاحي، فقد تأتي الكاميرا ب 25 أو 30 إطاراً في الثانية وإطار مفتاحي متقارب، وتحتاج قرصاً بحجم ضعف ما تحتاجه فعلاً.
• شراء كاميرات تعمل عبر التطبيق والسحابة فقط، ثم اكتشاف أنها لا تعطي بث RTSP عندما تريد الانتقال إلى مسجل مفتوح.
• الاعتماد على كشف الحركة وحده، فتصل عشرات التنبيهات الكاذبة في اليوم، ويتجاهل الجميع التنبيه الحقيقي الوحيد.
• حساب ميزانية PoE على استهلاك النهار، فتنطفئ بعض الكاميرات في الليل عندما تعمل الإضاءة IR في كل الكاميرات معاً.

الأسئلة التي ترسلها للمورد قبل أن توقع

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• نظام المراقبة أربعة أجزاء: الكاميرا والشبكة والمسجل والمشاهدة، وكل سطر في العرض ينتمي إلى واحد منها، والكاميرات الشبكية IP مع بروتوكول مفتوح تبقى صالحة إذا غيرت المسجل.
• الدقة لا تكفي وحدها، والسؤال الصحيح هو كثافة البكسل عند الهدف: 25 بكسلاً للمتر للاكتشاف، و62 للمراقبة، و125 للتمييز، و250 للتحقق من الهوية، وكاميرا 1920 بكسلاً لا تعطي الهوية إلا في مشهد عرضه 7.7 أمتار تقريباً.
• العدسة تحدد عرض المشهد، فالعدسة 2.8 ملم للصورة العامة، والعدسة الأضيق للنقطة التي يمر منها كل شخص، ومدى IR ليس مدى التعرف.
• الإطارات في الثانية والضغط ومعدل البت والمسافة بين الإطارات المفتاحية هي التي تحدد المساحة، وفي تجربتنا ضاعف تقريب الإطارات المفتاحية من ثانيتين إلى نصف ثانية معدل البت دون أي فائدة.
• RTSP يطلب الفيديو، وRTP يحمله، وONVIF يكتشف الكاميرا ويضبطها، والمسجل يحتاج RTSP فقط، وRTSP العادي غير مشفر فمكان الكاميرات شبكة معزولة.
• اسأل المورد الأسئلة في الجدول أعلاه قبل التوقيع، وخاصة سؤال RTSP والعمل دون سحابة.

وفي المقالات القادمة من مرحلة الكاميرات بإذن الله نحسب التخزين وعدد الأيام من قياسات حقيقية، ثم نتكلم عن الخصوصية والأنظمة، وتأمين الكاميرات، والمقارنة بين برامج التسجيل المفتوحة. وأقرب المقالات إلى هذا الموضوع على الموقع:

دليلأنواع كاميرات المراقبة وكيف تختار بينهاما الفرق بين أنواع كاميرات المراقبة، وما الذي تحتاجه في الكاميرا حتى تسجلها على جهازك، وكم قرصاً تحتاج للتسجيلات.دليلFrigate: تسجيل كاميرات المراقبة على سيرفرك مع كشف الأجسامكيف تثبت Frigate على سيرفرك، وتسجل به كاميرات المراقبة محلياً، ويكشف لك الأشخاص والسيارات دون أن يخرج الفيديو من بيتك.دليلمفاهيم الفيديو: الحاوية والترميز Codec ومعدل البتما الذي يحدد حجم ملف الفيديو وجودته، ولماذا يعمل ملف في متصفح ولا يعمل في آخر، مع تجربة حقيقية تقيس الفرق بين الترميزات.دليلكيف يعمل بث الفيديو المباشر وعند الطلب؟كيف يصل الفيديو إلى كل مشاهد بجودة تناسب سرعة اتصاله، ولماذا يتأخر البث المباشر عشرين ثانية أحياناً وأقل من ثانية أحياناً أخرى.دليلتقسيم الشبكة Network Segmentation بال VLAN وال VPCلماذا تصل كاميرا مخترقة إلى قاعدة بياناتك، وكيف تمنع ذلك بتقسيم الشبكة إلى مناطق لا يمر بينها إلا ما تسمح به.دليلبوابة تفتح تلقائياً بقراءة لوحة السيارة: مشروع عمليكيف تبني بوابة لمجمع سكني أو شركة تقرأ لوحة السيارة وتفتح للمصرح لهم، مع شاشة للحارس وسجل لكل دخول.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، وتنفيذ التجربة العملية على MediaMTX 1.21.1 وffmpeg 8.1.2 وDocker Engine 29.8.0 بمقطع موقف السيارات في الملكية العامة.