व्हिडिओ कोडेक कसे कार्य करते? भाग 2. काय, का, कसे

पहिला भागः व्हिडिओ आणि प्रतिमांसह कार्य करण्याच्या मूलभूत गोष्टी

काय? व्हिडिओ कोडेक हा सॉफ्टवेअर/हार्डवेअरचा एक भाग आहे जो डिजिटल व्हिडिओ कॉम्प्रेस करतो आणि/किंवा डीकंप्रेस करतो.

कशासाठी? बँडविड्थ आणि दोन्ही बाबतीत काही मर्यादा असूनही
आणि डेटा स्टोरेज स्पेसच्या बाबतीत, मार्केटला उच्च दर्जाच्या व्हिडिओची मागणी आहे. शेवटच्या पोस्टमध्ये आम्ही 30x24 च्या रिझोल्यूशनसह 480 फ्रेम्स प्रति सेकंद, 240 बिट्स प्रति पिक्सेलसाठी आवश्यक किमान कसे मोजले हे तुम्हाला आठवते का? आम्हाला कॉम्प्रेशनशिवाय 82,944 Mbit/s मिळाले. सामान्यतः HD/FullHD/4K टेलिव्हिजन स्क्रीन आणि इंटरनेटवर प्रसारित करण्याचा सध्या कॉम्प्रेशन हा एकमेव मार्ग आहे. हे कसे साध्य होते? आता मुख्य पद्धती थोडक्यात पाहू.

भाषांतर EDISON सॉफ्टवेअरच्या समर्थनाने केले गेले.

आम्ही गुंतलेले आहोत व्हिडिओ पाळत ठेवणे प्रणालीचे एकत्रीकरणआणि आम्ही मायक्रोटोमोग्राफ विकसित करत आहोत.

कोडेक वि कंटेनर

नवशिक्यांनी केलेली एक सामान्य चूक म्हणजे डिजिटल व्हिडिओ कोडेक आणि डिजिटल व्हिडिओ कंटेनर गोंधळात टाकणे. कंटेनर एक विशिष्ट स्वरूप आहे. व्हिडिओ (आणि शक्यतो ऑडिओ) मेटाडेटा असलेले रॅपर. संकुचित व्हिडिओ कंटेनर पेलोड म्हणून विचार केला जाऊ शकतो.

सामान्यतः, व्हिडिओ फाइलचा विस्तार त्याच्या कंटेनरचा प्रकार दर्शवतो. उदाहरणार्थ, video.mp4 फाइल बहुधा एक कंटेनर आहे एमपीईजी-एक्सएनयूएमएक्स भाग एक्सएनयूएमएक्स, आणि video.mkv नावाची फाईल बहुधा आहे matрёшка. कोडेक आणि कंटेनर स्वरूपाची पूर्णपणे खात्री करण्यासाठी, आपण वापरू शकता एफएफएमपीईजी किंवा MediaInfo.

इतिहास एक बिट

आम्ही पोहोचण्यापूर्वी कसे?, काही जुने कोडेक थोडे चांगले समजून घेण्यासाठी इतिहासात थोडे डुबकी घेऊ या.

व्हिडिओ कोडेक H.261 1990 मध्ये दिसू लागले (तांत्रिकदृष्ट्या - 1988 मध्ये) आणि 64 Kbps च्या डेटा ट्रान्सफर दराने ऑपरेट करण्यासाठी तयार केले गेले. याने आधीच कलर सबसॅम्पलिंग, मॅक्रोब्लॉक्स इत्यादी कल्पना वापरल्या आहेत. व्हिडिओ कोडेक मानक 1995 मध्ये प्रकाशित झाले H.263, जे 2001 पर्यंत विकसित झाले.

पहिली आवृत्ती 2003 मध्ये पूर्ण झाली एच. एक्सएनयूएमएक्स / एव्हीसी. त्याच वर्षी, TrueMotion ने त्याचे विनामूल्य हानीकारक व्हिडिओ कोडेक जारी केले VP3. गुगलने 2008 मध्ये कंपनी विकत घेतली VP8 त्याच वर्षी. डिसेंबर 2012 मध्ये, Google रिलीज झाले VP9, आणि हे ब्राउझर मार्केटच्या सुमारे ¾ मध्ये समर्थित आहे (मोबाइल डिव्हाइसेससह).

AV1 द्वारे विकसित केलेला एक नवीन विनामूल्य आणि मुक्त स्रोत व्हिडिओ कोडेक आहे मुक्त माध्यमांसाठी युती (AOMedia), ज्यामध्ये सर्वात प्रसिद्ध कंपन्या समाविष्ट आहेत, जसे की: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel आणि Cisco. कोडेकची पहिली आवृत्ती, 0.1.0, 7 एप्रिल 2016 रोजी प्रकाशित झाली.

AV1 चा जन्म

2015 च्या सुरुवातीस, Google वर काम करत होते VP10Xiph (जे Mozilla च्या मालकीचे आहे) वर काम करत होते डाला, आणि Cisco ने स्वतःचा विनामूल्य व्हिडिओ कोडेक नावाचा बनवला थोर.

नंतर एमपीईजी एलए साठी प्रथम वार्षिक मर्यादा जाहीर केल्या हेवीसी (H.265) आणि H.8 पेक्षा 264 पट जास्त शुल्क, परंतु त्यांनी लवकरच नियम पुन्हा बदलले:

वार्षिक मर्यादा नाही,
सामग्री शुल्क (कमाईच्या 0,5%) आणि
युनिट फी H.10 पेक्षा सुमारे 264 पट जास्त आहे.

मुक्त माध्यमांसाठी युती विविध क्षेत्रातील कंपन्यांनी तयार केले होते: उपकरणे उत्पादक (Intel, AMD, ARM, Nvidia, Cisco), सामग्री प्रदाता (Google, Netflix, Amazon), ब्राउझर निर्माते (Google, Mozilla) आणि इतर.

कंपन्यांचे एक सामान्य ध्येय होते - एक रॉयल्टी-मुक्त व्हिडिओ कोडेक. नंतर दिसते AV1 अधिक सोप्या पेटंट परवान्यासह. टिमोथी बी. टेरीबेरी यांनी एक आश्चर्यकारक सादरीकरण केले जे सध्याच्या AV1 संकल्पनेचे मूळ आणि त्याचे परवाना मॉडेल बनले.

तुम्हाला हे जाणून आश्चर्य वाटेल की तुम्ही ब्राउझरद्वारे AV1 कोडेकचे विश्लेषण करू शकता (इच्छुक लोक येथे जाऊ शकतात. aomanalyzer.org).

युनिव्हर्सल कोडेक

युनिव्हर्सल व्हिडिओ कोडेक अंतर्गत असलेल्या मुख्य यंत्रणा पाहू. यापैकी बहुतेक संकल्पना उपयुक्त आहेत आणि आधुनिक कोडेक्समध्ये वापरल्या जातात जसे की VP9, AV1 и हेवीसी. मी तुम्हाला चेतावणी देतो की स्पष्ट केलेल्या अनेक गोष्टी सोप्या केल्या जातील. काहीवेळा वास्तविक जगाची उदाहरणे (H.264 प्रमाणे) तंत्रज्ञानाचे प्रदर्शन करण्यासाठी वापरली जातील.

पहिली पायरी - प्रतिमा विभाजित करणे

पहिली पायरी म्हणजे फ्रेमला अनेक विभाग, उपविभाग आणि पलीकडे विभागणे.

कशासाठी? अनेक कारणे आहेत. जेव्हा आपण प्रतिमा विभाजित करतो, तेव्हा लहान हलणाऱ्या भागांसाठी लहान विभाग वापरून आपण मोशन वेक्टरचा अधिक अचूकपणे अंदाज लावू शकतो. स्थिर पार्श्वभूमी असताना तुम्ही स्वतःला मोठ्या विभागांमध्ये मर्यादित करू शकता.

कोडेक्स सामान्यत: या विभागांना विभाग (किंवा भाग), मॅक्रोब्लॉक्स (किंवा कोडिंग ट्री ब्लॉक्स) आणि एकाधिक उपविभागांमध्ये व्यवस्थापित करतात. या विभाजनांचा कमाल आकार बदलतो, HEVC ते 64x64 वर सेट करते तर AVC 16x16 वापरते आणि उपविभाजन 4x4 आकारांपर्यंत विभाजित केले जाऊ शकतात.

तुम्हाला शेवटच्या लेखातील फ्रेमचे प्रकार आठवतात का?! हेच ब्लॉक्सवर लागू केले जाऊ शकते, म्हणून आपल्याकडे आय-फ्रॅगमेंट, बी-ब्लॉक, पी-मॅक्रोब्लॉक इत्यादी असू शकतात.

ज्यांना सराव करायचा आहे त्यांच्यासाठी, प्रतिमा विभाग आणि उपविभागांमध्ये कशी विभागली आहे ते पहा. हे करण्यासाठी, आपण मागील लेखात आधीच नमूद केलेला वापरू शकता. इंटेल व्हिडिओ प्रो विश्लेषक (जे सशुल्क आहे, परंतु पहिल्या 10 फ्रेमपर्यंत मर्यादित असलेल्या विनामूल्य चाचणी आवृत्तीसह). विभागांचे विश्लेषण येथे केले आहे VP9:

2 रा टप्पा - अंदाज

एकदा आमच्याकडे विभाग झाले की आम्ही त्यांच्यासाठी ज्योतिषीय अंदाज लावू शकतो. च्या साठी INTER अंदाज हस्तांतरित करणे आवश्यक आहे गती वेक्टर आणि उर्वरित, आणि INTRA अंदाजासाठी ते प्रसारित केले जाते अंदाज दिशा आणि उर्वरित.

तिसरी पायरी - परिवर्तन

एकदा आमच्याकडे अवशिष्ट ब्लॉक (अंदाजित विभाग → वास्तविक विभाग) आला की, एकूण गुणवत्ता राखताना कोणते पिक्सेल टाकले जाऊ शकतात हे आम्हाला कळेल अशा प्रकारे त्याचे रूपांतर करणे शक्य आहे. अचूक वर्तन प्रदान करणारे काही परिवर्तने आहेत.

जरी इतर पद्धती आहेत, चला त्या अधिक तपशीलाने पाहूया. स्वतंत्र कोसाइन ट्रान्सफॉर्म (डीसीटी - पासून स्वतंत्र कोसाइन ट्रान्सफॉर्म). DCT ची मुख्य कार्ये:

• पिक्सेलच्या ब्लॉक्सना वारंवारता गुणांकांच्या समान आकाराच्या ब्लॉक्समध्ये रूपांतरित करते.
• अवकाशीय रिडंडंसी दूर करण्यात मदत करण्यासाठी शक्ती संकुचित करते.
• रिव्हर्सिबिलिटी प्रदान करते.

2 फेब्रुवारी 2017 सिंत्रा आर.जे. (सिंट्रा, आरजे) आणि बायर एफ.एम. (बायर एफएम) ने इमेज कॉम्प्रेशनसाठी डीसीटी सारख्या परिवर्तनाबद्दल एक लेख प्रकाशित केला ज्यासाठी फक्त 14 जोडणे आवश्यक आहेत.

तुम्हाला प्रत्येक बिंदूचे फायदे समजत नसल्यास काळजी करू नका. आता त्यांचे खरे मूल्य पाहण्यासाठी विशिष्ट उदाहरणे वापरू.

चला हा 8x8 पिक्सेलचा ब्लॉक घेऊ:

हा ब्लॉक खालील 8 बाय 8 पिक्सेल इमेज मध्ये प्रस्तुत केला आहे:

पिक्सेलच्या या ब्लॉकवर DCT लागू करा आणि गुणांकांचा 8x8 ब्लॉक मिळवा:

आणि जर आपण गुणांकांचा हा ब्लॉक रेंडर केला तर आपल्याला खालील प्रतिमा मिळेल:

तुम्ही बघू शकता, ती मूळ प्रतिमेसारखी दिसत नाही. तुम्ही पाहू शकता की पहिला गुणांक इतर सर्वांपेक्षा खूप वेगळा आहे. हा पहिला गुणांक DC गुणांक म्हणून ओळखला जातो, जो इनपुट अॅरेमधील सर्व नमुन्यांचे प्रतिनिधित्व करतो, सरासरीसारखे काहीतरी.

गुणांकांच्या या ब्लॉकमध्ये एक मनोरंजक गुणधर्म आहे: ते उच्च-फ्रिक्वेंसी घटकांना कमी-फ्रिक्वेंसी घटकांपासून वेगळे करते.

प्रतिमेमध्ये, बहुतेक शक्ती कमी फ्रिक्वेन्सीवर केंद्रित असते, म्हणून जर तुम्ही प्रतिमेला त्याच्या वारंवारता घटकांमध्ये रूपांतरित केले आणि उच्च वारंवारता गुणांक टाकून दिले, तर तुम्ही जास्त चित्र गुणवत्तेचा त्याग न करता प्रतिमेचे वर्णन करण्यासाठी आवश्यक डेटाचे प्रमाण कमी करू शकता.

वारंवारता सिग्नल किती लवकर बदलते याचा संदर्भ देते.

डीसीटी वापरून मूळ प्रतिमेचे फ्रिक्वेन्सी (गुणकांचा ब्लॉक) मध्ये रूपांतरित करून आणि नंतर कमीत कमी महत्त्वाच्या गुणांकांचा भाग टाकून चाचणी प्रकरणात मिळवलेले ज्ञान लागू करण्याचा प्रयत्न करूया.

प्रथम आम्ही ते वारंवारता डोमेनमध्ये रूपांतरित करतो.

पुढे, आम्ही गुणांकांचा भाग (67%) टाकून देतो, मुख्यतः खालचा उजवा भाग.

शेवटी, आम्ही गुणांकांच्या या टाकून दिलेल्या ब्लॉकमधून प्रतिमेची पुनर्रचना करतो (लक्षात ठेवा, ते इन्व्हर्टेबल असणे आवश्यक आहे) आणि मूळशी तुलना करतो.

आम्ही पाहतो की ते मूळ प्रतिमेशी साम्य आहे, परंतु मूळ प्रतिमेपासून बरेच फरक आहेत. आम्ही 67,1875% बाहेर फेकले आणि तरीही मूळसारखे काहीतरी मिळाले. आणखी चांगल्या गुणवत्तेची प्रतिमा मिळविण्यासाठी गुणांक अधिक विचारपूर्वक टाकून देणे शक्य होते, परंतु तो पुढील विषय आहे.

प्रत्येक गुणांक सर्व पिक्सेल वापरून तयार केला जातो

महत्त्वाचे: प्रत्येक गुणांक थेट एका पिक्सेलवर मॅप केलेला नाही, परंतु सर्व पिक्सेलची भारित बेरीज आहे. हा आश्चर्यकारक आलेख दर्शवितो की प्रत्येक निर्देशांकासाठी अद्वितीय वजन वापरून प्रथम आणि द्वितीय गुणांक कसे मोजले जातात.

तुम्ही त्यावर आधारित एक साधी प्रतिमा तयार करून डीसीटीची कल्पना करण्याचा प्रयत्न देखील करू शकता. उदाहरणार्थ, प्रत्येक गुणांक वजन वापरून तयार केलेले चिन्ह A येथे आहे:

4 था पायरी - परिमाणीकरण

मागील पायरीवर काही गुणांक टाकल्यानंतर, शेवटच्या टप्प्यावर (परिवर्तन) आम्ही परिमाणीकरणाचा एक विशेष प्रकार करतो. या टप्प्यावर माहिती गमावणे स्वीकार्य आहे. किंवा, अधिक सोप्या भाषेत, आम्ही कॉम्प्रेशन प्राप्त करण्यासाठी गुणांकांचे परिमाण करू.

तुम्ही गुणांकांच्या ब्लॉकचे परिमाण कसे काढू शकता? सर्वात सोप्या पद्धतींपैकी एक म्हणजे एकसमान परिमाणीकरण, जेव्हा आपण ब्लॉक घेतो, तेव्हा त्यास एका मूल्याने (10 ने) विभाजित करतो आणि परिणामास गोल करतो.

गुणांकांचा हा ब्लॉक आपण उलट करू शकतो का? होय, आपण ज्या मूल्याने भागले त्याच मूल्याने गुणाकार करू शकतो.

हा दृष्टिकोन सर्वोत्तम नाही कारण तो प्रत्येक गुणांकाचे महत्त्व विचारात घेत नाही. एका मूल्याऐवजी क्वांटायझर्सचे मॅट्रिक्स वापरता येऊ शकते आणि हे मॅट्रिक्स खालच्या उजवीकडील बहुसंख्य आणि वरच्या डावीकडील अल्पसंख्याकांचे परिमाण करून DCT मालमत्तेचे शोषण करू शकते.

पायरी 5 - एन्ट्रॉपी कोडिंग

एकदा आम्ही डेटा (इमेज ब्लॉक्स, फ्रॅगमेंट्स, फ्रेम्स) परिमाणित केल्यावर, आम्ही तरीही तो नुकसानरहितपणे संकुचित करू शकतो. डेटा संकुचित करण्याचे अनेक अल्गोरिदमिक मार्ग आहेत. आम्ही त्यापैकी काहींवर एक झटकन नजर टाकणार आहोत, सखोल समजून घेण्यासाठी तुम्ही Understanding Compression: Data Compression for Modern Developers ("कम्प्रेशन समजून घेणे: आधुनिक विकसकांसाठी डेटा कॉम्प्रेशन").

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, जो जोडला जातो (गणितीय पद्धतीने नाही): [१०][०], आणि शेवटी तिसरा वर्ण 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 (आमचा मूळ एन्कोड केलेला प्रवाह तयार करणे खाणे).

एन्कोडर आणि डीकोडर दोन्हीमध्ये चिन्ह संभाव्यतेची सारणी असणे आवश्यक आहे, म्हणून ते इनपुट डेटामध्ये देखील पाठवणे आवश्यक आहे.

अगदी मोहक, नाही का? ज्याने हा उपाय शोधला तो अत्यंत हुशार होता. काही व्हिडिओ कोडेक हे तंत्र वापरतात (किंवा किमान ते पर्याय म्हणून ऑफर करतात).

क्वांटाइज्ड बिट स्ट्रीम लॉसलेस कॉम्प्रेस करण्याची कल्पना आहे. निश्चितपणे या लेखात बरेच तपशील, कारणे, ट्रेड-ऑफ इत्यादी गहाळ आहेत. पण तुम्ही डेव्हलपर असाल तर तुम्हाला अधिक माहिती हवी. नवीन कोडेक्स भिन्न एन्ट्रॉपी एन्कोडिंग अल्गोरिदम वापरण्याचा प्रयत्न करतात जसे की अंधश्रद्धा निर्मूलन.

चरण 6 - बिटस्ट्रीम स्वरूप

हे सर्व केल्यानंतर, केलेल्या चरणांच्या संदर्भात संकुचित फ्रेम्स अनपॅक करणे बाकी आहे. एन्कोडरने घेतलेल्या निर्णयांबद्दल डीकोडरला स्पष्टपणे माहिती देणे आवश्यक आहे. डीकोडरला सर्व आवश्यक माहिती प्रदान करणे आवश्यक आहे: बिट खोली, रंग जागा, रिझोल्यूशन, अंदाज माहिती (मोशन वेक्टर, दिशात्मक इंटर प्रेडिक्शन), प्रोफाइल, स्तर, फ्रेम दर, फ्रेम प्रकार, फ्रेम नंबर आणि बरेच काही.

आम्ही बिटस्ट्रीमवर एक द्रुत कटाक्ष टाकू 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 चे मुख्य ध्येय "वेब-अनुकूल" व्हिडिओ सादरीकरण प्रदान करणे आहे. हे मानक टीव्ही (स्ट्रीम-आधारित), इंटरनेट (पॅकेट-आधारित) वर कार्य केले पाहिजे.

NAL घटकांच्या सीमा परिभाषित करण्यासाठी एक सिंक्रोनाइझेशन मार्कर आहे. प्रत्येक सिंक टोकनमध्ये एक मूल्य असते 0x00 0x00 0x01, पहिल्याच व्यतिरिक्त, जे समान आहे 0x00 0x00 0x00 0x01. आम्ही लाँच केले तर हेक्सडंप व्युत्पन्न केलेल्या 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 असतो एसपीएस. या प्रकारचा NAL सामान्य एन्कोडिंग व्हेरिएबल्स जसे की प्रोफाइल, लेव्हल, रिझोल्यूशन इ. बद्दल माहिती देण्यासाठी जबाबदार आहे.

आम्ही पहिला सिंक मार्कर वगळल्यास, कोणता NAL प्रकार पहिला आहे हे शोधण्यासाठी आम्ही पहिला बाइट डीकोड करू शकतो.

उदाहरणार्थ, सिंक टोकन नंतरचा पहिला बाइट आहे 01100111, जिथे पहिला बिट (0) क्षेत्रात आहे forbidden_zero_bit. पुढील 2 बिट (11) आम्हाला फील्ड सांगते nal_ref_idc, जे सूचित करते की हे NAL संदर्भ क्षेत्र आहे की नाही. आणि उर्वरित 5 बिट (00111) आम्हाला फील्ड सांगते nal_unit_type, या प्रकरणात तो SPS ब्लॉक आहे (7) NAL.

दुसरा बाइट (बायनरी=01100100, हेक्स=0x64, डिसेंबर=100) SPS NAL मध्ये फील्ड आहे प्रोफाइल_आयडीसी, जे एन्कोडरने वापरलेले प्रोफाइल दाखवते. या प्रकरणात, मर्यादित उच्च प्रोफाइल वापरण्यात आले (म्हणजे, द्विदिशात्मक बी-सेगमेंट समर्थन नसलेले उच्च प्रोफाइल).

आपण बिटस्ट्रीम तपशील पाहिल्यास H.264 SPS NAL साठी, आम्हाला पॅरामीटरचे नाव, श्रेणी आणि वर्णनासाठी अनेक मूल्ये सापडतील. उदाहरणार्थ, फील्ड पाहू pic_width_in_mbs_minus_1 и pic_height_in_map_units_minus_1.

पॅरामीटरचे नाव	श्रेणी	वर्णन
pic_width_in_mbs_minus_1	0	ue(v)
pic_height_in_map_units_minus_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) आहे आणि नंतर तुम्ही ते आणखी एक्सप्लोर करू शकता:

तपशील माहिती वापरुन, तुकड्याचा प्रकार डीकोड करणे शक्य होईल (स्लाइस_प्रकार) आणि फ्रेम क्रमांक (फ्रेम_संख्या) इतर महत्त्वाच्या क्षेत्रांमध्ये.

काही फील्डची मूल्ये मिळवण्यासाठी (ue(v), me(v), se(v) किंवा te(v)), आम्हाला आधारित विशेष डीकोडर वापरून तुकडा डीकोड करणे आवश्यक आहे घातांकीय गोलॉम्ब कोड. ही पद्धत व्हेरिएबल व्हॅल्यू एन्कोडिंगसाठी अतिशय कार्यक्षम आहे, विशेषत: जेव्हा अनेक डीफॉल्ट मूल्ये असतात.

मूल्ये स्लाइस_प्रकार и फ्रेम_संख्या या व्हिडिओचे 7 (आय-फ्रॅगमेंट) आणि 0 (पहिली फ्रेम) आहेत.

थोडा प्रवाह प्रोटोकॉल म्हणून विचार केला जाऊ शकतो. तुम्हाला बिटस्ट्रीम बद्दल अधिक जाणून घ्यायचे असल्यास, तुम्ही स्पेसिफिकेशनचा संदर्भ घ्यावा ITU H.264. इमेज डेटा कुठे आहे हे दर्शविणारा मॅक्रो डायग्राम येथे आहे (YUV संकुचित स्वरूपात).

इतर बिटस्ट्रीम तपासले जाऊ शकतात, जसे की VP9, H.265 (हेवीसी) किंवा अगदी आमचे नवीन सर्वोत्तम बिटस्ट्रीम AV1. ते सर्व समान आहेत? नाही, पण एकदा तुम्हाला किमान एक समजले की, बाकीचे समजून घेणे खूप सोपे आहे.

सराव करू इच्छिता? H.264 बिटस्ट्रीम एक्सप्लोर करा

तुम्ही एकच फ्रेम व्हिडिओ व्युत्पन्न करू शकता आणि बिटस्ट्रीमचे परीक्षण करण्यासाठी MediaInfo वापरू शकता H.264. खरं तर, बिट प्रवाहाचे विश्लेषण करणार्‍या स्त्रोत कोडकडे पाहण्यापासून काहीही प्रतिबंधित करत नाही H.264 (AVC).

सरावासाठी, आपण इंटेल व्हिडिओ प्रो विश्लेषक वापरू शकता (मी आधीच सांगितले आहे की प्रोग्राम सशुल्क आहे, परंतु 10 फ्रेमच्या मर्यादेसह विनामूल्य चाचणी आवृत्ती आहे?).

विहंगावलोकन

लक्षात घ्या की अनेक आधुनिक कोडेक आम्ही नुकतेच अभ्यासलेले मॉडेल वापरतात. येथे, व्हिडिओ कोडेकच्या ब्लॉक आकृतीवर एक नजर टाकूया थोर. त्यात आपण ज्या पायऱ्या पार केल्या आहेत त्या सर्वांचा समावेश आहे. या पोस्टचा संपूर्ण मुद्दा किमान तुम्हाला या क्षेत्रातील नवकल्पना आणि दस्तऐवजीकरणाची चांगली समज देणे हा आहे.

पूर्वी, अशी गणना केली गेली होती की 139p गुणवत्तेवर आणि 720 fps वर एक तास टिकणारी व्हिडिओ फाइल संचयित करण्यासाठी 30 GB डिस्क स्पेसची आवश्यकता असेल. आपण या लेखात चर्चा केलेल्या पद्धती वापरल्यास (इंटर-फ्रेम आणि अंतर्गत अंदाज, परिवर्तन, परिमाणीकरण, एन्ट्रॉपी कोडिंग इ.), तर आपण साध्य करू शकता (आम्ही प्रति पिक्सेल 0,031 बिट्स खर्च करतो या वस्तुस्थितीवर आधारित), एक व्हिडिओ समाधानकारक गुणवत्ता, केवळ 367,82 MB व्यापत आहे, 139 GB मेमरी नाही.

H.265 H.264 पेक्षा चांगले कॉम्प्रेशन रेशो कसे मिळवते?

आता आम्हाला कोडेक्स कसे कार्य करतात याबद्दल अधिक माहिती आहे, नवीन कोडेक कमी बिटसह उच्च रिझोल्यूशन कसे वितरित करू शकतात हे समजून घेणे सोपे आहे.

जर आपण तुलना केली AVC и हेवीसी, हे लक्षात ठेवण्यासारखे आहे की हे जवळजवळ नेहमीच मोठे CPU लोड आणि कॉम्प्रेशन रेशियो यांच्यातील निवड असते.

हेवीसी पेक्षा अधिक विभाग (आणि उपविभाग) पर्याय आहेत AVC, अधिक अंतर्गत अंदाज दिशानिर्देश, सुधारित एन्ट्रॉपी कोडिंग आणि बरेच काही. या सर्व सुधारणा करण्यात आल्या आहेत H.265 पेक्षा 50% जास्त संकुचित करण्यास सक्षम H.264.

पहिला भागः व्हिडिओ आणि प्रतिमांसह कार्य करण्याच्या मूलभूत गोष्टी

स्त्रोत: www.habr.com