מאת: Brian Ames, M&A. על המל”טים (מטוסים ללא טייס) להיות מסוגלים לקלוט ולשדר נתוני וידאו שוטפים. ככלל אין מידע חזותי חיוני בצומת, דבר המהווה פשרה במעבר למל”טים. כלומר מידע הוידיאו המשודר חייב להיות אמין באותה המידה כמו מגע חזותי ישיר. נדון עתה בוידיאו האנלוגי, המשדר תמונות באיכות טלוויזיונית מהמל”ט לקרקע. המשימה הושלמה – נכון? כן, אם המטרה היא לשגר מספר קטן של מל”טים. הבעיה כרוכה בספקטרום הדרוש כדי לשגר ולקלוט אותות אנלוגיים תקניים של טלוויזיה בצבעים. אותות הטלוויזיה של ה- National Television System Committee , שהם תקניים במרבית האמריקה הצפונית ובכל העולם, דורשים 6 מגה-הרץ. אם יימצאו יותר מידי מל”טים באוויר באותו הזמן פשוט לא יהיה מספיק רוחב-פס עבור כולם.
אפילו מל”טים בודדים חשים במחסור זה ברוחב-פס כאשר המשתמשים מבקשים שימוש במצלמות כפולות, קצבי מסגרת גבוהים, או רזולוציה גבוהה. אלה מקנים יתרונות ענקיים על הקרקע, אך גורמים לפשרה – הצורך ביתר רוחב-פס. הפיתרון הוא בדחיסה.
תקנים דוגמת ה-MJPEG ו-JPEG2000 זכו לפופולריות בשעה שהם שיגרו מידע במנות קטנטנות. נראה שאין גבול לסינרגיה זו. שניהם נראו כמצייתים לגרסה כלשהי של חוק Moore. אולם, הבעיה הייתה שדחיסה ואיכות הוידיאו היו מנוגדות. הדחיסה שאפה לגבול מעשי, ואילו הוידיאו עמד בפתח של תקופה של צמיחה עצומה. בערך לפני שנתיים, המצלמות והדחיסה הגיעו לנקודת עימות העשויה להוות כל ההבדל בשידור הוידיאו באוויר בזמן-אמת.
נקודת העימות הייתה המעבר מדחיסה מרחבית לדחיסה בזמן. הדחיסה המרחבית דוחסת עד כדי מספר פקודות כל מידע החוזר בתוך מסגרת יחידה. כלומר, אם קו אחד בתוך מסגרת הוא לבן, במקום לשגר מידע על כל פיקסל, דחיסה מרחבית רק תנחה את המערכת לכתוב את אותו ערך הפיקסל n פעמים.
התקן h.264, המקדם את הדחיסה המרחבית, נוצר כדי לשגר וידיאו דרך האינטרנט. דבר זה מתבטא במסגרות I, P ו-B. מסגרת I נוטלת צילום רגעי של כל התמונה – כמו מצלמה, ודוחסת אותו מרחבית. הבשורה החדשה הייתה מסגרת ה-P הנראית כמו מסגרת ה-I, והאומרת “אני רואה שהקו הבא ממסגרת ראשונה הוא עדיין כולו לבן – כך שרק שלח את הפקודה לחזור על אותו פיקסל, קו או קבוצה מהתמונה האחרונה”.
מסגרת ה-B הצעידה את המצב צעד אחד קדימה והתמקדה בסדר מסגרות לא סדיר. בעזרת שמירת מסגרות רבות בחוצץ והשוואה קדימה ואחורה, המערכת מסוגלת להשיג יחסי דחיסה מרשימים. כאשר הדבר דרש יותר לוגיקה וכוח מחשוב, התקדמויות בטכנולוגיה אפשרו זאת בכמיסות (latency) מזערית.
החלק הטוב ביותר היה היכולת לקבוע איכות לעומת יחסי דחיסה. ההסבר הפשוט לכך, אם כי התופעה מורכבת, הוא שרמת הדחיסה מבוססת על ריכוז של מסגרות I, P ו-B. דבר זה כונה קבוצת תמונות (Group of Pictures – GOP) האומרת למערכת באיזו תדירות לקלוט תמונה מלאה (מסגרת I) ובאיזה אורך לבנות את שרשרת התמונות הדחוסות כמבוססת על תמונה מלאה ראשונית זו. ככל שהשרשרת ארוכה יותר, הדחיסה גדולה יותר. הנטייה הטבעית של מתכנני המערכת הייתה לומר “עד כמה נמוך יכולה דחיסה זו לרדת ועדיין לשמור על הוידיאו שלי תקף?” התוצאות במעבדה היו מדהימות.
ועדיין, הסתמכות זו על מסגרות קדימה ואחורה היא בדיוק הסיבה מדוע h.264 אינה פועלת היטב עבור יישומים צבאיים ואוויריים קריטיים למשימה בזמן אמת. יש לתכנן את המל”טים כדי לפעול בכל זירה ובכל עת אם עליהם לגרום למהפכה בדרך בה צבא ארה”ב נלחמת באיומים. האתגר במקרה זה הוא בעיה נסתרת – פרופיל קצב שגיאת הביט (BER –bit error rate) הבלתי נראה והתלוי במצב.
שגיאות הביט מהוות בעיה עצומה עבור תכניות דחיסה בזמן. שגיאת ביט יחידה עלולה לבלבל את אלגוריתם הקידוד ולנעול חלקים שלמים מזרם הוידיאו עבור כל קבוצת התמונות, שיכולה להיות בת 16 מסגרות או יותר.
גרוע מזה, שגיאת ביט כל 0.5 שנייה (שניתן לחשב כטובה בחוגים מסוימים) עשויה ליצור מערכת הרואה וידיאו לעתים רחוקות ביותר. בפשטות רבה, עיין בתרחיש הבא: וידיאו לוכד מסגרת I במוצא ה-GOP ממש. המסגרת הבאה לאחר מכן נתקלת בשגיאת ביט. דבר זה גורם למה שמוכר כ-”שגיאה בקסקדה”. שגיאת הביט יכולה להימצא בקסקדה לכל מסגרת P ו-B הבאה לאחר מכן. השגיאה מתוקנת רק כאשר המסגרת I הבאה משוגרת. מסגרת ה-I החדשה “מנקה את הרעף”. כמה זמן לוקח לאפס את זרם הוידיאו וכיצד המערכת עומדת בפני שגיאה בקסקדה הם האתגר.
מפעילי מל”טים אשר מנחיתים רכבים, עוקבים אחר עצמים בעלי עניין או בוחרים מטרות אינם יכולים לעמוד בפני בעיות אלה. עבור מפעילי מל”טים אלה, היה עדיף שידור וידיאו אנלוגי בו התמונה מתערפלת כאשר התנאים הם רועשים – או כאשר התמונה נעלמת בשעה שהמל”ט מגיע לגבולות הקליטה שלו.
מפעיל המל”ט יעדיף כמו כן מסנן מרחבי בלבד, כפי שמצוי לרוב בשטח. במקרים אלה, זוהי רק שגיאת ביט ולא “שגיאת ביט בקסקדה”. מסגרת יחידה תשא קו פגום או סט פיקסלים פגומים עבור מסגרת אחת. שגיאה זו מבוקרת למשך זמן ושטח מסוימים.
הבעיה הופכת ל: האם אנחנו יכולים לתקן בעיות אלו ולגרום ל-h.264 לפעול כמו וידיאו אנלוגי תוך השגת רוחב-הפס הנמוך כדי לאפשר לכוחות צבא ארה”ב לשגר גלים על-גבי גלים של מל”טים?
חשבו על גלים ועל גלים של טלפונים סלולריים. דבר זה אכן עובד שם. טלפונים סלולריים רגילים פרוסים בצורה מסיבית וחייבים לספק שירות איכותי בכל מיני סביבות בעלות הפסדים. איך הם יכולים לתפקד בצורה יעילה? מלבד שתי הנקודות הברורות שלקול אנושי רוחב-פס נמוך (לעומת הוידיאו) ושהטלפונים הניידים יכולים להיכשל ללא תוצאות חמורות, ישנם שיעורים בסיסיים שיש ללמוד.
השיעור הראשון הוא שטלפונים סלולריים מפעילים אלגוריתמי תיקון שגיאה קדימה (forward error correction – FEC) כדי לטפל בשגיאות ביט. צורה מקובלת היא אלגוריתם Viterbi (לעתים קשור באלגוריתמי Reed Solomon FEC) דורשת לשגר נתונים יתירים כדי לאתר ולתקן שגיאות ביט. יתירות זו מכוונת לרוב כדי לאפשר למקלט לגלות ולתקן מספר מוגבל של שגיאות ביט מבלי לשלוח מחדש את הנתונים. מימוש זה של רוחב-הפס המיטבי המעשי הוא זה שגורם לטלפונים סלולריים לתפקד.
התשובה השנייה היא שבטלפונים סלולריים, האחריות לגבי ה-FEC והקידוד מטופלת ביחידה אחת. דבר זה מאפשר לטלפון לגלות את ה-BER ולנקוט במספר כלשהו של אמצעי תיקון.
אתגרים עבור הציוד הצבאי וה-h.264
במערכות צבאיות, רכיבי מערכת עצמאיים מטפלים ב-FEC ובקידוד. מקודד הוידיאו פועל בד”כ בצורה עיוורת. איכות קישור הרדיו – היכן שניתן לגלות את שגיאות הביט – איננו תחת בקרה או הזנת מידע למקודד. ללא שקיפות לתוך ה-BER, המקודד איננו יכול ליהנות מהמידע בזמן אמת כדי לכוון את רוחב-הפס להבטחת האיכות.
לתקן ה-h.264 יש אופציות FEC מובנות, אם כי הן אינן בד”כ מופעלות – במיוחד לא במקודדים מסחריים. עם קידוד מתקדם, היה אפשר לנטר את ה-BER ולכוון את כמות רוחב-הפס.
בעוד דבר זה אפשרי עבור סביבות הניתנות לחיזוי כללי, מל”ט המוכן להפעלה בכל מקום ובכל זמן עשוי לגלות שיש לו BER מסוים בשדה התעופה, אחר מעל שדה הקרב, אחר כאשר הוא חוצה הר ומאבד את קו הראייה, ואחר כאשר הוא חולף ליד מטוס אחר. האופי הבלתי-חזוי של ה-BER הופך את ה-h.264 למסוכן כאשר הוא מכוון לדחיסה מרבית. קביעת רוחב-פס מיטבית מעשית עבור מל”טים המבוסס על דפוסי שימוש אמיתיים עשויה לפתור בעיה זו.
על-פי דגם הטלפון הסלולרי, עלינו לפתח פרופיל רוחב-פס מיטבי מעשי. כדי לבצע זאת, יש לאסוף נתונים רבים וללמוד אותם אודות פרופילי BER מעשיים בשדה. דבר זה יסייע להגדיר את יחס הדחיסה התיאורטית המרבית עבור h.264 בתוך תנאי ה-BER, ולאפשר למערכת לספק דחיסות גבוהות יותר בעלות האיכות הדרושה.
שנית, עלינו להבין כיצד לדון ב-BER שאנחנו מבקרים – במיוחד במאבק עבור רוחב-פס. מל”ט המכוון לרוחב-פס מזערי בסביבה צפופה, בה זרם הנתונים צריך להילחם על מרחב, נמצא בחיסרון טכני ענקי. אין מנגנון אשר יבטיח איכות השירות עבור זרמי וידאו הנכנסים.
עד שמתכנני המערכות יטפלו בשתי סוגיות אלו, ל-h.264 יהיו סוגיות אמינות ושימושיות. בינתיים, עליך לזכור שבמעבדה כל אחד יכול לטעון לשיפורים ענקיים ביחסי הדחיסה. אל תאמין להם.
Brian Ames הוא מנהל חשבונות אסטרטגי ב-Digital Design Corp. מ-Arlington Heights, Ill.
הכתבה באדיבות אתר:
http://www.militaryaerospace.com/index.html
