בפעם הראשונה שהמרתי הקלטת מסך ללקוח, עשיתי את זה כמו שכולם עושים: הורדתי את ה-MOV לממיר, חיכיתי אחת עשרה דקות ושלחתי את ה-MP4. הקובץ היה קטן יותר ב-40% ורך יותר באופן ניכר, והלקוח שאל מדוע הטקסט בהדגמה נראה מטושטש. התשובה הייתה ששום דבר לא צריך להמיר מלכתחילה. הסרטון בתוך ה-MOV הזה כבר היה H.264, וזה בדיוק מה ש-MP4 מחזיק. 11 דקות של קידוד מחדש זרקו את האיכות כדי לייצר קובץ שיכול היה להיות זהה בתים תוך כשתי שניות. זה כל הרעיון מאחורי ממיר וידאו על Toolz.dev, וכדאי להבין בכל כלי בו אתה משתמש.
TL;DR: רוב קבצי ה-MOV כבר מכילים H.264 וידאו ואודיו AAC, שזה אותו הדבר ש-MP4 מכיל, כך שהמרה ביניהם אינה מצריכה קידוד מחדש כלל. הזרמים מועתקים לקונטיינר חדש, תהליך הנקרא רימוקסינג. זה לוקח שניות במקום דקות ולא מאבד כלום, כי אף פיקסל לא מפוענח או דחוס מחדש. הכלי ממיר וידאו מעתיק כברירת מחדל ומקודד מחדש רק כאשר הפורמטים דורשים זאת באמת, והוא פועל דרך FFMPeg הידור ל-WebAssembly בתוך לשונית הדפדפן שלך, כך שהסרטון לעולם לא יועלה.
מהו מיכל, ולמה זה משנה?
לקובץ וידאו יש שתי שכבות, וכמעט כל דבר מבלבל בהמרת וידאו נובע מערבוב ביניהם.
ה קוֹל הוא העטיפה. הוא מחזיק את הזרמים, מתעד כמה הם ארוכים, היכן כל פריים מתחיל, באיזו שפה נמצאת רצועת האודיו ואיזו תמונה ממוזערת להציג. MP4, MOV, WebM, AVI ו-MKV הם מכולות. הסיומת בקובץ נותנת שם לקונטיינר, לא לסרטון.
ה קוֹד הוא הדחיסה בפנים. H.264, H.265, VP9 ו-AV1 דוחסים את התמונה. AAC, Opus, MP3 ו-FLAC דוחסים את הסאונד. ה-codec הוא זה שקובע אם הקובץ מופעל במכשיר נתון, וזה מה שלוקח זמן לשנות.
ברגע שאתה מפריד בין שני הרעיונות האלה, השאלה השימושית מפסיקה להיות "איזה פורמט זה?" והופכת "איזו שכבה אני משנה?" שינוי המיכל הוא זול. שינוי ה-codec הוא יקר ומאבד. כלי שלא מבחין ביניהם יגבה ממך את הפעולה היקרה עבור העבודה הזולה בכל פעם.
מדוע MOV ל-MP4 כמעט מיידי?
כי MOV ו-MP4 הם קרובי משפחה קרובים. Quicktime's פורמט הקובץ היה הבסיס לפורמט קובץ המדיה הבסיסי של ISO, שעליו בנוי MP4, כך ששני הקונטיינרים מארגנים את הנתונים שלהם כמעט באותו אופן. והזרמים בתוכם הם בדרך כלל אותם זרמים: הקלטת אייפון, לכידת מסך של Mac, קליפ DSLR וייצוא בכורה, כולם מייצרים בדרך כלל וידאו H.264 עם אודיו AAC, בין אם הם עוטפים אותו ב-.mov או .mp4.
אז ההמרה היא א רֵימַצִ: קרא היכן כל זרם מתחיל ונגמר, כתוב את הבתים האלה לתוך מיכל חדש, כתוב אינדקס חדש. שום מסגרת לא מפוענחת. לא נבדק פיקסל. הפלט הוא אותם נתוני וידאו במעטפת אחרת, והוא חסר הפסד במובן זה שהפריימים המפוזרים זהים ביט-עבור-ביט.
בפועל זה אומר שקליפ של שתי דקות מסתיים תוך שנייה בערך במקום דקה או יותר, וגודל הקובץ בקושי זז, כי נתוני הווידאו לא השתנו. ממיר שלוקח דקות על העבודה הזו ומחזיר קובץ קטן יותר קידד אותו מחדש, וירידה בגודל היא איכות שכבר אין לך.
הנה כאשר כל נתיב חל.
| מקור | מטרה | מה קורה | מהירות | עלות איכותית |
|---|---|---|---|---|
| MOV (H.264/AAC) | mp4 | Remux, זרמים מועתקים | שְׁנִ | אף אחד |
| MP4 (H.264/AAC) | לְהִשְ | Remux, זרמים מועתקים | שְׁנִ | אף אחד |
| mov או mp4 | רֶכֶ | רֶה -קידוד ל-VP9/OPUS | דקות | חלק, תלוי בהגדרות |
| כל סרטון | GIF | רֶה -קידוד, פלטה מופחתת ל-256 צבעים | דקות | חמור, לפי עיצוב |
| GIF | mp4 | רֶה -קידוד ל-H.264 | שניות עד דקה | מינורי, בדרך כלל בלתי נראה |
מתי צריך לקודד מחדש?
שלושה מקרים, ורק שלושה.
מיכל היעד לא יכול להחזיק את ה-codec. WebM מקבלת VP8, VP9 ו-AV1 עבור וידאו ו-Vorbis או Opus עבור אודיו. הוא אינו מקבל את H.264. אז MP4 ל-WebM הוא תמיד המרה אמיתית, וזה ייקח זמן אמת.
ה-Codec המקור אינו H.264 במעטפת H.264. ProRes MOV ממצלמה, לכידת DV, DivX AVI ישן: אלה מחזיקים קודקים ש-MP4 יכול לשאת מבחינה טכנית במקרים מסוימים, אך רוב השחקנים יסרבו. המרתם פירושה פענוח ודחיסה מחדש.
אתה משנה את התמונה בכוונה. הורדת הרזולוציה, הורדת קצב הסיביות, שינוי קצב הפריימים. אין דרך להקטין סרטון מבלי לדחוס אותו מחדש, וזו הסיבה שכיווץ קובץ הוא עבודה שונה משינוי הפורמט שלו. בשביל זה, השתמש ב מַדחֵף, שקיים בדיוק בגלל שדחיסה והמרה הן פעולות שונות שאנשים מבלבלים באופן סביר.
למה המרה ל-GIF הרבה יותר גרועה ממה שזה נשמע?
GIF מכיל לכל היותר 256 צבעים עבור כל התמונה. זה הגבול המגדיר, המוגדר ב- מפרט GIF89A בשנת 1989, ואף מקודד לא יכול לעקוף את זה. לכן כל המרה מסרטון ל-GIF צריכה לבחור אילו 256 צבעים מתוך 16.7 מיליון שהמקור עשוי להכיל.
נעשה בתמימות, מסגרת אחר פריים, כל פריים בוחר את ה-256 הטוב ביותר שלו. התוצאה היא שאותה חולצה היא בצבע מעט שונה במסגרות רצופות, ונראה שהתמונה כולה זוחלת ומנצנצת. זוהי התלונה הנפוצה ביותר לגבי פלט וידאו ל-GIF, והיא לחלוטין חפץ של פלטות לכל פריים.
התיקון הוא קידוד של שני מעברים: סרוק תחילה את כל הקליפ, בנה פלטה אחת שמשרתת את כל זה, ואז קודד כל מסגרת מול הפלטה המשותפת הזו. הזחילה נעלמת כי הצבעים מפסיקים לנוע. ממיר Toolz מריץ את שני המעברים, וזו הסיבה ש-GIF ממנו לוקח רגע יותר מכלי במעבר בודד ונראה יציב הרבה יותר.
ההפתעה השנייה היא הגודל. GIF מאחסן מסגרות שלמות ולא את ההבדלים ביניהן, ללא פיצויי תנועה שהופך את קודקים הווידאו המודרניים ליעילים. קליפ של חמש שניות שהוא 400 KB כ-MP4 יהיה באופן שגרתי 4 MB כ-GIF. מה שמוביל להמרה שכדאי לעשות לעתים קרובות יותר ממה שאנשים מבינים.
האם עלי להמיר GIF ל-MP4 במקום?
כמעט תמיד, כן. אותה אנימציה המקודדת כמו H.264 היא בדרך כלל עשירית מהגודל, מופעלת בדפדפנים ניידים שבהם gif גדול נתקע או מצער, ותומך בפענוח חומרה כך שהוא לא מחמם את הטלפון. כל פלטפורמה חברתית גדולה ממירה בשקט את קובצי ה-GIF שאתה מעלה לווידאו בדיוק מהסיבות הללו, וזה אות סביר לגבי הפורמט המתאים לעבודה.
פרט אחד מחליט אם ההמרה עובדת בכלל. H.264 דורש ממדי פיקסלים זוגיים, בגלל איך התקן מארגנים דגימת כרומה, ול-GIF יש לעתים קרובות כאלה מוזרים: GIF ברוחב 601 פיקסלים הוא נורמלי לחלוטין. מקודד עם ממדים מוזרים או נכשל על הסף עם הודעה סתמית או מרפד בשקט את המסגרת. הממיר כאן מעגל את הגודל למספר הזוגי הקרוב ביותר לפני הקידוד, שהוא חיתוך של פיקסלים אחד שאף אחד לא יכול לראות ואת ההבדל בין קובץ לשגיאה.
הסרטון מועלה לשום מקום?
לא, וזה החלק שמשנה את אופן השימוש בו. ההמרה עוברת ffmpeg הידור ל-WebAssembly, מבוצע בתוך לשונית הדפדפן שלך. הקובץ נקרא מהדיסק שלך לזיכרון העמוד, מומר שם ומוחזר כהורדה.
יש לזה שלוש השלכות מעשיות:
- שום דבר לא עוזב את המכונה שלך. פתח את כלי ה-devtools, עבור לחלונית הרשת, המרת קובץ וצפה: אין בקשה נושאת את הסרטון. עבור צילומים תחת NDA, הדגמות מוצרים שלא פורסמו, כל דבר שיש בו אדם שלא הסכים להעלאה של צד שלישי, זה ההבדל בין שמיש ולא.
- אין תור ואין מכסה גודל. אתה לא מחכה מאחורי עבודות של אנשים אחרים, ושום תוכנית לא מגבילה אותך ל-100 מגה-בייט. הגבול האמיתי הוא הזיכרון של לשונית הדפדפן שלך, שבמחשב נייד רגיל מטפל בקבצים של כמה מאות מגה-בייט בנוחות.
- הריצה הראשונה איטית יותר מהשאר. על חבילת ffMPEG WebAssembly להוריד פעם אחת, שזה כמה שניות. לאחר מכן הוא נשמר במטמון, והמרות עוקבות מתחילות מיד.
המסחר כנה: שרת עם מקודד ייעודי מהיר יותר בקבצים גדולים מאוד. עבור הקליפים שרוב האנשים ממירים, הנסיעה הלוך ושוב של העלאה והורדה עולה יותר זמן ממה שהקידוד חוסך.
אילו הגדרות עושות את ההבדל?
עבור רימוקס, אין. אין מה להגדיר, כי שום דבר לא נקבע מחדש.
לקידוד מחדש, שניים.
רזולוציה עושה יותר מכל הגדרה אחרת. חציית רבע הרוחב והגובה ספירת הפיקסלים, והקובץ מגיע בערך. מעבר מ-1080p ל-720p הוא השינוי היעיל ביותר שקיים, ובמסך הטלפון קשה לראות את ההבדל.
קצב סיביות או יעד איכותי הוא השני. רוב הכלים חושפים זאת כמחוון איכותי ולא כמספר, שזו השיחה הנכונה: קצב סיביות קבוע מבזבז ביטים על סצנות פשוטות ומרעיב סצנות מורכבות, בעוד יעד איכותי מוציא את מה שכל סצנה צריכה.
קצב הפריימים הוא מנוף שלישי שאנשים מגיעים אליו ובדרך כלל לא צריכים. הורדת 30fps ל-15fps מפחיתה בחצי את הפריימים אך הופכת את התנועה למגמגמת בעליל, וזה חוסך פחות משינוי הרזולוציה מכיוון שבכל מקרה פריימים עוקבים דוחסים היטב אחד את השני.
# What a remux looks like at the command line. -c copy is the whole trick:
# copy the streams, do not decode them.
ffmpeg -i input.mov -c copy output.mp4
# Compare to a real conversion, which decodes and re-compresses every frame.
ffmpeg -i input.mov -c:v libx264 -crf 23 -c:a aac output.mp4
הפקודה הראשונה מסתיימת בערך בזמן שלוקח לקרוא את הקובץ. השני לוקח כל עוד הסרטון מורכב. כל ממיר מבוסס דפדפן ששווה להשתמש בו עושה את אותה הבחנה פנימית, ואת ממיר וידאו עושה.
מה קורה לשמע כשהמיכל משתנה?
על רימוקס, כלום. רצועת AAC מועתקת על פני Byte עבור Byte יחד עם הסרטון, וזו הסיבה שהמרת MOV ל-MP4 לא יכולה לדרדר את הסאונד: אותם נתוני אודיו דחוסים מגיעים לעטיפה החדשה.
בקידוד מחדש זה תלוי במטרה. WebM לא יכול לשאת AAC, אז האודיו נדחס מחדש ל-OPUS, וזה שלב אובדן המוחל על אודיו שכבר אובד. לעתים רחוקות הוא נשמע בדיבור ומדי פעם נשמע במוזיקה עם הרבה פרטים בתדר גבוה, כמו מצלתיים.
לפעמים האודיו הוא הדבר היחיד שאתה רוצה. ראיון מוקלט שצולם אך יפורסם כפודקאסט, הרצאה שתרצו בטלפון, פסקול שאתם מתמללים. המרת הסרטון כולו ואז השלכת התמונה היא הדרך האיטית. כְּכ מַחלֵל הַ שולף את הסאונד ישירות, ועבור מקורות MP4 ו-MOV הוא יכול להעתיק את רצועת ה-AAC הקיימת ל-M4A ללא קידוד מחדש, בדיוק אותו טריק כמו Remux. אם הקובץ שיש לך כבר אודיו ורק הפורמט שגוי, ה ממיר אותיות רישיות וקטנותו מטפל בצד הזה.
דבר אחד שכדאי לדעת: קובץ וידאו יכול לשאת מספר רצועות שמע, עבור שפות שונות או פרשנות נפרדת. רוב הכלים מבוססי הדפדפן, כולל זה, עובדים עם הרצועה הראשונה. אם למקור שלך יש יותר מאחד ואתה צריך אחד ספציפי, זו עבודה עבור FFMPEG בשורת הפקודה עם בורר זרם מפורש.
איזה פורמט כדאי לשלוח ולמי?
רוב עבודת ההמרה היא באמת השאלה הזו עם תחפושת. התשובה הכנה היא ש-MP4 עם H.264 וידאו ו-AAC Audio הוא הבחירה הנכונה הרבה יותר מכל שילוב אחר, מכיוון שהוא היחיד שמתנגן בכל מקום ללא מחשבה.
| לאן זה הולך | לִשְ | למה |
|---|---|---|
| לקוח, עמית, אימייל | MP4 (H.264/AAC) | השמעות בכל טלפון, מחשב נייד ודפדפן שנעשו בעשור הזה |
| אתר אינטרנט שאתה שולט בו | MP4, עם WebM כמקור שני | WebM קטן יותר באותה איכות, MP4 הוא ה-fallback |
| פלטפורמות חברתיות | mp4 | הם מקודדים מחדש את כל מה שאתה שולח, אז תן להם את הקלט הנקי ביותר |
| ציר זמן עריכה | הקובץ המקורי | כל המרה לפני העריכה עולה איכות לא ניתן לקבל בחזרה |
| אפליקציית צ'אט עם מכסה גודל | MP4, דחוס | שנה את הגודל, לא את הפורמט |
| מוטבע בחתימת אימייל או README | mp4 אם מותר, GIF רק אם לא | GIF הוא נפילה למקומות שמסרבים לווידאו, לא בחירה |
השורה שחוסכת הכי הרבה צער היא העריכה. אנשים ממירים קטעים לפני ייבואם, מאבדים איכות, ואז עורכים ומייצאים, מאבדים יותר. אם ציר זמן מקבל את המקור, תן לו את המקור והמר פעם אחת בסוף.
הטעות הנפוצה הנוספת היא המרה כאשר התכוונת לדחוס. "קובץ זה גדול מדי עבור מגבלת ההעלאה" אינו בעיית פורמט. שינוי MOV ל-MP4 לא יעזור, מכיוון שנתוני הווידאו זהים. להקטין אותו פירושו קידוד מחדש בכוונה, וזה מה מַדחֵף הוא עבור, או חיתוך החלקים שאינך צריך עם וידיאו טרימר ראשון. שלושים שניות שאתה חותך זה שלושים שניות שאף אחד לא צריך לקודד, וזה מנצח כל הגדרה איכותית.
איך זה בהשוואה להמרת תמונות?
אותו פיצול מיכל מול קודק קיים עבור תמונות, עם אותה תוצאה: חלק מההמרות זולות וללא אובדן, אחרות זורקות מידע. המרת PNG ל-BMP שומרת על כל פיקסל; המרתו ל-JPEG לא. כְּכ מדריך ממיר פורמט תמונה מכסה את הצד הזה, ואת מדריך דחיסת תמונה מכסה את ההבחנה המפסידה-לעומת ההפסד בעומק יותר ממה שמתאים כאן.
ההבדל המעשי הוא קנה מידה. המרת תמונה גרועה עולה לך תמונה אחת. המרת וידאו גרועה עולה לך אחת עשרה דקות ולקוח שואל מדוע הטקסט נראה מטושטש.
שאלות נפוצות
האם MOV או MP4 טובים יותר? גם, לרוב המטרות, כי הם בדרך כלל מכילים את אותו סרטון. ל-MP4 יש תמיכה רחבה יותר במכשירים, כך שהוא ברירת המחדל הבטוחה יותר לשיתוף. MOV הוא מה ש-Apple Tools מייצרים, והוא נושא כמה קודקים מקצועיים ש-MP4 לא.
מדוע הקובץ שהומר שלי גדל? המרת ל-codec או מיכל פחות יעיל, או ל-gif. Remux אף פעם לא משנה את הגודל באופן משמעותי; קידוד ל-codec ישן יותר יכול להצמיח אותו בקלות.
למה ה-MP4 שלי לא מתנגן במכשיר ישן? המיכל בסדר; ה-codec לא. זרם H.265 בעטיפת MP4 לא יתנגן על חומרה שמפענחת רק את H.264, למרות שהתוסף נראה מוכר. זהו המקרה הברור ביותר של השכבות החשובות.
