תשובה קצרה: בחרו את הפרוטוקול שהצד המקבל מסוגל לקבל בפועל. SRT הוא אפשרות לתרומה כאשר שני הקצוות תומכים בו והנתיב הוגדר; RTMP נותר מסירה נפוצה ממקודד לפלטפורמה או לשרת קליטה. הפעלה ומסירה לצופים נשארות משימות המשך שמוגדרות בנפרד.
התחילו במקבל, ואז בחרו את המסירה
| נקודת החלטה | נתיב SRT | נתיב RTMP |
|---|---|---|
| מקבל | מקבל תרומה תואם-SRT שבו אתם שולטים או שהוקצה לכם | נקודת קצה לקליטת RTMP או כתובת פלטפורמה שסופקה לפרסום |
| תעבורה | הפעלת SRT מבוססת UDP; מצב חי כולל בקרות תזמון ושידור חוזר | הפעלת RTMP מבוססת TCP אל נקודת הקצה שהוגדרה |
| שאלת רשת | האם שני העמיתים יכולים להגיע זה לזה והאם הגדרות המצב, ההשהיה וסיסמת הגישה תואמות? | האם המקודד יכול להגיע למארח והאם הכתובת/המפתח תואמים לחוזה נקודת הקצה? |
| שאלת קודק | אמתו בנפרד את המכל והקודקים שהמקבל מאשר | אמתו בנפרד את פרופיל השמע/וידאו שהיעד מאשר |
| משימת המשך שימושית | תרומה לזרימת עבודה תפעולית או הפקתית | פרסום לשירות קליטה או ל-RTMP Server מוגדר |
שלוש החלטות נפוצות
- הפלטפורמה מספקת רק כתובת ומפתח זרם: פרסמו RTMP לפי חוזה זה.
- הצוות שלכם שולט במקבל SRT: השתמשו ב-SRT כאשר מצב, מארח:יציאה, השהיה וכל Stream ID/סיסמת גישה סוכמו בשני הקצוות.
- תרומת SRT מסתיימת בפלטפורמת RTMP/RTMPS: אמתו בנפרד את תרומת ה-SRT ואת מסירת הפרסום לפלטפורמה.
מצב החי של SRT מתוכנן סביב חלון השהיה מוגדר ומשוב מהמקבל; חלון גדול יותר יכול לאפשר יותר זמן להתאוששות, אך הוא עדיין בחירת פריסה ולא הבטחה לתמונה טובה יותר. תאימות RTMP תלויה באותה מידה בנקודת הקצה. פלטפורמה הדורשת כתובת RTMP או RTMPS קובעת את המסירה הסופית גם אם רגל התרומה במקום אחר משתמשת ב-SRT.
מה משתנה תפעולית
| לפני החיבור הראשון | תעדו |
|---|---|
| SRT | מצב caller/listener/rendezvous; מארח:יציאה; השהיה; Stream ID או סיסמת גישה כאשר נעשה בהם שימוש; מכל וקודקי וידאו/שמע. |
| RTMP | כתובת קליטה מלאה, יישום/נתיב ומפתח; הפרופיל שהמקבל מצהיר עליו, לעיתים קרובות H.264/AAC כאשר נקודת הקצה דורשת זאת; ובדיקת תקינות הזרם שלה. |
השאירו אישורים מחוץ לצילומי מסך, יומני צ'אט והקלטות בדיקה.
הצפנת SRT ו-RTMPS עונים על שאלות אבטחת תעבורה שונות: אפשר להגדיר SRT עם הצפנה, ואילו RTMPS הוא RTMP המועבר מעל TLS. יעד RTMPS אינו מתאר את אפשרויות הקליטה של RTMP Server נפרד.
בדקו נתיב תרומה אחד
השתמשו באותו מקור מוכן עבור כל אחת מהלשוניות: נעלו את פורמט התוכנית, רשמו את הגדרות קודק הווידאו והשמע ותנו למפרסם גישה לנקודת הקצה שנבחרה לבדיקה. התחילו הפעלת פרוטוקול אחת, אשרו את מצב המפרסם, בדקו את התצוגה המקדימה ואז אמתו את פלט ההמשך אם זרימת העבודה משתמשת בו.
הדגמות פרוטוקולים
בחרו פרוטוקול לבדיקה
כל הדגמה מופעלת ידנית ומקבלת הקצאה זמנית נפרדת. השתמשו בהגדרות מקור תואמות כשאתם משווים תהליכי עבודה; דף זה אינו מבצע בדיקת השהיה מבוקרת.
הדגמת SRT חיה
נסה חיבור SRT חי
צור חיבור זמני לשעה אחת. שלח את ההזנה שלך לכתובת המפרסם במצב Caller, כאשר מזהה הזרם נשאר ריק. וצפה בה ב-Multiview למטה, או חבר את המקלט שלך לכתובת המקלט במצב Caller.
התוצאה מאשרת שהמקור שנבחר הגיע לאותו נתיב זמני ולתצוגה המקדימה שלו. זוהי בדיקת הגדרה, לא אמת מידה השוואתית, ולכן היא אינה מדרגת השהיה, איכות או אמינות. חזרו על תצורה שהשתנתה כבדיקה חדשה ושמרו את יומני המקבל או נתוני החיבור הגלויים למפעיל.
היכן Callaba משתלבת
RTMP Server של Callaba יכול להעניק למפרסמים ולמקבלים כללי גישה נפרדים ולהציג פעילות גלויה למפעיל. RTMP Server במצב אורח יכול במקום זאת להיות פתוח ללא כללי גישה מוגדרים מראש. SRT Server שלו הוא משאב התרומה המקביל לזרימת עבודה תואמת-SRT. תצפית בדפדפן והפעלה לצופים משתמשות במודולים המוגדרים בנפרד; כתובת פרסום RTMP אינה כתובת שניתן להפעיל בדפדפן.
השלבים הבאים
- למאזין RTMP מוגדר, עיינו בRTMP Server ובבקרות הגישה ומחזור החיים שלו.
- למקבל תרומת SRT, עיינו בSRT Server.
- לגשר מפורש, השתמשו בנתיב שער התרומה של RTMP המתועד רק לאחר אימות שני הקצוות.
