Video kodek necə işləyir. Hissə 2. Nə, niyə, necə

Birinci hissə: Video və şəkillərlə işləmənin əsası

Nə? Videokodek, rəqəmsal videonu sıxan və ya açan proqram təminatı/yumşaq təminatın bir hissəsidir.

Nə üçün? Bandwidth və məlumat saxlama məhdudiyyətlərinə baxmayaraq, bazar daha keyfiyyətli video tələb edir. Keçmiş postda 30 kadr/saniyə, 24 bit/piksəl, 480×240 qətnamə üçün minimum hesabladığımızı xatırlayırsınız? Sıxılmamış 82,944 Mbit/s əldə etdik. Sıxma, HD/FullHD/4K-nın televizor ekranlarına və internetə keçirilməsinin tək yoludur. Bu necə mümkündür? İndi əsas metodları qısa şəkildə nəzərdən keçirəcəyik.
Biz

Tərcümə EDISON Software şirkətinin dəstəyi ilə həyata keçirilmişdir.

video müşahidə sistemlərinin inteqrasiyası mikrotomograf inkişaf etdiririk, eləcə də Kodek vs Konteyner.

Yeni başlayanların geniş yayılmış bir səhvi, rəqəmsal video kodekini və rəqəmsal video konteynerini qarışdırmaqdır. Konteyner müəyyən bir formata aiddir. Videonun metadatasını (və bəlkə də səs) ehtiva edən bir qabdır. Sıxılmış videonu konteynerin yükü kimi nəzərdən keçirmək olar.

Adətən video faylının uzantısı onun konteyner növünü göstərir. Məsələn, video.mp4 faylı, ehtimal ki,

MPEG-4 Part 14 konteyneridir, və video.mkv adlı fayl, ehtimal ki,matryoshka . Kodek və konteyner formatında tam əmin olmaq üçünMediaInfo FFmpeg və alətindən istifadə edə bilərik..

Bir az tarix

İndi Necə?, tarixə qısa bir şəkildə nəzər salaq ki, bəzi köhnə kodekləri daha yaxşı başa düşək.

Video codec H.261 1990-cı ildə (texniki olaraq — 1988-ci ildən) ortaya çıxdı və 64 Kbit/s sürətində işləmək üçün hazırlanmışdır. Zamanında, rəng alt-nümunə, makro bloklar və s. kimi ideyalardan istifadə olunmuşdur. 1995-ci ildə H.263videokodek standartı dərc olundu və 2001-ci ilə qədər inkişaf etdi.

2003-cü ildə H.264/AVCilk versiyası tamamlandı. Eyni ildə 'TrueMotion' şirkəti, itkilərlə video sıxan pulsuz videokodeki olan VP3nı buraxdı. 2008-ci ildə Google bu şirkəti aldı, eyni ildə VP8 buraxıldı. Dekabr 2012-də Google VP9nı buraxdı və təxminən ¾ brauzer bazarında (mobil cihazlar da daxil) dəstəklənir.

AV1 — yeni, açıq mənbəli video kodekdir, Açıq Media Alyansı (AOMediatərəfindən inkişaf etdirilmişdir, bu alyansa Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel və Cisco kimi tanınmış şirkətlər daxildir. Kodekin 0.1.0 versiyası 7 aprel 2016-da dərc olundu.

AV1-in doğulması

2015-ci ilin əvvəlində Google VP10üzerində iş edirdi, Xiph (Mozilla-nın mülkiyyətində) isə Daalailə işləyirdi, Cisco isə 'Thor' adlı öz pulsuz videokodekini yaradıb. MPEG LA.

Sonra ilk öncə HEVC H.265 () üçün illik limitləri elan etdi və H.264-ə nisbətən 8 dəfə daha yüksək bir ödəniş tələb etdi, amma tezliklə qaydaları dəyişdirərək:illik limit olmadan,

məzmun üçün ödəniş (gəlirin 0.5%) və
məzmun haqqı (gəlirin 0,5%-i) və
məhsulun bir vahidi üçün ödəniş, H.264-dən təxminən 10 dəfə daha yüksəkdir.

Açıq Media Alyansı müxtəlif sahələrdən olan şirkətlər tərəfindən yaradılmışdır: avadanlıq istehsalçıları (Intel, AMD, ARM, Nvidia, Cisco), məzmun provayderləri (Google, Netflix, Amazon), brauzer yaradıcıları (Google, Mozilla) və başqaları.

Şirkətlərin hamısının ortaq məqsədi – lisenziya ödənişləri olmayan video kodekidir. Sonra AV1 çox daha sadə patent lisenziyasına sahib olan bir kodek meydana çıxır. Timothy B. Terriberry inanılmaz təqdimat etdi ki, bu da AV1-in indiki konsepsiyasının və onun lisenziya modelinin mənbəyidir.

AV1 kodekini brauzer vasitəsilə analiz edə biləcəyinizi öyrənəndə təəccüblənəcəksiniz (maraqlananlar üçün adres: aomanalyzer.org).

Ümumi kodek

Ümumi video kodekinin əsas mexanizmlərini nəzərdən keçirəcəyik. Bu konsepsiyaların əksəriyyəti müasir kodeklərdə, məsələn, istifadə olunur VP9, AV1 və H.265. Xəbərdar edirəm ki, izah edilən bir çox şey sadələşdiriləcək. Bəzən texnologiyaları nümayiş etdirmək üçün real nümunələrdən istifadə ediləcək (H.264 ilə bağlı vəziyyətdə olduğu kimi).

1-ci addım — şəkli parçalamaq

İlk addım, kadları bir neçə hissəyə, alt hissələrə və daha sonralara bölməkdir.

Niyə? Bir çox səbəb var. Şəkli parçalayanda, kiçik hərəkət edən hissələr üçün kiçik seqmentlərdən istifadə edərək hərəkət vektorunu daha dəqiq proqnozlaşdırmaq mümkündür. Statik fon üçün isə daha böyük hissələrlə kifayətlənmək olar.

Adətən kodeklər bu hissələri seqmentlərə (və ya hissələrə), makrobloklara (və ya kodlama ağacına) və bir çox alt hissələrə təşkil edir. Bu hissələrin maksimum ölçüsü dəyişir, HEVC 64×64 ölçüsünü təyin edir, AVC isə 16×16 istifadə edir, alt seqmentlər isə 4×4 ölçüsünə qədər parçalanır.

Ötən yazıda kadr növlərini xatırlayırsınız?! Bu, bloklara da tətbiq oluna bilər, beləliklə, I-fragment, B-blok, P-makrobloku və s. ola bilər.

Təcrübə etmək istəyənlər üçün — görün, necə şəkil seqmentlərə və alt hissələrə ayrılacaq. Bunun üçün artıq qeyd olunan Intel Video Pro Analyzer (pullu, amma ilk 10 kadr üçün məhdudiyyətlər olan pulsuz sınaq versiyası ilə) istifadə edilə bilər. Burada hissələr analiz edilmişdir. VP9:

2-ci addım — proqnozlaşdırma

Hissələrimiz olduqda, onların üzərində astrologik proqnozlar hazırlaya bilərik. INTER-proqnozlaşdırma üçün hərəkət vektorları və qalıq ötürülməlidir, INTRA-proqnozlaşdırma üçün isə proqnoz yönü və qalıq ötürülür.

3-cü addım — transformasiya

Qalıq bloku aldıqdan sonra (proqnozlaşdırılan seqment → gerçək seqment), onu belə bir şəkildə çevirmək mümkündür ki, ümumi keyfiyyəti qoruyarkən hansı pikselin atılacağını bilsin. Dəqiq davranışı təmin edən bəzi çevirmələr mövcuddur.

Daha digər metodlar olsa da, daha ətraflı şəkildə nəzərdən keçirək. diskret kosinus təhlili (DCT — diskret kosinus transformasiyası). DCT-nin əsas funksiyaları:

• Pixelləri bərabər ölçüdə frekans koeffisiyentləri bloklarına çevirir.
• Gücü yoğunlaşdırır, məkansal artıqlığı aradan qaldırmağa kömək edir.
• Təkrarlanabilirliyi təmin edir.

2017-ci il fevralın 2-də Sintra R.J. (Cintra, R.J.) və Bayer F.M. (Bayer F.M.) yalnız 14 əlavə tələb edən şəkillərin sıxılması üçün DCT-ya bənzər dönüş haqqında bir məqalə dərc etdilər.

Hər bir nöqtənin üstünlüklərini başa düşməsəniz narahat olmayın. İndi konkret misallar üzərində onların real dəyərini sübut edəcəyik.

Gəlin 8×8 ölçüsündə bir pixel blokunu götürək:

Bu blok aşağıdakı 8x8 pixel şəklini göstərir:

Bu pixel blokuna DCT tətbiq edərək 8×8 ölçüsündə koeffisiyentlər bloku alırıq:

Və əgər bu koeffisiyentlər blokunu render etsək, aşağıdakı şəkli alırıq:

Gördüyümüz kimi, bu, orijinal şəkilə bənzəmir. Görmək olar ki, birinci koeffisiyent digər bütün koeffisiyentlərdən kəskin fərqlənir. Bu birinci koeffisiyent DC-koeffisiyenti adlanır və giriş massivində bütün nümunələri təmsil edir, bir növ ortalama dəyərə bənzəyir.

Bu koeffisiyentlər blokunun maraqlı bir xüsusiyyəti var: o, yüksək tezlikli komponentləri aşağı tezlikli komponentlərdən ayırır.

Şəkildə gücün böyük hissəsi aşağı tezliklərdə cəmləşmişdir, buna görə də şəkli onun frekans komponentlərinə çevirsək və yüksək tezlikli koeffisiyentləri atsaq, şəkilin təsvir edilməsi üçün lazım olan məlumatların miqdarını azalda bilərik, keyfiyyətdən çox da güzəştə getmədən.

Tezlik, siqnalın nə qədər sürətlə dəyişdiyini göstərir.

Gəlin test nümunəsində əldə olunan biliklərimizi tətbiq edərək orijinal şəkli frekansına (koeffisiyentlər bloku) çevirək, DCT istifadə edərək, sonra isə ən az əhəmiyyətli koeffisiyentlərin bir hissəsini ataq.

Öncə onu frekans sahəsinə çevirək.

Sonra koeffisiyentlərin bir hissəsini (67%) atırıq, əsasən aşağı sağ hissədən.

Nəhayət, bu atılan koeffisiyentlər blokundan şəkli bərpa edirik (xatırlayırsınızsa, bu, tərsinə çevrilə bilən olmalıdır) və orijinal ilə müqayisə edirik.

Görürük ki, bu, orijinal şəkilə bənzəyir, amma orijinaldan çox fərqlidirlər. Biz 67,1875%-i atdıq və hələ də ilkə bənzər bir şey əldə etdik. Koeffisiyentləri daha düşünülmüş formada atmaqla daha yüksək keyfiyyətli bir şəkil əldə etmək olardı, amma bu artıq növbəti mövzudur.

Hər bir koeffisiyent bütün piksel istifadə edərək formalaşır.

Vacibdir: hər koefisinin birbaşa pikselə uyğun gəlməsi deyil, bütün pikslərin çəkili cəmini təqdim edir. Bu möhtəşəm qrafik, birinci və ikinci koeffisiyentin hər indeks üçün unikal çəkilərlə necə hesablandığını göstərir.

DCT-ni vizuallaşdırmağa da çalışa bilərsiniz, bu əsasında sadə görüntü formalaşmasının üzərinə baxaraq. Məsələn, hər koefisinin çəkisini istifadə edərək formalaşan simvol A-nı aşağıda görə bilərsiniz:

4-cü addım — kvantizasiya

Öncəki addımda bəzi koefisiyentləri atdıqdan sonra, son addımda (transformasiya) xüsusi bir kvantizasiya forması həyata keçiririk. Bu mərhələdə məlumat itirmək mümkündür. Yəni, sadəcə, sıxlaşma əldə etmək üçün koefisiyentləri kvantizasiya edəcəyik.

Koefisiyentlər blokunu necə kvantizasiya edə bilərik? Ən sadə metodlardan biri bərabər kvantizasiya olacaq, burada bloku bir dəyərə (10-a) bölürük və əldə olunanı yuvarlayırıq.

Bu koefisiyentlər blokunu geri çevirə bilərikmi? Bəli, eyni dəyərlə vuraraq edə bilərik.

Bu yanaşma ən yaxşısı deyil, çünki hər koefisinin önəmini nəzərə almır. Bir dəyər yerinə kvantizasiya matrisası istifadə oluna bilər və bu matris DCT-nin xüsusiyyətini istifadə edərək, əksər aşağı sağ koefisiyentləri kvantizasiya edə bilər.

5-ci addım — entropiya kodlaşdırması

Məlumatları (şəkil blokları, fragsiyalar, çərçivələr) kvantizasiya etdikdən sonra, hələ də onları itkisiz sıxışdıra bilirik. Məlumatları sıxışdırmağın bir çox alqoritmik yolları mövcuddur. Biz bunlardan bəziləri ilə kısaca tanış olacağıq, daha dərin anlayış üçün 'Sıxışma ilə tanış: Müasir Tərtibatçılar üçün Məlumat Sıxışdırma' kitabına baxa bilərsiniz.Understanding Compression: Data Compression for Modern Developers»).

VLC ilə video kodlaşdırma

Gəlin, bizdə simvollar axını olsun: a, e, r və — cari zamanı HH:MM:SS formatında göstərir. Axında hər simvolun nə qədər tez-tez baş verdiyinin ehtimalı (0 ilə 1 arasında) aşağıdakı cədvəldə təqdim olunur.

Ən mümkün olanlara unik kodlar (üstünlük verərək kiçik) verə bilərik, daha az mümkün olanlara isə daha böyük kodlar.

Axını sıxışdırırıq, hesab edərək ki, nəticədə hər simvola 8 bit sərf edəcəyik. Sıxlaşma olmadan simvol üçün 24 bit tələb olunardı. Hər simvolu kodu ilə əvəz etsək, qənaət əldə edirik!

İlk addım simvolun kodlaşdırılmasıdır e, bu 10-a bərabərdir, ikinci simvol isə a, əlavə edilir (riyazi olmayan şəkildə): [10] [0], və nəhayət, üçüncü simvol — cari zamanı HH:MM:SS formatında göstərir, bu da bizim son sıxılmış bit axınımızı [10] [0] [1110] və ya 1001110, üçün cəmi 7 bit tələb olunur (orijinaldan 3.4 dəfə az yer).

Qeyd edin ki, hər kod unikaldır və prefiksə sahib olmalıdır. Huffman alqoritmi bu ədədləri tapmağa kömək edəcək. Bu üsulun bazı çatışmazlıqları olsa da, hələ də bu alqoritmik metodu sıxılma üçün təklif edən video kodeklər mövcuddur.

Həm kodlayıcı, həm də deşifrə edici öz ikili kodları ilə simvol cədvəlinə daxil olmalıdır. Buna görə də, giriş məlumatlarında cədvəli göndərmək də vacibdir.

Aritmetik kodlama

Gəlin, bizdə simvollar axını olsun: a, e, r, s və — cari zamanı HH:MM:SS formatında göstərir, və onların ehtimalı bu cədvəl ilə təqdim edilir.

Bu cədvəl ilə, bütün mümkün simvolları əhatə edən, maksimum sayda sıralanmış aralıqları hazırlayaq.

İndi üç simvoldan ibarət axını kodlayaq: eat.

İlk simvolu seçirik e, bu 0,3 ilə 0,6 arasında (istisna olunmaqla) olan alt aralıqdadır. Bu alt aralığı götürürük və eyni proporsiyalarda bu yeni aralıq üçün yenidən bölürük.

Gelin axınımızı kodlamağa davam edək eat. İndi ikinci simvolu götürürük a, bu da 0,3 ilə 0,39 aralığında olan yeni alt aralıqdadır, sonra son simvolumuzu götürürük — cari zamanı HH:MM:SS formatında göstərir və eyni prosesi təkrarlayaraq, 0,354 ilə 0,372 arasındakı son alt aralığı əldə edirik.

Son alt aralıqdan 0,354 ilə 0,372 arasında bir ədəd seçməliyik. Gəlin 0,36 seçək (amma bu alt aralıqda istənilən başqa bir ədədi seçmək də mümkündür). Yalnız bu ədədlə orijinal axınımızın bərpasını edə biləcəyik. Bu, axınımızın kodlanması üçün aralıqları içərisində bir xətt çəkmək kimidir.

Tərs əməliyyat (yəni deşifrə etmə) də eyni dərəcədə sadədir: 0,36 ədədi və ilkin aralığımızla eyni prosesi həyata keçirə bilərik. Amma indi bu ədədi istifadə edərək, bu ədəd ilə kodlanmış axını müəyyən edirik.

İlk aralıqla qeyd edirik ki, ədədimiz kəsiyə uyğun olur, buna görə də bu bizim ilk simvolumuzdur. İndi bu alt aralığı yenidən bölərək, əvvəllər etdiyimiz eyni prosesi icra edirik. Burada 0,36-nın simvola uyğun olduğunu qeyd etmək olar. a, və prosesi yenilədikdə son simvolumuza çatdıq — cari zamanı HH:MM:SS formatında göstərir (orijinal kodlanmış axınımızın formalaşmasıdır. eat).

Həm kodlayıcı, həm də deşifrə edici simvol ehtimal cədvəlini əldə etməlidir, buna görə də giriş məlumatlarında onu da göndərmək vacibdir.

Olduqca zərif, elə deyilmi? Bu həlli düşünən şəxs həqiqətən ağıllıydı. Bəzi video kodeklər bu texnikanı istifadə edir (ya da, hətta, onu seçim olaraq təklif edirlər).

İdeya, itkisiz kvantlaşdırılmış bit axınını sıxmaqdır. Müəyyən ki, bu məqalədə bir çox detallardan, səbəblərdən, kompromislerden və s. çatışmır. Amma siz inkişaf etdirici olduğunuz halda, daha çox şey bilməlisiniz. Yeni kodeklər müxtəlif entropiya kodlama alqoritmlərini sınaqdan keçirir, məsələn, ANS.

6 addım - bit axını formatı

Bütün bunlardan sonra, icra edilmiş adımlar çerçevesinde sıkıştırılmış kareleri açmak kalıyor. Dekoderi, kodlayıcının aldığı kararlar hakkında net bir şekilde bilgilendirmek gereklidir. Dekodere gereken tüm bilgiler sağlanmalıdır: bit derinliği, renk alanı, çözünürlük, tahmin bilgisi (hareket vektörleri, yönlendirilmiş INTER tahmini), profil, seviye, kare hızı, kare tipi, kare numarası ve daha fazlası.

Bit akışıyla yüzeysel olarak tanışacağız. H.264. İlk adımımız, bir H.264 bit akışı oluşturmaktır (FFmpeg varsayılan olarak kodlama ile ilgili tüm parametreleri ekler, böylece SEI NAL — birazdan bunun ne olduğunu öğreneceğiz). Bunu kendi deposumuzu ve FFmpeg'i kullanarak gerçekleştirebiliriz.

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

Bu komut, H.264 64×64 çözünürlüğe sahip, YUV420renk alanına sahip tek bir kare ile ham bir bit akışı oluşturacaktır. Bu esnada, bir kare olarak aşağıdaki görüntü kullanılmaktadır.

H.264 bit akışı

Standart AVC (H.264) bilgilerin makro karelerde (ağ anlayışında) gönderileceğini belirtir ve buna NAL denir (bu ağın soyutlama seviyesidir). NAL'in ana amacı, videonun "ağa dost" bir temsilini sunmaktır. Bu standart, televizyonlarda (akış bazında) ve İnternet'te (paket bazında) çalışmalıdır.

NAL öğelerinin sınırlarını belirlemek için bir senkronizasyon işareti bulunmaktadır. Her senkronizasyon işareti bir değer içerir, 0x00 0x00 0x01, ilk olan hariç, değeri 0x00 0x00 0x00 0x01. dir. Eğer hexdump H.264 bit akışı için çalıştırırsak, dosyanın başında en az üç NAL paterni tespit ederiz.

Dediğimiz gibi, dekoder sadece görüntü verilerini değil, aynı zamanda video, kare, renk, kullanılan parametreler ve daha fazlasını bilmelidir. Her NAL'in ilk baytı, kategorisini ve türünü belirler.

Genellikle bir bit akışının ilk NAL'i SPSdır. Bu NAL türü, profil, seviye, çözünürlük gibi genel kodlama değişkenleri hakkında bilgi vermekten sorumludur.

İlk senkronizasyon işaretini atlarsak, ilk baytı çözümleyerek ilk NAL tipinin ne olduğunu öğrenebiliriz.

Örneğin, senkronizasyon işareti sonrası ilk byte 01100111dır; burada ilk bit (0) f alanında bulunur.orbidden_zero_bit. Sonraki 2 bit (11) bize nal_ref_idc, alanını belirtilmektedir. bu, bu NAL-nın bir referans sahəsi olub olmadığını göstərir. Və qalan 5 bit (00111) bize nal_unit_type, bu halda bu bir SPS blokudur (7) NAL.

İkinci bayt (binary=01100100, hex=0x64, dec=100) SPS NAL-dakı sahədir profile_idc, kodlaşdırıcı tərəfindən istifadə olunan profili göstərir. Bu halda, məhdud yüksək profil (yəni, geri istiqamətli B seqmentini dəstəkləməyən yüksək profil) istifadə olunub.

Bit axını spesifikasiyası ilə tanış olsanız, parameter adı, kateqoriya və təsvir üçün çox sayda dəyər tapacaqsınız. Məsələn, gəlin H.264 pic_width_in_mbs_minus_1 pic_height_in_map_units_minus_1 və Parameter adı.

119 dəyəri ilə ((119 + 1) * macroblock_size = 120 * 16 = 1920). Yenidən, yer saxlamaq üçün, 1920-ni kodlaşdırmaq əvəzinə, bunu 119 ilə etdilər. pic_height_in_map_units_minus_1 Yaradılmış videonun ikili formasını yoxlamağa davam etdikdə (məsələn:

xxd -b -c 11 v/minimal_yuv420.h264 ), son NAL-a keçmək olar, bu da kadrdır.Burada onun ilk 6 bayt dəyəri görünür:

. İlk baytın NAL tipini göstərdiyi bilinir, bu halda ( 01100101 10001000 10000100 00000000 00100001 11111111) bu bir IDR seqmentidir (5), ona görə də daha da araşdıra bilərsiniz:00101Spesifikasiya məlumatlarını istifadə edərək, seqment tipini (

slice_type) və çerçeve nömrəsini (frame_num) digər mühüm sahələr arasında dekodlaşdırmaq olar.Bəzi sahələrin dəyərlərini (

ueme(v), se(v), te(v) və ya )), dekodlaşdırma üçün xüsusi bir dekoder istifadə etməliyik,(vGömbəl kodu . Bu metod, daha çox standart dəyərlər olduqda, dəyişkən dəyərlərin kodlaşdırılması üçün çox effektivdir.Bu videonun dəyərləri 7 (I-seqment) və 0 (birinci çerçeve) bərabərdir.

Bit axını bir protokol kimi qəbul edilə bilər. Bit axını haqqında daha çox məlumat əldə etmək istəyirsinizsə, ) və çerçeve nömrəsini ( və ) digər mühüm sahələr arasında dekodlaşdırmaq olar. ITU H.264

spesifikasiyasına müraciət edin. Burada görünən makrosxema, məlumatların görüntü yeri harada olduğunu göstərir ( YUVsıxılmış formada).Digər bit axınlarını araşdıra bilərsiniz, məsələn, ) və ya hətta bizim yeni ən yaxşı bit axınını

. Hamısı oxşardır? Xeyr, amma ən azı birini anladıqdan sonra qalanlarını başa düşmək daha asandır. VP9, ) üçün illik limitləri elan etdi və H.264-ə nisbətən 8 dəfə daha yüksək bir ödəniş tələb etdi, amma tezliklə qaydaları dəyişdirərək: (H.265Təcrübə etmək istəyirsiniz? H.264 bit axınını araşdırın. AV1Tək çerçeveli video yarada və MediaInfo-dan bit axınını araşdırmaq üçün istifadə edə bilərsiniz.

Faktiki olaraq, bit axını təhlil edən mənbə koduna baxmağı da qadağan edən heç nə yoxdur.

Təcrübə üçün Intel Video Pro Analyzer-dan istifadə edə bilərsiniz (artıq demişəm ki, proqram pulludur, amma 10 çerçeve ilə məhdudlaşdırılmış pulsuz sınaq versiyası var). H.264Qeyd edək ki, müasir kodeklərin əksəriyyəti, yalnız araşdırdığımız modeli istifadə edir. Gəlin, video kodekini anlamaq üçün blok sxemasına baxaq. H.264 (AVC).

Təcrübə üçün Intel Video Pro Analyzer-dan istifadə edə bilərsiniz (artıq dediyim kimi, proqram pulludur, lakin 10 çərçivə ilə məhdudlaşdırılmış pulsuz sınaq versiyası var).

səhifəsinə aparır. Burada

Qeyd edək ki, bir çox müasir kodeklər eynilə öyrəndiyimiz modeli istifadə edir. Gəlin videokodekin blok-diagramına baxaq. MPEG LABu, bizim keçdiyimiz bütün addımları ehtiva edir. Bu qeydinin bütün məzmunu odur ki, siz, ən azından, bu sahədə innovasiyalar və sənədli məlumatları daha yaxşı başa düşəsiniz.

Əvvəlcə hesabladıq ki, bir saatlıq, 720p və 30 fps keyfiyyətlərində videofaylı saxlamaq üçün 139 GB disk məkanı lazım olacaq. Bu yazıda müzakirə olunan vasitələrdən (aralıq çərçivələri və daxili proqnozlar, transformasiya, kvantlaşdırma, entropiya kodlaşdırması və s.) istifadə edərək, 0,031 bit/dan piksel sərf etdiyimiz təqdirdə, videonun 367,82 MB-ı tutduğunu, 139 GB yer tutduğuna nisbətən yetərli keyfiyyətdə olduğunu əldə edə bilərik.

H.265 H.264-dən daha yaxşı sıxılma dərəcəsinə necə nail olur?

İndi codec-lərin necə işlədiyini daha yaxşı bildiyimizdə, yeni codec-lərin daha az bitlərlə daha yüksək çözünürlük təmin etməsinin necə mümkün olduğunu başa düşmək daha asandır.

Müqayisə edərkən AVC və H.265, unutmamaq lazımdır ki, bu, demək olar ki, həmişə CPU-nun yüksək yükü ilə sıxma dərəcəsi arasında seçimdir.

H.265 daha çox bölmə (və alt bölmələr) variantlarına malikdir AVC, daha çox daxili proqnoz istiqamətləri, təkmilləşdirilmiş entropiya kodlaşdırması və daha çox. Bütün bu təkmilləşdirmələr ** ) üçün illik limitləri elan etdi və H.264-ə nisbətən 8 dəfə daha yüksək bir ödəniş tələb etdi, amma tezliklə qaydaları dəyişdirərək: ** 50% daha çox sıxma qabiliyyətinə sahib edir, bundan daha yaxşıdır. H.264.

Birinci hissə: Video və şəkillərlə işləmənin əsası

Mənbə: habr.com