מה זה שידור SRT? השוואה בין SRT ל-RTMP

SRT הוא פרוטוקול להעברת וידאו שנבנה כדי לשרוד רשתות לא אמינות. כך הוא משחזר חבילות שאבדו, מה עושה הגדרת ה-latency, איך הוא משתווה ל-RTMP, ולמה רוב הפלטפורמות עדיין מבקשות RTMP.

StreamHouse Teamפורסם 30 באוקטובר 2026 · כ־6 דקות קריאה

בעמוד הזה

SRT (Secure Reliable Transport) הוא פרוטוקול קוד פתוח לשליחת וידאו חי ברשתות לא צפויות כמו האינטרנט הציבורי. הוא רץ מעל UDP, מבקש מחדש חבילות שאבדו, מאפשר לבחור כמה השהיה להחליף תמורת אמינות, ויכול להצפין את השידור. גופי שידור משתמשים בו כדי להעביר פידים באיכות גבוהה בין מיקומים.

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

עיקרי הדברים
SRT משתמש ב-UDP ומשחזר חבילות שאבדו בתוך חלון latency שאתם קובעים.
הוא מתאים לקישורים ארוכי טווח או עם אובדן חבילות, כמו אתרי אירוע מרוחקים ופידי contribution.
רוב פלטפורמות היוצרים עדיין מתעדות ingest של RTMP או RTMPS.
הצפנת AES עם סיסמה משותפת מגנה על פידי SRT בזמן המעבר.

מאיפה SRT הגיע ואיזו בעיה הוא פותר

SRT פותח על ידי חברת הווידאו Haivision ושוחרר כקוד פתוח ב-2017. היום הוא נתמך במגוון רחב של encoders, decoders, שרתי מדיה ותוכנות, כולל OBS ו-FFmpeg.

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

הוא עושה את זה בלי להתעניין הרבה במה שיש בתוך השידור. SRT הוא שכבת העברה, לא פורמט וידאו, ובדרך כלל הוא נושא MPEG transport stream שמכיל וידאו H.264 או HEVC עם אודיו AAC. הגמישות הזו עזרה לתהליכי עבודה מקצועיים לאמץ אותו במהירות.

איך עובדים שחזור החבילות ומאגר ה-latency

RTMP רוכב על TCP, שמשדר מחדש מידע שאבד אבל מאט את כל החיבור בכל פעם שמתגלה אובדן. בקישורים ארוכי טווח עם אובדן חבילות, זה מתבטא בתקיעות וב-buffering.

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

גודל המאגר הוא הגדרת ה-latency. ערכים גדולים יותר סובלים רשתות גרועות יותר במחיר של השהיה; ערכים קטנים שומרים על השהיה נמוכה אבל מוותרים על חבילות שמגיעות מאוחר מדי. נקודת פתיחה נפוצה היא כמה פעמים זמן הסבב (round-trip) בין השולח למקבל, עם הגדלה לקישורים לא יציבים. כלים שונים מבטאים latency ביחידות שונות, אז בדקו את התיעוד.

הצפנה, מזהי שידור ומצבי חיבור

SRT כולל פיצ'רים ש-RTMP לא מציע בעצמו:

הצפנה. AES עם סיסמה ששני הצדדים חולקים, עם מפתחות של 128, 192 או 256 סיביות. RTMP צריך את הגרסה הנפרדת RTMPS כדי להיות מוצפן.
Stream ID. מזהה אופציונלי שמאפשר לפורט קליטה אחד לקבל כמה פידים ולנתב כל אחד נכון, קצת כמו מפתח שידור.
מצבי חיבור. צד אחד מאזין בפורט והשני מתקשר אליו. מצב שלישי, rendezvous, גורם לשני הצדדים להתחבר בו-זמנית, מה שיכול לעזור כששניהם נמצאים מאחורי חומות אש.

מכיוון ש-SRT משתמש ב-UDP, פורט ה-UDP של הצד המאזין חייב להיות פתוח בכל חומת אש בדרך, בניגוד לחיבורי ה-TCP היוצאים של RTMP. לצד של RTMP, ראו איך RTMP עובד ו-RTMP מול RTMPS.

SRT מול RTMP: איפה כל אחד מנצח

אף פרוטוקול לא פשוט טוב יותר; כל אחד טוב בעבודות אחרות.

SRT מנצח ב-contribution. שליחת פיד מאתר אירוע מרוחק, מצוות שטח או מקישור סלולרי בחזרה למרכז ההפקה היא המקום שבו שחזור החבילות משתלם, וכך גם שרשראות שידור שמזינות מערכות playout, decoders ושרתי מדיה.
SRT מתמודד טוב יותר עם מרחק. בקישורים בין יבשות עם אובדן חבילות ו-jitter, מאגר latency מכוון היטב מניב בדרך כלל תוצאות יציבות יותר מ-RTMP שמבוסס על TCP.
RTMP מנצח בתאימות. כמעט כל encoder, שירות ופלטפורמה תומכים בו, וההגדרה היא רק כתובת ועוד מפתח.
RTMP פשוט יותר להטמעה. אין פורטי UDP, כוונון latency או סיסמאות לתאם.

כלל מעשי: השתמשו ב-SRT בין מערכות שאתם או שותף שולטים בהן, וב-RTMP או RTMPS לקפיצה האחרונה אל פלטפורמות ציבוריות.

למה YouTube, Twitch ורוב הפלטפורמות עדיין מבקשות RTMP

אם SRT כל כך עמיד, למה פלטפורמות היוצרים הגדולות ממשיכות לתעד ingest של RTMP ו-RTMPS?

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

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

לשלוח RTMP ו-SRT מאותו שידור בענן

הרבה מערכים צריכים את שני הפרוטוקולים בבת אחת: RTMP לפלטפורמות ציבוריות ו-SRT לאולפן, לשרת playout או למקלט של שותף. מ-encoder ביתי, זה אומר שני פלטים והעלאה כפולה.

StreamHouse מטפלת בזה בענן. הוסיפו YouTube, Twitch או Kick דרך RTMP או RTMPS, ועוד פלט SRT מותאם אישית שמכוון למקלט שלכם, לאותו שידור. שידור אחד מגיע לכולם, ויעדים נוספים לא צורכים משבצות שידור נוספות.

לתוכן מוקלט מראש, העלו את הסרטונים שלכם, שמוכנים מראש לפרופיל קידוד אחיד אחד, ואז בנו פלייליסט והפעילו או תזמנו אותו. השידור רץ בלופ 24/7, מתחבר מחדש אוטומטית אחרי תקלות רשת וממשיך לרוץ כשהמחשב שלכם כבוי.

שאלות נפוצות

האם SRT טוב יותר מ-RTMP לשידור?

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

האם ל-SRT יש השהיה נמוכה יותר מ-RTMP?

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

האם OBS יכול לשדר ב-SRT?

כן. הזינו כתובת srt:// כשרת מותאם אישית ב-OBS, עם פרמטרים כמו mode, latency ו-passphrase שכלולים בכתובת. השרת או השירות המקבל חייבים לתמוך ב-SRT ולהיות מוגדרים לקבל את החיבור.

האם SRT מוצפן כברירת מחדל?

רק כשמגדירים סיסמה. עם אותה סיסמה בשני הצדדים, SRT מצפין את הפיד באמצעות AES עם מפתחות של 128, 192 או 256 סיביות. בלי סיסמה הוא עובר לא מוצפן, אז הגדירו אחת לפידים שחוצים את האינטרנט הציבורי.