תשובה קצרה: האצת חומרה יכולה לשנות את משאב העיבוד המשמש לנתיב קידוד או פענוח נתמך. תאימות המקודד של היעד ואיתות Enhanced RTMP נשארים בדיקות נפרדות. התחילו בחוזה הפלט, בדקו פרופיל אחד תחת עומס מייצג, ואז החליטו אם קיבולת העיבוד מספקת.
השתמשו בהאצה עבור משימת עיבוד מדודה
| שכבה | החלטה | בדיקת קבלה |
|---|---|---|
| קלט | האם אפשר לפענח את המקור או להעבירו כפי שהוא בתהליך העבודה שנבחר? | תמונת קלט יציבה, מיפוי שמע וטלמטריה של המקור |
| המרה | העברה כפי שהוא, אריזה מחדש, או רנדישן חדש של מקודד/רזולוציה/קצב סיביות? | המקודד, הפרופיל, הממדים, קצב הפריימים ו-GOP המוצהרים בפלט תואמים לחוזה המקלט |
| האצה | האם הפרופיל שנבחר זמין במשאב העיבוד שנבחר? | הרצה מתמשכת מראה מרווח קיבולת שמיש וללא פגיעה במדיה שהתקבלה |
| תעבורה | לאיזו נקודת קצה ואיזו תעבורה הפלט זקוק? | היעד מתחבר באמצעות כתובת ה-URL והאישורים שהוקצו לו |
| Enhanced RTMP | האם זוג השולח/המקלט תומך באיתות המקודד הנדרש? | המקלט מקבל את המדיה בפועל; אל תשפטו לפי החיבור בלבד |
הפרידו בין ארבע פעולות
העברה כפי שהוא משאירה את המדיה המקודדת ללא שינוי. אריזה מחדש משנה מכל או אריזה בלי בהכרח לקודד מחדש את הזרמים. קידוד מחדש מפענח ומקודד ייצוג חדש. האצת חומרה היא פרט מימוש של נתיב עיבוד נתמך, ולא פורמט מדיה רביעי. הגדירו את הפעולה הנדרשת לפני שאתם מתאימים את התשתית לגודל.
מה האצת מדיה משנה בפועל
האצה עשויה לספק משאב מתאים לפעולות וידאו נבחרות, אך הצפיפות השמישה תלויה במקודד/פרופיל, ברזולוציה, בקצב הפריימים, במורכבות הקלט, במשימות אחרות ובשילוב הפלטפורמה/מנהל ההתקן. AWS מתארת את VT1 כמשפחת מופעי Amazon EC2 עבור עומסי עבודה של קידוד וידאו מחדש; השתמשו בכך כהקשר תשתיתי, ואז בדקו את המקור, הפלט והפריסה שנבחרו ב-Callaba. בקרי האצת החומרה שייכים ל-Live Video Transcoding, אך עדיין יש להריץ פרופיל על חומר מייצג לפני אישורו לייצור.
Enhanced RTMP הוא חוזה יכולת פעולה הדדית
מפרט Veovera מוסיף איתות RTMP/FLV עבור מקודדים חדשים יותר, כולל HEVC ו-AV1. התעבורה עדיין יכולה להיות RTMP או RTMPS בהתאם ליעד. RTMPS מגן על החיבור באמצעות TLS, ואילו Enhanced RTMP מוסיף איתות מקודד. בדקו את שתי היכולות מול נקודת הקצה של היעד. תיעוד המקודד העדכני של YouTube ופרטי הקליטה שהוקצו ליעד הם סמכות התצורה עבור נתיב YouTube.
תעדו תוצאת קבלה
רשמו את המקודד, הפרופיל, מחזור ה-GOP/פריימי המפתח, השמע ונקודת הקצה הנדרשים ביעד, ואז הריצו את הרנדישן שנבחר תחת עומס מייצג. שמרו את תוצאת הפלט שהתקבל יחד עם הפרופיל כדי שהמפעיל הבא יוכל לחזור על הנתיב שפועל.
בנו פרופיל אחד מהיעד לאחור
- רשמו את דרישות התעבורה, המקודד, השמע, הרזולוציה, קצב הפריימים, קצב הסיביות ופריימי המפתח הנוכחיות של היעד.
- בדקו את המקור. העבירו אותו כפי שהוא רק כאשר חוזה המדיה המלא כבר תואם.
- אם נדרשת המרה, בחרו פרופיל פלט שתואם לחוזה היעד וקבעו אם נתיב ההאצה שנבחר זמין.
- הריצו חומר תוכנית מייצג מספיק זמן כדי לצפות בהתנהגות העיבוד, בשמע/וידאו שהתקבלו ובהתאוששות.
- שמרו את הפרופיל התקין הידוע ואת הראיות ששימשו לאישורו.
פתרו תקלות לפי הגבול
קלט תקין בזמן שפלט לעולם אינו מתחיל מצביע תחילה על כתובת URL של היעד, אישורים, הפעלת פלט או פרופיל שאינו תואם. פלט מחובר עם וידאו שחור דורש בדיקה של המקודד/הפרופיל ושל המקלט. הגדלת ההשהיה או החלפת ההאצה אינן תחליף לבדיקת חוזה הפלט. כאשר איכות התנועה מתדרדרת, השוו את הרנדישן שהתקבל למקור ובדקו את בקרת הקצב, המחזוריות ומרווח העיבוד המתמשך.
היכן Callaba משתלבת
Live Video Transcoding הוא ממשק הבקרה של Callaba עבור הגדרות מקודד, פרופיל, קצב סיביות, קצב פריימים, ממדים, GOP, רצועה, ערוץ, האצת חומרה ושכבת-על. השתמשו ב-תיעוד Restream API לאחר שפרופיל ידני פועל. להגדרת Enhanced RTMP ייעודית ל-YouTube, פעלו לפי תהליך העבודה של YouTube; לגישת קלט, השתמשו ב-RTMP Server כדי להגדיר את צד הקליטה.
