פיתוח שיפור איכות וידאו מבוסס בינה מלאכותית באפליקציה לנייד

שיפור וידאו ב-AI באפליקציית מובייל: היכן צוואר הבקבוק

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

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

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

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

סיפור נפרד — ניתוק ההעלאה. אם השיפור מועבר לשרת, סביבת ההרצה הפלטפורמית כמו Core ML במכשיר לא מצילה: הסרטון נשלח כולו, ובמעבר בין רשתות או במעלית ההעברה נקטעת באמצע. המשתמש רואה לא „נמשיך מהמקום שבו הפסקנו”, אלא מסך ריק ושליחה מחדש של החומר מאפס.

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

מה משתנה אחרי ההטמעה: אפקטים מדידים

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

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

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

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

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

מצבי עיבוד וידאו: במכשיר ובענן

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

איך בוחרים מצב עיבוד

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

שלבי ההטמעה: מהאודיט ועד המסירה לצוות

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

1. אודיט של הפתרון הנוכחי. מפרקים איך הווידאו מגיע לאפליקציה: קודק, ביטרייט, רזולוציות בכניסה וביציאה, ובאיזה שלב אובדת החדות. בוחנים את מצבת המכשירים — שיעור הדגמים החלשים, זמינות מאיץ הנוירונים, ההתנהגות תחת עומס ובחום.
2. סכימת עיבוד. קובעים היכן לחשב: במכשיר או בשרת. המסלול המקומי נותן פרטיות ועבודה ללא רשת, אבל מוגבל בחישוב; המסלול השרתני סוחב מודלים כבדים, אך דורש ערוץ. מקבעים את סדר השלבים — סינון רעש, ייצוב, הגברת פרטים, צבע.
3. כיול מודלים לשיפור. מרכיבים סט שמתאים בדיוק לשחיקות של התוכן שלכם: תאורה חלשה, טשטוש מתנועה, ארטיפקטים של דחיסה. בנפרד מכיילים פנים וטקסט — עור „מפלסטיק” ואותיות הרוסות נראים מיד.
4. בדיקה על תעבורה חיה. מפעילים על חלק מהקהל עם מתג מבוקר ומשווים לקבוצת ביקורת: שיעור העיבודים המוצלחים, זמן התגובה, התחממות, תקלות במכשירים חלשים.
5. מסירה והכשרת הצוות. מוסרים קונפיגורציות, סקריפטים למדידות, תקנון עדכון המודלים וניתוח מקרי קצה, ומלמדים לשנות פרמטרים ולקרוא מטריקות.

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

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

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

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

מקרה בוחן: איך צומצמו הכשלים בהעלאת סרטונים

לפני השינוי האפליקציה הכינה את הסרטון כולו במכשיר ורק אחר כך שלחה אותו לשרת. המשתמש חיכה עד כמה דקות, בעת ניתוק בתקשורת ההתקדמות התאפסה, ובמכשירי הסגמנט הבינוני המשימה לעיתים קרובות לא הגיעה לסוף: המארז התחמם, המערכת סגרה את האפליקציה. 68% מההעלאות פורסמו בהצלחה, במכשירים חלשים — 54%, והתמיכה טיפלה ב-40–60 תלונות בשבוע.

היכן היה צוואר הבקבוק

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

מה נבנה מחדש

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

מה קרה בסוף

שיעור ההעלאות המוצלחות עלה מ-68% ל-96%, ובסגמנט הבינוני — מ-54% ל-92%. תלונות על „העליתי ואין סרטון” צומצמו למקרים בודדים בשבוע, וההתחממות וצריכת הסוללה בזמן הפרסום ירדו באופן ניכר. את העדכון בדקנו על מצבת מכשירים ושחררנו אותו שישה שבועות מתחילת העבודה.

מה לעשות אם העיבוד כבר רץ בשרת?

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

את הסכימה בוחרים לפי מצבת המכשירים ואורך ההקלטה.

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

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

התלבטויות בנוגע לעומס, איכות ותאימות

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

מה יקרה במכשירים חלשים?

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

מה עם פרטיות הפריימים?

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

בכמה יגדל הבילד?

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

כמה תמיכה תדרוש המערכת?

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

בואו נדון במשימה: שלחו את סכמת העיבוד הנוכחית

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

• סכמת העיבוד הנוכחית: היכן בדיוק מחושבים הפריימים — במכשיר, בשרת או בהיברידי, אילו שלבים מתבצעים לפי הסדר ובאיזה מהם אובדת האיכות.
• רשימת מכשירי היעד: לפחות עשרת הדגמים המרכזיים, כולל החלשים שבהם שהאפליקציה מותקנת בהם בפועל — מהם תלוי בחירת מצב העיבוד.
• מטריקות תלונות: שיעור הסרטונים עם ארטיפקטים, נשירה בשלב ההעלאה והייצוא, כמה זמן עובר מהצילום ועד הקובץ המוכן וכיצד המספרים האלה מחושבים כעת.
• דוגמאות של סרטונים בעייתיים: 5–10 מקורות יחד עם התוצאה לאחר העיבוד — לפי כמה סטים כאלה רואים איזה סוג פגמים משוחזר באופן עקבי.
• לוחות זמנים צפויים: לאיזה תאריך נדרשת התוצאה והאם יש תלות בפרסום עדכון נוסף.
• מגבלות שכדאי לציין מיד: פרטיות סרטוני המשתמשים, דרישות לעבודה אופליין, חלק העומס הזמין על הסוללה.

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