תשובה קצרה: השתמשו ב-RTMP כאשר מקודד נדרש לפרסם לנקודת קצה לקליטה, ב-WebRTC כאשר אינטראקציית הצופה והנתיב בזמן אמת מצדיקים זאת, וב-HLS כאשר הפצת קהל מבוססת HTTP היא הנתיב שנבחר. שירות חי משתמש לעיתים ביותר מאחד; שמות הפרוטוקולים מתארים גבולות שונים.
בחרו מהצופה חזרה אל המקור
| שאלה | WebRTC | HLS | RTMP |
|---|---|---|---|
| מקלט עיקרי | עמית דפדפן/יישום אינטראקטיבי או שירות מדיה | נגן ונתיב הפצה התומכים ב-HTTP | שרת קליטה או נקודת קצה של פלטפורמה |
| מודל תעבורה/הפצה | סשן מדיה בזמן אמת שמתבצע עליו משא ומתן עבור העמיתים | פלייליסט ומקטעי מדיה שנשלפים דרך HTTP | סשן פרסום מתמשך על גבי TCP |
| תפקיד הדפדפן | נועד לממשקי API של מדיה בזמן אמת בדפדפן | נמסר דרך נתיב נגן; תמיכת הפלטפורמה משתנה | אינו ניגון מקורי בדפדפנים מודרניים |
| בדיקת מקודד | אמתו תמיכה של הדפדפן, השירות ותהליך המשא ומתן | אמתו תאימות של הנגן, האריזה והרנדישן | אמתו תאימות של המקודד ונקודת הקצה לקליטה |
| בדיקת רשת | תנאי איתות, ICE/STUN/TURN וחומת אש | התנהגות של מקור, מטמון/CDN ובקשות הנגן | יכולת הגעה למארח ולפורט הקליטה שהוקצו |
| מתאים כאשר | אינטראקציה היא חלק מדרישת המוצר | הפצת קהל היא המשימה | מקודד חייב למסור הזנה למקלט קליטה |
מה לבדוק תחילה
| בחירת תהליך עבודה | נקודת קצה לבדיקה | בדיקת הקבלה הראשונה |
|---|---|---|
| תרומה אינטראקטיבית או קהל: WebRTC | נקודת קצה מוגדרת של צופה/סשן WebRTC | איתות יחד עם קישוריות ICE/TURN, ולאחר מכן שמע/וידאו של התוכנית |
| ניגון רחב בדפדפן: HLS | https://example.invalid/live/master.m3u8 | שליפת מניפסט והרנדישן המיועד בנגן |
| קליטת מקודד/פלטפורמה: RTMP | rtmp://example.invalid/app בתוספת מפתח שהוקצה | מצב המפרסם, ולאחר מכן פלט ה-HLS או WebRTC שנבחר במפורש |
אלו צורות של נקודות קצה, ולא כתובות שמוקצות על ידי Callaba. למודלי ההפצה הבסיסיים ראו W3C WebRTC, IETF HLS, ואת מפרט RTMP.
החלטה מהירה: בחרו את הפרוטוקול לפי המשימה
לתרומה אינטראקטיבית או להשתתפות קהל, בדקו איתות WebRTC ו-ICE/TURN לפני הבחירה בו. לניגון רחב בדפדפן, בדקו את מניפסט ה-HLS ואת הנגן. לקליטה ממקודד לפלטפורמה, בדקו RTMP מול נקודת הקצה שהוקצתה, ואז בחרו ובדקו את פלט ה-HLS או WebRTC במורד הזרם.
אם ההחלטה היא "כיצד הצופים מקבלים את התוכנית בדפדפן?", התחילו ב-WebRTC או HLS ובדרישות הנגן, הגישה וההפצה שלהם. אם היא "כיצד המקודד הזה מפרסם לפלטפורמה?", התחילו בחוזה קליטת ה-RTMP של הפלטפורמה. RTMP יכול להזין שלב HLS או WebRTC מאוחר יותר, אך אינו יוצר בעצמו שלב כזה.
השוואות שגויות נפוצות
WebRTC לעומת HLS
זוהי החלטת הפצה. WebRTC זקוק לנתיב סשן בזמן אמת; HLS זקוק להפצת פלייליסט/מקטעים ולנגן תואם. בדקו את נקודת הקצה המדויקת של הקהל ואת מודל הגישה שלה, ולא רק את הזנת המקור.
RTMP לעומת WebRTC
לרוב הם נמצאים בקצוות שונים של תהליך העבודה: RTMP כקליטת מקודד, ו-WebRTC כהפצה אינטראקטיבית. גשר הוא פונקציה מוגדרת של שרת מדיה או שירות, עם מקודדים, איתות ותפעול משלו — ולא מאפיין של כתובת URL כלשהי.
HLS לעומת RTMP
HLS אורז מדיה להפצת HTTP; RTMP מפרסם מדיה למקלט קליטה. צופה שאינו יכול לפתוח כתובת URL של RTMP זקוק לנתיב פלט ה-HLS או WebRTC שנבחר, ולא לדפדפן אחר.
תהליך עבודה משולב של פרוטוקולים
מקודד תוכנית יכול לפרסם RTMP למשאב קליטה מבוקר. המפעיל מאמת פעילות של המקור, ואז מגדיר פלט נפרד להפצת קהל — HLS לתהליך עבודה של נגן HTTP או WebRTC לנתיב האינטראקציה. אמתו כל גבול לפי הסדר: מקודד לקליטה, יצירת עיבוד/פלט, ואז כתובת ה-URL בפועל של הצופה.
רשימת בדיקה של פרוטוקולים לפני הפקה
- רשמו את אילוצי המקודד, קצב הפריימים, השמע ומקלט היעד של המקור.
- הקצו אחראי לאישורי פרסום, לאיתות/גישה ולבדיקת הנגן.
- השתמשו בקהל חזרה פרטי ובדקו התאוששות לאחר עצירת המקור.
- קשרו טענות על ניגון ישיר בדפדפן לפלט המוגדר, ולעולם לא לכתובת URL של מקור RTMP.
בחרו את הצעד הבא
לקליטת מקודד ולגישת מפרסם/מקלט, ראו RTMP Server. כתובת URL לפרסום RTMP עשויה להשתמש באותו שם יישום וזרם כמו כתובת URL של מקלט, אך למפרסם ולמקלט עדיין יש תפקידים שונים. לפלט בדפדפן, התחילו ב-הנחיות Web Player; לכוונת אריזה, ראו RTMP to HLS. אם תהליך העבודה הוא תרומת SRT ולא פרסום RTMP, SRT Server הוא הבעלים המתאים.
