תיקון סרטון פגום בדפדפן

מה הדף הזה בודק בפועל

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

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

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

אם אי פעם הרצתם סרטון פגום דרך ffmpeg וראיתם את השורה Invalid NAL unit size (0 > 1241) חולפת על המסך, זה בדיוק אותו מצב. נגנים מגיבים לו בדרך כלל בתקיעה, בדילוג או במריחה של ריבועים — כי זה כל מה שאפשר לעשות עם בייטים שלא קיימים.

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

שני סוגי נזק, ולכל אחד מראה אחר

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

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

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

למה הקובץ המתוקן קצר יותר

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

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

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

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

מה הכלי הזה לא יכול לעשות

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

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

רק H.264 ו-HEVC. אלה הקודקים ששומרים פריימים עם קידומות אורך, ואותן הבדיקה קוראת. קודקים כמו MJPEG ו-MPEG-4 Part 2 מסדרים את הפריימים אחרת — במדידה באותו סרגל כולם היו נראים פגומים, ולכן הדף פשוט לא מטפל בהם.

שאלות נפוצות