כשאנו עוקבים אחר שידורים חיים בטלוויזיה, למשל משחקי המונדיאל, באמצעות ממירים המשתמשים בתשתית האינטרנט, ניתן לעיתים להבחין בהשהיה בין ההתרחשות בשדה לבין התמונה שעל המסך, השהיה שנמשכת לפעמים אף יותר מדקה: בעוד השכנים, שמשתמשים בצלחת לווין או מקשיבים לשידור ברדיו, קופצים משמחה וצועקים "גול, גול!", אנו תקועים בתחילת ההתקפה. נספר על הטכנולוגיה אשר מאפשרת שידורים באיכות גבוהה, על ההשהיה שהיא גורמת וכיצד מנסים לקצר אותה, וגם – מדוע צריך לחשב את הווקטור שמתאר את תנועת רגלו של מסי?

כדי להציג תמונות באיכות טובה על מסך בעל רזולוציה גבוהה, צריך לשדר תמונות מהמגרש בקצב מהיר, כ-60 תמונות בשנייה. אילו היינו מנסים לשדר תמונות אלו ישירות מהמצלמה, היינו צריכים לשדר מידע בקצב מהיר מאוד, שערוצי התקשורת אינם יכולים לעמוד בו. לפיכך, המשדר צריך למצוא דרכים לשלוח את התמונות בצורה דחוסה שמכילה פחות ביטים, ובאופן כזה שהממיר הביתי יוכל להמיר אותן לתמונות רגילות לפני הצגתן. שיטות סטנדרטיות לדחיסת וידאו הוצעו ושוכללו במהלך השנים. הפורמט הראשון, שנקרא MPEG-1, פורסם בשנת 1991, ובשנת 1994 פורסם פורמט MPEG-2, שהפך לסטנדרט עבור צריבת דיסקים בפורמט DVD (כתבנו על פורמט זה בעבר [1]). כיום נפוץ סטנדרט שנקרא H264, וגרסאות שונות שלו משמשות לדחיסת וידאו בשידורי טלוויזיה. איך קורה הקסם?

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

נשים לב שרוב העצמים אשר צולמו במגרש כמעט שלא השתנו במהלך השנייה: אותו דשא, אותם שחקנים שעמדו במקום. לכן, ניתן לחסוך בתעבורה במידה שלא נשלח חלקים אלה של התמונה שוב ושוב. בשלב ראשון התוכנה במשדר שולחת תמונה אחת של המגרש, תמונה באיכות טובה בפורמט דמוי JPEG, שנקראת תמונת בסיס (I-frame). לאחר מכן, במקום לשלוח את שאר התמונות שצולמו, המשדר ישלח מכל תמונה רק את האזורים שחלו בהם שינויים ביחס לתמונות הקודמות, והמקלט יחבר את החלקים. תמונה כזאת, המכילה רק חלק מהפיקסלים, נקראת "predicted frames", ונסמנה באות P. לאחר שליחת כמה תמונות מסוג P, או כאשר הסיטואציה משתנה (למשל, השידור עובר לתמונת הספסל להראות את המאמן הלחוץ), המשדר ישלח תמונת בסיס חדשה.

לשם ביצוע התהליך, התוכנה במשדר מחלקת כל תמונה לרשת של בלוקים קטנים ("macro-blocks"), ריבועים בגודל 16x16 פיקסלים, ובודקת כל אחד מן הבלוקים אם הוא השתנה ביחס לתמונות קודמות. התוכנה שולחת את הפיקסלים החסרים רק אם היה שינוי בבלוק, וכך היא מצמצמת את התעבורה.

ויש תחכום נוסף: שיערוך תנועה [2] (motion estimation). גם אם התוכן של בלוק במקום מסוים בתמונה השתנה ביחס לתמונה הקודמת, ייתכן שאותו תוכן קיים בתמונה קודמת, אבל באזור אחר בתמונה. נניח שמצאנו במרכז התמונה בלוק שהכיל פיסה מהנעל של מסי, ובפריים הבא אותו תוכן נמצא במרחק 32 פיקסלים שמאלה ו-16 פיקסלים למעלה (זו הייתה זו בעיטה יפה כנראה!). לכן, עבור הפריים הבא, במקום לשלוח פיקסלים המשדר ישלח הודעה: "עבור הבלוק הזה נא להשתמש בבלוק מהפריים הקודם כשהוא מוסט ב-(16- ,32-) פיקסלים". זוג המספרים המייצג את התזוזה של הנעל נקרא וקטור התנועה. (תשובה לתהייה של צעירים: אכן יש שימוש אמיתי בווקטורים, ואפשר לתרגל באמצעות הנעל של מסי חיבור וקטורי המתבצע במעבר בין פריימים…)

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

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

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

תוספת יצירתית לדחיסה, שמשתמשים בה רבות ב-H264, היא תמונה שנקראת Bi-directional, המסומנת כ-B. תמונה זו נוצרת משימוש בבלוקים שנלקחים משתי תמונות: אחת מהעבר, שכבר נשלחה, ואחת מהעתיד, כזאת שכבר צולמה אבל עדיין ממתינה בזיכרון המשדר עד שיגיע תורה, ולכן ניתן להשתמש בה לצורך דחיסה. השימוש בתמונות מסוג B משפר מאוד את יחס הדחיסה, אבל הוא מחייב אגירת שלל תמונות בזיכרון המשדר לפני השליחה, כמו גם בממיר הביתי לפני ההצגה, ולכן גורם להשהיה ממושכת.

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

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

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

עיצוב התמונה: מירי אורנשטיין בעזרת תוכנת האינטליגנציה המלאכותית Midjourney
עריכה: סמדר רבן

מקורות והרחבות

[1] על DVD

[2] זיהוי תנועה