به دستگاه نیاز داریم, برای دریافت اطلاعات ویدیوهای دوربین Full HD با SDI (رابط داده سریال) روی خط و کدگذاری اطلاعات در استاندارد H.265. داده های فشرده باید در هر دو نوع DVB-T منتقل شوند (پخش ویدئوی دیجیتال زمینی) یا استاندارد DVB-S. خروجی آنالوگ ماژول طراحی شده می تواند هر دو سیگنال I و Q را بپذیرد, و همچنین سیگنال های مدوله شده.
فهرست مطالب
Q: آیا رمزگذار ویدیوی SDI شما از ورودی TSI پشتیبانی می کند؟ / تولید?
آ: برد رمزگذاری موجود ما به برد مدولاسیون داده ها را از طریق پورت شبکه منتقل می کند. به جای رابط TSI که شما نام بردید. این تأثیری بر استفاده از فرستنده به گیرنده ندارد. این یک رابط داخلی فرستنده است.
Q: از بردهای رمزگشای رمزگذار خود پشتیبانی کنید 525 i50 به 1080 P60 در فرمت ویدیویی?
آ: اکنون بردهای رمزگذار ویدیوی SDI ما از HD پشتیبانی می کنند: 720p @ 23.98Hz/24Hz/25Hz/29.97Hz/30Hz/50Hz59.94Hz/60Hz و 1080p @ 23.98Hz/24Hz/25Hz/29.97Hz/30Hz/50Hz/50Hz/60Hz/50Hz. پشتیبانی نمی کند 525 فرمت ویدیویی i50, خوبه؟
Q: آیا SDI COFDM DVB-T H265 SDI Encoder RF توان خروجی 0~10dBm را پشتیبانی می کند؟
آ: نقطه فرکانس خروجی شما از 400 مگاهرتز تا 2800 مگاهرتز مورد نیاز بسیار گسترده است.
دستیابی به خروجی 0~10dBm در چنین نقطه فرکانس وسیعی دشوار است, و افزودن Power Amplifier بر روی برد باعث افزایش مصرف برق و گرما می شود (همچنین اشاره کردید که برای دفع گرما نیازی به فن نیست).
آیا مایل به موافقت با موجود ما هستید؟ -3 به خروجی -10dBm و سپس PA خود را اضافه کنید (تقویت کننده توان)?
Q: ابعاد رمزگذار COFDM DVB-T H265 SDI شما چقدر است?
آیا درخواست ابعاد خاصی دارید؟? اندازه موجود ما 70x45mm است.
آ: بردهای رمزگذار و رمزگشای ویدیویی موجود ما می توانند نیازهای پروژه شما را برآورده کنند.
بزرگترین نگرانی مهندس من این است که شرکت شماست, به عنوان عضوی از صنعت پخش و تلویزیون، نیازهای نسبتاً بالایی برای کیفیت ویدیوی تصویر دارد.
برد رمزگذاری ویدیوی ما فشرده سازی با اتلاف را برای تأخیر کم انجام می دهد. آیا می توانید مجموعه ای از نمونه های موجود را برای آزمایش و تأیید کیفیت تصویر بردارید? اگر فکر می کنید نمونه های ما می توانند نیازهای شرکت شما را برآورده کنند, ما تابلو را با توجه به نیاز شرکت شما دوباره طراحی و ترسیم خواهیم کرد.
Q: ممکن است اطلاعات بیشتری در مورد VBR ارائه دهید?
با اعمال ویدیو در TX, پارامتر VBR در طول زمان تغییر می کند و یک مقدار ثابت نیست. ممکن است اطلاعات بیشتری در این مورد ارائه دهید?
آ: VBR نرخ بیت رمزگذاری ویدیو در فرستنده است. از آنجایی که تصویر ویدیو به صورت پویا تغییر می کند, البته VBR متغیر است, اما حول نرخ بیت رمزگذاری تنظیم شده توسط سیستم انتقال نوسان دارد: 7.81*0.8= 6.248 مگابیت در ثانیه.
Q: با وجود داشتن حافظه فلش روی گیرنده من, REC OFF و No Storage روی صفحه نمایش داده می شوند. چرا این اتفاق می افتد?
تو توضیحات گفتی: Key2: دکمه سوئیچ برای ضبط ویدیویی, مطبوعات کوتاه برای تغییر وضعیت آن. گیرنده به طور خودکار دستگاه ذخیره سازی را بررسی می کند (کارت میکرو SD یا دیسک USB, کارت اولویت SD) پس از روشن شدن و شروع به ضبط ویدیو با قرار دادن دستگاه ذخیره سازی. فقط دکمه را فشار دهید تا دوباره متوقف یا ضبط شود.
آ: سیستم دریافت کننده درایو فلش USB را شناسایی نمی کند. درایو فلش USB باید به فرمتی فرمت شود که سیستم ما بتواند آن را تشخیص دهد.
Q: هر دو B1 و B2 صفر هستند. این نشان می دهد که وجود دارد 0 % نرخ خطای نیش!!! کدام محدوده از این پارامترها قابل قبول است?
آ: وقوع یک نرخ خطای بیت ممکن است باعث ایجاد مشکل در تصویر ویدیو شود. زمانی که میزان خطای بیت بسیار کم باشد, تاثیری بر جلوه تصویر ویدئویی نخواهد داشت.
Q: آیا می توانم محتویات صفحه برنامه نویس را سفارشی کنم؟?
آ: محتوای نمایش پانل پیکربندی (برنامه نویس) برای تغییر برای مشتریان باز نیست.
Q: چرا کانال S2 برنامه ریزی نشده است? به نظر می رسد که تیونر دوم در حال حاضر کار نمی کند.
آ: S2 به آنتن گیرنده اشاره دارد 2, که می تواند به طور معمول کار کند. فرکانس و پهنای باند همان s1 و s2 است.
Q: چرا تاخیری که من محاسبه کردم بسیار زیاد است? این اطراف است 470 خانم.
در توضیحات شما در حال آمدن است: ویژگی های عادی پیش فرض ماژول گیرنده ما را می توان با ماژول فرستنده H.265 جفت کرد. تأخیر ویدیوی HD از ورودی فرستنده تا صفحه نمایش HDMI گیرنده حدود 200 میلیثانیه تا 250 میلیثانیه است..
آ: تاخیری که ما تست کردیم حدود 250 میلی ثانیه بود. چطوری تستش کردی? روش تاخیری که تست کردیم, لطفا بررسی کنید لینک ویدیوی یوتیوب.
Q: فرستنده رمزگذار SDI و ماژول گیرنده رمزگشا چقدر تأخیر دارند?
به یاد دارم که گفتید پروتکل را برای تأخیر بهتر بهینه کردید. از آنجایی که من از تاخیر H.264 سریع شما استفاده نمی کنم (130 خانم) چه مقدار تاخیر باید در راه اندازی من داشته باشیم?
آ: تأیید کردید که باید از H265 پشتیبانی کنید, اما نه حالت تأخیر کم H264. برای رسیدن به حالت تاخیر کم, گیرنده باید به سخت افزار گیرنده دیگری تغییر کند, و سفت افزار مربوطه باید قبل از ارسال رایت شود.
Q: آیا می توانم از گیرنده COFDM شما برای دریافت کانال تلویزیونی معمولی DVB-T استفاده کنم؟?
گفتید پروتکل ویدیو را برای تأخیر بهتر در TX تغییر دادید. آیا می توانم از RX شما به عنوان یک DVB-T تجاری استفاده کنم؟? چگونه می توانم کانال معمولی DVB-T را دریافت کنم?
آ: اگر واقعاً می خواهید از آن به عنوان یک گیرنده DVB-T معمولی استفاده کنید, ما باید یک سیستم عامل دیگر را ارتقا دهیم. (رمزگذاری روی رمزگذار و رمزگشایی روی رمزگشا را حذف کنید).
Q: چگونه می توانم از عملکرد منوی OSD شما در گیرنده COFDM استفاده کنم?
در توضیحات شما در حال آمدن است:
ماژول گیرنده همچنین دارای قابلیت ضبط DVR با کارت Micro SD یا دیسک USB است. ماژول گیرنده همچنین پخش ویدئو را از طریق USB برای رمزگشاهای دستگاه اندروید از راه دور مانند گوشی های هوشمند یا Android PAD فعال می کند.. این به چندین بیننده از راه دور اجازه می دهد تا یک ویدیو را نظارت کنند
همزمان. ماژول گیرنده همچنین از رشته کاراکترهای نمایش بر روی صفحه نمایش ویدیو همراه با ویدیو در حالت OSD پشتیبانی می کند.
آ: دیدن مستندات آنلاین OSD.
Q: چگونه می توانم رمزگذاری AES را روشن کنم? کلید را کجا وارد کنم?
آ: پانل پیکربندی می تواند رمز عبور را ویرایش و تغییر دهد.
Q: سوال تصویر متنی کمان را نشان دهید:
آ: این عملکرد اختیاری توسط سایر محصولات مورد نیاز است (تابع پورت شبکه برای اتصال به یک پیوند بی سیم دو طرفه استفاده می شود). لطفاً آن را در برنامه خود نادیده بگیرید.
Q: تاخیر زمانی داده های UART در انتقال یک طرفه چقدر است?
برای داده های UART از TX تا RX, داده هایی است که از طریق فرآیند رمزگذاری پردازش می شوند یا در زمان واقعی منتقل می شوند? من به انتقال بیدرنگ داده نیاز دارم.
آ: داده ها و ویدئو با هم از طریق بسته cofdm بی سیم ارسال می شوند. بنابراین تاخیر مانند ویدیو است.
Q: برای فرستنده. امکان تغییر GI و FEC و پارامتر دیگری مطابق جدول شما در توضیحات وجود دارد?
آ: بله.
Q: قدرت دقیق در این نقطه از چیست 1350 به 1450 مگاهرتز? من برای طراحی یک PA به این اطلاعات نیاز دارم.
حداکثر خروجی باند فرکانسی 1350~1450 حدود -10±2dBm است.. توصیه می شود PA بر اساس ورودی -15dBm طراحی شود. فرستنده ما را می توان تا -15dBm تنظیم کرد.
Q: آیا برنامه نویس شما عملکرد بازنشانی کارخانه ای را دارد؟?
اگر پارامترهای هر طرفی مانند فرکانس GI یا FEC یا پهنای باند ویدیو را تغییر دهم, چگونه می توانم تمام پارامترها را در حالت بازنشانی کارخانه بازنشانی کنم? من تازه وارد این هیئت هستم, و برای رسیدن به خواسته ام باید برخی پارامترها را تغییر دهم. اما من از تغییر اطلاعات پیش فرض می ترسم.
آ: TX ما / برنامه نویس RX ویژگی بازنشانی کارخانه ای ندارد.
Q: آیا رمزگذار ورودی ویدیوی SDI شما از 1080i25/1080i30 پشتیبانی می کند؟?
از 1080i50 و 1080i60 پشتیبانی می کند, از 1080i25 یا 1080i30 پشتیبانی نمی کند.
Q: میشه چندتا فایل فنی بهم معرفی کنید برای تعمیر قسمت برق از برد انکودر ویدئو 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 اهم را بین آی سی برق و مدار بعدی جدا کنید, و سپس از یک مولتی متر برای اندازه گیری اینکه آیا آی سی برق خراب است یا مدار بعدی اتصال کوتاه است استفاده کنید.. اگر آی سی برق خراب است, آی سی برق را تعویض کنید; اگر مدار بعدی اتصال کوتاه داشته باشد, شما باید مدار بعدی را بررسی کنید.
Q: آیا برد رمزگذار می تواند داده های UART را از طریق ارتباط UDP دریافت و ارسال کند (IP:بندر)?
آ: بله, انتقال داده UART تحت ما پشتیبانی می شود پروتکل سفارشی پیش فرض, با برخی ملاحظات مهم:
1. پروتکل سفارشی (سیستم عامل پیش فرض)
سیستم عامل پیش فرض حمل و نقل ما از a پروتکل مالتی پلکس سفارشی که پشتیبانی می کند انتقال شفاف UART (گذر سریال).
- دادههای UART با جریانهای صوتی/تصویری چندگانه میشوند.
- از این رو, طرف دریافت کننده باید از مربوطه استفاده کند پروتکل سفارشی کتابخانه demux برای جدا کردن داده های UART از جریان رسانه.
- هنگامی که همراه با برد رمزگشای ما استفاده می شود, انتقال شفاف UART به درستی کار می کند و همانطور که انتظار می رود می توان آن را ارسال/دریافت کرد.
یادداشت برای پخش کننده های رایانه شخصی
نرم افزار پخش کننده رایانه فعلی ما فقط دموکس و پردازش می کند:
- داده های ویدیویی
- داده های صوتی
در حال حاضر, انجام می دهد نه پردازش یا خروجی داده های سریال UART.
2. پروتکل استاندارد MPEG-TS
اگر برد انکودر با فلش شود سیستم عامل/پروتکل استاندارد MPEG-TS:
- فقط پخشهای صوتی و تصویری پشتیبانی میشوند.
- UART/سریال انتقال داده است پشتیبانی نشده تحت حالت MPEG-TS.
لطفاً هنگام انتخاب راه حل میان افزار/پروتکل، این را در نظر بگیرید.
| نوع پروتکل | صوتی / تصویری | انتقال شفاف UART |
|---|---|---|
| پروتکل سفارشی (به طور پیش فرض) | پشتیبانی | پشتیبانی |
| استاندارد MPEG-TS | پشتیبانی | پشتیبانی نمی شود |
Q: آیا سیستمافزاری دارید که از H.264 خام یا RTP بهجای MPEG-TS برای پخش UDP پشتیبانی میکند؟?
آ: سیستم عامل UDP ما جریان های اولیه H.264 خام را منتقل نمی کند. پخش UDP در دو فرمت بسته به نسخه سیستم عامل پشتیبانی می شود:
- آ فرمت اختصاصی سفارشی, یا
- این استاندارد MPEG-TS (جریان حمل و نقل MPEG) قالب
اینها با ساختهای میانافزار مختلف مطابقت دارند (معمولاً با پسوندهایی مانند نسخه های "T" یا غیر"T" متمایز می شوند).
Q: آیا از RTP به عنوان یک پروتکل پخش مستقل پشتیبانی می کنید؟?
آ: ما یک "حالت پخش RTP خام" جداگانه ارائه نمی دهیم. با این حال, RTP قبلاً به صورت داخلی در جریان RTSP استفاده می شود. در حالت RTSP, صدا و تصویر از طریق بسته های RTP به عنوان بخشی از پشته RTSP/RTP/RTCP منتقل می شوند.. از این رو, RTP به طور غیرمستقیم از طریق RTSP پشتیبانی می شود نه به عنوان یک قالب پخش مستقل UDP.
Q: آیا سیستم می تواند H.264 خام را روی UDP خروجی دهد?
آ: خیر. انتقال جریان اولیه H.264 خام از طریق UDP پشتیبانی نمی شود. این به دلیل اندازه بسته و محدودیت های شبکه است. یک فریم I می تواند بسیار بزرگ باشد و نمی تواند به طور قابل اعتماد در یک بسته IP منفرد منتقل شود.
برای انتقال پایدار, جریان های ویدئویی باید با استفاده از یک فرمت انتقال مانند:
- MPEG-TS, یا
- RTP (از طریق RTSP)
Q: قاب کلید چطوره (GOP) فاصله پیکربندی شده است?
آ: فاصله فریم کلیدی توسط پارامتر GOP در رابط وب (صفحه تنظیمات ویدیو).
- اگر GOP روی 0 (حالت پیش فرض/خودکار), سیستم به طور خودکار بازه فریم I را با نرخ فریم ورودی تراز می کند.
- مثال: اگر ورودی باشد 1080P60, سپس فاصله I-frame خواهد بود 60 فریم (1 GOP دوم).
این رفتار کدگذاری تطبیقی را بر اساس ویژگی های منبع ورودی تضمین می کند.
Q: چرا H.264 خام نمی تواند مستقیماً از طریق IP/UDP منتقل شود?
آ: زیرا فریم های H.264 (مخصوصا فریم های I) می تواند بسیار بزرگ باشد و از حداکثر واحد انتقال فراتر رود (مرد) از بسته های شبکه. بدون کپسوله کردن, تحویل مطمئن را نمی توان تضمین کرد. از این رو, برای تقسیم بندی مناسب، ویدئو باید با استفاده از فرمت های پخش استاندارد مانند MPEG-TS یا RTP بسته بندی شود, زمان بندی, و مونتاژ مجدد.
Q: تأخیر سیستم من در کل ~230 میلی ثانیه است. رسیور و نمایش 45 میلی ثانیه طول می کشد, ~ 185 میلی ثانیه برای دوربین و رمزگذار باقی می ماند. من انتظار دارم که دوربین 60 میلیثانیه کمک کند (4 فریم در 60 فریم در ثانیه), بنابراین رمزگذار به نظر می رسد ~120 میلی ثانیه است. آیا راهی برای کاهش تأخیر انکودر وجود دارد؟? من می دانم که MPEG-TS عمدتاً بر رمزگشایی تأثیر می گذارد, نه رمزگذاری.
آ: راهنمای تجزیه و بهینه سازی تاخیر
برای بهینه سازی دقیق تاخیر سیستم, مهم است که ابتدا هر مرحله را به طور مستقل قبل از فرض تنگناها تأیید کنید.
1. ابتدا تأخیر دوربین را تأیید کنید (مرحله بحرانی)
قبل از بهینه سازی رمزگذاری, شما باید سهم واقعی دوربین را تایید کنید.
یک روش اندازه گیری عملی:
- خروجی HDMI دوربین را مستقیماً به صفحه نمایش وصل کنید
- دوربین را به سمت یک کرونومتر با دقت بالا که روی یک مانیتور کامپیوتر جداگانه نمایش داده می شود، بگیرید
- هر دو صحنه زنده و خروجی HDMI را به طور همزمان ضبط کنید
- برای محاسبه تأخیر دوربین سرتاسر، مهرهای زمانی فریم را مقایسه کنید
یادداشت:
- از کرونومتر با دقت بالا استفاده کنید (فاصله تیک کوچکتر دقت را بهبود می بخشد)
- پردازش ISP دوربین اغلب یکی از عوامل اصلی است
- در تجربه ما:
- 1080دوربینهای p معمولاً تأخیر 100 میلیثانیه را معرفی میکنند
- برخی از مدلها ممکن است به دلیل سنگینتر بودن خطوط لوله ISP از این فراتر رود
2. پیکربندی دوربین تاثیر زیادی دارد
اگر تاخیر دوربین زیاد باشد, بهینه سازی باید از آنجا شروع شود:
- وضوح کمتر (به عنوان مثال, 720p در مقابل 1080p) → ISP و تاخیر خط لوله را کاهش می دهد
- نرخ فریم بالاتر (به عنوان مثال, 60 فریم بر ثانیه در مقابل 30 فریم در ثانیه) → تاخیر بافر فریم را کاهش می دهد
- خط لوله پردازش تصویر ساده تر → بار ISP را کاهش می دهد
این تغییرات اغلب تأخیر را موثرتر از تنظیم رمزگذار کاهش می دهند.
3. تأخیر رمزگذار احتمالاً بیش از حد برآورد شده است
آ 120 تاخیر رمزگذاری ms معمولاً برای رمزگذارهای سخت افزاری معمولی بعید است.
بر اساس اندازه گیری های داخلی:
- یک رمزگذار سخت افزاری + رمز گشا + انتقال + خط لوله نمایش از طریق اترنت معمولاً منجر می شود:
- ~80-100 ms کل تأخیر سرتاسر
این دلالت دارد:
- تأخیر فقط رمزگذار به طور قابل توجهی کمتر از 120 خانم
- رمزگذاری معمولاً عامل اصلی در یک سیستم پیکربندی مناسب نیست
4. روش انتقال مهم است (مخصوصا بی سیم)
لطفا بررسی کنید که آیا سیستم استفاده می کند یا خیر:
- اترنت سیمی
- انتقال بی سیم
اگر از بی سیم استفاده می شود:
- پهنای باند کم (<20 مگابیت در ثانیه) می تواند تاخیر قابل توجهی ایجاد کند
- انتقال I-frame بزرگ ممکن است باعث ایجاد بافر و تاخیر در صف شود
- حتی اگر رمزگذاری کارآمد باشد، این میتواند تأخیر انتها به انتها را به طرز چشمگیری افزایش دهد
5. شفاف سازی سربار MPEG-TS و پروتکل
درک شما در کل درست است:
- MPEG-TS تأخیر قابل توجهی را در مرحله رمزگذاری اضافه نمی کند
- بیشتر سربار پروتکل به رفتار بسته بندی و رمزگشایی مربوط می شود, خود را رمزگذاری نمی کند
- عملیات Mux/demux در درجه اول عملیات حافظه هستند و در سیستم های معمولی تاخیر ناچیزی دارند
6. روش رفع اشکال توصیه شده
برای تعیین دقیق منابع تأخیر:
- در هر مرحله خط لوله، مهر زمانی داخلی اضافه کنید:
- زمان ضبط دوربین
- ورودی/خروجی رمزگذار
- ارسال/دریافت شبکه
- خروجی رسیور
- نمایش تازه کردن
- مطمئن شوید که لاگ سبک وزن است و بر عملکرد تأثیر نمی گذارد
- مانیتور عمق بافر در زمان واقعی برای تشخیص ایجاد صف
خلاصه پاسخ ما
- تاخیر ISP دوربین اغلب یکی از عوامل پنهان اصلی است (~ 100 ms در 1080p معمول است)
- تأخیر رمزگذار معمولاً بسیار کمتر از حد تصور است
- انتقال بی سیم و بافر می تواند به طور قابل توجهی تاخیر را افزایش دهد
- اندازه گیری مُهر زمان سیستماتیک قابل اعتمادترین راه برای شناسایی تنگنای واقعی است
سوال بپرسید
از پاسخ شما سپاسگزاریم. ✨