לשים שני קבצי וידאו מקצה לקצה נשמע כמו הפעולה הזולה בעולם, ובמשך כחמש דקות האמנתי בזה. ואז הצטרפתי לקליפ של 1280x720 במהירות של 30 פריימים לשנייה לקליפ של 640x480 ב-25fps בשיטה המהירה ביותר שיש, שמעתיקה את הזרמים ולא משכתבת כלום. זה הפיק קובץ. הקובץ טען באורך של אחת עשרה נקודה תשע תשע שש שניות כאשר שני הקליפים מסתכמים באחת עשרה, המיכל אמר 1280x720 בעוד שהחצי השני של הזרם היה 640x480, וה-Muxer הדפיס אזהרה לגבי חותמות זמן משוכתבות עבור כל פריים של הקליפ השני. כל מה שקשור לחיבור וידאו נובע מהסיבה שזה קורה.
TL;DR: ה-Cheap Join עובד רק כאשר שני הקבצים כבר מסכימים על codec, רזולוציה, קצב פריימים ובסיס זמן, מה שצילומים משני מכשירים אף פעם לא עושים זאת. המסלול הכנה מפענח את שניהם ומקודד קובץ אחד חדש, שהוא איטי יותר ומייצר משהו שמתנגן. נמדד כאן: שיטת ההעתקה דיווחה על 11.996 שניות למשך 11 שניות של צילומים והכריזה על רזולוציה שגויה; הקוד מחדש הפיק בדיוק 11,000 שניות ב-1280x720 עקבי בודד תוך 0.63 שניות. יש להתאים תחילה קליפים בגדלים שונים למסגרת אחת, או שהחיבור נדחה על הסף. כְּכ עוֹבֵ עושה הכל בדפדפן, עד שמונה קליפים ושלושים דקות.
למה אפשר להדביק שני קליפים לא רק?
כי קובץ וידאו הוא לא זרם של תמונות עם כותרת עליו. זהו מיכל המחזיק זרמים מקודדים, והקידוד נושא מצב.
H.264 דוחס על ידי תיאור רוב הפריימים כהבדלים מפריימים אחרים. פריים מפתח עומד לבדו; כל מה שאחריו מוגדר ביחס למה שהיה קודם, עד לפריים המפתח הבא. המפענח צריך גם את ערכות הפרמטרים של Stream, המתארות את הרזולוציה, פורמט הצבע והפרופיל, והוא מחזיק בסיס זמן הממיר את המספרים בכל מנה לשניות.
שני קבצים שנעשו על ידי שני מכשירים מסכימים על שום דבר מזה. רזולוציה שונה פירושה ערכות פרמטרים שונות. קצב פריימים שונה פירושו בדרך כלל בסיס זמן שונה. אפילו שני קליפים מאותו טלפון, שהוקלטו בהפרש של שנה, יכולים להיות שונים מכיוון שאפליקציית המצלמה שינתה את הגדרות המקודד שלה.
שרשור הבתים נותן לך זרם שהמפענח שלו נאמר דבר אחד בכותרת ומעביר עוד חצי דרך. לפעמים שחקן מתמודד. לעתים קרובות הוא מציג את הקליפ הראשון ומפסיק, או מנגן את השני כרעש צבעוני.
מה מייצרת השיטה המהירה?
קובץ, ערימת אזהרות ומשך שגוי.
ffmpeg's concat demuxer עם העתקת זרם היא השיטה כל "פשוט הצטרף אליהם" ממליצה באינטרנט על תשובה, וזה באמת הכלי הנכון כאשר הכניסות תואמות. הצביע על שני הקליפים הלא תואמים שלי הוא יוצא בהצלחה, והנה מה שהוא מחזיר:
| מידה | מְצוּ | מְיוּ |
|---|---|---|
| תְמִ | 11,000 שניות | 11.996 שניות |
| החלטה מוצהרת | ערך אחד, נכון | 1280x720 עבור זרם שהופך ל-640x480 |
| אזהרות חותמת זמן | אף אחד | אחד לכל פריים של הקליפ השני |
האזהרות כולן אומרות את אותו הדבר:
Non-monotonic DTS; previous: 90981, current: 76133; changing to 90982.
This may result in incorrect timestamps in the output file.
חותמות הזמן של הקליפ השני מופעלות מחדש מאפס, כפי שהם צריכים בתוך הקובץ שלהם, וה-Muxer לא יכתוב זרם שחותמות הזמן שלו הולכים אחורה. אז הוא ממציא חדשים, פריים אחד בכל פעם, וההבדל המצטבר בין התזמון האמיתי לתזמון המומצא הוא המקום ממנו מגיעה השנייה הנוספת.
FFMPeg עדיין יכול לפענח את שני החצאים לאחר מכן, מכיוון ש-FFMPeg סובלני בצורה יוצאת דופן. דפדפן לא. זה הקובץ שמתנגן בסדר במחשב שלך ומציג מלבן שחור עבור צופה.
מה עולה ההצטרפות דרך גרף סינון, ומה זה קונה?
זה עולה פענוח מלא וקודד. הוא קונה קובץ שהוא נכון.
במקום להעתיק זרמים, כל קלט מפוענח למסגרות, המסגרות נחתכות ומצטרפות בתוך גרף סינון, וזרם חדש אחד מקודד מהתוצאה. כל פריים עובר דרך מפענח ומקודד, שזו עבודה אמיתית.
מה שהוא קונה הוא שלפלט יש codec אחד, רזולוציה אחת, קצב פריימים אחד וקבוצה אחת רציפה של חותמות זמן, כי הכל היה מקודד בבת אחת מאפס. על אותם שני קליפים:
| מידה | מַעֲר | גרף סינון |
|---|---|---|
| תְמִ | 11.996 שניות | 11,000 שניות |
| רזולוציה | מוצהר 1280x720, הופך ל-640x480 | 1280x720 לכל אורכו |
| מִסְבָ | 305 | 305 |
| זמן ייצוא | מֵז | 0.63 שניות |
| גודל | קטן יותר | 2.1 מגה |
0.63 שניות של עבודה למשך 11 שניות של פלט, על שולחן העבודה המריץ FFMPeg באופן מקורי. בלשונית דפדפן דרך WebAssembly זה איטי פי כמה, שהוא המסחר הכנה והסיבה שספירת הקליפים מוגבלת.
מדוע כל קליפ זקוק ל-TimeStamps שלו מחדש?
מכיוון ששרשור בגרף מסנן מצטרף לזרמים, וחותמות הזמן של הזרם הם מוחלטים.
כל מסגרות של קליפ מגיעות עם זמני נשיאה שנמדדו מתחילת הקובץ שלהם. חתוך קטע מאמצע קליפ והפריימים האלה עדיין אומרים "זה קורה ב-42 שניות". חבר אותם לקליפ שמסתיים ב-6 שניות ויש לך זרם שקפץ מ-6 ל-42, עם 36 שניות של כלום בין לבין.
setpts=PTS-STARTPTS מפחית את ההתחלה של כל קליפ משלו מכל פריים, כך שכל קליפ מתחיל באפס לפני שהוא מצטרף. המקבילה לאודיו היא asetpts. בלעדיהם הפלט מנגן את הקליפ הראשון, אחר כך הקפאה ארוכה, ואז את השני. זוהי הטעות הנפוצה ביותר בפקודות qfmpeg בכתב יד, והיא שקטה: הקובץ תקף ומשך הזמן פשוט שגוי.
מה קורה כשהקליפסים בגדלים שונים?
ההצטרפות מסורבים, ועד לאחרונה הסירוב הזה היה כל הסיפור כאן.
ה מסנן קונקט משווה את הכניסות שלו ולא יפעל אם מידות הווידאו או יחס הגובה-רוחב המדגם לא יסכימו:
Input link in0:v0 parameters (size 640x480, SAR 1:1) do not match the
corresponding output link in0:v0 parameters (1280x720, SAR 1:1)
Failed to configure output pad on Parsed_concat_8
זו ביטול, לא אזהרה: לא מופק קובץ. שני טלפונים, או קליפ טלפון והקלטת מסך, זה בדיוק המקרה שמפעיל את זה, וזו הסיבה הרגילה שמישהו בכלל מצטרף לקליפים.
אודיו לא צריך עזרה כזו, שכדאי לדעת כי זה מנוגד לאינטואיציה. אותו גרף הצטרף למסלול מונו של 44.1 קילו-הרץ לסטריאו של 48 קילו-הרץ ללא תלונה והפיק קובץ מדויק של 11,000 שניות. רק צד הווידאו הוא קפדני.
התיקון הוא להסדיר מסגרת אחת לכל ציר הזמן ולהתאים כל קליפ לתוכו לפני ההצטרפות. הגובה מגיע מרזולוציית הפלט שבחרת, או מהקליפ הראשון כאשר אתה שומר על רזולוציית המקור, והרוחב עוקב אחר יחס הגובה-רוחב של הקליפ כך שציר זמן של קטעי דיוקן נשאר לאורך. לאחר מכן כל קליפ מותאם כך שיתאים למסגרת הזו ומרופד כדי למלא אותה:
scale=1280:720:force_original_aspect_ratio=decrease,
pad=1280:720:(ow-iw)/2:(oh-ih)/2,setsar=1
התאמה במקום מילוי פירושה שקליפ בצורת אחרת הוא ב-Letterbox במקום למתוח, שהוא הקטן מבין שתי הרעות כאשר קליפ של 4:3 פוגש ציר זמן של 16:9. setsar=1 אינו עיטור: המסנן משווה יחס גובה-רוחב לדוגמה כמו גם ממדי פיקסלים, כך ששני קליפים יכולים להיות באותו גודל ועדיין להידחות.
שני הממדים מעוגלים למספרים זוגיים, מכיוון ש-H.264 ב-4:2:0 מאחסן צבע בחצי רזולוציה לכל כיוון ואינו יכול לקודד רוחב או גובה אי זוגי.
למה רק שמונה קליפים ושלושים דקות?
מכיוון שכל קליפ עולה מעבר פענוח בתוך לשונית דפדפן, ולכרטיסייה יש כמות קבועה של זיכרון.
שמונה כניסות פירושן שמונה מפענחים הפועלים על אותו גרף סינון, בתוספת המקודד, בתוספת כל קובץ מקור המוחזק בזיכרון מכיוון שאין דיסק להזרים ממנו. שלושים דקות של פלט הן הנקודה שעברה שהקידוד לוקח מספיק זמן כדי שאנשים יניחו שהדף נתקע.
אף גבול אינו חוק בפורמט. שניהם הם השורה שעברה בניית הדפדפן מפסיקה להיות נעימה, והם מצוינים מראש במקום להתגלות כאשר כרטיסייה קורסת ארבעים דקות לתוך ייצוא. גם קליפ קצר יותר מעשירית השנייה מסורב, כי מתחת לזה הוא לא תורם פריימים ושגיאות FFMPEG במקום מזהיר.
לכל דבר גדול יותר, זה הכלי השגוי ועורך שולחן העבודה הוא הנכון.
במה שונה הגזירה כאן מהגוזם?
חיתוך בתוך חיבור הוא מסגרת מדויקת, וזה לא עולה שום דבר נוסף.
המסורים וידיאו טרימר מציע מצב מהיר שמעתיק את הזרם ויכול לחתוך רק על פריים מפתח, וזו הסיבה שהתחלת הגזרה נוחתת לפעמים עד עשר שניות מוקדם. המדריך שלו מכסה מדוע בפירוט.
המסחר הזה לא קיים כאן, כי הייצוא ממילא מקודד הכל מחדש. הגזרה מתרחשת בתוך גרף המסנן, על פריימים מפוענחים, כך שחיתוך ב-4.3 שניות הוא חתך ב-4.3 שניות. אתה מקבל דיוק פריים בחינם, כתופעת לוואי של העלות שאתה כבר משלם.
אז אם אתה רוצה קליפ אחד חתוך ולא שום דבר אחר, המצב המהיר של הגוזם מהיר הרבה יותר. אם אתה מצטרף למשהו, חתוך כאן.
מה עושה שינוי מהירות לאודיו?
יש לטפל בו בנפרד, והחשבון אינו זהה לווידאו.
מהירות וידאו היא פעולת חותמת זמן: setpts=PTS/2 מפחית בחצי את זמן ההצגה של כל פריים והפריימים עצמם אינם נוגעים. אודיו לא יכול לעבוד כך, כי השמעת דגימות פי שניים מהר מעלה את הגובה באוקטבה. כְּכ atempo מסנן דגימה מחדש במקום זאת, שומר על הגובה ומשנה את משך הזמן.
atempo מקובל רק 0.5 עד 2.0 במעבר בודד במשך רוב חייו, כך ששינוי פי 4 נבנה כשני מעברים פי 2 ושינוי של 0.25x כששני מעברים פי 0.5. הבנייה הנוכחית העלתה את התקרה, ו-FFMPeg 8.1 מדווח על טווח של 0.5 עד 100. נמדד על קליפ אחד, סינגל atempo=4 ושרשרת atempo=2,atempo=2 נחת במרחק של 11 מילישניות זה מזה.
השרשרת היא עדיין מה שנבנה, מכיוון שהליבת WebAssembly מובאת בזמן ריצה במקום מוצמדת לגרסה, והכפלת מעברים נכונה בכל מבנה שאי פעם שלח את הפילטר. טווח המהירות המוצע, פי 0.25 עד פי 4, הוא המקום שבו התוצאה היא עדיין עריכה ולא חידוש.
MP4 או WebM?
MP4 אלא אם יש לך סיבה ספציפית, והסיבה היא כמעט תמיד רישיון ולא טיעון איכותי.
| mp4 | רֶכֶ | |
|---|---|---|
| קודק וידאו | H.264 | VP9 |
| קודק אודיו | אָסוֹט | אוֹפוס |
| משחק ב | הַכ� | דפדפנים, רוב השחקנים המודרניים |
| לקודד מהירות בכרטיסייה | יותר מהר | איטי במידה ניכרת |
| גודל באיכות דומה | גדול יותר | קטן יותר |
VP9 מייצר קבצים קטנים יותר באותה איכות נתפסת, והוא ללא תמלוגים, מה שחשוב לפרויקטים מסוימים ולא בכלל לאחרים. ffmpeg's own מדריך קידוד VP9 בוטה לגבי עלות המהירות. מה שזה לא מהיר. נתיב WebM כאן פועל ב-CRF גבוה יותר עם תאריך יעד בזמן אמת ו cpu-used 5, שהן הגדרות שקידוד שולחן העבודה יחשבו כבלתי זהירות, כי בלעדיהם קידוד VP9 בלשונית לוקח מספיק זמן כדי להרגיש שבור.
נתיב MP4 משתמש -preset veryfast ב-CRF 23 עם yuv420p, פלוס -movflags +faststart, שמעביר את האינדקס לקדמת הקובץ כך שהוא מופעל בזמן ההורדה ולא רק לאחר מכן.
כמה גדול יהיה הייצוא וכמה זמן זה ייקח?
הגודל ניתן לחיזוי מהרזולוציה. הזמן אינו צפוי מכלום.
מכיוון שהייצוא תמיד מקודד מחדש, גודל קובץ המקור אומר לך מעט מאוד על התוצאה. ההערכה המוצגת מגיעה מגובה הפלט במקום זאת: בערך 5 Mbps ב-1080p, 2.5 ב-720p, 1.2 מתחת לזה, כאשר WebM נוחתת בסביבות 70% מהנתון MP4 ואודיו המוסיפה 128 kbps אלא אם כן הושתקה.
זו אומדן ומתויג כאחד, כי התוכן חשוב יותר מכל נוסחה. צילום ראיון סטטי ו-Pan כף יד דרך עצים באותה רזולוציה ואותו CRF נבדלים בכמה פעמים, מכיוון ש-CRF מכוון לרמת איכות ומוציא כל קצב סיביות שדורש.
הזמן תלוי במחשב שלך, ברזולוציה, במספר הקליפים והאם יש ללשונית משהו אחר לעשות. ה-FFMPeg Run המקורי מעל 11 שניות של פלט תוך 0.63 שניות; צפו שהדפדפן יהיה איטי מזה פי כמה, וצפו ש-WebM יהיה איטי יותר.
מה זה לא עושה
הוא מצטרף, חותך, מסדר מחדש, מדרג, משנה מהירות ומפיל אודיו. זה כל סט התכונות, ואת הפער בינו לבין עורך וידאו כדאי להיות ברור לגביו.
אין מעברים, אין כותרות, אין רצועת מוזיקה, אין תיקון צבע, אין חיתוך, אין נפח לכל קליפ, אין שום דבר ממוסגר, אין תצוגה מקדימה של ציר הזמן המוגמר. כל קליפ נחתך וממוקם, קבוצה אחת של הגדרות פלט חלה על כולם, והתוצאה מקודדת.
זה מכסה עבודה אמיתית ומקובלת: מספר הקלטות שצריכות להפוך לקובץ אחד, קצוץ לחלקים השימושיים, בסדר הנכון, בגודל שמשהו יקבל. לכל דבר הכרוך בהחלטה יצירתית, השתמש בעורך.
באיזה סדר נכנסים הקליפים והאם אפשר לשנות?
הסדר שהוספת אותם, וכן, עם כפתורי העלייה והמטה בכל קליפ.
הזמנה מחדש היא פעולת רשימה ולא וידאו: העברת קליפ משנה את אינדקס הקלט שהוא תופס בגרף הסינון, ושום דבר לא נקרא מחדש או מפוענח מחדש עד שהייצוא פועל. אז מהלך הוא מיידי ככל שהקבצים גדולים, ותוכל לארגן מחדש ציר זמן כמה פעמים שתרצה בחינם.
כפתורים במקום גרירה ושחרור הם בחירה מכוונת עבור רשימה של שמונה פריטים לכל היותר. כל אחד מהם נושא תווית שקוראת לקליפ שהוא מזיז, כך שהסדר ניתן לשינוי באמצעות מקלדת וקריא על ידי קורא מסך, שאף אחד מהם לא נותן לך ידית גרירה ללא הרבה עבודה נוספת.
הדבר ששווה לבדוק לפני הייצוא הוא כיוון הרצף. מספר הקלטות של אותו אירוע מגיעות בדרך כלל מבוחר קבצים בסדר אלפביתי, שהוא סדר הקבצים של המצלמה שיוצרים במקרה ולא תמיד הסדר שבו בוצעו ההקלטות.
למה זה פועל בדפדפן?
מכיוון שהצילומים הם בדרך כלל מהסוג שאתה מעדיף לא להעלות, והעבודה לא צריכה שרת.
כל פעולה כאן היא ffmpeg, ו-ffmpeg קומפילציה ל-WebAssembly. הקבצים נקראים מהדיסק שלך ללשונית, מפוענחים שם, מצטרפים לשם, מקודדים שם ומוחזרים כהורדה. שום דבר לא מועלה, שום תור לא מחזיק את הצילומים שלך, ואין עותק במחשב שאתה לא שולט בו.
הקליפים שאנשים מצטרפים אליהם הם ראיונות, התייעצויות, הקלטות משפחתיות, צילומי מסך של תוכנה פנימית, טיוטות תחת אמברגו. האלטרנטיבה הרגילה מעלה כמה מאות מגה-בייט לשירות חינמי, ממירה אותו על חומרה שאינך יודע עליה דבר, ושומרת אותה בתנאים שאף אחד לא קורא.
העלויות הן שמונה תקרות הקליפ ושלושים הדקות, וקוד איטי יותר ממחשב שולחני. שניהם מצוינים לפני שמתחילים, וזה המסחר ששווה לקחת.
