भिडियो कोडेक कसरी काम गर्छ? भाग २। के, किन, कसरी

पहिलो भाग: भिडियो र छविहरूसँग काम गर्ने आधारभूत कुराहरू

के? भिडियो कोडेक सफ्टवेयर/हार्डवेयरको एउटा टुक्रा हो जसले डिजिटल भिडियोलाई कम्प्रेस र/वा डिकम्प्रेस गर्छ।

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

अनुवाद एडिसन सफ्टवेयरको समर्थनमा बनाइएको थियो।

हामी संलग्न छौं भिडियो निगरानी प्रणाली को एकीकरणर हामी माइक्रोटोमोग्राफ विकास गर्दैछौं.

कोडेक बनाम कन्टेनर

एक सामान्य गल्ती newbies ले डिजिटल भिडियो कोडेक र डिजिटल भिडियो कन्टेनर भ्रमित छ। कन्टेनर एक निश्चित ढाँचा हो। भिडियो (र सम्भवतः अडियो) मेटाडेटा समावेश भएको र्यापर। कम्प्रेस गरिएको भिडियोलाई कन्टेनर पेलोडको रूपमा सोच्न सकिन्छ।

सामान्यतया, भिडियो फाइलको विस्तारले कन्टेनरको प्रकारलाई संकेत गर्दछ। उदाहरणका लागि, फाइल video.mp4 सम्भवतः कन्टेनर हो MPEG-4 भाग 14, र video.mkv नामको फाइल धेरै सम्भव छ matrёshka। कोडेक र कन्टेनर ढाँचाको पूर्ण रूपमा निश्चित हुन, तपाइँ प्रयोग गर्न सक्नुहुन्छ FFmpeg वा MediaInfo.

बिटको इतिहास

हामी पुग्नु अघि कसरी?, केही पुराना कोडेकहरू अलि राम्रोसँग बुझ्नको लागि इतिहासमा थोरै डुबुल्की मारौं।

भिडियो कोडेक H.261 1990 मा देखा पर्‍यो (प्राविधिक रूपमा - 1988 मा) र 64 Kbps को डाटा ट्रान्सफर दरमा सञ्चालन गर्न सिर्जना गरिएको थियो। यसले पहिले नै रङ सबसम्पलिंग, म्याक्रोब्लकहरू, आदि जस्ता विचारहरू प्रयोग गरिसकेको छ। भिडियो कोडेक मानक 1995 मा प्रकाशित भएको थियो H.263, जुन 2001 सम्म विकसित भयो।

पहिलो संस्करण 2003 मा पूरा भएको थियो H.264 / AVC। त्यही वर्ष, TrueMotion ले यसको नि: शुल्क हानिपूर्ण भिडियो कोडेक नामक जारी गर्‍यो VP3। गुगलले कम्पनीलाई २००८ मा किनेको थियो, जारी गर्दै VP8 उही वर्ष। डिसेम्बर २०१२ मा, गुगल जारी भयो VP9, र यो ब्राउजर बजारको लगभग ¾ मा समर्थित छ (मोबाइल उपकरणहरू सहित)।

AV1 द्वारा विकसित नयाँ नि:शुल्क र खुला स्रोत भिडियो कोडेक हो खुला मिडियाको लागि गठबन्धन (AOMedia), जसमा सबैभन्दा प्रसिद्ध कम्पनीहरू समावेश छन्, जस्तै: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel र Cisco। कोडेकको पहिलो संस्करण, 0.1.0, अप्रिल 7, 2016 मा प्रकाशित भएको थियो।

AV1 को जन्म

2015 को सुरुमा, Google मा काम गरिरहेको थियो VP10Xiph (जुन Mozilla को स्वामित्वमा छ) मा काम गरिरहेको थियो डाला, र Cisco ले आफ्नै नि: शुल्क भिडियो कोडेक भनिन्छ थोर.

त्यसपछि MPEG ला को लागि पहिलो वार्षिक सीमा घोषणा गरियो HEVC (H.265) र H.8 को तुलनामा 264 गुणा बढी शुल्क, तर तिनीहरूले चाँडै नियमहरू फेरि परिवर्तन गरे:

वार्षिक सीमा छैन,
सामग्री शुल्क (राजस्वको ०.५%) र
एकाइ शुल्क H.10 भन्दा लगभग 264 गुणा बढी छ।

खुला मिडियाको लागि गठबन्धन विभिन्न क्षेत्रका कम्पनीहरूद्वारा सिर्जना गरिएको थियो: उपकरण निर्माताहरू (Intel, AMD, ARM, Nvidia, Cisco), सामग्री प्रदायकहरू (Google, Netflix, Amazon), ब्राउजर सिर्जनाकर्ताहरू (Google, Mozilla) र अन्य।

कम्पनीहरूको साझा लक्ष्य थियो - रोयल्टी-मुक्त भिडियो कोडेक। त्यसपछि देखिन्छ AV1 धेरै सरल प्याटेन्ट लाइसेन्स संग। Timothy B. Terryberry ले एक आश्चर्यजनक प्रस्तुति दिनुभयो जुन हालको AV1 अवधारणा र यसको लाइसेन्सिङ मोडेलको उत्पत्ति भयो।

तपाईं ब्राउजर मार्फत AV1 कोडेक विश्लेषण गर्न सक्नुहुन्छ भनेर थाहा पाउँदा छक्क पर्नुहुनेछ (चासो राख्नेहरूले यहाँ जान सक्छन्। aomanalyzer.org).

विश्वव्यापी कोडेक

विश्वव्यापी भिडियो कोडेक अन्तर्निहित मुख्य संयन्त्रलाई हेरौं। यी धेरै अवधारणाहरू उपयोगी छन् र आधुनिक कोडेकहरू जस्तै प्रयोग गरिन्छ VP9, AV1 и HEVC। म तपाईंलाई चेताउनी दिन्छु कि व्याख्या गरिएका धेरै कुराहरू सरल बनाइनेछन्। कहिलेकाहीँ वास्तविक संसार उदाहरणहरू (जस्तै H.264 सँग) प्रविधि प्रदर्शन गर्न प्रयोग गरिनेछ।

पहिलो चरण - छवि विभाजन

पहिलो चरण फ्रेमलाई धेरै खण्डहरू, उपखण्डहरू र पछाडि विभाजन गर्नु हो।

के को लागि? त्यहाँ धेरै कारणहरू छन्। जब हामी छवि विभाजित गर्छौं, हामी साना गतिशील भागहरूका लागि साना खण्डहरू प्रयोग गरेर गति भेक्टरको अधिक सही भविष्यवाणी गर्न सक्छौं। स्थिर पृष्ठभूमिको लागि तपाईं आफैलाई ठूला खण्डहरूमा सीमित गर्न सक्नुहुन्छ।

कोडेक्सहरूले सामान्यतया यी खण्डहरूलाई खण्डहरू (वा भागहरू), म्याक्रोब्लकहरू (वा कोडिङ ट्री ब्लकहरू), र बहु ​​उपखण्डहरूमा व्यवस्थित गर्दछ। यी विभाजनहरूको अधिकतम आकार भिन्न हुन्छ, HEVC ले यसलाई 64x64 मा सेट गर्दछ जबकि AVC ले 16x16 प्रयोग गर्दछ, र उपविभाजनहरू 4x4 आकारहरूमा विभाजित गर्न सकिन्छ।

के तपाइँ अन्तिम लेखबाट फ्रेमका प्रकारहरू सम्झनुहुन्छ?! समान ब्लकहरूमा लागू गर्न सकिन्छ, त्यसैले हामीसँग एक I-खण्ड, एक B-ब्लक, एक P-macroblock, आदि हुन सक्छ।

अभ्यास गर्न चाहनेहरूका लागि, छविलाई खण्ड र उपखण्डहरूमा कसरी विभाजन गरिएको छ हेर्नुहोस्। यो गर्नको लागि, तपाइँ अघिल्लो लेखमा उल्लेख गरिएको एक प्रयोग गर्न सक्नुहुन्छ। इंटेल भिडियो प्रो विश्लेषक (एक जुन भुक्तान गरिएको छ, तर नि: शुल्क परीक्षण संस्करणको साथ जुन पहिलो 10 फ्रेमहरूमा सीमित छ)। खण्डहरू यहाँ विश्लेषण गरिएको छ VP9:

दोस्रो चरण - पूर्वानुमान

एकपटक हामीसँग खण्डहरू छन्, हामी तिनीहरूको लागि ज्योतिषीय भविष्यवाणी गर्न सक्छौं। को लागी INTER पूर्वानुमान हस्तान्तरण गर्नुपर्छ गति वेक्टरहरू र बाँकी, र INTRA पूर्वानुमानको लागि यो प्रसारित हुन्छ पूर्वानुमान दिशा र बाँकी।

तेस्रो चरण - रूपान्तरण

एकचोटि हामीसँग अवशिष्ट ब्लक (पूर्वानुमान गरिएको खण्ड → वास्तविक खण्ड) छ, यसलाई समग्र गुणस्तर कायम राख्दा कुन पिक्सेलहरू खारेज गर्न सकिन्छ भन्ने कुरा हामीलाई थाहा हुने गरी रूपान्तरण गर्न सम्भव छ। त्यहाँ केही परिवर्तनहरू छन् जसले सही व्यवहार प्रदान गर्दछ।

यद्यपि त्यहाँ अन्य विधिहरू छन्, तिनीहरूलाई थप विवरणमा हेरौं। असतत कोसाइन रूपान्तरण (DCT - बाट असतत कोसाइन रूपान्तरण)। DCT को मुख्य कार्यहरू:

• पिक्सेलका ब्लकहरूलाई फ्रिक्वेन्सी गुणांकहरूको बराबर आकारका ब्लकहरूमा रूपान्तरण गर्छ।
• स्थानिय रिडन्डन्सी हटाउन मद्दत गर्नको लागि शक्ति सघन गर्दछ।
• उल्टोपन प्रदान गर्दछ।

फेब्रुअरी 2, 2017 Sintra R.J. (Cintra, RJ) र Bayer F.M. (बायर एफएम) ले छवि कम्प्रेसनको लागि DCT-जस्तो रूपान्तरणको बारेमा एउटा लेख प्रकाशित गर्‍यो जसलाई केवल 14 थपहरू आवश्यक पर्दछ।

चिन्ता नगर्नुहोस् यदि तपाइँ प्रत्येक वस्तुको फाइदाहरू बुझ्नुहुन्न भने। अब तिनीहरूको वास्तविक मूल्य हेर्न विशेष उदाहरणहरू प्रयोग गरौं।

पिक्सेलको यो ८x८ ब्लक लिऔं:

यो ब्लक निम्न ८ गुणा ८ पिक्सेल छविमा रेन्डर गरिएको छ:

पिक्सेलको यो ब्लकमा DCT लागू गर्नुहोस् र गुणांकहरूको 8x8 ब्लक प्राप्त गर्नुहोस्:

र यदि हामीले गुणांकको यो ब्लक रेन्डर गर्छौं भने, हामीले निम्न छवि प्राप्त गर्नेछौं:

तपाईले देख्न सक्नुहुन्छ, यो मूल छवि जस्तो देखिदैन। तपाईंले देख्न सक्नुहुन्छ कि पहिलो गुणांक अन्य सबै भन्दा धेरै फरक छ। यो पहिलो गुणांक DC गुणांकको रूपमा चिनिन्छ, जसले इनपुट एरेमा सबै नमूनाहरू प्रतिनिधित्व गर्दछ, केहि औसत जस्तै।

गुणांकहरूको यो ब्लकमा एक रोचक गुण छ: यसले उच्च-फ्रिक्वेन्सी घटकहरूलाई कम-फ्रिक्वेन्सीहरूबाट अलग गर्दछ।

छविमा, अधिकतर शक्ति कम फ्रिक्वेन्सीहरूमा केन्द्रित हुन्छ, त्यसैले यदि तपाईंले छविलाई यसको फ्रिक्वेन्सी कम्पोनेन्टहरूमा रूपान्तरण गर्नुभयो र उच्च फ्रिक्वेन्सी गुणांकहरू खारेज गर्नुभयो भने, तपाईंले धेरै तस्विर गुणस्तर त्याग नगरी छवि वर्णन गर्न आवश्यक डेटाको मात्रा घटाउन सक्नुहुन्छ।

फ्रिक्वेन्सीले संकेत कति छिटो परिवर्तन हुन्छ भन्ने बुझाउँछ।

DCT को प्रयोग गरेर मूल छविलाई यसको फ्रिक्वेन्सी (गुणकहरूको ब्लक) मा रूपान्तरण गरेर र त्यसपछि कम से कम महत्त्वपूर्ण गुणांकहरूको अंश खारेज गरेर परीक्षण केसमा प्राप्त ज्ञानलाई लागू गर्ने प्रयास गरौं।

पहिले हामी यसलाई फ्रिक्वेन्सी डोमेनमा रूपान्तरण गर्छौं।

अर्को, हामी गुणांकको भाग (67%) खारेज गर्छौं, मुख्यतया तल्लो दाहिने भाग।

अन्तमा, हामी गुणांकको यो खारेज गरिएको ब्लकबाट छविलाई पुन: निर्माण गर्छौं (याद राख्नुहोस्, यो उल्टो हुनुपर्छ) र यसलाई मूलसँग तुलना गर्नुहोस्।

हामी देख्छौं कि यो मूल छविसँग मिल्दोजुल्दो छ, तर त्यहाँ मूलबाट धेरै भिन्नताहरू छन्। हामीले 67,1875% फ्याँक्यौं र अझै पनि मूलसँग मिल्दोजुल्दो कुरा पायौं। अझ राम्रो गुणस्तरको छवि प्राप्त गर्नको लागि अधिक विचारपूर्वक गुणांकहरू खारेज गर्न सम्भव थियो, तर त्यो अर्को विषय हो।

प्रत्येक गुणांक सबै पिक्सेल प्रयोग गरेर उत्पन्न हुन्छ

महत्त्वपूर्ण: प्रत्येक गुणांक प्रत्यक्ष रूपमा एक पिक्सेलमा म्याप गरिएको छैन, तर सबै पिक्सेलहरूको भारित योगफल हो। यो अचम्मको ग्राफले देखाउँछ कि कसरी पहिलो र दोस्रो गुणांकहरू प्रत्येक अनुक्रमणिकाको लागि अद्वितीय वजन प्रयोग गरेर गणना गरिन्छ।

तपाईं यसमा आधारित एक साधारण छवि गठन हेरेर DCT कल्पना गर्न पनि प्रयास गर्न सक्नुहुन्छ। उदाहरणका लागि, यहाँ प्रत्येक गुणांक वजन प्रयोग गरेर उत्पन्न गरिएको प्रतीक A हो:

चौथो चरण - परिमाणीकरण

हामीले अघिल्लो चरणमा केही गुणांकहरू फ्याँकेपछि, अन्तिम चरण (रूपान्तरण) मा हामी क्वान्टाइजेशनको विशेष रूप प्रदर्शन गर्छौं। यस चरणमा यो जानकारी गुमाउन स्वीकार्य छ। वा, अझ सरल रूपमा, हामी सङ्कुचन प्राप्त गर्न गुणांकहरू परिमाण गर्नेछौं।

तपाईं गुणांकको ब्लक कसरी परिमाण गर्न सक्नुहुन्छ? एक सरल तरिका एक समान परिमाणीकरण हो, जब हामी एक ब्लक लिन्छौं, यसलाई एक मान (10 द्वारा) द्वारा विभाजित गर्नुहोस् र परिणामलाई गोल गर्नुहोस्।

के हामी गुणांकको यो ब्लक उल्टाउन सक्छौं? हो, हामी गर्न सक्छौं, हामीले भाग गरेको समान मूल्यले गुणन गर्न सक्छौं।

यो दृष्टिकोण सबै भन्दा राम्रो छैन किनभने यसले प्रत्येक गुणांकको महत्त्वलाई ध्यानमा राख्दैन। कसैले एकल मानको सट्टा क्वान्टाइजरको म्याट्रिक्स प्रयोग गर्न सक्छ, र यो म्याट्रिक्सले तल्लो दायाँको बहुमत र माथिल्लो बायाँको अल्पसंख्यकलाई परिमार्जन गरेर DCT सम्पत्तिको शोषण गर्न सक्छ।

चरण 5 - एन्ट्रोपी कोडिङ

एकचोटि हामीले डाटा (छवि ब्लकहरू, टुक्राहरू, फ्रेमहरू) परिमाणित गरिसकेपछि, हामी अझै पनि यसलाई हानिरहित रूपमा कम्प्रेस गर्न सक्छौं। त्यहाँ डाटा कम्प्रेस गर्न धेरै एल्गोरिदमिक तरिकाहरू छन्। हामी ती मध्ये केहीलाई द्रुत रूपमा हेर्न जाँदैछौं, गहिरो बुझ्नको लागि तपाईंले पुस्तक बुझ्न सक्नुहुन्छ: आधुनिक विकासकर्ताहरूका लागि डाटा कम्प्रेसन ("कम्प्रेसन बुझ्दै: आधुनिक विकासकर्ताहरूको लागि डाटा कम्प्रेसन")।

VLC प्रयोग गरेर भिडियो सङ्केतन

मानौं हामीसँग क्यारेक्टरहरूको स्ट्रिम छ: a, e, r и t। प्रत्येक क्यारेक्टर स्ट्रिममा कति पटक देखिन्छ भन्ने सम्भाव्यता (० देखि १ सम्म) यस तालिकामा प्रस्तुत गरिएको छ।

	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, जसले हाम्रो अन्तिम कम्प्रेस गरिएको बिटस्ट्रिमलाई [१०][०][१११०] वा बराबर बनाउँछ 1001110, जसलाई केवल 7 बिट्स चाहिन्छ (मूल भन्दा 3,4 गुणा कम ठाउँ)।

कृपया ध्यान दिनुहोस् कि प्रत्येक कोड उपसर्गको साथ एक अद्वितीय कोड हुनुपर्छ। Huffman एल्गोरिथ्म तपाईंलाई यी नम्बरहरू फेला पार्न मद्दत गर्नेछ। यद्यपि यो विधि यसको त्रुटिहरू बिना छैन, त्यहाँ भिडियो कोडेकहरू छन् जुन अझै पनि कम्प्रेसनको लागि यो एल्गोरिदमिक विधि प्रस्ताव गर्दछ।

दुबै एन्कोडर र डिकोडरसँग तिनीहरूको बाइनरी कोडहरूको साथ प्रतीक तालिकामा पहुँच हुनुपर्दछ। त्यसकारण, इनपुटको रूपमा तालिका पठाउन पनि आवश्यक छ।

अंकगणित कोडिङ

मानौं हामीसँग क्यारेक्टरहरूको स्ट्रिम छ: a, e, r, s и t, र तिनीहरूको सम्भावना यस तालिकामा प्रस्तुत गरिएको छ।

	a	e	r	s	t
सम्भावना	0,3	0,3	0,15	0,05	0,2

यो तालिका प्रयोग गरेर, हामी सबै सम्भावित क्यारेक्टरहरू समावेश गर्ने दायराहरू निर्माण गर्नेछौं, सबैभन्दा ठूलो संख्याद्वारा क्रमबद्ध।

अब तीनवटा क्यारेक्टरहरूको स्ट्रिम इन्कोड गरौं: खान.

पहिले पहिलो वर्ण चयन गर्नुहोस् e, जुन ०.३ देखि ०.६ सम्मको सबरेन्जमा छ (समावेश छैन)। हामी यो सबरेन्ज लिन्छौं र यसलाई पहिलेको समान अनुपातमा फेरि विभाजन गर्छौं, तर यो नयाँ दायराको लागि।

हाम्रो स्ट्रिम कोडिङ जारी राखौं खान। अब दोस्रो क्यारेक्टर लिनुहोस् a, जुन ०.३ देखि ०.३९ सम्म नयाँ सबरेन्जमा छ, र त्यसपछि हाम्रो अन्तिम वर्ण लिनुहोस् t र उही प्रक्रियालाई पुन: दोहोर्याउँदै, हामीले ०.३५४ देखि ०.३७२ सम्मको अन्तिम उप-दायरा पाउँछौं।

हामीले अन्तिम सबरेन्जमा ०.३५४ देखि ०.३७२ सम्मको संख्या चयन गर्न आवश्यक छ। ०.३६ छनोट गरौं (तर तपाईले यो सबरेन्जमा कुनै पनि अन्य नम्बर रोज्न सक्नुहुन्छ)। यस नम्बरको साथ मात्र हामी हाम्रो मूल स्ट्रिम पुनर्स्थापित गर्न सक्षम हुनेछौं। यो हाम्रो स्ट्रिम इन्कोड गर्न दायरा भित्र रेखा कोर्दै गरेको जस्तो छ।

उल्टो अपरेशन (अर्थात, डिकोडिङ) एकदम सरल छ: हाम्रो संख्या 0,36 र हाम्रो प्रारम्भिक दायरा संग, हामी समान प्रक्रिया चलाउन सक्छौं। तर अब, यो नम्बर प्रयोग गरेर, हामी यो नम्बर प्रयोग गरेर एन्कोड गरिएको स्ट्रिम पहिचान गर्छौं।

पहिलो दायराको साथ, हामीले याद गर्छौं कि हाम्रो संख्या टुक्रासँग मेल खान्छ, त्यसैले यो हाम्रो पहिलो वर्ण हो। अब हामी यस उप-दायरालाई पहिलेको जस्तै प्रक्रिया पछ्याएर फेरि विभाजन गर्छौं। यहाँ तपाईंले देख्न सक्नुहुन्छ कि 0,36 प्रतीकसँग मेल खान्छ a, र प्रक्रिया दोहोर्याएर हामी अन्तिम क्यारेक्टरमा आइपुग्यौं t (हाम्रो मूल एन्कोड गरिएको स्ट्रिम बनाउँदै खान).

एन्कोडर र डिकोडर दुवैमा प्रतीक सम्भावनाहरूको तालिका हुनुपर्छ, त्यसैले यसलाई इनपुट डेटामा पनि पठाउन आवश्यक छ।

एकदम सुरुचिपूर्ण, हैन? जो कोही यो समाधानको साथ आयो धेरै स्मार्ट थियो। केही भिडियो कोडेकहरूले यो प्रविधि प्रयोग गर्छन् (वा कम्तिमा यसलाई विकल्पको रूपमा प्रस्ताव गर्नुहोस्)।

विचार हानिरहित रूपमा क्वान्टाइज्ड बिट स्ट्रिम कम्प्रेस गर्नु हो। पक्कै पनि यस लेखमा धेरै विवरणहरू, कारणहरू, ट्रेड-अफहरू, आदि हराइरहेको छ। तर यदि तपाईं विकासकर्ता हुनुहुन्छ भने, तपाईंले थप जान्नुपर्छ। नयाँ कोडेकहरू जस्तै विभिन्न एन्ट्रोपी एन्कोडिङ एल्गोरिदमहरू प्रयोग गर्ने प्रयास गर्नुहोस् ANS.

चरण 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 तत्वहरूको सीमाहरू परिभाषित गर्नको लागि सिंक्रोनाइजेसन मार्कर छ। प्रत्येक सिंक टोकनले मान समावेश गर्दछ 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 हो SPS। यस प्रकारको NAL ले सामान्य इन्कोडिङ चरहरू जस्तै प्रोफाइल, स्तर, रिजोल्युसन, आदि बारे जानकारी गराउन जिम्मेवार छ।

यदि हामीले पहिलो सिंक मार्कर छोड्यौं भने, कुन NAL प्रकार पहिलो हो भनेर हामीले पहिलो बाइटलाई डिकोड गर्न सक्छौं।

उदाहरण को लागी, सिंक टोकन पछि पहिलो बाइट हो 01100111, जहाँ पहिलो बिट (0) फिल्डमा छorbidden_zero_bit। अर्को २ बिट (11) हामीलाई क्षेत्र बताउँछ nal_ref_idc, जसले यो NAL सन्दर्भ क्षेत्र हो वा होइन भन्ने संकेत गर्छ। र बाँकी ५ बिट्स (00111) हामीलाई क्षेत्र बताउँछ nal_unit_type, यस अवस्थामा यो SPS ब्लक हो (7) NAL।

दोस्रो बाइट (बाइनरी=01100100, हेक्स=0x64, दिसम्बर=100) SPS NAL मा फिल्ड छ profile_idc, जसले एन्कोडरले प्रयोग गरेको प्रोफाइल देखाउँछ। यस अवस्थामा, एक सीमित उच्च प्रोफाइल प्रयोग गरिएको थियो (अर्थात्, द्विदिशात्मक B-खण्ड समर्थन बिना उच्च प्रोफाइल)।

यदि तपाइँ बिटस्ट्रीम विशिष्टता हेर्नुहुन्छ 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), र त्यसपछि तपाईं यसलाई थप अन्वेषण गर्न सक्नुहुन्छ:

स्पेसिफिकेशन जानकारी प्रयोग गरेर, यो टुक्रा प्रकार डिकोड गर्न सम्भव हुनेछ (स्लाइस_प्रकार) र फ्रेम नम्बर (frame_num) अन्य महत्त्वपूर्ण क्षेत्रहरू बीच।

केहि क्षेत्रहरूको मानहरू प्राप्त गर्न (ue(v), me(v), se(v) वा te(v)), हामीले आधारमा विशेष डिकोडर प्रयोग गरेर टुक्रालाई डिकोड गर्न आवश्यक छ घातांक Golomb कोड। यो विधि चर मानहरू सङ्केतन गर्नका लागि धेरै कुशल छ, विशेष गरी जब त्यहाँ धेरै पूर्वनिर्धारित मानहरू छन्।

मानहरू स्लाइस_प्रकार и frame_num यस भिडियोको 7 (I-fragment) र 0 (पहिलो फ्रेम) हो।

एक बिट स्ट्रिम एक प्रोटोकल रूपमा सोच्न सकिन्छ। यदि तपाइँ बिटस्ट्रिमको बारेमा थप जान्न चाहानुहुन्छ भने, तपाइँ निर्दिष्टीकरणलाई सन्दर्भ गर्नुपर्छ ITU H.264। यहाँ छवि डाटा कहाँ छ भनेर देखाउने म्याक्रो रेखाचित्र छ (YUV संकुचित रूपमा)।

अन्य बिटस्ट्रिमहरू जाँच गर्न सकिन्छ, जस्तै VP9, H.265 (HEVC) वा हाम्रो नयाँ उत्कृष्ट बिटस्ट्रीम पनि AV1। के तिनीहरू सबै समान छन्? होइन, तर एकपटक तपाईंले कम्तिमा एउटा बुझ्नुभयो भने, बाँकीलाई बुझ्न धेरै सजिलो हुन्छ।

अभ्यास गर्न चाहनुहुन्छ? H.264 बिटस्ट्रीम अन्वेषण गर्नुहोस्

तपाईं एकल फ्रेम भिडियो उत्पन्न गर्न सक्नुहुन्छ र बिटस्ट्रिम जाँच गर्न MediaInfo प्रयोग गर्न सक्नुहुन्छ H.264। वास्तवमा, तपाइँलाई बिट स्ट्रिमको विश्लेषण गर्ने स्रोत कोड हेर्नबाट पनि केहि पनि रोक्दैन H.264 (AVC).

अभ्यासको लागि, तपाइँ इंटेल भिडियो प्रो विश्लेषक प्रयोग गर्न सक्नुहुन्छ (के मैले पहिले नै कार्यक्रम भुक्तान गरिएको छ भनेर भनेको छु, तर त्यहाँ 10 फ्रेमहरूको सीमाको साथ नि: शुल्क परीक्षण संस्करण छ?)

सिंहावलोकन

ध्यान दिनुहोस् कि धेरै आधुनिक कोडेकहरूले उही मोडेल प्रयोग गर्छन् जुन हामीले भर्खरै अध्ययन गरेका छौं। यहाँ, भिडियो कोडेकको ब्लक रेखाचित्रलाई हेरौं थोर। यसमा हामीले पार गरेका सबै चरणहरू समावेश छन्। यस पोष्टको सम्पूर्ण बिन्दु कम्तिमा तपाईंलाई यस क्षेत्रमा आविष्कारहरू र कागजातहरूको राम्रो बुझाइ दिनु हो।

पहिले, यो गणना गरिएको थियो कि 139 GB डिस्क स्पेस 720p गुणस्तर र 30 fps मा एक घण्टा टिक्ने भिडियो फाइल भण्डारण गर्न आवश्यक हुनेछ। यदि तपाइँ यस लेखमा छलफल गरिएका विधिहरू प्रयोग गर्नुहुन्छ (अन्तर-फ्रेम र आन्तरिक भविष्यवाणीहरू, रूपान्तरण, क्वान्टाइजेसन, एन्ट्रोपी कोडिङ, आदि), त्यसपछि तपाइँ प्राप्त गर्न सक्नुहुन्छ (हामीले प्रति पिक्सेल ०.०३१ बिट्स खर्च गर्छौं भन्ने तथ्यमा आधारित), धेरैको भिडियो। सन्तोषजनक गुणस्तर, केवल 0,031 MB ओगटेको, 367,82 GB मेमोरी होइन।

H.265 ले H.264 भन्दा राम्रो कम्प्रेसन अनुपात कसरी प्राप्त गर्छ?

अब जब हामी कोडेक्सले कसरी काम गर्छ भन्ने बारे थप जान्दछ, यो बुझ्न सजिलो छ कि कसरी नयाँ कोडेकहरूले थोरै बिटहरूसँग उच्च रिजोलुसनहरू डेलिभर गर्न सक्छन्।

यदि हामी तुलना गर्छौं AVC и HEVC, यो याद गर्न लायक छ कि यो लगभग सधैं ठूलो CPU लोड र कम्प्रेसन अनुपात बीच एक विकल्प हो।

HEVC भन्दा बढी खण्ड (र उपखण्ड) विकल्पहरू छन् AVC, थप आन्तरिक भविष्यवाणी निर्देशनहरू, सुधारिएको एन्ट्रोपी कोडिङ, र थप। यी सबै सुधारहरू भएका छन् H.265 50% भन्दा बढी कम्प्रेस गर्न सक्षम H.264.

पहिलो भाग: भिडियो र छविहरूसँग काम गर्ने आधारभूत कुराहरू

स्रोत: www.habr.com