FFmpeg יכול לפרסם מקור בדיקת RTMP לנקודת קצה שהוקצתה, אך פקודה שהושלמה אינה תוצאת הקבלה. השתמשו בקלט מוכר, הגנו על כתובת ה-URL והמפתח, ולאחר מכן אמתו את פעילות המפרסם, המדיה המפוענחת ונתיב המקלט שנבחר.
בחרו תחילה את מצב הגישה
במצב מבוקר, Publisher ו-Receiver הם תפקידים נפרדים באותו שם זרם מוגדר ויכולים להשתמש באותה כתובת URL של RTMP. במצב Guest, פתחו במכוון את נקודת הקצה והשתמשו בשם זרם שאינו ריק; על המקלט להשתמש באותו שם.
לפני הפרסום
קבלו מהפריסה את כתובת ה-URL לפרסום RTMP ואת מפתח הזרם. אל תדביקו מפתח אמיתי בהיסטוריית מעטפת, בכרטיס פנייה או במאמר. ודאו שבניית FFmpeg שלכם חושפת תמיכה ב-RTMP: תיעוד הפרוטוקולים של FFmpeg מתאר אפשרויות פרוטוקול; תיעוד הפורמטים שלו מכסה את התנהגות ה-muxer.
ffmpeg -protocols | grep rtmpתוצאה צפויה: הפקודה מציגה גרסת RTMP הנתמכת בבנייה זו. אם לא, התאימו את הבדיקה לבנייה המותקנת במקום להניח שחבילה כוללת את הפרוטוקול.
פרסמו קובץ בקצב זמן אמת
ffmpeg -re -stream_loop -1 -i input.mp4 -c copy -f flv "rtmp://INGEST_HOST:PORT/APP/STREAM_NAME_OR_KEY"תוצאה צפויה: FFmpeg ממשיך לדווח על התקדמות פריימים במקום לשלוח את הקובץ במהירות שהאחסון מאפשר. -re קורא קובץ בקצב המקורי שלו בבדיקה תחומה זו. החליפו את מצייני המקום בערכים שהוקצו עבור המאזין; אל תשנו את נתיב היישום או את המפתח.
בצעו המרה כאשר חוזה הפלט דורש זאת
ffmpeg -re -stream_loop -1 -i input.mov -c:v libx264 -pix_fmt yuv420p -g 60 -c:a aac -ar 48000 -b:a 128k -f flv "rtmp://INGEST_HOST:PORT/APP/STREAM_NAME_OR_KEY"תוצאה צפויה: המקלט רואה מפרסם רציף עם וידאו ושמע הניתנים לפענוח. זו דוגמה, לא מרשם קידוד אוניברסלי: בחרו קצב פריימים, מרווח GOP/פריימי מפתח, קצב סיביות, רזולוציה ופרמטרי שמע עבור המקלט ותהליך ההפצה בפועל.
אמתו בשרת, ואז בתוצאה המיועדת
- ודאו ש-RTMP Server מדווח על המפרסם הצפוי ועל קצב הסיביות הנכנס.
- בדקו תמונה ושמע מהמקלט שהוגדר או מנקודת הניטור.
- בדקו את פלט ההמשך היחיד המיועד: הקלטה, ניתוב או נגן דפדפן.
- הפסיקו את התהליך פעם אחת ואמתו את מצב המקלט ואת תוכנית ההתאוששות.
עבור התקן לכידה חי, החליפו את קלט הקובץ בתחביר קלט ה-FFmpeg המתועד שלו ושמרו על אותן בדיקות קבלה בצד השרת. הימנעו מלולאות התחברות מחדש אוטומטיות עד שתדעו כיצד המאזין מטפל בהפעלות כפולות; לולאה עלולה להסתיר את השגיאה השימושית הראשונה.
בחרו בפרוטוקול נקודת הקצה שסופק
השתמשו בפרוטוקול נקודת הקצה שסופק עבור משימה זו. Callaba RTMP Server מספק את המאזין, כללי הגישה ותצוגת הפעילות; צפייה בדפדפן משתמשת בפלט שהוגדר בנפרד.
תצורה קשורה
הגדירו את המאזין ב-Callaba RTMP Server, השתמשו ב-מדריך המפעיל לבדיקות גישה ומצב, או עקבו אחר RTMP ל-HLS כאשר התוצאה המיועדת היא הפצה בדפדפן.
שולח ומקלט אבחון מקומיים
ffmpeg -re -f lavfi -i testsrc2=size=1280x720:rate=30 -f lavfi -i sine=frequency=1000:sample_rate=48000 -c:v libx264 -pix_fmt yuv420p -g 60 -c:a aac -b:a 128k -f flv "rtmp://INGEST_HOST:PORT/APP/STREAM_NAME_OR_KEY"תוצאה צפויה: FFmpeg מדווח על פריימי וידאו בקצב של כ-30 fps ועל זרם שמע אחד; Callaba מדווחת על קצב הסיביות של הקלט. ערך GOP של 60 נותן פריים מפתח כל שתי שניות ב-30 fps, נקודת פתיחה מעשית לתהליך מקטעים של שתי שניות — לא הגדרת שרת נדרשת.
העתיקו רק לאחר בדיקת הקלט: ffprobe -v error -show_entries stream=codec_name,codec_type -of default=nw=1 input.mp4. השתמשו בפלט זה כדי להשוות את פרטי קודק הקלט והשמע לחוזה המתועד של המקלט. העתקה סבירה רק לאחר שהם תואמים. עבור מקלט אבחון, ffplay -fflags nobuffer "rtmp://RECEIVER_HOST:PORT/APP/STREAM_NAME_OR_KEY" אמור לפתוח תמונה וצליל לאחר שהמקלט מתחבר. עיינו ב-מקורות המסננים של FFmpeg עבור testsrc2 ו-sine.
השלבים הבאים
הגדירו את המאזין ב-Callaba RTMP Server, ולאחר מכן אמתו גישה ופעילות ב-מדריך המפעיל.
