סיפורי באגים – זה לא באג זה …

הפעם בחרתי להביא שני סיפורים על דברים שנראים כמו באגים אבל בעצם הם …. 

מקרה I – זה לא באג זה ….

אחד הבאגים המעניינים שנתקלתי בהם החודש נגע בבעיה מוכרת: כיצד למנוע ארטיפקטים כתוצאה מנפילות פאקטים באפליקציות של וידאו מעל IP כמו סטרימינג או וידאו-קונפרנסינג. במקרה זה כמות הארטיפקטים היתה עצומה ולא נראתה קורלציה בין כמות הארטיפקטים לסוג הערוץ או יחס ה-FEC. בבדיקה פשוטה של הקלטת מוצא הדוחס, נמצא שהוידאו היוצא מהדוחס כבר מכיל את הארטיפקטים האלו (ראה בתמונה) עוד לפני מעבר בערוץ. האם זה באג בדוחס הוידאו? ע"י שימוש באנלייזר וידאו ( Vega H.264 Analyzer) היה ניתן לראות כי הוידאו חוקי לחלוטין ובכל זאת יוצר ארטיפקטים של tiering הדומים לאלו הנוצרים ע"י איבוד של פאקטים. עיון בתעוד של הקודק גילה כי כדי לעמוד במגבלות גודל מקסימלי של Slice Size הוכנס מוד מיוחד שברגע ש-Slice מגיע לגודל מקסימלי הוא פשוט מדלג על שארית ה-Slice ולא מקודד אותה. התמונה הנוצרת היא ערבוב של שתי פריימים: הפריים הנוכחי והפריים הקודם. תוצאה זו דומה לתוצאה של נפילת פאקט בו הוחזק חלק מהמידע של הפריים הנוכחי. במקרה זה, הוידאו היה חוקי לחלוטין ללא באגים, התנהגות הדוחס והוידאו שיצר היו חוקיים (אם כי בלתי ניתנים לשימוש) והתברר כי התנהגות זו הוכנסה בכוונה ע"פ בקשת החברה. מתברר שה"באג" הזה היה פיטצ'ר.

מקרה II – זה לא באג זה ….
מקרה מעניין אחר בו נתקלתי החודש היה קובץ MP4 בו האודיו הפסיק באמצע הקובץ בעת הזרמה משרת בעוד שניגון לוקלי לא הראה שום בעיה. תקלה כזו יכולה להצביע על בעיה ב – Hint tracks המכילים את אינפורמציית ההזרמה עבור השרת ואינם בשימוש בעת ניגון לוקלי. בדיקה של הקובץ באמצעות Jongbel AtomBox  ובאמצעות – MP4Box החינמי, העלו כי אכן יש בעיות חוקיות קשות ב-Hint tracks. מחקר קצר גילה כי יש נגנים בהם מתגלה בעיית האודיו גם בניגון לוקלי ולכן הבעיה שהתגלתה ב-hint track אינה קשורה לאודיו. מחקר מעמיק יותר גילה כי הבעיות נגרמו כתוצאה משינוי בסיס הזמן באמצע האודיו טרק מבסיס זמן של 90000 המתאים לוידאו לבסיס זמן של 48000, דבר זה הוא חוקי על פי הסטנדרט של ה- MP4 File Format ולכן כלי הבדיקה לא התריאו עליו בצורה אוטומטית כתקלה. גם ה-VLC  שהוא נגן עמיד ודי חסין תקלות הצליח לנגן את האודיו ללא בעיות, לעומת זאת בנגנים אחרים כן התבטאה הבעיה הזו. גם במקרה זה התברר שהבאג הוא לא באג אלא "פיטצ'ר חוקי אך לא בשימוש" של הסטנדרט, הפתרון היה לבקש מהחברה שמייצרת את הקבצים לתקן את התהליך כך שיופיע רק בסיס זמן אחד בקבצים המיוצרים.

מסקנות:

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

רוצים ללמוד עוד על כלי אינטדרציה ובדיקות לוידאו?  בדקו את הקורס שלי Hands – on Video

פורסם בקטגוריה Uncategorized | להגיב

דחיסת וידאו וחיות אחרות

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

  • הגדרת מרחבי צבע והמרות בין מרחבי צבע
  • דגימה, תדירות וזוית מרחבית,
  • יתירות מרחבית, יתירות טמפורלית וכו

חשבתי לעשות תרגיל קטן בהגדרת סטנדרט לקידוד וידאו. לא H.265 – זה שמרני מדי (שוב מרחב RGB המומר ל – YUV, תעדוף ה – Y, המרה לבלוקים, המרת תדר) חשבתי לעשות סטנדרט קידוד וידאו ליצור בעל העין המורכבת ביותר שאני מכיר ותתפלאו – אלו לא בני האדם, לא נץ או נשר אלא סרטן המנטיס (שאיננו סרטן כלל). חשבתם פעם איך נראה מרחב הצבע שלו? ראיית העומק שלו? קצב התמונות? או מושגים שאנחנו לא מדמיינים בכלל כמו פאזה?

Clipboard01

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

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

Clipboard02

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

עוד בנושא במאמר הנפלא הזה ב- national geographic

ונחזור לדחיסת הוידאו. נתחיל במרחבי הצבע, האם באמת אנו צריכים ליצור מרחב צבע 13 ממדי או מספר מרחבים ספרביליים? לדעתי ניתן לראות שלסרטן מרחב צבע אחיד ותמיד יש חפיפות בין מספר רב של קולטנים. לגבי התעדוף בין צבעים שונים, בדומה למטריצות ה – Qp השונות שיש לרכיבי ההארה והגוון (Luma & Chroma), אשר יש להן חשיבות רבה לדחיסה גם כאן נצטרך לתת לתת לכל רכיב חשיבות משתנה על פי הרגישות והצפיפות של קולטני הצבע השונים.

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

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

מה לגבי הפאזה / קיטוב?  – אנו לא קולטים את קיטוב האור ולכן לא צריכים להעביר את הפאזה אך האם זה לא יבלבל את הסרטנים? האם זה יהיה דומה למעבר שלנו מצפיית תלת מימד לדו-מימד בטלוויזיה או שזה יצור תמונה מעוותת לחלוטין?

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

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

השאלות הנשאלות פה הם לא שאלות תאורטיות בלבד, היישומים של העברת פאזה יכולים לשמש גם לסרטי תלת מימד והולגרמות לטלויזיות 3D ללא משקפיים ולמקרני משקפיים בדומה ל-Google Glasses.

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

פורסם בקטגוריה Uncategorized | להגיב

סיפורי באגים – אין אודיו

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

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

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

ביום למחרת – הלקוח חוזר "ניסנו על קובץ אחר – אין אודיו". #$!! ניסיתי להמיר את אותו קובץ לפי אותה פרוצדורה בבית – עובד – יש אודיו. גררררררר…..נסעתי לשם ביצעתי את תהליך ההמרה ו…באמת אין אודיו  #@&%!!!!

השוונו גרסאות של תוכנות הקידוד והמוקסינג הכל זהה, שורות הפקודה, קובץ להמרה – הכל זהה. לצערי לא היה לי H264 Analyzer Interra לא שנראה לי שהוא היה עוזר, גודלי קבצי המוצא אודיו ו-MP2TS  היו זהים.

באין ברירה הכנסתי את הקבצים ל-FFProbe אנלייזר טקסטואלי פשוט שמספק פרמטרים כלליים לגבי הקובץ וסוגי הסטרימים שלו ו.. הפתעה. למרות שאין הבדל בגודל, יש הבדל בין הקבצים המקודדים למרות הזהות  במוחלטת בין קובץ הכניסה תוכניות ההמרה ושורת הפקודה. מדוע? ומה הקשר להבדל במערכת ההפעלה בין המחשב שלי (Windows7) למחשב הלקוח (WinXP)?

רמז: תוספת   -ar 48000 בשורת הפקודה של FFMPEG פתרה את הבעיה.

 פתרון 

כיון שלא ניתן קצב דגימה דיפולטי לאודיו, ה-FFMPEG  דגם אודיו בקצב הטבעי של מערכת ההפעלה שהוא 48KHz ב-Win7  ו-44.1KHz ב-WinXP. היות שהממיר היה מכוון לקליטה בקצב דגימה של 48KHz הקונפיגורציה והתוכנה עבדו על מחשב ה-Win7 אך לא על מחשב ה-XP.

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

פורסם בקטגוריה Uncategorized | עם התגים , , , , , , , | להגיב

הכרות עם פתרונות HTML5 Video

בראשית (סוף שנות ה90 ותחילת העשור הקודם) היה תוהו ובוהו ומגוון רחב של פורמטי ונגנים וידאו היו קיימים כולל Windows Media Player, QuickTime ו – Real. ב-2003 יצא לראשונה נגן הוידאו של פלאש והפך במהירות לנגן הוידאו הסטנדרטי.

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

  1. אפל הודיעה שלא תתמוך בפלאש במוצריה.
  2. עלייה בתמיכה ובתפוצה של דפדפנים תומכי HTML5
  3. סיבוכיות ועלויות גבוהות לתמיכה בהאצת פריסת וידאו בחומרה במכשירי מובייל (בעיקר אנדרואיד) רבים

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

אין היום פתרון יחיד המחליף את כל יכולות הוידאו של הפלאש, לפיכך, נסקור קודם כל את סוגי הפתרונות העיקריים שמספק הפלאש:

ניגון קבצים – Progressive Download בדומה ל- YouTube
ניגון שידוריLive או VoD לפעמים תוך תמיכה אוטומטית במספר מהירויות הורדה (Adaptive Bitrate)
תמיכה בועידת וידאו (Video Conferencing)

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

הנושא של ועידות וידאו הוא משני ויפתר כנראה על-ידי ה- WebRTC של גוגל שנמצא בתהליך הפיכה לסטנדרט. לפיכך נתמקד בנושא שידורי ה-Live או ה- VOD.

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

  1.    שרת stateless פשוט שאינו "זוכר" את מצב הלקוח (pause, play, stop) ויכול להיות מיושם בקלות על גבי כל שרת HTTP פשוט כמו Apache.
  2.    שידורי קטעי מדיה ארוזים מעל HTTP כאשר הלקוח שולח בקשה נפרדת מהשרת לכל קטע מדיה (סגמנט) באורך של שתיים עד עשר שניות
  3.    שימוש בסגמנט ה "עומד בפני עצמו", כלומר מכיל את כל האינפורמציה הדרושה לפתיחת:

              ◦  מתחיל בתחילת GOP

              ◦  מכיל את האינפורמציה על סוגי המדיה והטרקים הקיימים בו (PAT ו-PMT ב-MP2TS או האטומים המקבילים ב- MP4FF)

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

הפרוטוקולים הקיימים כיום הם:

  1. Apple HLS – פתרון ה–HTTP Streaming של אפל, פתרון זה הוא הנפוץ ביותר ונתמך ע"י מכשירי אפל וכן ע"י דפדפן ספארי ובצורה מוגבלת ע"י חלק ממכשירי האנדרואיד. פתרון זה צפוי להמשיך להתמך  והוא אף נכלל כפרופיל בפתרון ה -DASH העתידי
  2. Microsoft Smooth Streaming – הפתרון של מיקרוסופט, עובד רק ב-windows ומבוסס על MP4 File Format. מייקרוסופט הודיע שתתמוך בעתיד בפרוטוקול ה – DASH.
  3.  HDS – Adobe HTTP Streaming – פתרון של אדובה, מבוסס גם הוא על MP4 FF. כמו מייקרוסופט, גם אדובה הודיע שתתמוך בעתיד ב – DASH ולכן לא צפוי המשך תמיכה ל – HDS.

עוד על הפרוטוקולים האלו במצגת הבאה.

פתרון ה-DASH עדיין רחוק מתמיכה ברוב הפלטפורמות ולכן הפתרון המקובל ביותר הוא HLS, פרוטוקול זה נתמך ע"י iPhone ו – iPAD וכן ע"י ספארי אך רחוק מלכסות את כל הדפדפנים והמכשירים.

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

עבור מכשירי האנדרואיד ניתן להשתמש באפליקציית נגן חיצוני כמו Bsplayer או ע"י אינטגרציית קוד FFMPEG  לאנדרואיד התומך ב – HLS

פורסם בקטגוריה HTML5 Video | עם התגים , , , , , , , , | להגיב

ניהול פרוייקטי ראייה ממוחשבת

קיימות דוגמאות רבות לראייה ממוחשבת על פלטפורמות שונות כמו מצגת ה-FastCV של קוואלקום או מערכת הפיתוח לאנדרואיד TADP של NVIDIA (עליה אני ירצה בקרוב).
הפעם רצית להציג בעיה כללית יותר: כיצד לנהל פרוייקט ראייה ממוחשבת נכון. הכוונה ב"נכון" היא מינימזציה של זמן פיתוח ומשאבים על מנת להגיע לקוד עובד על פלטפורמה חדשה.

התסריט המקובל לפרוייקט ראייה ממוחשבת הוא:
• אנשי ה-Bizdev מצליחים להחתים לקוח גדול (סמסונג, TI, Intel)
• דרישה מאנשי הפיתוח לספק את פתרון ה-PC של החברה (במקרה הטוב) או את דמו הMatlab  על פלטפורמת המובייל או האמבדד של הלקוח.

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

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

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

האם לנצח נעשה פורטינג?
ארגון Krhonos, הארגון שפתר את בעיות התאימות לכרטיסי מסך (OpenGL) לאודיו – OpenSL לרכיבי מולטימדיה OpenMAX ולנושאים נוספים, עובד על סטנדרטת תאימות חדש, ה-OpenVX שיגדיר ממשק עיבוד תמונה וראייה ממוחשבת אחיד אותו יממשו יצרני המעבדים. עד שיגיע אותו יום אוטפי בו API אחיד יריץ פונקציות שעברו אופטימיזציה על מעבדים של יצרנים שונים, נותר לנו רק לתכנן נכון את תהליך העבודה ולעבוד חכם.

במצגת הבאה, תיארתי את שני תהליכי הפיתוח. באיזה תהליך מפתחים אצלכם?

פורסם בקטגוריה Computer Vision | עם התגים , , , , , , , | להגיב