העברת תוכן ב-YouTube בשידור חי באמצעות HLS

במסמך הזה מוסבר איך להשתמש בפרוטוקול HTTP Live Streaming (HLS) כדי: לשדר נתונים בשידור חי ב-YouTube ממקודד. המסמך הזה מיועד עבור ספקי מקודדים שרוצים להוסיף למוצרים שלהם תמיכה בהטמעת נתונים בפרוטוקול HLS. HLS הטמעת נתונים היא בחירה טובה לתוכן פרימיום שדורש באיכות גבוהה ורזולוציה גבוהה בזמן אחזור ארוך יחסית. לתקציר השוואה בין פרוטוקולים שונים של הטמעת נתונים ב-YouTube בשידור חי אפשר לעיין במאמר בנושא השוואה בין פרוטוקולים של הטמעת סטרימינג בשידור חי ב-YouTube.

כדי לשדר נתונים בשידור חי באמצעות פרוטוקול HLS, המקודד צריך לשלוח סדרה של מדיה פלייליסטים ופלחי מדיה לנקודת הקצה של YouTube בפרוטוקול HLS באמצעות HTTP PUT או בקשות POST. מבחינת המקודד, נקודת הקצה של YouTube HLS הוא שרת HTTP פסיבי.

כל קטע מדיה מייצג את תוכן המולטימדיה בפועל בחלק קצר של השידור שנמשך בין שנייה לארבע שניות. כל פלייליסט של מדיה תיאור האופן שבו להרכיב מחדש את הפלחים של מדיה בסדר הנכון של השידור.

דרישות פורמט המדיה

להטמעת נתוני HLS של YouTube יש את הדרישות הבאות לגבי וידאו ואודיו content:

• הווידאו והאודיו חייב לעבור רמיקס בפורמט M2TS.
• רכיבי קודק הווידאו הנתמכים הם H.264 ו-HEVC.
• יש תמיכה בקצב פריימים של עד 60fps.
• יש תמיכה רק ב-GOP סגור.
• קודק האודיו הנתמך הוא AAC, ויש תמיכה רק באודיו בטראק אחד.

דרישות מפורטות יותר מפורטות בקטע פלחים של מדיה.

HDR

וידאו עם טווח דינמי גבוה (HDR) נתמך באמצעות קודק HEVC כולל בדרישות הנוספות הבאות:

• תקני הצבעים הנתמכים הם PQ ו-HLG של 10 ביט עם רמת הארה משתנה. באופן מפורט יותר:
  • פורמט Chroma חייב להיות YUV 4:2:0 10bit.
  • פונקציית ההעברה חייבת להיות בפורמט PQ (שנקרא גם SMPTE ST 2084) או HLG (נקרא גם ARIB STD-B67).
  • צבעי היסוד חייבים להיות בתקן Rec. 2020.
  • מקדמי מטריצות חייבים להיות Rec. רמת הארה משתנה בשנת 2020.
• דוגמה לטווח מוגבל (או MPEG-range) וגם לדגימה של טווח מלא (או JPEG-range) והערכים הנתמכים. חשוב להגדיר את הטווח בהתאם טווח הערכים לדוגמה שבו התוכן משתמש. ערכי דגימה מהטווח המוגבל הם מומלץ.

קבלת כתובת URL להטמעת נתוני HLS

קבלת כתובת URL להטמעת נתוני HLS מ-YouTube API

כדי לקבל את כתובת ה-URL המלאה להטמעת נתונים, המקודדים יכולים להשתמש בכלי YouTube Live Streaming (סטרימינג בשידור חי ב-YouTube) API כדי להוסיף שידור חי משאב עם ההגדרה הבאה נכסים:

"cdn": {
  "ingestionType": "hls",
  "frameRate": "variable",
  "resolution": "variable"
}

בתשובה מה-API, השדה cdn.ingestionInfo.ingestionAddress מציין כתובת ה-URL הראשית להטמעת נתונים, והשדה cdn.ingestionInfo.backupIngestionAddress מציין את כתובת ה-URL להטמעת נתונים לגיבוי. לקבלת פרטים נוספים, אפשר לקרוא את מאמרי העזרה של מקור המידע liveStreams.

קבלת כתובת URL להטמעת נתוני HLS מ-YouTube Studio

בממשק האינטרנט של YouTube Studio, אחרי שהיוצר לוחץ על 'יצירה' סטרימינג', מוצג ב-YouTube 'מַפתח שידור' שמורכב מאותיות וספרות ומקפים. המפתח הסודי מזהה גם את היוצר וגם את .

אפשר ליצור כתובת URL של HLS ממפתח השידור הזה באופן הבא:

https://a.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY&copy=0&file=

... כאשר $STREAM_KEY הוא מַפתח השידור שמוצג בממשק האינטרנט. מוצרים לדוגמה: https://a.upload.youtube.com/http_upload_hls?cid=abcd-efgh-ijkl-mnop-qrst&copy=0&file=

כדי לשפר את האמינות, אפשר לשדר עותק שני מיותר של הטמעת הנתונים. לכתובת ה-URL הזו לגיבוי:

https://b.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY&copy=1&file=

חשוב לשים לב שיש בגיבוי שני הבדלים לעומת כתובת ה-URL הראשית: גם שם המארח והפרמטר copy= השתנו. הטמעת הנתונים של הגיבוי חייבת לשלוח ערך פרמטר copy= שונה מההטמעה הראשית, כדי להימנע הדבר משחית את הסטרימינג.

השלמת כתובת ה-URL להטמעת נתוני HLS

כתובות URL שהתקבלו באחת מהשיטות הן תבניות חלקיות. כל סיום עם פרמטר שאילתה file= ריק. כדי ליצור את כתובת ה-URL הסופית, המקודד צריך להוסיף את שם הקובץ של פלייליסט של מדיה או של פלח מדיה בסוף כתובת ה-URL, וכך להשלים את הפרמטר file=.

הכללים הבאים חלים על הערך של הפרמטר file=:

• המקודד עשוי ליצור שם קובץ של פלייליסט של מדיה או של קטע מדיה מ- תווים אלפאנומריים, קווים תחתונים, לוכסנים לפנים, מקפים ונקודות. אין תמיכה בתווים אחרים.
• אסור למקודד לקודד את שם הקובץ בכתובת URL.
• שמות הקבצים עשויים לכלול רכיבי נתיב יחסיים או מוחלטים, למרות שזה אף פעם לא נדרש. אם המקודד כולל רכיב נתיב בשם קובץ של פלח מדיה, הוא חייב להפנות לאותו נתיב של הפלייליסט המתאים.

הדרישות לפרוטוקול HLS

פלייליסטים במדיה וקטעי מדיה שנשלחים על ידי המקודד חייבים להתאים המהדורה השנייה של סטרימינג בשידור חי ב-HTTP מפרט.

מפרט HLS מגדיר שני סוגי פלייליסטים: 'פלייליסט מדיה' ו'מאסטר' פלייליסט. כיוון שמערכת YouTube ממירה תוכן בסטרימינג לרזולוציות שונות בקצב העברת נתונים, המקודד לא צריך לשלוח תוכן עם קצבי העברת נתונים שונים YouTube. כתוצאה מכך, YouTube תומך רק בפלייליסטים של מדיה לצורך הטמעת נתונים בפרוטוקול HLS, המערכת מתעלמת מפלייליסטים ראשיים. (פלייליסט ראשי מספק קבוצת וריאנטים מקורות נתונים, שכל אחד מהם מתאר גרסה שונה של אותו תוכן).

המקודד צריך:

• לשלוח בדיוק זרם מקודד אחד ברזולוציה הגבוהה ביותר שאתם רוצים משרתם את המשתמשים (רזולוציה וקודק בודדים).
• אודיו ווידאו מוקפים.
• להשתמש ב-HTTPS ובחיבור קבוע לכל הבקשות.

הקטעים הבאים מכילים דרישות ספציפיות יותר לפלייליסטים של מדיה ופלחים במדיה.

פלייליסטים של מדיה

פלייליסט של מדיה מכיל רשימה של קטעי מדיה שאפשר לחבר ביניהם שמייצגים שידור מולטימדיה רציף שניתן לפענוח. הפלייליסט של המדיה מספר לשרת לאילו פלחי מדיה לצפות ואיך לסדר אותם כראוי שהרכיבו מחדש את השידור.

דרישות

• שם הקובץ של הפלייליסט של המדיה חייב להסתיים ב-.m3u8 או ב-.m3u.

• פלייליסט המדיה הראשון שנשלח לשידור חייב להתחיל במספר הרצף הערך 0 ומספר הרצף צריכים לגדול באופן מונוטוני.

• התג EXT-X-MEDIA-SEQUENCE חייב לזהות את מספר הרצף של פלח המדיה הראשון שרשום בפלייליסט.

• פלייליסט של מדיה לא יכול להכיל יותר מחמישה מקטעים בתור. א' הפלח בהמתנה אם השרת לא קיבל אותו או אישר לקבל אותו.

  בנוסף לפילוחים בהמתנה, יש לכלול גם כמה בכל פלייליסט של מדיה. עבודה זו מפחיתה את הסבירות אם פלייליסט של מדיה אבד בצד השרת, שאפשר לדלג עליו. עבור לדוגמה, אפשר לכלול עד שני קטעים שאושרו ועד חמישה קטעים בכל פלייליסט של מדיה.

  לתשומת ליבכם: השרת מאשר שהוא קיבל פלח מדיה על-ידי החזרת תגובת 200 (OK) או 202 (Accepted) לגבי ההעלאה של הקטע הזה. א' תגובת 202 מציינת שהשרת קיבל את הקטע לפני פלייליסט שמזהה את הפלח הזה.

• לשלוח פלייליסט מעודכן של מדיה עבור כל פלח מדיה, כדי שה השרת יכול להתאושש במהירות אם מאבד פלייליסט של מדיה.

• מאחר שהשרת מאשר שקיבל פלחי מדיה, אפשר להגדיל את ערך התג EXT-X-MEDIA-SEQUENCE כדי למנוע מהפלייליסט של המדיה להיות ארוך מדי. לדוגמה, אם השרת כבר אישר שהוא קיבל את תשעת קטעי המדיה הראשונים, הפלייליסט הבא של המדיה עשוי להציג את השמינית, מקטעי המדיה התשיעית והעשירית.

• התגים EXT-X-KEY ו-EXT-X-SESSION-KEY לא נתמכים.

דוגמאות

ברשימה הבאה מוצגת דוגמה לקבצים שהמקודד אמור שליחה:

Media Playlist file with seqnum #0
Media Segment file #0
Media Playlist file with seqnum #0-#1
Media Segment file #1
Media Playlist file with seqnum #0-#2
Media Segment file #2
Media Playlist file with seqnum #1-#3
Media Segment file #3
...

בדוגמה הבאה מוצג פלייליסט של מדיה שנשלח באמצע של סרטון בשידור חי. . מכיוון שהדוגמה נמצאת מאמצע השידור, הערך של התג EXT-X-MEDIA-SEQUENCE הוא לא אפס.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:4
#EXT-X-MEDIA-SEQUENCE:2680

#EXTINF:3.975,
fileSequence2680.ts
#EXTINF:3.941,
fileSequence2681.ts
#EXTINF:3.975,
fileSequence2682.ts

פלחי מדיה

הרשימה הבאה מפרטת את הדרישות לשימוש בפלחי מדיה:

• שמות קבצים
  • שמות הקבצים של פלחי המדיה בכתובת ה-URL חייבים לכלול את שם הקובץ .ts והוא צריך להתאים לשמות הקבצים בפלייליסט.
  • שמות הקבצים של מקטעי מדיה חייבים להיות ייחודיים בכל הפעלות מחדש של המקודד השידור יתחיל מחדש.
• פורמט
  • קטעי מדיה חייבים להיות בפורמט M2TS וצריך לבצע אתחול עצמי.
  • כל קטע M2TS חייב להכיל תוכנית MPEG-2 אחת.
  • הקטע M2TS חייב להכיל PAT ו-PMT, ושני החלקים הראשונים מנות Transport Stream בפלח צריכות להיות PAT ו-PMT.
• תוכן
  • הווידאו והאודיו חייב לעבור מיקס.
  • רכיבי קודק הווידאו הנתמכים הם H.264 ו-HEVC.
  • יש תמיכה ב-HDR עם HEVC (ראו דרישות ל-HDR).
  • יש תמיכה בקצב פריימים של עד 60fps.
  • יש תמיכה רק ב-GOP סגור.
  • קודק האודיו הנתמך הוא AAC, ורק אודיו בטראק יחיד נתמך.
  • מומלץ להגדיר קטעי מדיה באורך של 1-4 תווים שניות, כפי שמתואר בקטע הבא. אסור ליצור קטעי מדיה להיות באורך של יותר מ-5 שניות.
  • אפשר להצפין קטעי מדיה רק בשכבת TLS/SSL עם HTTPS. אין תמיכה במנגנוני הצפנה אחרים.

משך הזמן של פלח המדיה

אנחנו מצפים להשתמש בהטמעת נתונים בפרוטוקול HLS בתוכן פרימיום שדורש באיכות וברזולוציה גבוהה. בדרך כלל, זמן האחזור של הטמעת נתונים בפרוטוקול HLS גבוה יותר מזה של RTMP- והטמעת נתונים מבוססת WebRTC כי הטמעת נתונים של HLS מבוססת על מקטעים.

מומלץ להגדיר משך של 'פלח מדיה' של 1 עד 4 שניות, מפני קטעי מדיה קטנים יותר עשויים לקצר את זמן האחזור, אבל בעלות של זמן ארוך יותר קצב אגירת נתונים ויעילות קידוד נמוכה יותר. כפי שהזכרנו בקטע הקודם, קטעי מדיה לא יכולים להיות ארוכים מ-5 שניות.

קצב העברת נתונים

העזרה של YouTube רמקול סֶנטר (מול הצופה) שמספק הנחיות להגדרות של קצב העברת נתונים.

לתשומת ליבכם: בדרך כלל, HEVC מניב 25% עד 50% יותר דחיסת נתונים באותו זמן איכות הווידאו בהשוואה ל-H.264. לכן, ערכי קצב העברת הנתונים שנמצאים בקצה התחתון של אפשר להשתמש בטווחים המוצעים עם HEVC כדי לחסוך ברוחב פס, שימושי לתוכן באיכות 4K.

דרישות אחרות

• מקודדים צריכים להגדיר את הכותרת User-Agent בבקשת ה-HTTP באמצעות בתחביר הבא, שכולל את שם היצרן, שם הדגם version:

  User-Agent: <manufacturer> / <model> / <version>
  

כתוביות

בהטמעת הנתונים בפרוטוקול HLS יש שתי אפשרויות לשליחת כתוביות:

• שליחת כתוביות באמצעות בקשות HTTP POST נפרדות. זה עובד לכולם הטמעת נתונים של HLS.
• כתוביות מוטמעות בתקן 608/708 פועלות עם הטמעת נתונים של HLS בתקן H264 את קודק הווידאו אבל לא עם בהטמעת נתונים המשתמשים בקודק הווידאו HEVC. לקבלת מידע נוסף פרטים נוספים זמינים בדרישות לגבי כתוביות מיידיות. במרכז העזרה של YouTube.

קודי תגובה של HTTP

הקטעים הבאים מסבירים את קודי התגובה ש-YouTube מחזיר תגובות לפלחים במדיה ולפלייליסטים של מדיה שהועברו באמצעות פרוטוקול HLS.

200 (OK)

בתגובה לבקשת PUT או POST, HTTP 200 (OK) מציינת ששרת YouTube קיבל פעולה צפויה וטיפל בה בהצלחה.

בתגובה לבקשת DELETE, תגובת HTTP 200 (OK) של HTTP מציינת השרת של YouTube קיבל את הבקשה והתעלמות ממנה. שרת YouTube לא מחייבים את הלקוח למחוק משאב כלשהו בזרם, והוא מתעלם בקשות DELETE. מטעמי ביצועים, YouTube ממליץ על לקוחות לא לשלוח DELETE.

202 (התקבל)

תגובת HTTP 202 (Accepted) מציינת ששרת YouTube קיבל את קטע מדיה לפני קבלת פלייליסט של מדיה שמכיל את פלח המדיה הזה. ההודעה הזו מציינת ללקוח שצריך לשלוח את הפלייליסט של המדיה שכולל אותו פלח מדיה בהקדם האפשרי כדי למנוע עיכוב בעיבוד פלח. שימו לב שלא תהיה בעיה אם המקודד שולח פלייליסט של מדיה לכל פלח מדיה.

400 (בקשה שגויה)

תגובת HTTP 400 (בקשה שגויה) מציינת אחת מהבעיות הבאות אירעה:

• כתובת האתר שגויה
• לא ניתן לנתח את הפלייליסט או שהוא מכיל תגים לא נתמכים

401 (לא מורשה)

תגובת HTTP 401 (לא מורשית) מציינת שהפרמטר cid כתובת ה-URL הבסיסית של נקודת הקצה של YouTube HLS פגומה או שפג תוקפה. הלקוח/ה צריך לעדכן את הפרמטר cid כדי להמשיך.

405 (שיטה לא מותרת)

תגובת HTTP 405 (method Not Allowed) מציינת שהבקשה ולא בקשת POST, PUT או DELETE.

500 (שגיאת שרת פנימית)

תגובת HTTP 500 (שגיאת שרת פנימית) מציינת שהשרת היה לא ניתן לעבד את הבקשה. עבור השגיאה הזו, מומלץ לנסות שוב בקשה עם מעריכיות השהיה לפני ניסיון חוזר (backoff).