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

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

כדי לשדר נתונים בשידור חי באמצעות 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 מ-YouTube API

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

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

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

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

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

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

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

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

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

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

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

במפרט 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, ויש תמיכה רק באודיו עם טראק יחיד.
    • מומלץ שהמשך הזמן של קטעי המדיה יהיה בין שנייה אחת לארבע שניות, כפי שמתואר בקטע הבא. משך הזמן של קטעי המדיה לא יכול להיות ארוך מ-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 (OK)

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

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

202 (התקבל)

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

400 (בקשה לא תקינה)

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

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

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

405 (Method Not Allowed)

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

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

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