نحن بحاجة إلى أجهزة, لتلقي المعلومات حول مقاطع فيديو كاميرا Full HD مع SDI (واجهة البيانات التسلسلية) على الخط وترميز المعلومات بمعيار H.265. يجب إرسال البيانات المضغوطة إما عبر نظام DVB-T (بث الفيديو الرقمي الأرضي) أو معيار DVB-S. يمكن للإخراج التناظري للوحدة المصممة قبول إشارات I وQ, وكذلك الإشارات المعدلة.
جدول المحتويات
س: هل يدعم جهاز تشفير الفيديو SDI إدخال TSI؟ / انتاج |?

ا: تقوم لوحة التشفير الموجودة لدينا إلى لوحة التعديل بنقل البيانات عبر منفذ الشبكة. بدلاً من واجهة TSI التي ذكرتها. وهذا لا يؤثر على استخدام جهاز الإرسال لجهاز الاستقبال. هذه هي الواجهة الداخلية لجهاز الإرسال.
س: هل تدعم لوحات فك التشفير الخاصة بك 525 i50 ل 1080 P60 على تنسيق الفيديو?
ا: الآن تدعم لوحات تشفير الفيديو SDI الخاصة بنا الدقة العالية: 720p @ 23.98 هرتز/24 هرتز/25 هرتز/29.97 هرتز/30 هرتز/ 50 هرتز59.94 هرتز/60 هرتز و1080 بكسل عند 23.98 هرتز/24 هرتز/25 هرتز/29.97 هرتز/30 هرتز/50 هرتز/59.94 هرتز/60 هرتز. لا يدعم 525 تنسيق الفيديو i50, هل الامور على ما يرام؟
س: هل يدعم جهاز SDI COFDM DVB-T H265 SDI Encoder RF طاقة الإخراج 0 ~ 10dBm?

ا: نقطة تردد الإخراج الخاصة بك من 400 ميجا هرتز إلى 2800 ميجا هرتز المطلوبة واسعة جدًا.
من الصعب تحقيق إخراج يتراوح بين 0 إلى 10 ديسيبل في ظل نقطة التردد الواسعة هذه, وستؤدي إضافة مضخم الطاقة على اللوحة إلى زيادة استهلاك الطاقة والحرارة (لقد ذكرت أيضًا أنه ليست هناك حاجة لمروحة لتبديد الحرارة).
هل أنت على استعداد للموافقة على القائمة لدينا -3 إلى إخراج -10 ديسيبل ثم قم بإضافة السلطة الفلسطينية الخاصة بك (السلطة مكبر للصوت)?
س: ما هو أبعاد جهاز التشفير COFDM DVB-T H265 SDI؟?

هل لديك طلب البعد الخاص? حجمنا الحالي هو 70x45 ملم.
ا: يمكن للوحات تشفير وفك تشفير الفيديو الموجودة لدينا أن تلبي احتياجات مشروعك.
أكبر ما يقلق مهندسي هو أن شركتك, كعضو في صناعة البث والتلفزيون لديها متطلبات عالية نسبيًا لجودة صورة الفيديو.
ستقوم لوحة ترميز الفيديو الخاصة بنا بإجراء ضغط مع فقدان البيانات من أجل زمن وصول منخفض. هل يمكن أخذ مجموعة من العينات الموجودة لاختبارها والتأكد من جودة الصورة? إذا كنت تعتقد أن عيناتنا يمكن أن تلبي متطلبات شركتك, سنقوم بإعادة تصميم ورسم اللوحة وفقًا لمتطلبات شركتك.

س: هل يمكنك تقديم المزيد من المعلومات حول VBR?
من خلال تطبيق الفيديو على TX, ستتغير معلمة VBR بمرور الوقت وهي ليست قيمة ثابتة. هل يمكنك تقديم المزيد من المعلومات حول هذا الأمر?
ا: VBR هو معدل بت ترميز الفيديو عند جهاز الإرسال. منذ أن تتغير صورة الفيديو ديناميكيًا, VBR متغير بالطبع, ولكنه يتقلب حول معدل بتات التشفير الذي يحدده نظام النقل: 7.81*0.8=6.248 ميجابت في الثانية.
س: على الرغم من وجود وحدة تخزين فلاش على جهاز الاستقبال الخاص بي, يتم عرض REC OFF وNo Storage على الشاشة. لماذا يحدث هذا؟?
قلت في الوصف: Key2: زر التبديل لتسجيل الفيديو, اضغط لفترة قصيرة لتغيير حالته. سيقوم جهاز الاستقبال بفحص جهاز التخزين تلقائيًا (بطاقة SD الصغيرة أو قرص USB, بطاقة SD ذات الأولوية) بعد التشغيل والبدء في تسجيل الفيديو عند إدخال جهاز التخزين. فقط اضغط على الزر للتوقف أو التسجيل مرة أخرى.
ا: فشل نظام الاستقبال في اكتشاف محرك أقراص فلاش USB. يجب تهيئة محرك أقراص فلاش USB بتنسيق يمكن لنظامنا التعرف عليه.
س: كل من B1 وB2 يساوي صفرًا. وهذا يدل على وجود أ 0 % معدل الخطأ في اللدغة!!! أي نطاق من هذه المعلمات مقبول?
ا: قد يؤدي حدوث معدل خطأ بت إلى حدوث مشكلات في صورة الفيديو. عندما يكون معدل خطأ البت صغيرًا جدًا, لن يؤثر على تأثير صورة الفيديو.

س: هل يمكنني تخصيص محتويات شاشة المبرمج?
ا: محتوى عرض لوحة التكوين (مبرمج) ليست مفتوحة للعملاء للتعديل.
س: لماذا لا تتم برمجة قناة S2? يبدو أن الموالف الثاني لا يعمل في الوقت الراهن.
ا: يشير S2 إلى هوائي الاستقبال 2, والتي يمكن أن تعمل بشكل طبيعي. التردد وعرض النطاق الترددي نفس S1 و S2.
س: لماذا الكمون الذي حسبته ضخم? إنه موجود 470 الآنسة.
في وصفك القادمة: يمكن إقران الميزات العادية الافتراضية لوحدة الاستقبال لدينا مع وحدة الإرسال H.265 الخاصة بنا. يبلغ زمن وصول الفيديو عالي الدقة من إدخال جهاز الإرسال إلى شاشة عرض جهاز الاستقبال HDMI حوالي 200 مللي ثانية إلى 250 مللي ثانية.
ا: كان التأخير الذي اختبرناه حوالي 250 مللي ثانية. كيف اختبرته? طريقة التأخير التي اختبرناها, يرجى التحقق من رابط الفيديو يوتيوب.
س: ما مقدار زمن الوصول الذي يتمتع به جهاز إرسال تشفير SDI ووحدة استقبال وحدة فك التشفير?
أتذكر أنك قلت أنك قمت بتحسين البروتوكول لتحسين زمن الوصول. لأنني لا أستخدم زمن الاستجابة السريع H.264 (130 الآنسة) ما مقدار زمن الوصول الذي يجب أن يكون لدينا في الإعداد الخاص بي؟?
ا: لقد أكدت أنك بحاجة إلى دعم H265, ولكن ليس وضع الكمون المنخفض H264. لتحقيق وضع الكمون المنخفض, يجب تغيير جهاز الاستقبال إلى جهاز استقبال آخر, ويجب حرق البرامج الثابتة المقابلة قبل الشحن.
س: هل يمكنني استخدام جهاز استقبال COFDM الخاص بك للحصول على قناة تلفزيون DVB-T العادية؟?
لقد قلت أنك قمت بتغيير بروتوكول الفيديو لتحسين زمن الوصول في تكساس. هل يمكنني استخدام RX الخاص بك باعتباره DVB-T تجاريًا? كيف يمكنني استقبال قناة DVB-T العادية?
ا: إذا كنت ترغب حقًا في استخدامه كمستقبل عادي DVB-T, علينا ترقية البرامج الثابتة الأخرى. (قم بإزالة التشفير الموجود على جهاز التشفير وفك التشفير على جهاز فك التشفير).
س: كيف يمكنني استخدام وظيفة قائمة OSD الخاصة بك على جهاز استقبال COFDM?
في وصفك القادمة:
تتضمن وحدة الاستقبال أيضًا وظيفة تسجيل DVR باستخدام بطاقة Micro SD أو قرص USB. تتيح وحدة الاستقبال أيضًا بث الفيديو عبر USB لأجهزة فك تشفير أجهزة Android عن بعد مثل الهواتف الذكية أو Android PAD. يتيح ذلك للعديد من المشاهدين عن بعد مراقبة نفس الفيديو
معًا. تدعم وحدة الاستقبال أيضًا سلسلة أحرف العرض على شاشة عرض الفيديو مع الفيديو معًا في وضع OSD.
ا: نرى OSD الوثائق عبر الإنترنت.
س: كيف يمكنني تشغيل تشفير AES؟? أين يجب أن أدخل المفتاح?
ا: يمكن لجنة التكوين تحرير كلمة المرور وتغييرها.
س: أشر إلى سؤال صورة النص القوس:

ا: هذه الوظيفة الاختيارية مطلوبة بواسطة منتجات أخرى (يتم استخدام وظيفة منفذ الشبكة للاتصال برابط لاسلكي ثنائي الاتجاه). الرجاء تجاهله في طلبك.
س: ما هو التأخير الزمني لبيانات UART على الإرسال أحادي الاتجاه؟?
لبيانات UART من TX إلى RX, هي البيانات التي تتم معالجتها من خلال عملية الترميز أو تنتقل في الوقت الفعلي? أنا بحاجة إلى نقل البيانات في الوقت الفعلي.

ا: يتم إرسال البيانات والفيديو معًا عبر حزمة COFDM اللاسلكية. لذا فإن التأخير هو نفسه كما هو الحال مع الفيديو.
س: للارسال. من الممكن تغيير GI وFEC ومعلمة أخرى وفقًا لجدولك في الوصف?
ا: نعم فعلا.
س: ما هي القوة الدقيقة في هذه المرحلة من 1350 إلى 1450 ميغاهيرتز? أحتاج إلى هذه المعلومات لتصميم PA.
الحد الأقصى للإخراج من نطاق التردد 1350 ~ 1450 حوالي -10 ± 2DBM. يوصى بتصميم السلطة الفلسطينية بناءً على إدخال -15dbm. يمكن ضبط جهاز الإرسال الخاص بنا إلى -15dbm.
س: هل لدى المبرمج الخاص بك وظيفة إعادة ضبط استعادة المصنع?
إذا قمت بتغيير أي معلمات من أي جانب مثل التردد GI أو FEC أو عرض نطاق الفيديو, كيف يمكنني إعادة تعيين كافة المعلمات في وضع المصنع? أنا جديد في هذا المجلس, وأحتاج إلى تغيير بعض المعايير لتحقيق رغبتي. لكنني أخشى تغيير الأجزاء الافتراضية من المعلومات.
ا: لدينا تكساس / لا يحتوي مبرمج RX على ميزة إعادة ضبط المصنع.
س: هل يدعم جهاز تشفير إدخال الفيديو SDI 1080i25/1080i30?
وهو يدعم 1080i50 و1080i60, لا يدعم 1080i25 أو 1080i30.
س: هل يمكنك أن تقدم لي بعض الملفات الفنية لإصلاح جزء الطاقة من VCAN1731 SDI لوحة تشفير الفيديو?
ا: يرجى التحقق من الملفات على الرابط أدناه.
- https://ivcan.com/wp-content/uploads/Vcan1731-Component-Part-Number-Map-1.pdf
- https://ivcan.com/wp-content/uploads/Vcan1731-Component-Part-Number-Map-2.pdf
- https://ivcan.com/wp-content/uploads/vcan1731_A01_power.pdf
فكرة الصيانة الخاصة بنا هي استبعاد ما إذا كان هناك دائرة قصيرة وحيث تكون الدائرة القصيرة. فمثلا, افصل المقاوم المغناطيسي أو مقاوم 0-أوم بين IC الكهربائي والدائرة اللاحقة, ثم استخدم مقياس متعدد لقياس ما إذا كانت الطاقة IC مكسورة أو أن الدائرة اللاحقة معقولة. إذا تم كسر Power IC, استبدل Power IC; إذا كانت الدائرة اللاحقة قصيرة الدائرة, عليك التحقق من الدائرة اللاحقة.
س: Can the encoder board receive and forward UART data through UDP communication (IP:ميناء)?
ا: نعم فعلا, UART data transmission is supported under our default custom protocol, with some important considerations:
1. البروتوكول المخصص (Default Firmware)
Our default shipping firmware uses a custom multiplexed protocol that supports UART transparent transmission (serial passthrough).
- UART data is multiplexed together with audio/video streams.
- وبالتالي, the receiving side must use the corresponding custom protocol demux library to separate UART data from the media stream.
- When used together with our decoder board, UART transparent transmission works properly and can be forwarded/received as expected.
Note for PC Players
Our current PC player software only demuxes and processes:
- Video data
- البيانات الصوتية
في الوقت الحاضر, إنه كذلك ليس process or output UART serial data.
2. Standard MPEG-TS Protocol
If the encoder board is flashed with the standard MPEG-TS firmware/protocol:
- Only audio and video streams are supported.
- UART/serial data transmission is غير معتمد under MPEG-TS mode.
Please take this into consideration when selecting the firmware/protocol solution.
| Protocol Type | الصوت / الفيديو | UART Transparent Transmission |
|---|---|---|
| البروتوكول المخصص (افتراضي) | أيد | أيد |
| Standard MPEG-TS | أيد | Not Supported |
س: Do you have firmware that supports raw H.264 or RTP instead of MPEG-TS for UDP streaming?
ا: Our UDP firmware does not transmit raw H.264 elementary streams. UDP streaming is supported in two formats depending on firmware version:
- ا custom proprietary format, أو
- ال standard MPEG-TS (MPEG Transport Stream) شكل
These correspond to different firmware builds (typically distinguished by a suffix such as “T” or non-“T” versions).
س: Do you support RTP as a standalone streaming protocol?
ا: We do not provide a separate “raw RTP streaming mode.” However, RTP is already used internally within RTSP streaming. In RTSP mode, audio and video are transmitted over RTP packets as part of the RTSP/RTP/RTCP stack. وبالتالي, RTP is supported indirectly through RTSP rather than as an independent UDP streaming format.
س: Can the system output raw H.264 over UDP?
ا: لا. Raw H.264 elementary stream transmission is not supported over UDP. This is due to packet size and network constraints. A single I-frame can be very large and cannot be reliably transmitted in a single IP packet.
For stable transmission, video streams must be encapsulated using a transport format such as:
- مبيغ-TS, أو
- RTP (via RTSP)
س: How is the key frame (الحزب الجمهوري) interval configured?
ا: The key frame interval is controlled by the GOP parameter في واجهة الويب (video settings page).
- If GOP is set to 0 (default/auto mode), the system automatically aligns the I-frame interval with the input frame rate.
- مثال: If the input is 1080P60, then the I-frame interval will be 60 إطارات (1 second GOP).
This ensures adaptive encoding behavior based on input source characteristics.
س: Why can’t raw H.264 be transmitted directly over IP/UDP?
ا: Because H.264 frames (especially I-frames) can be very large and exceed the maximum transmission unit (رجل) of network packets. Without encapsulation, reliable delivery cannot be guaranteed. وبالتالي, video must be packetized using standardized streaming formats such as MPEG-TS or RTP for proper segmentation, توقيت, and reassembly.
س: My system latency is ~230 ms total. Decoder and display take ~45 ms, leaving ~185 ms for camera and encoder. I expect the camera contributes ~60 ms (4 frames at 60 إطارا في الثانية), so the encoder seems to be ~120 ms. Is there a way to reduce encoder latency? I understand MPEG-TS mainly affects decoding, not encoding.
ا: Latency Breakdown and Optimization Guidance
To accurately optimize system latency, it is important to first validate each stage independently before assuming bottlenecks.
1. Verify Camera Latency First (Critical Step)
Before optimizing encoding, you should confirm the actual camera contribution.
A practical measurement method:
- Connect the camera HDMI output directly to a display
- Point the camera at a high-precision stopwatch displayed on a separate PC monitor
- Capture both the live scene and HDMI output simultaneously
- Compare frame timestamps to calculate end-to-end camera latency
ملحوظات:
- Use a high-precision stopwatch (smaller tick interval improves accuracy)
- Camera ISP processing is often a major contributor
- In our experience:
- 1080p cameras typically introduce ~100 ms latency
- Some models may exceed this due to heavier ISP pipelines
2. Camera Configuration Has a Major Impact
If camera latency is high, optimization should start there:
- دقة أقل (على سبيل المثال, 720p vs 1080p) → reduces ISP and pipeline delay
- Higher frame rate (على سبيل المثال, 60 fps vs 30 إطارا في الثانية) → reduces frame buffering latency
- Simpler image processing pipeline → reduces ISP load
These changes often reduce latency more effectively than encoder tuning.
3. Encoder Latency Is Likely Overestimated
ا 120 ms encoding delay is generally unlikely for typical hardware encoders.
Based on internal measurements:
- A hardware encoder + فك + انتقال + display pipeline over Ethernet typically results in:
- ~80–100 ms total end-to-end latency
This implies:
- Encoder-only latency is significantly lower than 120 الآنسة
- Encoding is usually not the dominant contributor in a properly configured system
4. Transmission Method Matters (Especially Wireless)
Please verify whether the system uses:
- إيثرنت السلكية
- الإرسال اللاسلكي
If wireless is used:
- Low bandwidth (<20 ميغابت في الثانية) can introduce significant delay
- Large I-frame transmission may cause buffering and queueing delays
- This can noticeably increase end-to-end latency even if encoding is efficient
5. MPEG-TS and Protocol Overhead Clarification
Your understanding is generally correct:
- MPEG-TS does not significantly add latency at the encoding stage
- Most protocol overhead is related to packetization and decoding behavior, not encoding itself
- Mux/demux operations are primarily memory operations and have negligible delay in typical systems
6. Recommended Debugging Approach
To precisely locate latency sources:
- Add internal timestamps at each pipeline stage:
- Camera capture time
- Encoder input/output
- Network send/receive
- Decoder output
- Display refresh
- Ensure logging is lightweight and does not affect performance
- Monitor buffer depth in real time to detect queue buildup
Summary our answer
- Camera ISP delay is often a major hidden contributor (~100 ms at 1080p is common)
- Encoder latency is usually much lower than assumed
- Wireless transmission and buffering can significantly increase delay
- Systematic timestamp measurement is the most reliable way to identify the real bottleneck

طرح سؤال
شكرًا لردكم ✨