אנחנו צריכים מכשירים, כדי לקבל את המידע על סרטוני מצלמת Full HD עם SDI (ממשק נתונים טוריים) על הקו ומידע מקודד בתקן H.265. יש להעביר נתונים דחוסים ב-DVB-T (שידור וידאו דיגיטלי יבשתי) או תקן DVB-S. הפלט האנלוגי של המודול המעוצב יכול לקבל גם אותות I וגם Q, כמו גם אותות מאופננים.
תוכן העניינים
ש: האם מקודד הווידאו SDI שלך תומך בכניסת TSI / תְפוּקָה?
א: לוח הקידוד הקיים שלנו ללוח אפנון מעביר נתונים דרך יציאת הרשת. במקום ממשק TSI שציינת. זה לא משפיע על השימוש במשדר למקלט. זהו ממשק פנימי של המשדר.
ש: האם לוחות מפענח המקודד שלך תומכים 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/509Hz/50.Hz. זה לא תומך 525 פורמט וידאו i50, זה בסדר?
ש: האם SDI COFDM DVB-T H265 SDI Encoder RF שלך תומך בהספק פלט של 0~10dBm?
א: נקודת תדר הפלט שלך מ-400Mhz ל-2800Mhz הנדרשת היא רחבה מאוד.
קשה להשיג פלט של 0~10dBm תחת נקודת תדר רחבה כל כך, והוספת מגבר כוח על הלוח תגדיל את צריכת החשמל והחום (ציינת גם שאין צורך במאוורר לפיזור חום).
האם אתה מוכן להסכים לקיים שלנו -3 לפלט -10dBm ולאחר מכן הוסף PA משלך (מגבר כוח)?
ש: מה הממד של מקודד COFDM DVB-T H265 SDI שלך?
האם יש לך בקשת מימד מיוחדת? הגודל הקיים שלנו הוא 70x45 מ"מ.
א: לוחות מקודד ומפענח הווידאו הקיימים שלנו יכולים לענות על צורכי הפרויקט שלך.
הדאגה הגדולה ביותר של המהנדס שלי היא שהחברה שלך, כחבר בתעשיית השידור והטלוויזיה יש דרישות גבוהות יחסית לאיכות וידאו תמונה.
לוח קידוד הווידאו שלנו יבצע דחיסה מאבדת עבור זמן אחזור נמוך. האם אתה יכול לקחת סט של דוגמאות קיימות כדי לבדוק ולאשר את איכות התמונה? אם אתה חושב שהדגימות שלנו יכולות לעמוד בדרישות החברה שלך, אנו נעצב מחדש ונצייר את הלוח בהתאם לדרישות החברה שלך.
ש: האם תוכל לספק מידע נוסף על VBR?
על ידי החלת וידאו על TX, הפרמטר VBR ישתנה עם הזמן ואינו ערך סטטי. האם תוכל לספק מידע נוסף על כך?
א: VBR הוא קצב הסיביות של קידוד הווידאו במשדר. מאז תמונת הווידאו משתנה באופן דינמי, VBR הוא כמובן משתנה, אבל הוא משתנה סביב קצב סיביות הקידוד שנקבע על ידי מערכת השידור: 7.81*0.8=6.248Mbps.
ש: למרות שיש לי אחסון פלאש ברסיבר שלי, REC OFF ו-No Storage מוצגים על המסך. למה זה קורה?
אמרת בתיאור: Key2: כפתור מתג להקלטת וידאו, לחיצה קצרה כדי לשנות את מצבו. המקלט יבדוק אוטומטית את התקן האחסון (כרטיס מיקרו SD או דיסק USB, כרטיס SD עדיפות) לאחר ההפעלה והתחל להקליט וידאו כאשר התקן האחסון מוכנס. פשוט לחץ על הכפתור כדי לעצור או להקליט שוב.
א: המערכת המקבלת לא מצליחה לזהות את כונן הבזק מסוג USB. יש לאתחל את כונן הבזק מסוג USB לפורמט שהמערכת שלנו יכולה לזהות.
ש: גם B1 וגם B2 הם אפס. זה מצביע על כך שיש א 0 % שיעור שגיאות נשיכה!!! איזה טווח של פרמטרים אלה מקובל?
א: התרחשות של שיעור שגיאות סיביות עלולה לגרום לבעיות בתמונת הווידאו. כאשר שיעור שגיאות הסיביות קטן מאוד, זה לא ישפיע על אפקט תמונת הווידאו.
ש: האם אני יכול להתאים אישית את תוכן מסך המתכנת?
א: תוכן התצוגה של לוח התצורה (מְתַכנֵת) אינו פתוח ללקוחות לשינויים.
ש: למה ערוץ S2 לא מתוכנת? נראה שהטיונר השני אינו פועל כרגע.
א: S2 מתייחס לאנטנת קליטה 2, שיכול לעבוד כרגיל. התדר ורוחב הפס זהים ל-s1 ו-s2.
ש: למה ההשהיה שחישבתי היא עצומה? זה בסביבה 470 גברת.
בתיאור שלך מגיע: ניתן לשייך את תכונות ברירת המחדל הרגילות של מודול המקלט שלנו עם מודול המשדר H.265 שלנו. זמן השהיה של וידאו HD מהזנת המשדר למסך ה-HDMI של המקלט הוא בערך 200ms עד 250ms.
א: ההשהיה שבדקנו הייתה בסביבות 250ms. איך בדקתם את זה? דרך ההשהיה שבדקנו, בבקשה בדוק את ה קישור לסרטון יוטיוב.
ש: כמה זמן אחזור יש למשדר ולמודול מקלט המפענח של מקודד SDI שלך?
אני זוכר שאמרת שעשית אופטימיזציה של הפרוטוקול עבור זמן אחזור טוב יותר. מכיוון שאני לא משתמש בהשהיית H.264 המהירה שלך (130 גברת) כמה זמן אחזור צריך להיות לנו בהגדרות שלי?
א: אישרת שאתה צריך לתמוך ב-H265, אבל לא מצב חביון נמוך של H264. כדי להשיג מצב חביון נמוך, יש להחליף את המקלט לחומרת מקלט אחרת, ויש לצרוב את הקושחה המתאימה לפני המשלוח.
ש: האם אוכל להשתמש במקלט COFDM שלך כדי לקבל את ערוץ הטלוויזיה הרגיל של DVB-T?
אמרת ששינית את פרוטוקול הווידאו לשיפור השהייה ב-TX. האם אוכל להשתמש ב-RX שלך בתור DVB-T מסחרי? כיצד אוכל לקבל את ערוץ ה-DVB-T הרגיל?
א: אם אתה באמת רוצה להשתמש בו בתור מקלט DVB-T רגיל, אנחנו צריכים לשדרג קושחה אחרת. (הסר את ההצפנה על המקודד והפענוח על המפענח).
ש: כיצד אוכל להשתמש בפונקציית תפריט ה-OSD שלך במקלט COFDM?
בתיאור שלך מגיע:
מודול המקלט כולל גם פונקציונליות של הקלטת DVR עם כרטיס Micro SD או דיסק USB. מודול המקלט מאפשר גם הזרמת וידאו דרך USB עבור מפענחי מכשירי אנדרואיד מרוחקים כמו סמארטפונים או Android PAD. זה מאפשר לצופים מרחוק מרובים לנטר את אותו סרטון
בּוֹ זְמַנִית. מודול המקלט תומך גם במחרוזת תווי תצוגה במסך תצוגת הווידאו כשהווידאו ביחד במצב OSD.
א: לִרְאוֹת תיעוד מקוון של OSD.
ש: איך אני יכול להפעיל את הצפנת AES? היכן עלי להזין את המפתח?
א: לוח התצורה יכול לערוך ולשנות את הסיסמה.
ש: ציין את שאלת תמונת טקסט הקשת:
א: פונקציה אופציונלית זו נדרשת על ידי מוצרים אחרים (פונקציית יציאת הרשת משמשת לחיבור לקישור אלחוטי דו-כיווני). אנא התעלם ממנו ביישום שלך.
ש: מהו עיכוב הזמן של נתוני UART בשידור חד-כיווני?
עבור נתוני UART מ-TX ל-RX, הוא הנתונים מעובדים בתהליך הקידוד או מועברים בזמן אמת? אני דורש העברת נתונים בזמן אמת.
א: הנתונים והווידאו נשלחים יחד באמצעות חבילת cofdm אלחוטית. אז העיכוב זהה לזה של וידאו.
ש: עבור משדר. אפשר לשנות GI ו-FEC ופרמטר נוסף לפי הטבלה שלך בתיאור?
א: כן.
ש: מה הכוח המדויק בשלב זה 1350 ל 1450 MHz? אני צריך את המידע הזה כדי לעצב רשות.
הפלט המרבי של פס התדרים 1350~1450 הוא בסביבות -10±2dBm. מומלץ לתכנן את ה-PA על בסיס קלט של -15dBm. ניתן לכוונן את המשדר שלנו עד -15dBm.
ש: האם למתכנת שלך יש את הפונקציה לאפס את שחזור היצרן?
אם אני משנה פרמטרים של כל צד כמו תדר GI או FEC או רוחב פס וידאו, איך אני יכול לאפס את כל הפרמטרים במצב איפוס היצרן? אני חדש בלוח הזה, ואני צריך לשנות כמה פרמטרים כדי להשיג את הרצון שלי. אבל אני חושש לשנות את פיסות המידע המוגדרות כברירת מחדל.
א: TX שלנו / למתכנת RX אין תכונת איפוס להגדרות היצרן.
ש: האם מקודד כניסת ה-SDI Video שלך תומך ב-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 הכוח נשבר או שהמעגל שלאחר מכן קצר חשמלי. אם IC הכוח נשבר, החלף את IC הכוח; אם המעגל הבא קצר, אתה צריך לבדוק את המעגל הבא.
ש: האם לוח המקודד יכול לקבל ולהעביר נתוני UART באמצעות תקשורת UDP (IP:נמל)?
א: כן, העברת נתונים של UART נתמכת תחת שלנו ברירת המחדל של פרוטוקול מותאם אישית, עם כמה שיקולים חשובים:
1. פרוטוקול מותאם אישית (קושחה ברירת מחדל)
ברירת המחדל של קושחת המשלוח שלנו משתמשת ב-a פרוטוקול מרובה מותאם אישית שתומך שידור UART שקוף (מעבר סדרתי).
- נתוני UART משולבים יחד עם זרמי אודיו/וידאו.
- לָכֵן, הצד המקבל חייב להשתמש במתאים ספריית דמוקס בפרוטוקול מותאם אישית להפרדת נתוני UART מזרם המדיה.
- בשימוש יחד עם לוח המפענח שלנו, שידור UART שקוף פועל כראוי וניתן להעביר/לקבל אותו כצפוי.
הערה עבור נגני PC
תוכנת נגן ה-PC הנוכחית שלנו רק דגימות ותהליכים:
- נתוני וידאו
- נתוני אודיו
בהווה, זה כן לא מעבד או פלט נתונים סדרתיים של UART.
2. פרוטוקול MPEG-TS סטנדרטי
אם לוח המקודד מהבהב עם ה קושחה/פרוטוקול MPEG-TS סטנדרטיים:
- רק זרמי אודיו ווידאו נתמכים.
- UART/העברת נתונים טורית היא אינו נתמך במצב MPEG-TS.
אנא קח זאת בחשבון בעת בחירת פתרון הקושחה/פרוטוקול.
| סוג פרוטוקול | אודיו / וידאו | שידור UART שקוף |
|---|---|---|
| פרוטוקול מותאם אישית (בְּרִירַת מֶחדָל) | נתמך | נתמך |
| MPEG-TS סטנדרטי | נתמך | לא נתמך |
ש: האם יש לך קושחה שתומכת ב- H.264 או RTP גולמי במקום MPEG-TS להזרמת UDP?
א: קושחת UDP שלנו אינה משדרת זרמים גולמיים של H.264 יסודיים. הזרמת UDP נתמכת בשני פורמטים בהתאם לגרסת הקושחה:
- א פורמט קנייני מותאם אישית, אוֹ
- ה MPEG-TS סטנדרטי (MPEG Transport Stream) פוּרמָט
אלה תואמים לבנות קושחה שונות (נבדל בדרך כלל על ידי סיומת כגון "T" או גרסאות שאינן "T".).
ש: האם אתה תומך ב-RTP כפרוטוקול סטרימינג עצמאי?
א: אנחנו לא מספקים "מצב הזרמת RTP גולמי" נפרד. אוּלָם, RTP כבר נמצא בשימוש פנימי בתוך הזרמת RTSP. במצב RTSP, אודיו ווידאו מועברים דרך מנות RTP כחלק מחסנית RTSP/RTP/RTCP. לָכֵן, RTP נתמך בעקיפין דרך RTSP ולא כפורמט סטרימינג עצמאי של UDP.
ש: האם המערכת יכולה להוציא H.264 גולמי על UDP?
א: לא. שידור זרם גולמי H.264 אינו נתמך באמצעות UDP. זה נובע מגודל מנות ומגבלות רשת. I-frame בודד יכול להיות גדול מאוד ולא ניתן לשדר אותו בצורה מהימנה בחבילת IP אחת.
לשידור יציב, זרמי וידאו חייבים להיות מובלעים באמצעות פורמט הובלה כגון:
- MPEG-TS, אוֹ
- RTP (דרך RTSP)
ש: איך מסגרת המפתח (GOP) מרווח מוגדר?
א: מרווח הפריימים המפתח נשלט על ידי פרמטר GOP בממשק האינטרנט (דף הגדרות וידאו).
- אם GOP מוגדר ל 0 (מצב ברירת מחדל/אוטומטי), המערכת מיישרת אוטומטית את מרווח ה-I-frame עם קצב הפריימים הקלט.
- דוגמא: אם הקלט הוא 1080P60, אז מרווח ה-I-frame יהיה 60 מסגרות (1 GOP השני).
זה מבטיח התנהגות קידוד אדפטיבית המבוססת על מאפייני מקור הקלט.
ש: מדוע לא ניתן להעביר H.264 גולמי ישירות דרך IP/UDP?
א: כי מסגרות H.264 (במיוחד I-frames) יכול להיות גדול מאוד ולעלות על יחידת השידור המקסימלית (אָדָם) של מנות רשת. ללא אנקפסולציה, לא ניתן להבטיח משלוח אמין. לָכֵן, וידאו חייב להיות מנותק באמצעות פורמטי סטרימינג סטנדרטיים כגון MPEG-TS או RTP עבור פילוח מתאים, תִזמוּן, והרכבה מחדש.
ש: זמן האחזור של המערכת שלי הוא ~230 אלפיות השנייה בסך הכל. המפענח והתצוגה לוקחים ~45 אלפיות השנייה, משאיר ~185 אלפיות השנייה למצלמה ומקודד. אני מצפה שהמצלמה תורמת ~60 אלפיות השנייה (4 מסגרות ב 60 fps), אז נראה שהמקודד הוא ~120 אלפיות השנייה. האם יש דרך להפחית את זמן ההשהיה של המקודד? אני מבין ש-MPEG-TS משפיע בעיקר על פענוח, לא קידוד.
א: פירוט אחזור והנחיות אופטימיזציה
כדי לייעל במדויק את זמן האחזור של המערכת, חשוב תחילה לאמת כל שלב באופן עצמאי לפני הנחת צווארי בקבוק.
1. בדוק תחילה את אחזור המצלמה (שלב קריטי)
לפני אופטימיזציה של קידוד, עליך לאשר את תרומת המצלמה בפועל.
שיטת מדידה מעשית:
- חבר את יציאת ה-HDMI של המצלמה ישירות לתצוגה
- כוון את המצלמה לעבר שעון עצר בעל דיוק גבוה המוצג על צג מחשב נפרד
- צלם הן את הסצנה החיה והן את פלט ה-HDMI בו-זמנית
- השווה חותמות זמן של פריים כדי לחשב את זמן האחזור של המצלמה מקצה לקצה
הערות:
- השתמש בשעון עצר בעל דיוק גבוה (מרווח תקלות קטן יותר משפר את הדיוק)
- עיבוד ISP של מצלמה הוא לעתים קרובות תורם מרכזי
- מהניסיון שלנו:
- 1080מצלמות p בדרך כלל מציגות זמן אחזור של ~100 אלפיות השנייה
- דגמים מסוימים עשויים לעלות על זה בגלל צינורות ISP כבדים יותר
2. לתצורת המצלמה יש השפעה גדולה
אם זמן האחזור של המצלמה גבוה, אופטימיזציה צריכה להתחיל שם:
- רזולוציה נמוכה יותר (לְמָשָׁל, 720p לעומת 1080p) → מפחית את עיכוב ISP וצינור
- קצב פריימים גבוה יותר (לְמָשָׁל, 60 fps לעומת 30 fps) → מפחית את זמן האחזור של חציצה של מסגרת
- צינור עיבוד תמונה פשוט יותר → מפחית עומס של ספק שירותי האינטרנט
שינויים אלה לעתים קרובות מפחיתים את זמן ההשהיה בצורה יעילה יותר מאשר כוונון מקודד.
3. סביר להניח שהאיחור של המקודד מוערך יתר על המידה
א 120 עיכוב קידוד ms בדרך כלל לא סביר עבור מקודדי חומרה טיפוסיים.
מבוסס על מדידות פנימיות:
- מקודד חומרה + מפענח + הפצה + צינור תצוגה דרך Ethernet מביא בדרך כלל:
- ~80-100 אלפיות השנייה זמן אחזור כולל מקצה לקצה
זה מרמז:
- זמן האחזור למקודד בלבד נמוך משמעותית מ 120 גברת
- קידוד בדרך כלל אינו התורם הדומיננטי במערכת מוגדרת כהלכה
4. שיטת השידור חשובה (במיוחד אלחוטי)
אנא ודא אם המערכת משתמשת:
- Ethernet Wired
- שידור אלחוטי
אם נעשה שימוש אלחוטי:
- רוחב פס נמוך (<20 Mbps) יכול להכניס עיכוב משמעותי
- שידור I-frame גדול עלול לגרום לאגירת חציצה ועיכובים בתור
- זה יכול להגדיל באופן ניכר את זמן האחזור מקצה לקצה גם אם הקידוד יעיל
5. MPEG-TS והבהרת פרוטוקול תקורה
ההבנה שלך בדרך כלל נכונה:
- MPEG-TS אינו מוסיף חביון משמעותי בשלב הקידוד
- רוב תקורה של פרוטוקול קשורה להתנהגות מנות ופענוח, לא מקודד את עצמו
- פעולות Mux/demux הן בעיקר פעולות זיכרון ויש להן עיכוב זניח במערכות טיפוסיות
6. גישת ניפוי באגים מומלצת
כדי לאתר במדויק מקורות חביון:
- הוסף חותמות זמן פנימיות בכל שלב של צינור:
- זמן לכידת מצלמה
- קלט/פלט מקודד
- שליחה/קבלה ברשת
- פלט מפענח
- רענון תצוגה
- ודא שהרישום הוא קל משקל ואינו משפיע על הביצועים
- עקוב אחר עומק המאגר בזמן אמת כדי לזהות הצטברות תור
סיכום התשובה שלנו
- עיכוב ISP של מצלמה הוא לעתים קרובות תורם נסתר גדול (~100 אלפיות השנייה ב-1080p זה נפוץ)
- זמן האחזור של המקודד הוא בדרך כלל נמוך בהרבה מהמשער
- שידור אלחוטי ואגירה יכולים להגביר משמעותית את העיכוב
- מדידת חותמת זמן שיטתית היא הדרך האמינה ביותר לזהות את צוואר הבקבוק האמיתי
שאל שאלה
תודה רבה ששלחת את התשובה! ✨