שידור 24/7 על VPS מול שירות ענן מנוהל: מה באמת עדיף?
הרצת שידור 24/7 על VPS עם FFmpeg נראית פשוטה, עד שהפלייליסט מתחיל מההתחלה, התהליך קורס באמצע הלילה או שיעד נוסף מכפיל את התעבורה היוצאת. הנה מה שבאמת כרוך בפתרון עצמאי, ומתי שירות מנוהל הגיוני יותר.
כ־6 דקות קריאה
בעמוד הזה
אפשר בהחלט להריץ שידור 24/7 על VPS עם FFmpeg: מעלים את הסרטונים לשרת שכור, כותבים פלייליסט concat ומריצים אותו בלולאה אל כתובת ה-RTMP של הפלטפורמה. זה עובד, וזה יכול להיות גם פרויקט לימודי מצוין. העלות האמיתית היא הזמן שלכם, שהולך על קידוד, התאוששות מקריסות, ניטור ותכנון רוחב פס.
הנה מה שבאמת כרוך בפתרון עשה-זאת-בעצמך, ומתי שירות מנוהל הוא שימוש טוב יותר בשעות שלכם.
עיקרי הדברים
- לולאת FFmpeg בסיסית מקימים מהר; לשמור עליה פעילה במשך חודשים, זו העבודה האמיתית.
- קצבי פריימים או חותמות זמן שאינם תואמים עלולים להקריס פלייליסט במצב copy ולהחזיר אותו להתחלה.
- FFmpeg לא יפעיל את עצמו מחדש ולא ישלח לכם התראה.
- כל יעד נוסף מוסיף את מלוא קצב הסיביות שלו לתעבורה היוצאת.
איך נראית תצורת VPS עצמאית
מערך האירוח העצמי הטיפוסי מורכב מארבעה חלקים:
- VPS מבוסס Linux עם מספיק שטח דיסק לספריית הסרטונים ומספיק תעבורה יוצאת לשידור שלעולם לא נעצר.
- קובצי הווידאו שלכם, שמועלים דרך SFTP או מסונכרנים מאחסון.
- קובץ פלייליסט עבור ה-concat demuxer של FFmpeg.
- פקודת FFmpeg שקוראת את הפלייליסט בזמן אמת, מריצה אותו בלולאה ודוחפת אותו לכתובת ingest כמו
rtmp://a.rtmp.youtube.com/live2יחד עם המפתח שלכם.
רוב המדריכים משתמשים במצב stream copy, שבו FFmpeg מעביר את הווידאו והאודיו כמו שהם, בלי קידוד מחדש. צריכת ה-CPU נשארת זעירה, כך ששרת קטן מסתדר, והשידור הראשון באמת עולה לאוויר מהר.
הבעיה: מצב copy עובד חלק רק כשכל הקבצים עקביים מבחינה טכנית, ושם בדיוק הולך המאמץ לטווח הארוך.
קידוד וחותמות זמן: למה פלייליסטים של FFmpeg מתחילים מחדש
במצב stream copy, FFmpeg מחבר את הקבצים זה לזה כמו שהם, כך שקובץ חריג אחד שובר את נקודות החיבור. החשודים הקבועים:
- קצבי פריימים שאינם תואמים, למשל ייצוא ב-29.97 fps לצד קבצים ב-30 fps, או הקלטת טלפון עם קצב פריימים משתנה.
- רזולוציות או פורמטי אודיו שונים, כמו קליפ ב-720p בין קבצים ב-1080p.
- בסיסי זמן חריגים או חותמות זמן חסרות שמשאירים אחריהם חלק מעורכי הווידאו ומקליטי המסך.
התסמינים נעים בין אזהרות בלוג, דרך וידאו קפוא ועד יציאה של FFmpeg. כשהוא מופעל מחדש, הפלייליסט מתחיל שוב מהסרטון הראשון, והצופים רואים את אותה שעת פתיחה שוב ושוב.
הפתרון הוא לקודד מחדש את כל הקבצים לפרופיל אחד לפני שהם נכנסים לפלייליסט: אותה רזולוציה, קצב פריימים קבוע, אותו מרווח keyframes ואותו פורמט אודיו. ראו הגדרות קידוד לשידור 24/7.
קריסות, הפעלות מחדש וניטור, הכול עליכם
FFmpeg הוא כלי מצוין, אבל הוא תהליך יחיד שלא אכפת לו אם הוא נשאר בחיים. כשהפלטפורמה מנתקת את החיבור, הרשת מגמגמת או שקובץ מסוים גורם לשגיאה, הוא פשוט יוצא, ושום דבר לא מחזיר אותו, אלא אם בניתם:
- מפקח תהליכים, למשל שירות systemd עם הפעלה מחדש אוטומטית.
- מעקב אחר המיקום, כדי שהפעלה מחדש לא תתחיל את הפלייליסט מההתחלה.
- בדיקות תקינות שמוודאות שהפלטפורמה באמת מקבלת וידאו, כי תהליך שרץ עדיין יכול להופיע כלא מחובר.
- התראות לטלפון, כדי שתקלה בשלוש לפנות בוקר לא תימשך עד ארוחת הבוקר.
ויש גם תחזוקה שוטפת: עדכונים, אתחולים, דיסקים שמתמלאים בלוגים ומפתחות שידור שיושבים בטקסט גלוי בתוך סקריפטים. שום דבר מזה לא קשה לבד; ביחד זו משרה חלקית. ראו ניטור תקינות וזמינות השידור כדי לדעת על מה לשים עין.
רוחב פס וכמה יעדים משרת אחד
שידור שלא נעצר צורך יותר נתונים ממה שאנשים מצפים. שידור אחד של 6 Mbps שרץ 30 יום שולח בערך 1.9 TB. שלחו אותו לשלוש פלטפורמות, והשרת דוחף כ-18 Mbps מסביב לשעון, קרוב ל-6 TB בחודש. בדקו את מכסת התעבורה היוצאת של הספק ואת תנאי החריגה.
ל-FFmpeg עם כמה יעדים יש שיגעונות משלו. תהליך אחד לכל פלטפורמה פירושו כמה תהליכים שצריך לפקח עליהם. ה-tee muxer של FFmpeg שולח קלט אחד לכמה יציאות, אבל יעד אחד שנכשל, למשל פלטפורמה שדוחה מפתח שפג תוקפו, יכול להפיל את כל התהליך, אלא אם כל יציאה מוגדרת לסבול כשלים.
גם השיגעונות של הפלטפורמות הם באחריותכם, כמו מגבלת הארכיון של 12 שעות ב-YouTube, שלולאה פשוטה מתעלמת ממנה.
מתי שידור עצמאי על VPS הוא הבחירה הנכונה
אירוח עצמי מתאים כשרוב הדברים האלה נכונים:
- אתם מרגישים בנוח בשורת הפקודה של Linux ונהנים לתחזק מערכות.
- אתם משדרים ליעד אחד, או שאתם מוכנים לבנות טיפול בכשלים עבור כמה יעדים.
- ספריית הסרטונים שלכם קטנה ויציבה, ואתם שולטים באופן שבו כל קובץ מיוצא.
- הפעלה מחדש מדי פעם מראש הפלייליסט לא מפריעה במיוחד לקהל שלכם.
- אתם רוצים ללמוד איך שידור עובד מתחת למכסה המנוע.
שירות מנוהל הגיוני יותר כשהשידור תומך בהכנסה או במותג, כשאתם מוסיפים סרטונים לעיתים קרובות, כשאתם צריכים כמה פלטפורמות, או כשעדיף להשקיע את הזמן שלכם בתוכן. ההשוואה ההוגנת היא חשבון השרת בתוספת שעות של הקמה ותיקונים בשעות הלילה, מול שירות שכבר פתר את הבעיות האלה.
להריץ את אותה לולאת 24/7 ב-StreamHouse במקום
StreamHouse מחליף כל אחד מהרכיבים במערך הזה. הסרטונים שמועלים מוכנים מראש לפרופיל קידוד אחיד, שמשאיר את קצב הסיביות וחותמות הזמן יציבים, כך שקובץ לא תואם לא מתחיל את הפלייליסט מחדש. בונים את הפלייליסט בדפדפן, מוסיפים יעדים כמו YouTube, Twitch, Rumble, Facebook, RTMP מותאם אישית או SRT, ולוחצים על Start או מתזמנים שעה.
הלולאה רצה 24/7 בענן ומתחברת מחדש אוטומטית אחרי תקלות בפלטפורמה או ברשת. אפשר להוסיף, להסיר או לשנות את סדר הסרטונים בזמן השידור; השינויים חלים מהסרטון הבא. יעדים נוספים לא צורכים משבצות שידור נוספות, ובערוץ YouTube מחובר, הגנת ההקלטה יכולה לסגור את השידור הראשון בנקודה שתבחרו ולהמשיך בשידור חדש בלי להתחיל את הפלייליסט מחדש.
השוו בין מינויים לבין קרדיטים בתשלום לפי שימוש בדף המחירים.
שאלות נפוצות
אפשר להריץ שידור YouTube 24/7 עם FFmpeg על VPS?
כן. פקודת FFmpeg בלולאה שמכוונת לכתובת ה-RTMP של YouTube משאירה ערוץ בשידור חי. החלק הקשה הוא לשמור עליו תקין במשך שבועות: קידוד עקבי, הפעלות מחדש אוטומטיות, ניטור וארכוב של שידורים ארוכים, הכול עליכם.
למה הפלייליסט שלי ב-FFmpeg ממשיך להתחיל מההתחלה?
בדרך כלל קובץ אחד לא תואם לשאר, עם קצב פריימים, רזולוציה או פורמט אודיו שונים. במצב copy חותמות הזמן נשברות, FFmpeg יוצא ומתחיל מחדש מהסרטון הראשון. קודדו מחדש כל קובץ לפרופיל קבוע אחד.
כמה רוחב פס צורך שידור 24/7 בחודש?
בערך 1.9 TB לשידור אחד של 6 Mbps שרץ ברציפות 30 יום, ויותר באופן יחסי לקצבי סיביות גבוהים יותר או ליעדים נוספים. שלוש פלטפורמות בקצב הזה פירושן קרוב ל-6 TB, אז בדקו קודם את מכסת התעבורה של השרת.
צריך VPS חזק כדי לשדר 24/7?
לא, אם מקודדים את הקבצים מראש ומשתמשים ב-stream copy, שדורש מעט מאוד CPU. קידוד 1080p בזמן אמת על השרת הוא סיפור אחר: הוא דורש ליבות ייעודיות, ותוכניות משותפות קטנות לרוב לא עומדות בקצב של זמן אמת.
