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

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

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

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

דרישות לגבי פורמט המדיה

הדרישות הבאות חלות על תוכן וידאו ואודיו בהעלאה באמצעות פרוטוקול HLS ב-YouTube:

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

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

HDR

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

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

איך מקבלים כתובת URL להטמעת נתונים בפרוטוקול HLS

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

כדי לקבל את כתובת ה-URL המלאה להטמעת נתונים, המקודדים יכולים להשתמש ב-YouTube Live Streaming API כדי להוסיף משאב liveStream עם המאפיינים הבאים:

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

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

איך מקבלים כתובת URL להעברה של נתוני HLS מ-YouTube Studio

שימו לב: השיטה הזו להשגת כתובות URL להעלאת תוכן בפורמט HLS היא תכונת בטא ועשויה להשתנות בעתיד.

בממשק האינטרנט של YouTube Creator Studio, אחרי שהיוצר לוחץ על Create Stream, מוצג ב-YouTube מַפתח שידור שמורכב מתווים אלפאנומריים ומקפים. המפתח הסודי הזה מזהה גם את היוצר וגם את הסטרימינג ב-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 לגיבוי לבין כתובת ה-URL הראשית: שם המארח והפרמטר copy= השתנו. כדי למנוע פגיעה בשידור, הטמעת הנתונים לגיבוי חייבת לשלוח ערך פרמטר copy= שונה מזה של הטמעת הנתונים הראשית.

השלמת כתובת ה-URL להטמעת נתונים בפרוטוקול HLS

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

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

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

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

הפלייליסטים של המדיה וקטעי המדיה שהמקודד שולח צריכים לעמוד בדרישות של מפרט HTTP Live Streaming, מהדורה שנייה.

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

המקודד חייב:

• לשלוח בדיוק זרם אחד מקודד ברזולוציה הכי גבוהה שרוצים להציג למשתמשים (רזולוציה וקודק יחידים).
• לשלב אודיו ווידאו.
• להשתמש ב-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, ורק אודיו עם טראק אחד נתמך.
  • מומלץ שאורך קטע המדיה יהיה בין שנייה אחת ל-4 שניות, כמו שמוסבר בקטע הבא. האורך של קטעי המדיה לא יכול להיות יותר מ-5 שניות.
  • פלחים של מדיה חייבים להיות מוצפנים רק בשכבת TLS/SSL באמצעות HTTPS. אין תמיכה במנגנוני הצפנה אחרים.

משך קטע המדיה

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

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

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

במרכז העזרה של YouTube יש הנחיות להגדרות של קצב העברת הנתונים.

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

דרישות אחרות

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

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

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

כתוביות

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

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

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

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

‫200 (תקין)

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

בתגובה לבקשת DELETE, תגובת HTTP 200 (OK) מציינת שהשרת של 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 (שגיאת שרת פנימית) מציינת שהשרת לא הצליח לעבד את הבקשה. במקרה של השגיאה הזו, מומלץ לנסות שוב את הבקשה עם השהיה מעריכית לפני ניסיון חוזר.