תארו לעצמכם: משתמש מתחיל שידור חי, אבל תוך דקה צופים מתלוננים על עיכובים ופגמים. תרחיש טיפוסי: אפליקציית המובייל משתמשת בקידוד תוכנה, והרשת לא יכולה להתמודד עם קצב הסיביות הגבוה. התוצאה—אובדן קהל וביקורות שליליות. התחממות יתר וצריכת סוללה מהירה הן בעיה נוספת של קידוד תוכנה. אנחנו יודעים איך להימנע מכך. הצוות שלנו יישם למעלה מ-20 פרויקטים של שידור חי עבור iOS ו-Android, תוך הבטחת יציבות גם בחיבורים לא יציבים. חיסכון במשאבים: קידוד חומרה מפחית את צריכת החשמל ב-90% בהשוואה לתוכנה. מאחורי כל שידור עומד תהליך מורכב: לכידת מצלמה, קידוד חומרה H.264/H.265, אריזת קונטיינר, שליחה לשרת מדיה, והעברה ל-CDN. לכל שלב יש API ומהמורות משלו. בואו נפרק אותם בפירוט.
לכידת וידאו ואודיו
AVCaptureSession הוא נקודת הכניסה ב-iOS. אנו מגדירים את הגדרת האיכות (sessionPreset = .hd1280x720), מוסיפים AVCaptureDeviceInput עבור מצלמה ומיקרופון, מוסיפים AVCaptureVideoDataOutput ו-AVCaptureAudioDataOutput עם נציגים (delegates). captureOutput(_:didOutput:from:) מספק CMSampleBuffer—פריימים גולמיים מהמצלמה בזמן אמת.
כיוון: יש לעדכן את AVCaptureConnection.videoOrientation בעת סיבוב המכשיר. אחרת, הצופים יראו וידאו הצידה אם השידור מתחיל במצב לאורך.
ב-Android, אנו משתמשים ב-Camera2 API או CameraX (מומלץ). CameraX.bindToLifecycle() עם Preview + VideoCapture use case. VideoCapture.output.prepareRecording() הוא הקלטה מקורית. לשידור חי אנו צריכים זרם גולמי: ImageAnalysis use case עם setOutputImageFormat(OUTPUT_IMAGE_FORMAT_YUV_420_888), פריימים מעובדים ידנית דרך MediaCodec.
| פלטפורמה | API לכידה | זרם פריימים |
|---|---|---|
| iOS | AVCaptureSession | CMSampleBuffer |
| Android | CameraX/Camera2 | YUV_420_888 (Image) |
למה קידוד חומרה?
FFmpeg תוכנתי בטלפון פירושו התחממות יתר וסוללה מתה תוך 20 דקות. אנו משתמשים רק במקודדי חומרה: VideoToolbox ב-iOS ו-MediaCodec ב-Android. זה חסכוני באנרגיה פי 10 ומספק 30 fps יציבים ב-720p. המפתחים המוסמכים שלנו מבטיחים אינטגרציה אמינה של קידוד חומרה.
ב-iOS: VideoToolbox—VTCompressionSession. אנו יוצרים סשן עם kVTVideoEncoderSpecification_RequireHardwareAcceleratedVideoEncoder: kCFBooleanTrue. ה-outputCallback מקבל CMSampleBuffer עם H.264/H.265 מקודדים.
פרמטרים מרכזיים:
-
kVTCompressionPropertyKey_RealTime: kCFBooleanTrue— מצב זמן אמת -
kVTCompressionPropertyKey_ProfileLevel: kVTProfileLevel_H264_High_AutoLevel -
kVTCompressionPropertyKey_AverageBitRate: 2_000_000(2 Mbps עבור 720p) -
kVTCompressionPropertyKey_MaxKeyFrameInterval: 60(פריים מפתח כל 2 שניות ב-30 fps)
ב-Android: MediaCodec. MediaFormat.createVideoFormat("video/avc", width, height). configure(format, null, null, MediaCodec.CONFIGURE_FLAG_ENCODE). ב-dequeueOutputBuffer אנו מקבלים יחידות NAL מקודדות.
לאודיו: AudioRecord → MediaCodec עם audio/mp4a-latm (AAC-LC). קצב דגימה 44100 הרץ, קצב סיביות 128 kbps.
איך להבטיח יציבות שידור?
קצב סיביות אדפטיבי (ABR) הוא המנגנון המרכזי לשידור חי ממצלמה. אנו עוקבים אחר מהירות ההעלאה: RTMPStream.info.byteCount ב-HaishinKit, קריאת חוזר NetworkInfo ב-rtmp-rtsp-stream-client-java. אם רוחב הפס יורד, אנו מפחיתים ברצף את קצב הסיביות, קצב הפריימים והרזולוציה. מרווח הבדיקה האופטימלי הוא 5-10 שניות כדי למנוע תנודות חדות באיכות. גישה זו מפחיתה הפרעות ב-70%.
HaishinKit היא ספרייה פופולרית ל-iOS המטפלת בזרמי RTMP ו-SRT. עבור Android, אנו משתמשים באופן דומה ב-CMSampleBuffer.
אריזה ל-RTMP או SRT
מפלט MediaCodec/RTMPStream אנו מקבלים יחידות NAL של H.264 ופריימים של AAC. יש לארוז אותם בפרוטוקול תעבורה. אנו משתמשים ב-SRT בזכות עמידות הרשת שלו, או RTMP לתאימות רחבה עם CDN.
ספריות מוכנות:
- iOS: HaishinKit (Swift)—RTMP, SRT, HLS. Swift מקורי ללא תלות ב-FFmpeg.
SRTStream,rtmp-rtsp-stream-client-java. - Android:
RtmpCamera2(Pedro Vicente)—דחיפת RTMP ו-RTSP.SRTStreamעם CameraX.rtmp_streamingעבור SRT. - Flutter:
ffmpeg-kit-ios(עטיפה על ספריות מקוריות) או ערוץ פלטפורמה מקורי. - חוצה פלטפורמות עם FFmpeg:
ffmpeg-kit-android/FFmpegKit.executeAsync("-f avfoundation -i 0:0 -c:v libx264 -preset ultrafast -f flv rtmp://...")—AVCaptureVideoPreviewLayer. עובד אבל מעמיס על המעבד יותר ממקודד חומרה.
השוואה בין RTMP ל-SRT
SRT טוב פי 2-3 מ-RTMP מבחינת חביון ועמידות בפני אובדן נתונים.
| מאפיין | RTMP | SRT |
|---|---|---|
| חביון | 2-5 שניות | 0.5-2 שניות |
| עמידות בפני אובדן | נמוכה | גבוהה (FEC/ARQ) |
| תמיכת CDN | רחבה | גדלה |
| מקרה שימוש | שידורים מסורתיים | רשתות חלשות, סמינרים מקוונים |
לשידור חי ממובייל, אנו ממליצים על SRT בזכות עמידות הרשת שלו.
תצוגה מקדימה וממשק משתמש
תצוגה מקדימה של מצלמה—PreviewView (iOS) / AVCaptureSession.beginConfiguration() CameraX (Android). שכבת-על על גבי זה: מחוון "Live", מספר צופים, קצב סיביות, רמת אות.
מעבר בין מצלמה קדמית/אחורית ללא הפסקת השידור: iOS—commitConfiguration() → הסרת קלט ישן → הוספת חדש → stream.captureSettings.isVideoMirrored. HaishinKit תומך בזה בשורה אחת: stream.captureSettings.isVideoMirrored.
מה כלול בעבודת שידור חי
- לכידת וידאו/אודיו מהמצלמה
- קידוד חומרה עם כוונון פרמטרים
- אינטגרציה של הפרוטוקול הנבחר (RTMP/SRT/HLS)
- קצב סיביות אדפטיבי וניטור רשת
- ממשק תצוגה מקדימה עם מחווני שכבת-על
- בדיקות על מכשירים אמיתיים ברשתות שונות
- תיעוד אינטגרציה ותמיכה לאחר השקה
צרו קשר כדי לדון בפרויקט שלכם. הזמינו פיתוח שידור חי—קבלו ייעוץ ממהנדס מנוסה. תוכלו גם לבקש דוגמאות לפרויקטים שלנו. אנו מבטיחים איכות וניסיון מוכח עם למעלה מ-20 יישומים מוצלחים.
לוחות זמנים
שידור חי ממצלמה בפלטפורמה אחת (RTMP או SRT) עם תצוגה מקדימה וממשק בסיסי: 3-5 ימים. חוצה פלטפורמות עם קצב סיביות אדפטיבי, מעבר מצלמה ואינטגרציה ספציפית לשרת מדיה: 1-2 שבועות. עלות הפיתוח מתחילה מ-$3,000, עם הצעת מחיר מפורטת לאחר ניתוח דרישות.