לקוח ביקש ממני פעם הקלטת מסך קצרה של באג. הלכידה הייתה 212 מגה-בייט למשך ארבע דקות, וזה מה שעולה לך תצוגת רשתית ב-60 פריימים לשנייה, ושרת הדואר שלהם הקפיץ אותו פעמיים לפני שחשבתי שהמגבלה של 25 מגה-בייט בהודעת השגיאה לא הייתה המספר שהייתי צריך לנצח. הקבצים המצורפים מקודדים ב-base64, כך שהקובץ מגיע לגודל שליש גדול יותר ממה שהותיר. הייתי צריך להיות מתחת ל-18 מגה-בייט בערך, לא 25. ההקלטה יצאה במהירות של 6 מגה-בייט, 720p, ללא אודיו, ונראתה חדה לחלוטין, כי הקלטת מסך של באג היא בעיקר דף סטטי עם סמן שזז על פניו וזה נדחס יפה. השיעור השימושי לא היה הגדרה. זה היה שכל אחת מהעבודות האלה היא אותו חישוב של שלוש שורות, וברגע שאתה יכול לעשות את זה אתה מפסיק לנחש.
TL;DR: רמת איכות לא נותנת לך גודל קובץ, מכיוון שגורם בקצב קבוע הוא יעד איכותי והגודל המתקבל תלוי בכמות התנועה שהצילומים נושאים. כדי להגיע לגבול קשה, עבדו אחורה ממנו: קצב סיביות מטרה בקילוביט לשנייה הוא הגודל ב-Bytes כפול 8, חלקי משך הזמן בשניות, חלקי 1000. לאחר מכן בחר את הרזולוציה שקצב הסיביות הרגיל שלה יושב מתחת למספר הזה. הורדת 1080p עד 720p חוסכת יותר מכל מחוון איכותי, והורדת אודיו שאינך זקוקה לחסכון יותר ממה שאנשים מצפים. כְּכ מַדחֵף ב-Toolz.dev מריץ את ה-Encode דרך FFMPEG הידור ל-WebAssembly בלשונית הדפדפן שלך, מציג את האומדן לפני תחילתו, ולעולם לא מעלה את הקובץ.
מדוע הגדרה איכותית אף פעם לא מבטיחה לך מידה?
כי שתי הדרכים הנפוצות ביותר לדחוס סרטון עונות על שאלות שונות, וזו שמייצרת תוצאות טובות יותר היא זו שלא יכולה לומר לך את הגודל מראש.
ִתְשׁו מצב אומר: השתמש ב-2 מגה-ביט לשנייה, מה שזה דורש. הגודל אז הוא חשבון, צפוי בדיוק, והאיכות מתנדנדת בפראות. כרטיס כותרת עדיין וזריקת גשם כף יד מקבלים שניהם 2 Mbps, כך שכרטיס הכותרת מבזבז את רובו והגשם נראה כמו חצץ רטוב.
גורם שיעור קבוע מצב אומר: החזק את האיכות הזו, השקיע כל ביטים שצריך. מסגרות קלות מקבלות מעט ביטים, מסגרות קשות מקבלות רבות, והתמונה נשארת חזותית אפילו מההתחלה ועד הסוף. הגודל הוא מה שזה לא יהיה.
כל מקודד מודרני ממליץ על השני לכל דבר שלא מועבר בשידור חי, וזה מה שהמדחס כאן משתמש בו. העלות היא שהמספר בעמוד לפני הלחיצה על הכפתור הוא אומדן, הנגזר מקצב הסיביות האופייני לאותה רזולוציה ואיכות, והנתון האמיתי זז עם הצילומים. הקלטת מסך סטטי נוחתת באופן שגרתי בחצי מההערכה. צילומי כף יד של מים נעים יכולים לנחות מעליו. קונפטי, שלג, עלווה ברוח ובגרגרי מצלמה הם ארבעת הדברים שעוברים על פני כל הערכה, מכיוון שכולם קרובים לרעש אקראי ורעש הוא הדבר היחיד שדחיסה לא יכולה לעשות איתו כלום.
מה בוחר CRF כשאתה בוחר רמה?
הסולם פועל 0 עד 51 עבור 8 סיביות H.264, כאשר 0 הוא ללא הפסדים ו-51 אינו ניתן לצפייה, וה- FFMPeg H.264 מדריך קידוד מעמיד את ברירת המחדל ב-23 ואת טווח העבודה השפוי של בערך 17 עד 28. המאפיין שכדאי לשנן הוא שהסקאלה היא לוגריתמית: שינוי של 6 בערך בחצי או מכפיל את קצב הסיביות. העובדה הבודדת הזו אומרת לך מה כל רמה עושה לפני שאתה מנסה אותה.
המדחס מציע שלושה, לא מחוון, מכיוון שההבדל בין CRF 26 ל-27 אינו נראה בעוד שההבדל בין 23 ל-33 הוא כל הנקודה.
| רמה | H.264 CRF | VP9 CRF | אודיו | בשביל מה זה נועד |
|---|---|---|---|---|
| אור | 23 | 31 | 160 Kbps | ארכיון עותקים וצילומים שתערוך שוב. קרוב מספיק חזותית ללא אובדן. |
| מאוזן | 28 | 36 | 128 Kbps | התשובה הרגילה. בערך חצי מקצב הסיביות של האור, ועל מסך מחשב נייד אתה צריך לחפש את ההבדל. |
| חזק | 33 | 42 | 96 Kbps | פוגע בגבול קשה. חפצי אמנות מתחילים להופיע בצילומים מפורטים, ולאף אחד לא אכפת בהעלאת צ'אט. |
מספרי VP9 הם סולם נפרד, וזו הסיבה שהם נראים לא קשורים. רמת האור 31 היא בדיוק מה שגוגל VP9 קידוד המלצות לווידאו לפי דרישה רשום כאיכות היעד עבור 1080p, ואת שאר הטבלה כדאי לשמור על סימניות: 32 עבור 720p, 33 או 34 עבור 480p, 15 עבור 4k.
מה חוסך יותר מקום, איכות נמוכה יותר או פחות פיקסלים?
פחות פיקסלים, בפער רחב, והוא לא קרוב.
רזולוציה היא כמות דו מימדית. מעבר מ-1080p ל-720p אינו שליש, הוא יורד ב-2.07 מיליון פיקסלים ל-0.92 מיליון, כך שלמקודד יש 56% פחות פיקסלים לתאר לפני שהוא מקבל החלטה איכותית אחת. הקובץ מופיע בהמשך, בערך. מעבר מ-4K ל-1080p מסיר שלושה רבעים מהם.
הנה מה שקליפ של דקה נוחת, לפי גובה ורמת המקור, תוך שימוש בקצבי הסיביות האופייניים שמהם הכלי מעריך. אודיו כלול.
| מקור | אור | מאוזן | חזק |
|---|---|---|---|
| 4K (2160p) | 106 מגה-בייט | 61 מגה | 35 מגה |
| 1080p | 35 מגה | 20 מגה-בייט | 11 מגה |
| 720p | 20 מגה-בייט | 12 מגה | 7 מגה |
| 480p | 10 מגה-בייט | 6 מגה | 4 מגה |
קרא אותו לרוחב ולמטה. זזת צעד אחד למטה בעמודת האיכות חוסכת כ-43%. מעבר צעד אחד למטה בעמודת הרזולוציה חוסך גם כ-42%, מה שנראה כמו עניבה עד שתבחין שצעדי איכות אוזלים אחרי שלוש ועולים לך חפצים גלויים, בעוד ששלב רזולוציה לא עולה כלום על המסך שרוב האנשים יצפו בהם. קליפ 1080p המוצג בהודעה רפה מוצג בקופסה ברוחב של כ-400 פיקסלים.
הסדר לנסות, אם כן: זרוק את הרזולוציה לכל מה שהצופה ישתמש בו באופן מציאותי, ישמור על איכות מאוזנת, והגיע לחזק רק אם עדיין לא הצלחת.
איך נוחתים מתחת לגבול קשה כמו 8 מגה-בייט?
לעבוד אחורה. כל החישוב הוא שורה אחת, וזה היצירה היחידה של חשבון וידאו שכדאי ללמוד.
# total bitrate (kbps) = target size (bytes) x 8 / duration (s) / 1000
#
# 8 MB, 45-second clip:
# 8,000,000 x 8 / 45 / 1000 = 1,422 kbps total
# minus 96 kbps of audio = 1,326 kbps for video
#
# 1080p strong is ~1,400 kbps video -> about 8.4 MB. Just over.
# 720p strong is ~800 kbps video -> about 5.0 MB. Comfortable.
#
# the equivalent single pass, if you have ffmpeg installed:
ffmpeg -i input.mp4 -c:v libx264 -crf 33 -preset fast \
-vf scale=-2:720 -c:a aac -b:a 96k \
-movflags +faststart -pix_fmt yuv420p output.mp4
שלושה דברים הופכים את זה לאמין בפועל.
- להשאיר מרווח ראש. כוון ל-80% מהמגבלה. CRF לא פוגע ביעד גודל, והפעם האחת שהוא חורג הוא הזמן שבו אתה שולח את הקובץ.
- ספור את תקורה הקידוד אם הוא עובר בדוא"ל. Base64 מייצג כל 24 סיביות של קלט כ-4 תווים, על ידי RFC 2045, אז חיבור מתנפח בשליש על החוט. מגבלת תיבת דואר של 25 מגה-בייט היא כ-18 מגה-בייט של קובץ בפועל.
- אל תסמוך על מספר שזכרת. מגבלת ההעלאה החינמית של Discord הייתה 8 מגה-בייט, לאחר מכן 25 מגה-בייט, לאחר מכן 10 מגה-בייט, ולאחר מכן 20 מגה-בייט נכון לאוגוסט 2026. Gmail מחזיקה ב-25 מגה-בייט במשך שנים. WhatsApp דוחס מחדש כל דבר שאתה שולח בלי קשר. בדוק את המגבלה ביום שאתה צריך את זה, ואז בצע את החשבון.
אם הקליפ ארוך מהדבר שאתה רוצה להראות, המהלך הטוב יותר הוא לחתוך אותו במקום לסחוט אותו. חציית משך הזמן חותכת לחצי את הגודל באיכות מלאה, מה ששום הגדרה לא יכולה להשתוות. כְּכ וידיאו טרימר יוציא את הטווח מבלי לקידוד מחדש כלל כאשר החתך נוחת ליד מסגרת מפתח, והתוצאה היא קטעים זהים לבתים בחצי מהגודל.
האם הורדת קצב הפריימים עוזרת?
פחות ממה שהייתם חושבים, וזה נראה גרוע יותר מכל דבר אחר ברשימה.
הסיבה היא שפריימים רצופים כבר נדחסים זה מול זה. קודק וידאו מאחסן פריים מלא אחד ואז מתאר את ההבדלים, כך ש-Frame 31 בקליפ של 60 FPS הוא כמעט בחינם, מכיוון שהוא כמעט זהה ל-Frame 30. לזרוק אותו לא שומר את הביטים שאתה מדמיין שהוא שומר. בקצבים טיפוסיים החיסכון קרוב יותר לליניארי מאשר חופשי, כך ש-60 פריימים לשנייה עד 30 פריימים לשנייה מורידים אולי שליש ולא חצי, ו-30 פריימים לשנייה עד 15 פריימים לשנייה נותנים לך רעש גלוי בכל תנועת מצלמה.
ישנם שני מקרים שבהם זו השיחה הנכונה. הקלטת מסך של תוכן סטטי ברובו מאבדת שום דבר קריא ב-15 פריימים לשנייה, וזה בדיוק המקרה שבו אתה בדרך כלל מנסה בכל כוחה להיכנס מתחת לגבול. וצילומים שאתה ממיר לאנימציה עבור עמוד, שבו הצופה לא צופה ב-Motion אלא מבחין בה, שורד 12 עד 15 פריימים לשנייה בסדר.
לכל דבר עם אדם או מצלמה הזיזו בו, השאר את קצב הפריימים לבד והוריד את הרזולוציה במקום זאת.
האם האודיו צריך לשרוד?
שאל למה מיועד האודיו, כי הוא לא בחינם.
הקלטה של 10 דקות עם אודיו במהירות 128 kbps נושאת 9.6 mb של צליל לפני שהתמונה מקבלת ביט בודד. אם האודיו הזה הוא לכידת מסך שקטה עם זמזום חדר בתוכו, או מוזיקה שאתה הולך להחליף, או רצועת קול שכבר תמללת, שחרור זה הוא החיסכון הקל ביותר שיש וזה לא עולה לצופה כלום. למדחס יש מתג בדיוק זה, שעובר -an ומשמיט את זרם האודיו לחלוטין.
כשהסאונד חשוב, הרמות יורדות מ-160 ל-128 ל-96 kbps, שהן הנקודות המקובלות. 96 Kbps AAC מתאים לדיבור ודק בקול במוזיקה. אם אתה רוצה את האודיו לבד, כקובץ לתמלל או לערוך, מַחלֵל הַ מושך את המסלול החוצה מבלי לגעת בסרטון, וה ממיר אותיות רישיות וקטנותו יקודד אותו מחדש בתנאים שלו.
פרט אחד תופס אנשים. סרטון ללא רצועת אודיו מתנגן בשקט ברוב הנגנים ולא מצליח להפעלה אוטומטית בכמה דפדפנים ישנים לנייד שמצפים שהרצועה תשתקה. אם הקליפ נכנס לדף אינטרנט, רצועה שקטה של 8 kbps היא לפעמים בטוחה יותר מכלום, אם כי כל משלוח דפדפן היום מטפל ב-MP4 של וידאו בלבד.
האם WebM שווה את ההמתנה הנוספת?
זה תלוי לחלוטין מי פותח את הקובץ.
VP9 במיכל WebM נוחת בערך ברבע מ-H.264 באיכות גלויה דומה. זה רווח אמיתי, ובאתר שלך, שבו הדרישה היחידה היא שדפדפן יוכל להפעיל אותו, WebM הוא בדרך כלל הקובץ הטוב יותר. Chrome, Firefox ו-Edge תמכו ב-VP9 במשך עשור, ומאז גרסה 14 של Safari.
העלות מופיעה פעמיים. קידוד VP9 איטי יותר מ-x264, באופן מהותי בדפדפן, ופרט אחד מעביר את כל מי שמפעיל את הפקודה ביד: VP9 מכבד יעד איכותי רק כאשר קצב הסיביות הוא אפס במפורש. לְבַ -crf 36 בפני עצמו והמקודד משתמש בשקט בקצב סיביות ברירת מחדל במקום ומתעלם ממך. זה צריך -crf 36 -b:v 0, וזה מה שהכלי שולח.
העלות השנייה היא כל מה שהוא לא דפדפן. אפליקציות צ'אט, שדות העלאה של CMS, עורכי וידאו, PowerPoint, חלונית התצוגה המקדימה במנהל קבצים, הטלפון של הלקוח שלך: רבים מהם מקבלים MP4 ומשיכים בכתפיים ב-WebM. אם הקובץ הולך לאדם, שלח MP4 עם H.264. אם הוא נכנס לדף שאתה שולט בו, WebM. אותו פיצול עובר דרך כל שאלת הפורמט, שבה מדריך רמוקס כיסויים מצד ההמרה.
למה MP4 דחוס לפעמים מסרב להתחיל לנגן?
בגלל המקום שבו הגיע האינדקס, וזה הדגל האחד שאסור לך לעזוב.
MP4 שומר תוכן עניינים המתאר היכן כל פריים מתחיל. הכתובת כרגיל, המקודד מגלה את כל זה תוך כדי וכותב את הטבלה בסוף הקובץ. להפעלה מדיסק זה בסדר. מוגש דרך HTTP, זה אומר שהנגן לא יכול להתחיל עד שיש לו את כל הקובץ, אז סרטון של 40 מגה-בייט באפליקציית צ'אט או CMS יושב שם ולא עושה כלום בזמן שהוא מוריד, ואז מתחיל.
-movflags +faststart עושה מעבר שני על הקובץ המוגמר ומעביר את הטבלה לחזית. הקידוד לוקח רגע יותר והסרטון מתחיל להתנגן לאחר שנייה. לכל MP4 שהמדחס מייצר יש את זה.
שני דגלים נוספים בפקודה זו יש לתאימות ולא לגודל. -pix_fmt yuv420p כוחות 4:2:0 תת-דגימת כרומה, מכיוון ש-4:2:2 או 4:4:4 MP4 תקף ומסרב לנגן ברשימה ארוכה של מפענחי חומרה. ומסנן קנה המידה נכתב scale=-2:720 יותר מאשר scale=-1:720, כי H.264 דורש ממדי פיקסלים ו -2 מעגל את הרוחב המחושב למספר זוגי. בקש רוחב אי זוגי והקידוד נכשל עם "רוחב לא מתחלק ב-2" במקום להתאים למשהו קרוב.
למה דחיסה פעמיים נראית הרבה יותר גרועה?
אובדן דור, והוא תלול יותר ממה שאנשים מצפים כי דחיסה אובדן אינה עוצמתית.
הקוד הראשון זורק את הפרטים שהוא שופט שהעין לא תפספס ומשאירה אחריה חפצי אמנות משלה: חסימה קלה בקצוות, שיפועים מוחלקים, צלצול סביב ניגודיות גבוהה. לקידוד השני אין דרך לדעת שהחפצים האלה אינם התמונה. הוא מתייחס אליהם כאל תוכן שכדאי לשמר, מוציא ביטים בתיאורם ומוסיף את שלו על גבי. שלושה סבבים של דחיסה מאוזנת על אותו קליפ נראים גרועים יותר מסיבוב אחד של חזק, בגודל קובץ גדול יותר.
אז הכללים המעשיים קצרים. דחוס מהמקור בכל פעם, אף פעם מהעותק שכבר יצרת. אם אתה צריך גם גרסת ארכיון קלה וגם גרסה קטנה כדי לשלוח, צור את שניהם מהמקור. ואם כבר עבר קובץ דרך פלטפורמה שמדחסת מחדש בהעלאה, שהיא רובם, התייחסו כבר למה שהורדתם כדור שני.
זה אותו חשבון שקובע דחיסת תמונה והסיבה ש-JPEG שנשמר הופך שוב ושוב לבוץ, ואותה סיבה מדחס PDF עובד על התמונות בתוך מסמך ולא על המסמך בכללותו.
האם הקובץ עוזב את המחשב שלך?
לא, ולווידאו זה משנה את מה שהכלי שמיש עבורו.
הקידוד עובר ffmpeg הידור ל-WebAssembly, מופעל בלשונית הדפדפן. הקובץ נקרא מהדיסק שלך לזיכרון העמוד, מקודד שם ומוחזר כהורדה. פתח את כלי ה-DevTools, עבור לחלונית הרשת, דחוס משהו וצפה: אין בקשה נושאת את הסרטון.
שלוש השלכות בהמשך.
שום דבר לא מועלה, אז שום דבר לא נשמר. לא יושב עותק על שרת ומחכה למדיניות שמירה כדי למחוק אותו, כי לא נוצר עותק. להדגמת מוצר שלא שוחררה, קטעים תחת NDA, או כל דבר עם אדם שלא הסכים להעלאה של צד שלישי, זה ההבדל בין שמיש ולא.
המגבלות הן הדפדפנים, לא התוכניות. כל הקובץ נכנס לזיכרון הכרטיסיות, כך שהדף מקבל עד 500 מגה-בייט ומכסה מעבר בודד ב-30 דקות, והוא בודק את שניהם כאשר אתה בוחר את הקובץ ולא לאחר הורדה של מנוע של ארבעה מגה-בייט ושתי דקות של קידוד. אין תור, אין סימן מים, אין חשבון ואין דרגת גודל לקנות.
הריצה הראשונה איטית יותר. חבילת FFMPeg WebAssembly מוריד פעם אחת, שלוקח כמה שניות, ונשמר לאחר מכן במטמון. הכלי טוען אותו על הדחיסה הראשונה ולא כשהדף נפתח, כך שהדף עצמו נשאר מהיר.
מתי מקודד שולחני הוא הכלי הנכון?
כאשר המספרים שלמעלה מפסיקים להיות האילוץ. לשונית דפדפן היא מקודד סביר וצינור וידאו גרוע, ושווה להיות ברור היכן הקו נופל.
עבור לקבצים מעל 500 מגה-בייט או קליפים מעל חצי שעה, כאשר זיכרון הכרטיסיות הוא הגבול האמיתי. עבור ל-Native עבור אצווה, כי 40 קליפים דרך לולאה במעטפת מנצחים 40 נסיעות בכל ממשק. עבור למקור כאשר אתה צריך קידוד דו-מעבר כדי להגיע לגודל מדויק, שמעבר CRF בודד לא יכול להבטיח. ועבור ל-Native עבור קידוד חומרה, שבו GPU יעשה תוך 20 שניות את מה ש-WebAssembly לוקח ארבע דקות.
עבור קליפ אחד שצריך לרדת למגבלה בחמש הדקות הקרובות, במחשב נייד, מבלי להתקין דבר או למסור את הצילומים לאדם זר, הדפדפן הוא הנתיב המהיר יותר במרחק. זו העבודה מַדחֵ נבנה עבור, לצד ה ממיר לשינוי הפורמט וה- מדחס תמונה לאותה בעיה מימד אחד למטה.
