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

במאמר הזה מוסבר איך להשתמש בפרוטוקול HTTP Live Streaming ‏ (HLS) כדי לשדר נתונים בשידור חי ב-YouTube ממקודד. המסמך הזה מיועד לספקי מקודדים שרוצים להוסיף תמיכה בהטמעה של HLS במוצרים שלהם. הטמעה של HLS היא בחירה טובה לתוכן פרימיום שנדרשת בו איכות גבוהה ורזולוציה גבוהה עם זמן אחזור גבוה יחסית. כאן אפשר לראות השוואה קצרה בין פרוטוקולים שונים להטמעת נתונים שנתמכים ב-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-bit.
  • שיטת ההעברה חייבת להיות PQ (שנקראת גם SMPTE ST 2084) או HLG (שנקראת גם ARIB STD-B67).
  • צבעי היסוד חייבים להיות Rec. 2020.
  • מקדמי המטריצה חייבים להיות Rec. 2020 רמת הארה משתנה.
• מערכת Ad Manager תומכת בערכי דגימה של טווח מוגבל (או טווח MPEG) ושל טווח מלא (או טווח JPEG). חשוב להגדיר את הטווח בהתאם לטווח ערכי הדוגמה שמשמשים בתוכן. מומלץ להשתמש בערכים לדוגמה בטווח מוגבל.

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

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

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

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

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

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

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

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

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

‫… where $STREAM_KEY is the Stream Key displayed in the web interface. לדוגמה: 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=

שימו לב שיש שני הבדלים בין כתובת הגיבוי לכתובת הראשית: גם שם המארח וגם הפרמטר 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

Media Segments

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

• שמות קבצים
  • שמות הקבצים של פלח המדיה בכתובת ה-URL חייבים לכלול את הסיומת .ts filename ולהיות זהים לשמות הקבצים בפלייליסט.
  • שמות הקבצים של פלח המדיה צריכים להיות ייחודיים בכל הפעלה מחדש של המקודד ובכל הפעלה מחדש של הסטרימינג.
• פורמט
  • מקטעי המדיה צריכים להיות בפורמט M2TS ולהיות בעלי הפעלה עצמית.
  • כל פלח M2TS חייב להכיל תוכנית MPEG-2 אחת.
  • מקטע M2TS חייב להכיל PAT ו-PMT, ושני חבילות הנתונים הראשונות של Transport Stream במקטע צריכות להיות PAT ו-PMT.
• Content
  • צריך לבצע מיקס של הווידאו והאודיו.
  • קודקי הווידאו הנתמכים הם 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 לא דורש מהלקוח למחוק משאבים בסטרימינג, והוא מתעלם מבקשות 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 (שגיאת שרת פנימית) מציינת שהשרת לא הצליח לעבד את הבקשה. במקרה של השגיאה הזו, מומלץ לנסות שוב את הבקשה עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff).