פעם חתכתי תשובה של ארבעים שניות מראיון, הורדתי אותה לחפיסה וצפיתי ברמקול מתחיל באמצע המשפט שבע שניות לפני הקטע שרציתי. קבעתי את ההתחלה בזהירות. הגוזם התעלם ממני, או לפחות כך זה נראה. זה לא היה: הוא עשה את הדבר היחיד שחיתוך מהיר יכול לעשות, שהוא להתחיל בפריים המפתח הקרוב ביותר לפני הנקודה שביקשתי. ברגע שאתה יודע את זה, ההתנהגות מפסיקה להיות באג והופך לבחירה עם שתי אפשרויות, ובחירת הנכונה לוקחת שנייה.
TL;DR: חיתוך מהיר מעתיק את זרם הווידאו הקיים במקום קידודו מחדש, ועותק יכול להתחיל רק ב-keyframe. בקשו להתחיל ב-0:07 בקובץ שה-keyframes שלו מרוחקים עשר שניות והחתך מתחיל ב-0:00, כי זו הנקודה האחרונה שממנה יכול המפענח להתחיל. הסוף נוחת במקום שבו שאלת; רק ההתחלה נסחפת, והוא נסחף לאחור. התיקון כאשר אתה צריך את המסגרת המדויקת הוא קידוד מחדש, שהוא איטי יותר ועולה מעט איכות. כְּכ וידיאו טרימר מציע את שניהם וברירת המחדל ל-Fast One.
למה החתך מתחיל מוקדם יותר ממה ששאלת?
כי כמעט שום מסגרת בסרטון היא תמונה שלמה.
דחיסת וידאו פועלת על ידי אחסון פריים מלא אחד ולאחר מכן תיאור השינויים. מסגרת מפתח, מסגרת IDR כהלכה H.264, מחזיק תמונה שלמה ולא תלוי בכלום. הפריימים שאחריו מחזיקים הבדלים: הבלוק הזה זז ארבעה פיקסלים שמאלה, אזור זה לא השתנה, הפיקסלים הללו נעשו מעט כהים יותר. פריים באמצע הרצף הזה הוא חסר משמעות בפני עצמו, האופן שבו הבדל הוא חסר משמעות ללא הקובץ שהוא חל עליו.
אז כשאתה מבקש להתחיל ב-0:07 והכלי מעתיק את הזרם מבלי לפענח אותו, אין שום דבר ב-0:07 להעתקה. יש תיאור של איך 0:07 שונה ממשהו קודם. המקומות היחידים ששחקן יכול להתחיל הם פריימים המפתח, והבטוחה היחידה היא פריים המפתח האחרון בנקודת ההתחלה שלך או לפניה.
האלטרנטיבה היא לפענח את הסרטון עד 0:07, לזרוק את מה שהיה קודם, ולדחוס את מה שנשאר לקובץ חדש שמתחיל ב-keyframe חדש. זה מדויק, וזה הנתיב האיטי, מהסיבה שהוא עושה עבודה אמיתית על כל פריים במקום להעתיק בתים.
כמה רחוקים זה מזה פריימים מפתח, באמת?
יותר ממה שרוב האנשים מניחים, והפער הוא מה שמחליט עד כמה חתך מהיר נראה שגוי.
מדדתי את זה במקום לנחש. קידוד שלושים שניות של צילומי בדיקה עם x264 בברירות המחדל שלו, ולאחר מכן פירוט הפריימים המרכזיים:
ffmpeg -f lavfi -i "testsrc=duration=30:size=640x360:rate=25" -c:v libx264 clip.mp4
ffprobe -select_streams v -show_entries packet=pts_time,flags -of csv=p=0 clip.mp4 \
| awk -F, '$2 ~ /K/ {print $1}'
# 0.000000
# 10.000000
# 20.000000
פריים מפתח אחד כל עשר שניות. זה ברירת המחדל של x264' של 250 פריימים בין פריימים למפתח, ב-25 פריימים לשנייה. בקובץ המקודד עם ברירות המחדל הללו, חיתוך מהיר יכול להתחיל עד עשר שניות לפני הנקודה שבחרת.
רוב הצילומים שאתה מטפל בהם ידידותיים יותר, מכיוון שרובם נוצרו לסטרימינג, שבו שחקנים צריכים נקודות כניסה תכופות כדי להחליף איכות. הנה הטווח שכדאי לדעת:
| מקור | פער פריים מפתח טיפוסי | במקרה הגרוע ביותר בחיתוך מהיר |
|---|---|---|
| הקלטת טלפון | 1 עד 2 שניות | בקושי מורגש |
| הזרמת וידאו, HLS או Dash | 2 עד 6 שניות | מורגש בקליפ קצר |
| ברירת המחדל של x264 או ffmpeg | 10 שניות ב-25 FPS | הורס קיצור דרך |
| מקליט מסך, תנועה נמוכה | 10 שניות או יותר | הורס קיצור דרך |
התבנית: לכל דבר המקודד לנגן יש פריימים מקרובים, ולכל דבר המקודד פעם אחת לאחסון אין.
מה עושה הסחף לקובץ?
הוא מזיז את ההתחלה ומשאיר את הסוף לבד, מה ששווה לדייק לגביו כי קל להניח שכל החלון מחליק.
שואל את אותו קליפ עבור 0:07 עד 0:15, חלון של שמונה שניות, עם עותק זרם:
| מוּבָן | מסגרות מפתח במקור | תוצאה | מה קרה |
|---|---|---|---|
| 7 עד 15 שניות | 0, 10, 20 | 0s עד 15.08s | ההתחלה נפלה חזרה לפריים המפתח ב-0 |
| 12 עד 20 | 0, 10, 20 | 10 עד 20.08 שניות | ההתחלה נפלה חזרה לפריים המפתח ב-10 |
| 7 עד 15 שניות | כל 2 שניות | 6 עד 15.08 שניות | התחל נפל אחורה מסגרת מפתח אחת |
הסוף נכון בשלושתם. בדקתי את זה על ידי גיבוב פריימים במקום לסמוך על משך הזמן: המסגרת האחרונה של הפלט זהה למסגרת המקור ב-15.04 שניות, שהיא המסגרת אחרי זו שביקשתי והמקום הנכון לעצור בו. מה שהשתנה הוא איפה זה מתחיל.
זו הסיבה שהקובץ ארוך מהחלון שבחרת. חתך שחשבתם שהוא שמונה שניות מגיע כחמש עשרה, לא בגלל שמשהו התגבר, אלא בגלל שהגיעו שבע שניות של הובלה. בקליפ שבו פריימים המקשים בהפרש של שתי שניות, אותו חיתוך מגיע כמו תשע שניות ואף אחד לא שם לב.
מתי כדאי לקודד מחדש במקום?
שלושה מקרים, ומחוצה להם הנתיב המהיר הוא הכלי הטוב יותר.
אתה צריך מסגרת ספציפית. חיתוך מילה, על מחווה, ברגע שכדור פוגע במחבט. דיוק ה-keyframe אינו מספיק טוב ושום טיפול עם המחוון לא יעזור, כי הגבול הוא בקובץ ולא בממשק.
הקליפ קצר. הובלה של שבע שניות בחתך של שלושים שניות היא מטרד. בחיתוך של ארבע שניות זה כל העניין.
אתה חותך מקובץ עם מסגרות מפתח דלילות. הקלטות מסך וכל דבר שיוצאו פעם אחת לארכיון, כפי שמראות המידות למעלה.
העלות אמיתית אבל קטנה יותר ממה שאנשים חוששים. קידוד מחדש מפענח כל פריים בחלון ודוחס אותו שוב, כך שלוקח זמן פרופורציונלי לאורך החיתוך ולא לגודל הקובץ, והוא מאבד דור של איכות. בקצב קבוע של 23, שזה מה שהגוזם משתמש במצב המדויק שלו, ההפסד הזה קרוב לבלתי נראה במעבר אחד. זה מעבר שני על קטעים שכבר נדחס פעם אחת, וזה אותו דבר אובדן דור השולט בדחיסה באופן כללי.
איך אתה מוצא את ה-keyframes בקובץ שלך?
פקודה אחת, והיא אומרת לך מראש אם הנתיב המהיר יצליח.
# the first ten keyframe timestamps, in seconds
ffprobe -select_streams v -show_entries packet=pts_time,flags -of csv=p=0 input.mp4 \
| awk -F, '$2 ~ /K/ {print $1}' | head -10
אם הפערים הם שנייה או שתיים, חתוך מהר והפסיק לחשוב על זה. אם הם בני עשר, והחתך שלך חשוב, קידוד מחדש.
יש לזה שימוש שני. אם אתה מייצר קטעים אנשים אחרים יחתכו, קידוד עם מרווח מפתח קצר יותר הופך את חייהם להרבה יותר קלים, בעלות קטנה בגודל הקובץ. פריים מפתח הוא תמונה מלאה, אז יותר מהם פירושם יותר בתים, וזו בדיוק הסיבה שמקודדים מרווחים אותם כשאף אחד לא ביקש שום דבר אחר.
האם הגזירה מאבדת איכות?
הדרך המהירה לא, במובן המוחלט. שום דבר לא מפוענח, כך ששום דבר לא נדחס מחדש: הפריימים בפלט הם אותן פריימים דחוסים שהיו בקלט, בייט עבור בייט, במיכל חדש. חתוך קובץ עשר פעמים כך והעשירי זהה באיכותו לראשון.
הנתיב המדויק עושה זאת פעם אחת. החלון מפוענח ודחוס שוב, כך שהוא קולט דור אחד של אובדן. על מקור מקודד היטב במטרה איכותית הגיונית קשה לראות את זה, והכלל ההגיוני הוא לבצע את החיתוך שאתה צריך במעבר אחד מהמקור במקום לקצץ גזרה של גזרה.
אף אחת מהנתיבים לא מעלה, מחדד או משפר שום דבר. גוזם מסיר זמן, שזה כל העבודה.
למה הקליפ הגזום שלי לא מתחיל להתנגן מיד?
בגלל המקום שבו המדד נוחת, וזה אותו דגל שחשוב בעת הדחיסה.
MP4 מכיל טבלה המתארת היכן מתחילה כל פריים. כתוב בסדר הברור, הטבלה הזו מסתיימת בסוף הקובץ, מכיוון שהמקודד יודע את תוכנו רק כשהוא סיים. מושמע מדיסק, בסדר. מוגש דרך HTTP, שחקן לא יכול להתחיל עד שכל הקובץ יגיע.
הגוזם עובר -movflags +faststart, שעושה מעבר שני מהיר ומניע את השולחן הזה לחזית. לאחר מכן החתך מתחיל להתנגן בזמן שהוא מוריד, וזה מה שאתה רוצה כשהקובץ נכנס לאפליקציית צ'אט, CMS או שקופית שמושכת אותו מכתובת אתר.
מה קורה לאודיו?
האודיו נחתך על גבולות המסגרת שלו, ואלה קצרים בהרבה ממרווחי פריימים מפתח וידאו, כך שהשמע יכול להתחיל קרוב יותר לסימן שלך מאשר התמונה.
חוסר ההתאמה הזה הוא המקור לתקלת החיתוך הקלאסית האחרת: קליפ שהצליל שלו מעט לפני התמונה, או שמתחיל עם קטע של מילה. התיקון הוא בטיעונים ולא בעריכה, והגוזם מעביר אותו: -avoid_negative_ts make_zero מבסס מחדש את חותמות הזמן של שני הזרמים כך שהפלט מתחיל באפס כשהזרמים עדיין מיושרים זה לזה. בלעדיו, עותק זרם יכול לפלוט חותמות זמן שליליות עבור הפריימים בין פריים המפתח לנקודת החיתוך שלך, ושחקנים לא מסכימים לגבי מה לעשות עם אלה. חלק מדלגים, חלקם מתעכבים, חלקם מנגנים את האודיו מוקדם.
אם אתה רק רוצה את הסאונד, חתוך את הסרטון קודם ואז חילוץ האודיו הוא הסדר השגוי. חלץ תחילה וחתוך את האודיו, כי חיתוכים באודיו הם מדויקים וזולים.
האם עדיף לקצץ באפליקציית הצילום של הטלפון?
לקליפ אישי מהיר, זה בסדר וזה ממש שם. לכל דבר שתפרסם, לא, והסיבה אינה ברורה.
עורכי טלפון בדרך כלל מקודדים מחדש בייצוא, והם עושים זאת עם הגדרות שנבחרו למהירות ולגודל קובץ צפוי ולא לנאמנות. אתה משלם דור של הפסד על כל גזרה. גרוע מכך, חלקם חותכים בצורה לא הרסנית, מאחסנים את נקודות ה-In וה-OUT שלך כמטא נתונים לצד המקור, שנראה כמו חיתוך בטלפון ואינו חיתוך ברגע שהקובץ עוזב אותו: הנמען מקבל את הקליפ המלא, או רשימת עריכה שהנגן שלו מתעלם ממנו.
חיתוך מצב העתקה מונע את שתי הבעיות. הקובץ שאתה מקבל הוא הקובץ שכולם מקבלים, והפריימים בו מעולם לא פוענחו.
הסרטון עוזב את המכונה שלי?
לֹא . החתך עובר ffmpeg הידור ל-WebAssembly בתוך הכרטיסייה דפדפן: הקובץ נקרא מהדיסק לזיכרון העמוד, חתוך שם ומוחזר כהורדה. חלונית הרשת ב-DevTools נשארת ריקה מהסרטון בזמן שזה קורה.
עבור קטעים, זה חשוב יותר מאשר עבור רוב סוגי הקבצים. קליפ הוא בדרך כלל הדבר הגדול והאישי ביותר שכל אחד עורך, והסידור הרגיל עבור גוזם מקוון בחינם הוא שאתה מעלה את הצילומים שלך לאדם זר וסומכים על מדיניות השמירה בדף שלא קראת. כאן לא קיים עותק לשמירה.
המגבלות הן הכרטיסיות ולא התוכנית: חתך בודד מוגבל לשלושים דקות, וכל המקור צריך להתאים לזיכרון הדפדפן. מעבר לכך, כלי שולחני הוא גם מהיר יותר וגם אמין יותר, ועדיף לומר זאת מאשר להגיש לך כרטיסייה שנגמרת הזיכרון בדקה תשע.
מתי עורך שולחן העבודה הוא הכלי הנכון?
כשאתה עושה יותר מאשר להסיר זמן. הצטרפות למספר קליפים, הוספת כותרות, צבע, מוזיקה או חיתוך בצורת גל שאתה צריך לראות ברמת המדגם. זה ציר זמן עריכה, לא גוזם, והתשובה הנכונה היא עורך אמיתי.
בתוך הדפדפן, קו ההפרדה נקי כמעט באותה מידה. הסרת מתיחה אחת מקליפ אחד היא חיתוך. חיבור חלקים יחד הוא עוֹבֵ. מה שהופך את התוצאה לקטנה יותר הוא מַדחֵ, ושינוי המיכל או ה-codec הוא ממיר, שהוא א פעולה שונה מדחיסה למרות שהשניים מתבלבלים כל הזמן.
מדוע התצוגה המקדימה והקובץ המיוצא לא מסכימים?
מכיוון שממשק חיתוך אוסף את אותו מספר משלושה מקומות שאינם מסכימים על מהו מספר, והעלאתם לערך אחד היא רוב העבודה בגוזם.
שדה טקסט נותן לך כל מה שמישהו הקליד, שיכול להיות 7, 0:07, 00:00:07 או 7.25. סליידר נותן ציפה עם יותר דיוק ממה שמישהו רוצה. אלמנט וידאו currentTime נותן ציפה נוספת, שאינה בהכרח חותמת הזמן של מסגרת בכלל: דפדפנים רשאים לדווח על מיקום בין פריימים, והם עושים זאת.
אם השלושה הללו נוחתות בשניות מעט שונות, התצוגה המקדימה מציגה דבר אחד והיצוא מייצר אחר, שהוא הבאג הספציפי שגורם לגוזם להרגיש שבור גם כשהחתך נכון. המנתח כאן מקבל את כל שלוש צורות קוד הזמן, פותר אותן מיושר לימין כך שהחלק האחרון הוא תמיד שניות בכל אורך, ומעביר ערך בודד הן לתצוגה המקדימה והן לייצוא. שדה מוקלף למחצה לא מחזיר כלום במקום לזרוק, כך שהקלט לא יתפוצץ בכל הקשה בזמן שאתה מקליד 0:0.
העצה המעשית: הקלד את קוד הזמן במקום לגרור, כאשר השני המדויק חשוב. מחוון הוא למציאת הרגע, שדה מיועד למתן שמות.
איך אני חותך קטע מהאמצע?
שני חתכים וחיבור, ואף גוזם לא עושה את זה בשלב אחד, מה שמפתיע אנשים לעתים קרובות למדי.
הסרת האמצע של קליפ פירושה שמירה על החלק לפני הבחירה שלך והחלק שאחריו, שהוא שני חלונות נפרדים, ואז חיבורם בחזרה. הגוזם כאן מייצר חלון אחד לכל ריצה, אז הרצף הוא: חתוך מההתחלה ועד תחילת הקטע הרע, חתוך מסוף הקטע הרע ועד הסוף, ואז חבר את השניים ב- עוֹבֵ.
שני דברים שכדאי לצפות בהם כשאתה עושה את זה. ה-Join עובד בצורה נקייה כאשר שני החלקים חולקים codec, רזולוציה וקצב פריימים, מה שהם יגיעו אם שניהם יגיעו מאותו קובץ מקור דרך חיתוך מצב העתקה. והתפר נוחת על גבול פריים מפתח משני הצדדים, כך שהחלק השני מתחיל מעט מוקדם יותר ממה שסימנת, בדיוק כפי שתואר לעיל. אם נקודת החיתוך חשובה, השתמש במצב המדויק עבור היצירה השנייה.
האפשרות השנייה היא לעצור לפני שתתחיל: אם מה שאתה רוצה הוא הדגשה ולא עריכה, שני קליפים נפרדים הם לרוב שימושיים יותר מקליפ אחד עם פער תפור ממנו.
