פרסום זרם ממצלמה: RTSP ו-HLS אינם אותו קצה

אתם חושפים פורט אחד של המצלמה, מפנים אליו נגן ומניחים שבעיית האינטרנט נפתרה. ואז טלפון לא יכול לנגן אותה, דפדפן לא יכול לנגן אותה, ועמוד הניהול של המצלמה נמצא במרחק נתיב אחד שהוקלד לא נכון מהקצה הציבורי. מודל המסירה שבחרתם, RTSP או HLS, קובע את רוב זה לפני שנכתבת אפילו כלל חומת אש אחד. ה-VPN מספק רק את הקטע הפרטי.

ה-VPN מתקן את נתיב המקור, לא את נתיב הצופה

שרת VPS המחובר לרשת המקומית של המצלמה דרך מנהרה יכול להגיע למצלמה בכתובת הפרטית שלה, וזה באמת שימושי. זה אומר שהמצלמה לא צריכה פורט נכנס משלה ושהנתב הביתי נשאר סגור. זה לא אומר לכם באיזו שפה ידבר הצופה. נגן שולחני, דפדפן, טלפון וטלוויזיה חכמה תומכים בפרוטוקולים שונים, ולכל אחד יש ציפיות משלו לגבי TLS, אימות וקודקים.

הנה ההנחה שכדאי לזרוק: פרסום לכאורה אומר להפוך את המקור לנגיש. פרסום למעשה אומר לתת לקהל מוגדר דרך נתמכת לצרוך את המדיה. לזרם מפורסם יש פורמט, קהל ואישור גישה; למצלמה נגישה אין אף אחד מאלה. נגישות היא החלק שהמנהרה פותרת, ונקודת הכניסה של הצופה היא החלק שעדיין עליכם לתכנן.

RTSP הוא משא ומתן, לא פורט אחד

RTSP נושא את בקרת ההפעלה: לקוח מבקש תיאור, מגדיר מסלול מדיה אחד או יותר ואז מנגן. תעבורת המדיה עצמה נדברת במהלך ההגדרה הזו, ולכן הפרוטוקול לא מתואר היטב בפורט TCP אחד שהועבר. המשא ומתן הזה הוא החלק שאנשים מפספסים כשהם משווים כללי חומת אש.

בהתאם לנקודות הקצה, RTP יכול להגיע בפורטי UDP נפרדים או להיות שזור בחיבור הבקרה. ממסר שמעביר רק 554 ומניח שהשאר יעבוד יוצר בדרך כלל הפעלה שמתחברת, מדווחת על מסלול ואז לא מציגה דבר. בדקו איזו תעבורה המצלמה שלכם באמת מדברת לפני שכותבים עבורה כללים. לכידה בצד הפרטי עונה על זה בדקה, וניחוש עולה ערב.

לקהל קטן ומוכר עם נגנים תואמים, ממסר RTSP שהוגדר בכוונה יכול להיות התשובה הנכונה. הגבילו מאיזה מקור הוא רשאי למשוך ודרשו אימות בממסר. רשמו את הנגנים שבדקתם, כי זרם RTSP שעובד ב-VLC עדיין עלול להיכשל בדפדפן.

HLS הוא רשימת השמעה ועוד משאבים

צופה HLS מושך רשימת השמעה ואז מושך את קטעי המדיה שאותה רשימה מכנה. מפרט HLS מגדיר את מודל המשאבים הזה, והפרט התפעולי החשוב הוא שרשימות השמעה מפנות לכתובות URL אחרות. הפניות יחסיות נפתרות ביחס למיקום רשימת ההשמעה, ולכן פרוקסי שמשכתב נתיבים חייב לשכתב אותן באופן עקבי.

אם המצלמה כבר מגישה HLS שמיש, חזית ציבורית יכולה להעביר את בקשות רשימת ההשמעה והקטעים דרך המנהרה. שימו לב למפתחות, להפניות ולכתובות URL שהאפליקציה מייצרת. כל כתובת URL מוחלטת שמצביעה על מארח פרטי נשברת ברגע שצופה מחוץ לרשת המקומית עוקב אחריה. נתיבים יחסיים הם אלה ששורדים שכתוב של פרוקסי, ולכן העדיפו אותם בכל מקום שבו אתם שולטים בפלט המיוצר.

אם המצלמה מדברת רק RTSP, משהו חייב להמיר את המקור לפורמט של הצופה. אריזה מחדש וטרנסקודינג הם עבודות שונות: אריזה מחדש משמרת את הקודק, בעוד שטרנסקודינג מקודד אותו מחדש לצורך תאימות, ורק השני עולה CPU רציני. אף אחד מהם לא הופך לנחוץ רק מפני שיש VPN בנתיב.

תכננו את קישור ההעלאה לפי המקום שבו מתרחשת ההפצה. קליטה פרטית אחת שמזינה שירות מדיה ציבורי מתנהגת אחרת לגמרי מכל צופה שמושך את הזרם שלו דרך המנהרה. הדפוס השני מסתיים בדרך כלל בחיבור ביתי רווי ובמצלמה שנראית כאילו היא נכשלת באקראי.

שימו את האימות בקצה שאתם מפרסמים

TLS, אימות צופים ותיעוד גישה שייכים לנקודת הכניסה הציבורית, לא למצלמה. זה שומר את פרטי הגישה של המצלמה בנפרד מפרטי הגישה של הזרם. זה גם נותן לכם מקום אחד לשלול גישה כשחבר קהל עוזב. לשים את הבקרות האלה על המצלמה פירושו במקום זאת שכל שינוי בקהל הופך לשינוי ניהולי במכשיר שאמור לעולם לא להיות נגיש לציבור.

הפרידו בין ה-VPN והרשאות הניהול של המצלמה לבין נתיב הפרסום. שרת VPS שיכול להגיע לממשק האינטרנט של המצלמה כדי למשוך זרם לא אמור להיות גם המכונה שחושפת את הממשק הזה. הקהל לא אמור לדעת לעולם את כתובת המצלמה.

לאחר מכן אמתו את שני הקצוות שבניתם בפועל במקום להניח שהשרשרת עובדת:

$ ffprobe -v error -rtsp_transport tcp rtsp://10.50.0.9:554/stream1
$ curl -sI https://stream.example.net/live/index.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl

בדיקה מוצלחת של המקור הפרטי ושליפה מוצלחת של רשימת ההשמעה בקצה הציבורי מוכיחות חצאים שונים של התכנון. בדקו אותם בנפרד. ניגון מאותו סוג לקוח שהקהל שלכם משתמש בו הוא הבדיקה היחידה שמכסה את כל השרשרת.

בסופו של דבר יש לכם שרשרת עם מטרה בכל חוליה: מקור פרטי, קליטה מוגבלת, אריזה נבחרת, כניסת צופה מורשית. אף אחת מהחוליות האלה אינה ניתנת לדילוג, ואף אחת לא נוצרת מפתיחת פורט.