איך עובד Codec וידאו? חלק 2. מה, למה, איך

часть Первая: יסודות העבודה עם וידאו ותמונות

מה? Codec וידאו הוא תוכנה/חומרה שדוחסת ו/או מפרקת וידאו דיגיטלי.

בשביל מה? למרות מגבלות מסוימות הן מבחינת רוחב הפס והן
ובמונחים של שטח אחסון נתונים, השוק דורש וידאו באיכות גבוהה יותר. זוכרים איך בפוסט האחרון חישבנו את המינימום הנדרש ל-30 פריימים לשנייה, 24 ביטים לפיקסל, ברזולוציה של 480x240? קיבלנו 82,944 Mbit/s ללא דחיסה. דחיסה היא כיום הדרך היחידה לשדר בדרך כלל HD/FullHD/4K למסכי טלוויזיה ולאינטרנט. איך זה מושג? עכשיו בואו נסתכל בקצרה על השיטות העיקריות.

התרגום נעשה בתמיכה של תוכנת EDISON.

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

Codec לעומת קונטיינר

טעות נפוצה שמתחילים עושים היא בלבול בין רכיבי Codec וידאו דיגיטלי לבין מיכל וידאו דיגיטלי. קונטיינר הוא פורמט מסוים. עטיפה המכילה מטא נתונים של וידאו (ואולי אודיו). ניתן לחשוב על הסרטון הדחוס כמטען מיכל.

בדרך כלל, הסיומת של קובץ וידאו מציינת את סוג המיכל שלו. לדוגמה, הקובץ video.mp4 הוא כנראה מיכל MPEG-4 חלק 14, וסביר להניח שקובץ בשם video.mkv מטריושקה. כדי להיות בטוח לחלוטין בפורמט ה-Codec ו-Container, אתה יכול להשתמש FFmpeg או מדיה.

קצת היסטוריה

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

Codec וידאו H.261 הופיע ב-1990 (טכנית - ב-1988) ונוצר לפעול בקצב העברת נתונים של 64 Kbps. הוא כבר השתמש ברעיונות כמו תת-דגימת צבע, בלוקים של מאקרו וכו'. תקן ה-codec של הווידאו פורסם ב-1995 H.263, שהתפתחה עד 2001.

הגרסה הראשונה הושלמה ב-2003 H.264 / AVC. באותה שנה, TrueMotion שחררה את ה-Codec הווידאו החינמי שלה שנקרא VP3. גוגל רכשה את החברה ב-2008, והוציאה VP8 אותה שנה. בדצמבר 2012, גוגל פרסמה VP9, והוא נתמך בכ-¾ משוק הדפדפנים (כולל מכשירים ניידים).

AV1 הוא קודק וידאו חדש בחינם וקוד פתוח שפותח על ידי ברית למדיה פתוחה (AOMedia), הכוללת את החברות המפורסמות ביותר, כגון: גוגל, מוזילה, מיקרוסופט, אמזון, נטפליקס, AMD, ARM, NVidia, אינטל וסיסקו. הגרסה הראשונה של ה-codec, 0.1.0, פורסמה ב-7 באפריל, 2016.

לידתו של AV1

בתחילת 2015, גוגל עבדה על VP10Xiph (שהינה בבעלות מוזילה) עבדה על דאאלה, וסיסקו יצרה codec וידאו חינמי משלה בשם Thor.

לאחר מכן MPEG LA הכריזו לראשונה על מגבלות שנתיות עבור HEVC (H.265) ועמלה גבוהה פי 8 מאשר עבור H.264, אך עד מהרה שינו שוב את הכללים:

ללא מגבלה שנתית,
עמלת תוכן (0,5% מההכנסות) ו
דמי היחידה גבוהים בערך פי 10 מ-H.264.

ברית למדיה פתוחה נוצר על ידי חברות מתחומים שונים: יצרני ציוד (Intel, AMD, ARM, Nvidia, Cisco), ספקי תוכן (גוגל, נטפליקס, אמזון), יוצרי דפדפנים (גוגל, מוזילה) ואחרים.

לחברות הייתה מטרה משותפת - Codec וידאו ללא תמלוגים. ואז מופיע AV1 עם רישיון פטנט הרבה יותר פשוט. Timothy B. Terryberry נתן מצגת מהממת שהפכה למקור הקונספט הנוכחי של AV1 ומודל הרישוי שלו.

תופתעו לדעת שתוכלו לנתח את ה-Codec AV1 דרך דפדפן (המעוניינים יכולים ללכת אל aomanalyzer.org).

Codec אוניברסלי

בואו נסתכל על המנגנונים העיקריים העומדים בבסיס ה-Codec הווידאו האוניברסלי. רוב המושגים הללו שימושיים ומשמשים בקודקים מודרניים כגון VP9, AV1 и HEVC. אני מזהיר אותך שרבים מהדברים שיוסברו יהיו מפושטים. לפעמים ישמשו דוגמאות מהעולם האמיתי (כמו עם H.264) כדי להדגים את הטכנולוגיה.

שלב 1 - פיצול התמונה

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

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

רכיבי קודקים מארגנים בדרך כלל את הקטעים הללו למקטעים (או נתחים), מאקרו בלוקים (או בלוקים של עץ קידוד) ותת-סעיפים מרובים. הגודל המקסימלי של המחיצות הללו משתנה, HEVC מגדיר אותו ל-64x64 בעוד ש-AVC משתמש ב-16x16, וניתן לפצל מחיצות משנה בגדלים של 4x4.

זוכרים את סוגי הפריימים מהכתבה האחרונה?! ניתן להחיל את אותו הדבר על בלוקים, כך שנוכל לקבל I-fragment, B-block, P-macroblock וכו'.

למי שרוצה להתאמן, צפו כיצד התמונה מחולקת לחלקים ותתי-סעיפים. כדי לעשות זאת, אתה יכול להשתמש בזה שכבר הוזכר במאמר הקודם. Intel Video Pro Analyzer (זו בתשלום, אבל עם גרסת ניסיון בחינם המוגבלת ל-10 הפריימים הראשונים). קטעים מנותחים כאן VP9:

שלב שני - חיזוי

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

שלב 3 - טרנספורמציה

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

למרות שישנן שיטות אחרות, בואו נסתכל עליהן ביתר פירוט. טרנספורמציה קוסינוס בדידה (DCT - מ טרנספורמציה קוסינוס בדידה). הפונקציות העיקריות של DCT:

• ממירה בלוקים של פיקסלים לבלוקים שווים בגודלם של מקדמי תדר.
• מעבה כוח כדי לסייע בביטול יתירות מרחבית.
• מספק הפיכות.

2 בפברואר 2017 סינטרה R.J. (Cintra, RJ) ו-Bayer F.M. (Bayer FM) פרסם מאמר על טרנספורמציה דמוית DCT לדחיסת תמונה הדורשת רק 14 תוספות.

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

ניקח את גוש הפיקסלים הזה בגודל 8x8:

בלוק זה מעובד לתמונה הבאה של 8 על 8 פיקסלים:

החל DCT על גוש פיקסלים זה וקבל גוש 8x8 של מקדמים:

ואם נעבד את גוש המקדמים הזה, נקבל את התמונה הבאה:

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

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

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

תדירות מתייחסת לכמה מהר האות משתנה.

בואו ננסה ליישם את הידע שנצבר במקרה המבחן על ידי המרת התמונה המקורית לתדירות שלה (גוש מקדמים) באמצעות DCT ולאחר מכן ביטול חלק מהמקדמים הפחות חשובים.

ראשית נמיר אותו לתחום התדר.

לאחר מכן, נזרוק חלק (67%) מהמקדמים, בעיקר החלק הימני התחתון.

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

אנו רואים שהוא דומה לתמונה המקורית, אך ישנם הבדלים רבים מהמקור. זרקנו 67,1875% ועדיין קיבלנו משהו שדומה למקור. אפשר היה להשליך ביתר מחשבה את המקדמים כדי לקבל תמונה באיכות טובה עוד יותר, אבל זה הנושא הבא.

כל מקדם נוצר באמצעות כל הפיקסלים

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

אתה יכול גם לנסות לדמיין את ה-DCT על ידי הסתכלות על היווצרות תמונה פשוטה המבוססת עליו. לדוגמה, הנה הסמל A שנוצר באמצעות כל משקל מקדם:

שלב 4 - קוונטיזציה

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

כיצד ניתן לכמת גוש של מקדמים? אחת השיטות הפשוטות ביותר היא קוונטיזציה אחידה, כאשר אנו לוקחים בלוק, מחלקים אותו בערך אחד (ב-10) ומעגלים את התוצאה.

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

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

שלב 5 - קידוד אנטרופיה

לאחר שמכמתנו את הנתונים (בלוקים של תמונה, פרגמנטים, פריימים), אנחנו עדיין יכולים לדחוס אותם ללא אובדן. ישנן דרכים אלגוריתמיות רבות לדחיסת נתונים. אנחנו הולכים להסתכל במהירות על כמה מהם, להבנה מעמיקה יותר אתה יכול לקרוא את הספר הבנת דחיסה: דחיסת נתונים למפתחים מודרניים ("הבנת דחיסה: דחיסת נתונים עבור מפתחים מודרניים").

קידוד וידאו באמצעות VLC

נניח שיש לנו זרם של דמויות: a, e, r и t. ההסתברות (הנעה בין 0 ל-1) לתדירות שבה כל תו מופיע בזרם מוצגת בטבלה זו.

	a	e	r	t
הסתברות	0,3	0,3	0,2	0,2

אנו יכולים להקצות קודים בינאריים ייחודיים (רצוי קטנים) לקודים הסבירים ביותר, וקודים גדולים יותר לקודים הפחות סבירים.

	a	e	r	t
הסתברות	0,3	0,3	0,2	0,2
קוד בינארי	0	10	110	1110

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

השלב הראשון הוא קידוד התו e, ששווה ל-10, והתו השני הוא a, שמתווסף (לא בצורה מתמטית): [10][0], ולבסוף התו השלישי t, מה שהופך את זרם הסיביות הדחוס הסופי שלנו לשווה ל-[10][0][1110] או 1001110, אשר דורש רק 7 ביטים (פי 3,4 פחות מקום מהמקור).

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

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

קידוד אריתמטי

נניח שיש לנו זרם של דמויות: a, e, r, s и t, וההסתברות שלהם מוצגת בטבלה זו.

	a	e	r	s	t
הסתברות	0,3	0,3	0,15	0,05	0,2

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

עכשיו בואו נקודד זרם של שלושה תווים: לאכול.

תחילה בחר את התו הראשון e, שנמצא בתת-טווח שבין 0,3 ל-0,6 (לא כולל). אנחנו לוקחים את תת הטווח הזה ומחלקים אותו שוב באותם פרופורציות כמו קודם, אבל עבור הטווח החדש הזה.

בואו נמשיך בקידוד הזרם שלנו לאכול. עכשיו קח את הדמות השנייה a, שנמצא בטווח המשנה החדש מ-0,3 עד 0,39, ואז קחו את התו האחרון שלנו t ובחזרה על אותו תהליך שוב, נקבל את תת-הטווח הסופי מ-0,354 ל-0,372.

אנחנו רק צריכים לבחור מספר בתת הטווח האחרון מ-0,354 עד 0,372. בוא נבחר 0,36 (אבל אתה יכול לבחור כל מספר אחר בתת-טווח זה). רק עם המספר הזה נוכל לשחזר את הזרם המקורי שלנו. זה כאילו אנחנו מציירים קו בתוך הטווחים כדי לקודד את הזרם שלנו.

הפעולה ההפוכה (כלומר, פִּעַנוּחַ) פשוט באותה מידה: עם המספר שלנו 0,36 והטווח ההתחלתי שלנו, אנחנו יכולים להפעיל את אותו תהליך. אבל כעת, באמצעות המספר הזה, אנו מזהים את הזרם המקודד באמצעות המספר הזה.

עם הטווח הראשון, אנו שמים לב שהמספר שלנו מתאים לפרוסה, לכן זהו התו הראשון שלנו. כעת אנו מחלקים שוב את תת הטווח הזה על ידי ביצוע אותו תהליך כמו קודם. כאן אתה יכול לראות ש-0,36 מתאים לסמל a, ולאחר שחזרנו על התהליך הגענו לדמות האחרונה t (יוצרים את הזרם המקודד המקורי שלנו לאכול).

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

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

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

שלב 6 - פורמט ביטסטרים

לאחר ביצוע כל זה, כל מה שנותר הוא לפרק את הפריימים הדחוסים בהקשר של השלבים שבוצעו. יש ליידע את המפענח במפורש על ההחלטות שהתקבלו על ידי המקודד. יש לספק למפענח את כל המידע הדרוש: עומק סיביות, מרחב צבע, רזולוציה, מידע חיזוי (וקטורי תנועה, חיזוי INTER כיווני), פרופיל, רמה, קצב פריימים, סוג מסגרת, מספר מסגרת ועוד.

נסתכל במהירות על זרם הסיביות H.264. הצעד הראשון שלנו הוא ליצור זרם סיביות מינימלי H.264 (FFmpeg כברירת מחדל מוסיף את כל אפשרויות הקידוד כגון SEI NAL - נגלה מה זה עוד קצת). אנחנו יכולים לעשות זאת באמצעות המאגר שלנו ו-FFmpeg.

./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264

פקודה זו תיצור זרם סיביות גולמי H.264 עם מסגרת אחת, רזולוציית 64×64, עם מרחב צבע YUV420. במקרה זה, התמונה הבאה משמשת כמסגרת.

H.264 סיביות

סטנדרטי AVC (H.264) קובע שמידע יישלח במקרופריים (במובן הרשת), שנקרא נאל (זוהי רמת הפשטה ברשת). המטרה העיקרית של NAL היא לספק מצגת וידאו "ידידותית לאינטרנט". תקן זה אמור לעבוד על טלוויזיות (מבוססות זרם), באינטרנט (מבוסס מנות).

קיים סמן סנכרון להגדרת הגבולות של רכיבי NAL. כל אסימון סנכרון מכיל ערך 0x00 0x00 0x01, חוץ מהראשון, ששווה ל 0x00 0x00 0x00 0x01. אם נשיק hexdump עבור זרם סיביות H.264 שנוצר, אנו מזהים לפחות שלוש תבניות NAL בתחילת הקובץ.

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

מזהה סוג NAL	תיאור
0	סוג לא ידוע
1	קטע תמונה מקודד ללא IDR
2	קטע נתוני פרוסה מקודדת A
3	קטע נתוני פרוסה מקודדת B
4	קטע נתוני פרוסה מקודדת C
5	קטע IDR מקודד של תמונת IDR
6	מידע נוסף על תוסף SEI
7	סט פרמטרים של רצף SPS
8	סט פרמטרים של תמונת PPS
9	מפריד גישה
10	סוף הרצף
11	סוף השרשור
...	...

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

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

לדוגמה, הבית הראשון אחרי אסימון הסנכרון הוא 01100111, שבו החלק הראשון (0) נמצא בשדה forbidden_zero_bit. 2 הביטים הבאים (11) מספר לנו את השדה nal_ref_idc, מה שמציין אם NAL זה הוא שדה התייחסות או לא. ואת 5 הביטים הנותרים (00111) מספר לנו את השדה Nal_unit_type, במקרה זה זה בלוק SPS (7) NAL.

בייט שני (בינרי=01100100, hex=0x64, דצמבר=100) ב-SPS NAL הוא השדה profile_idc, אשר מציג את הפרופיל שבו השתמש המקודד. במקרה זה, נעשה שימוש בפרופיל גבוה מוגבל (כלומר, פרופיל גבוה ללא תמיכה דו-כיוונית בקטע B).

אם אתה מסתכל על מפרט זרם הסיביות H.264 עבור SPS NAL, אנו נמצא ערכים רבים עבור שם פרמטר, קטגוריה ותיאור. לדוגמה, בואו נסתכל על השדות pic_width_in_mbs_minus_1 и תמונה_גובה_ביחידות_מפה_מינוס_1.

שם פרמטר	קטגוריה	תיאור
pic_width_in_mbs_minus_1	0	ue(v)
תמונה_גובה_ביחידות_מפה_מינוס_1	0	ue(v)

אם נבצע כמה פעולות מתמטיות עם הערכים של שדות אלה, נקבל רזולוציה. אפשר לייצג 1920 x 1080 באמצעות pic_width_in_mbs_minus_1 עם ערך של 119 ((119 + 1) * macroblock_size = 120 * 16 = 1920). שוב, כדי לחסוך במקום, במקום לקודד את 1920, עשינו את זה עם 119.

אם נמשיך לבדוק את הסרטון שנוצר שלנו בצורה בינארית (לדוגמה: xxd -b -c 11 v/minimal_yuv420.h264), אז אתה יכול ללכת ל-NAL האחרון, שהוא המסגרת עצמה.

כאן אנו רואים את ערכי 6 הבתים הראשונים שלו: 01100101 10001000 10000100 00000000 00100001 11111111. מכיוון שהבייט הראשון ידוע כמציין את סוג NAL, במקרה זה (00101) הוא קטע IDR (5), ולאחר מכן תוכל לחקור אותו עוד יותר:

באמצעות מידע המפרט, ניתן יהיה לפענח את סוג הפרגמנט (slice_type) ומספר מסגרת (frame_num) בין תחומים חשובים אחרים.

כדי לקבל את הערכים של כמה שדות (ue(v), me(v), se(v) או te(v)), עלינו לפענח את הפרגמנט באמצעות מפענח מיוחד המבוסס על קוד גולומב אקספוננציאלי. שיטה זו יעילה מאוד לקידוד ערכי משתנים, במיוחד כאשר ישנם ערכי ברירת מחדל רבים.

משמעויות slice_type и frame_num מהסרטון הזה הם 7 (I-fragment) ו-0 (פריים ראשון).

ניתן לחשוב על זרם סיביות כעל פרוטוקול. אם אתה רוצה לדעת יותר על זרם הסיביות, עליך לעיין במפרט ITU H.264. להלן דיאגרמת מאקרו המראה היכן נמצאים נתוני התמונה (YUV בצורה דחוסה).

ניתן לבחון זרמי סיביות אחרים, כגון VP9, H.265 (HEVC) או אפילו הביטסטרים הטובים ביותר החדשים שלנו AV1. האם כולם דומים? לא, אבל ברגע שאתה מבין לפחות אחד, הרבה יותר קל להבין את השאר.

רוצה להתאמן? חקור את זרם הסיביות של H.264

אתה יכול ליצור סרטון פריים בודד ולהשתמש ב-MediaInfo כדי לבחון את זרם הסיביות H.264. למעשה, שום דבר לא מונע ממך אפילו להסתכל על קוד המקור שמנתח את זרם הסיביות H.264 (AVC).

לתרגול אפשר להשתמש ב-Intel Video Pro Analyzer (כבר אמרתי שהתוכנית בתשלום, אבל יש גרסת ניסיון חינמית עם הגבלה של 10 פריימים?).

סקירה

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

בעבר, זה היה מחושב כי יידרש 139 GB של שטח דיסק כדי לאחסן קובץ וידאו שנמשך שעה אחת באיכות 720p ו-30 פריימים לשנייה. אם אתה משתמש בשיטות שנדונו במאמר זה (תחזיות בין-פריים ופנימיות, טרנספורמציה, קוונטיזציה, קידוד אנטרופיה וכו'), אז אתה יכול להשיג (בהתבסס על העובדה שאנו מוציאים 0,031 סיביות לפיקסל), סרטון של די איכות משביעת רצון, תופסת רק 367,82 MB, לא 139 GB של זיכרון.

כיצד משיג H.265 יחס דחיסה טוב יותר מאשר H.264?

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

אם אתה משווה AVC и HEVC, כדאי לזכור שכמעט תמיד מדובר בבחירה בין עומס מעבד גדול יותר ויחס דחיסה.

HEVC יש יותר אפשרויות סעיף (ותת-סעיף) מאשר AVC, יותר כיווני חיזוי פנימיים, קידוד אנטרופיה משופר ועוד. כל השיפורים הללו נעשו H.265 מסוגל לדחוס 50% יותר מ H.264.

часть Первая: יסודות העבודה עם וידאו ותמונות

מקור: www.habr.com