הזרמת HLS ממכשיר נייד אינה טריוויאלית. הטלפון משמש כמקור: הוא לוכד וידאו בקטעים, מעלה אותם לשרת HTTP, ומעדכן את רשימת ההשמעה m3u8. בניגוד לנגינת HLS, כאן חשוב להבטיח לכידה יציבה, אריזה מהירה ל-TS, והעלאה אמינה. אנו מיישמים פרויקטים כאלה במפתח סגור: מבחירת פרוטוקול ועד אינטגרציית CDN. להלן נפרט את הפרטים הטכניים.
כיצד פועל HLS-push ממכשיר
התכנית הקלאסית: טלפון → HTTP PUT/POST של קטעי TS + עדכון .m3u8 → שרת origin HTTP → CDN → צופים. חלופה: טלפון → RTMP → שרת מדיה → HLS לצופים (אז HLS נוצר על ידי השרת, לא הטלפון). HLS-push ישיר נתמך על ידי: Apple Media Stream Segmenter (macOS בלבד), CloudFront עם WebDAV, Akamai Media Services, ו-nginx מותאם אישית עם ngx_http_dav_module. אנו מעדיפים שרת origin הניתן להתאמה אישית כי הוא נותן שליטה מלאה על זמן השהיה ופורמט הקטעים.
השוואת גישות ב-iOS וב-Android
| פלטפורמה | כלי | מקודד | פורמט קטעים | אמינות | זמן השהיה |
|---|---|---|---|---|---|
| iOS | FFmpegKit (h264_videotoolbox) | חומרה H.264 | MPEG-TS | גבוהה | 6–30 שניות (רגיל) / 2–4 שניות (LL-HLS דרך שרת) |
| iOS | מקטע TS מותאם אישית | חומרה H.264 | MPEG-TS (PES/PMT ידני) | בינונית (שגיאות אריזה) | דומה |
| Android | FFmpegKit (h264_mediacodec) | חומרה H.264 | MPEG-TS או fMP4 | גבוהה | 6–30 שניות |
| Android | MediaMuxer עם fMP4 | חומרה H.264 | fMP4 (HLS v7+) | נמוכה (לא סטנדרטי) | גבוה יותר עקב בופינג |
למה לבחור ב-HLS-push ישיר על פני RTMP?
RTMP הוא פרוטוקול עם חיבור קבוע, הדורש שרת ממסר (למשל, Nginx-RTMP). זה מוסיף קפיצה נוספת ומגדיל את זמן השהיה. HLS-push ישיר עובד דרך HTTP, ומאפשר העלאה ישירה של קטעים ל-CDN (Akamai, CloudFront). החיסרון הוא שזה דורש קוד לקוח חכם יותר לאריזת TS והעלאה. הניסיון שלנו מראה שעבור שידורים חיים עם עד 10,000 צופים, HLS-push עובד בצורה יציבה וזולה יותר מ-RTMP+CDN. החיסכון בתשתית יכול להגיע ל-30–40%.
כיצד ליישם הזרמת HLS ב-iOS?
ל-iOS אין מקודד HLS מובנה לשידור חי—רק AVAssetExportSession לקבצים. עבור HLS חי אנו בונים את הצינור באופן ידני:
AVCaptureSession → AVCaptureVideoDataOutput → VideoToolbox (encode H.264) →
накапливаем NAL units в TS-сегменты по 2-4 секунды →
URLSession.uploadTask на сервер →
обновляем m3u8 манифестהרכבת MPEG-TS מיחידות NAL דורשת אריזה ידנית של חבילות PES עם טבלאות PAT/PMT. אין ספרייה מוכנה ב-Swift. לכן, בפועל אנו משתמשים ב-FFmpegKit:
-f avfoundation -i 0:0 -c:v h264_videotoolbox -b:v 2M -hls_time 2 -hls_list_size 5 -hls_flags delete_segments -method PUT http://origin/stream/index.m3u8 AVCaptureSession → AVCaptureVideoDataOutput → VideoToolbox (encode H.264) → накапливаем NAL units в TS-сегменты по 2-4 секунды → URLSession.uploadTask на сервер → обновляем m3u8 манифест הוא מקודד החומרה. הדגל -f avfoundation -i 0:0 -c:v h264_videotoolbox -b:v 2M -hls_time 2 -hls_list_size 5 -hls_flags delete_segments -method PUT http://origin/stream/index.m3u8 מעלה קטעים ורשימת השמעה לשרת. זה עובד עם עומס CPU מתון.
מה זה Low-Latency HLS ומתי צריך אותו?
ל-HLS רגיל יש זמן השהיה של 6–30 שניות. LL-HLS מפחית אותו ל-2–4 שניות באמצעות הוראות h264_videotoolbox (שהוצגו על ידי Apple ב-WWDC). יצירת חלקי LL-HLS (משך 0.2–0.5 שניות) ממכשיר נייד היא קשה ביותר ללא מקודד ייעודי. גישה מעשית יותר: המכשיר דוחף RTMP עם בופור קטן, ושרת המדיה (Nimble Streamer, Wowza) עם תוסף LL-HLS יוצר את הזרם לצופים. זהו פתרון מוכח שאנו ממליצים עליו אם זמן השהיה קריטי.
השוואת תכניות: HLS-push ישיר מול RTMP+שרת
| קריטריון | HLS-push ישיר | RTMP + שרת מדיה |
|---|---|---|
| זמן השהיה | 6–30 שניות (רגיל) | 8–35 שניות (כולל ממסר) |
| תשתית | שרת origin HTTP | שרת RTMP (Nginx-RTMP, Wowza) |
| מורכבות לקוח | גבוהה (סגמנטציה) | בינונית (דחיפת RTMP) |
| אינטגרציית CDN | ישירה (בקשות PUT) | דרך שרת ממסר |
| סובלנות תקלות | גבוהה (HTTP קל יותר לשמירה במטמון) | בינונית (חיבור RTMP חייב להיות קבוע) |
מה כלול ביישום HLS streaming במפתח סגור
- ניתוח דרישות: קצב סיביות, רזולוציה, קהל יעד, CDN.
- בחירת תכנית: HLS-push ישיר או RTMP → שרת.
- פיתוח אפליקציית לקוח: iOS (Swift + FFmpegKit) או Android (Kotlin + FFmpegKit).
- הגדרת שרת origin: nginx עם מודול DAV או CDN צד שלישי (Akamai, CloudFront).
- בדיקות: בדיקות עומס, בדיקות זמן השהיה, יציבות תחת אות חלש.
- תיעוד והדרכה: תיאור אינטגרציה, הגדרת פרופיל provisioning עבור push notifications ומשימות רקע.
מפרט HLS Authoring של Apple
מידע נוסף על הגדרת שרת origin
כדי להגדיר שרת origin, אנו משתמשים לעתים קרובות ב-nginx עם המודול ngx_http_dav_module. התצורה מאפשרת קבלת בקשות PUT מהמכשיר והגשת קטעי TS ורשימת ההשמעה m3u8. דוגמה לבלוק location: /stream { dav_methods PUT; dav_access user:rw group:rw; }תהליך עבודה
- ניתוח: קביעת פרוטוקול, זמן השהיה נדרש, קיבולת אחסון בשרת.
- עיצוב: תכנית צינור (לכידה → קידוד → סגמנטציה → העלאה → מניפסט).
- יישום: כתיבת קוד ב-Swift/Kotlin, אינטגרציית FFmpegKit.
- בדיקות: על מכשירים אמיתיים (iPhone 12, Pixel 6) עם קצבי סיביות ורשתות שונים.
- פריסה: פרסום ל-App Store / Google Play, הגדרת שרת, ניטור.
לוחות זמנים משוערים
יישום דרך FFmpegKit עם העלאה ל-origin: בין 2 ל-3 ימים. מקטע TS מותאם אישית ו-LL-HLS: בין שבוע לשבועיים. לוחות זמנים מדויקים תלויים במורכבות האינטגרציה (מספר קצבי סיביות, תמיכה בהזרמת רקע).
טעויות נפוצות וכיצד להימנע מהן
- התעלמות מ-Push Notifications: עבור HLS-push ברקע, הגדר כראוי
-method PUT(iOS) ו-EXT-X-PART(Android). - תזמון קטעים שגוי: קטעים ארוכים מ-6 שניות מגדילים את זמן השהיה ואת הסיכון להפרעה בצד הצופה.
- חוסר טיפול בשגיאות העלאה: HTTP 4xx/5xx צריך להפעיל שידור חוזר של הקטע עם backoff אקספוננציאלי.
- הזנחת טבלאות PAT/PMT: בהרכבה ידנית של TS, כל שגיאה הופכת את הזרם לבלתי קריא עבור נגנים.
הניסיון שלנו: 5+ שנים בהזרמת מובייל ויותר מ-10 פרויקטים שהושלמו. קבלו ייעוץ להערכת הפרויקט שלכם. צרו קשר—ננתח את הדרישות שלכם ונציע ארכיטקטורת הזרמת HLS אופטימלית ממכשיר נייד. אנו מבטיחים פעולה יציבה ועמידה בהנחיות סקירת App Store (iOS) ובמדיניות Google Play.