👩🏿‍🏫 🐆 🗾 QCM-08DL डैशबोर्ड के लिए एक 264 एवी वीडियो कनवर्टर का विकास 🧐 ⛹️ 🚤

वास्तव में, लेख को एक कंटेनर से दूसरे कंटेनर में डीवीआर वीडियो को रीपैकेजिंग करने के लिए एक कार्यक्रम के विकास के लिए समर्पित है, अगर इसे रूपांतरण कहा जा सकता है। हालाँकि, मेरा सारा जीवन मुझे लगा कि कनवर्टर वीडियो प्रारूप को परिवर्तित करने (ट्रांसकोडिंग) में लगा हुआ है। यह लेख मेरे पिछले प्रकाशन का दूसरा हिस्सा है, जहाँ मैंने डीवीआर की सभी वीडियो रिकॉर्डिंग तक पहुँचने के बारे में विस्तार से बात की है। लेकिन प्रकाशन की शुरुआत में, मैंने एक और कार्य निर्धारित किया: एल्गोरिथ्म का अध्ययन करने के लिए जिसके द्वारा मानक 264-एवी रिपैकर प्रोग्राम काम करता है और एक ही प्रोग्राम बनाता है जो समान संचालन करेगा, लेकिन एक पर नहीं, बल्कि संपूर्ण फ़ाइलों का समूह, इसके अलावा "वन क्लिक"।

मैं एक बार फिर सरल भाषा में सभी चीजों का सार समझाऊंगा।

उपयोगकर्ता के पास एक वीडियो रिकॉर्डर है, उदाहरण के लिए, लोकप्रिय मॉडल QCM-08DL। उसे एक विशिष्ट तिथि और समय के लिए एक वीडियो की आवश्यकता होती है। वह इसे या तो यूएसबी फ्लैश ड्राइव पर या कंप्यूटर पर एक डीवीआर के वेब-आधारित इंटरफ़ेस के माध्यम से निकाल सकता है। निकाले गए वीडियो फ़ाइल (एक्सटेंशन .264) केवल डीवीआर के साथ आने वाले प्लेयर प्रोग्राम में खुलेंगे। खिलाड़ी बहुत असहज है। आप इसे अभी भी वीएलसी प्लेयर में खोल सकते हैं RAW H264 मोड को डीमूलिप्लेक्सिंग सेटिंग्स (एडवांस्ड के लिए सेटिंग्स) में सेट करके। लेकिन एक ही समय में, जाहिरा तौर पर, ऑडियो धाराओं के ब्लॉक, जिन्हें वीडियो के रूप में व्याख्या किया जाता है, और कोई आवाज़ नहीं होती है, सामान्य प्लेबैक में हस्तक्षेप करते हैं। और किसी भी खिलाड़ी में वीडियो खोलने के लिए, .264 फ़ाइल को पहले कुछ लोकप्रिय प्रारूप में बदलना होगा, उदाहरण के लिए, एवी। डीवीआर के साथ एक रूपांतरण कार्यक्रम भी शामिल है। लेकिन वह बहुत असहज भी है। जब एक या अधिक फ़ाइलों की बात आती है, तो कोई समस्या नहीं होती है। हालांकि, जब कार्य हार्ड ड्राइव पर सभी वीडियो तक पहुंच प्राप्त करना है, और इससे भी अधिक उन सभी को लोकप्रिय प्रारूप में परिवर्तित करने के लिए, मानक उपकरण व्यावहारिक रूप से उपयुक्त नहीं हैं।

सभी फ़ाइलों तक पहुंच की समस्या हल हो गई है। यह अंतिम प्रकाशन का विषय था। हम दूसरी समस्या को हल करने के लिए आगे बढ़ते हैं। मुझे पहले से ही "व्यावहारिक सलाह" दी गई है: फ़ाइल नाम में "264" से "एवी" तक एक्सटेंशन का नाम बदलना पर्याप्त है, और सब कुछ गलत हो जाएगा, वे कहते हैं, परेशान करने के लिए कुछ भी नहीं है। लेकिन यह किसी भी सामान्य उपयोगकर्ता की सबसे आम गलती है, जो एक नियम के रूप में, प्रासंगिक मुद्दों को नहीं समझता है।

पिछले प्रकाशन में, मैंने पहले ही .264 स्रोत फ़ाइल की संरचना के बारे में संक्षेप में लिखा था। मैं आपको याद दिला दूं।

ऑडियो और वीडियो स्ट्रीम के साथ मुख्य जानकारी 65,536 बाइट्स की भरपाई में उत्पन्न होती है। वीडियो स्ट्रीम ब्लॉक एक 8-बाइट हेडर "01dcH264" से शुरू होता है ("00dcH264" भी पाया जाता है)। निम्नलिखित 4 बाइट्स बाइट्स में वीडियो स्ट्रीम के वर्तमान ब्लॉक के आकार का वर्णन करते हैं। शून्य के 4 बाइट्स (00 00 00 00) के बाद, वीडियो स्ट्रीम ब्लॉक स्वयं शुरू होता है। ऑडियो स्ट्रीम ब्लॉक का शीर्षक "03wb" है (हालांकि, मेरी टिप्पणियों के अनुसार, कुछ मामलों में हेडर का पहला चरित्र वैकल्पिक रूप से "0" था)। सूचना के 12 बाइट्स के बाद जो मुझे अभी तक पता नहीं चला है। और 17 वें बाइट के साथ शुरू - 160 बाइट्स की एक निश्चित लंबाई का एक ऑडियो स्ट्रीम। फ़ाइल के अंत में कोई टैग नहीं हैं।

मैं ऊपर टिप्पणी करूंगा। 65,536 बाइट्स की भरपाई के लिए सब कुछ अनसुलझा और अनावश्यक है। 65,536 बाइट्स की ऑफसेट से स्ट्रीम के पहले हेडर तक, एक छोटा सा अंतर है, जिनमें से सामग्री भी हल नहीं होती है, और, इसके अलावा, जैसा कि मैंने जाँच की, यह एक नियमित कार्यक्रम द्वारा रूपांतरण के बाद आउटपुट एवी फ़ाइल में प्रकट नहीं होता है।

वीडियो स्ट्रीम का प्रत्येक ब्लॉक एक फ्रेम का प्रतिनिधित्व करता है। वीडियो स्ट्रीम के ब्लॉक के हेडर में पहला वर्ण वैकल्पिक रूप से "0" है। मैंने उसके उद्देश्य का पता नहीं लगाया, क्योंकि, जैसा कि मुझे पता चला, यह कार्य को हल करने की कुंजी नहीं है। वीडियो स्ट्रीम के हेडर का दूसरा वर्ण या तो "1" या "0" हो सकता है। दूसरे मामले में, वीडियो स्ट्रीम ब्लॉक की सामग्री तथाकथित संदर्भ फ्रेम है। और पहले मामले में, वीडियो स्ट्रीम ब्लॉक की सामग्री एक एन्कोडेड संपीड़ित फ़्रेम है, जो संदर्भ फ़्रेम पर निर्भर करता है। संदर्भ फ्रेम की सामग्री का आकार संपीड़ित उप-फ्रेम की सामग्री के आकार से काफी बड़ा है। संदर्भ फ्रेम पुनरावृत्ति अवधि सबसे अधिक संभावना डीवीआर में संपीड़न अनुपात सेटिंग्स पर निर्भर करता है। लेकिन मेरे मामले में, पुनरावृत्ति की अवधि 1 फ्रेम / सेकंड थी।

वीडियो को "264" कंटेनर से "एवी" कंटेनर में पुन: भेजने के लिए नियमित कार्यक्रम ने फ्रेम दर के संबंध में अलग-अलग परिणाम दिए। उच्च रिज़ॉल्यूशन मोड (704 * 576) में दर्ज किए गए वीडियो के मामले में, फ्रेम दर 20 फ्रेम / सेकंड थी। और कम रिज़ॉल्यूशन (352 * 288) के मामले में - 25 फ्रेम / सेक। यह जानकारी MediaInfo उपयोगिता द्वारा प्रदान की गई है। यह यह भी बताती है कि वीडियो का आकार किसी भी मामले में समान है: 720 * 576, और वीडियो स्ट्रीम का आकार (यह उपयोगिता रिपोर्ट) 704 * 576 या 352 * 288 है। अधिकांश खिलाड़ियों को विशेष रूप से वीडियो स्ट्रीम के आकार के लिए तैनात किया जाता है। हालाँकि, मैं एक ऐसे खिलाड़ी से मिला, जिसने 352 * 288 फ़ाइल खेलते समय गलत तरीके से हाफ स्क्रीन मोड प्रदर्शित किया था। मैं पूर्णकालिक प्रतिनिधि के इस मामूली दोष को वीडियो स्ट्रीम की सामग्री के बाइट्स को देखकर और वहां से फ्रेम आकार के बारे में जानकारी खींचकर ठीक करना चाहता था। लेकिन जल्दी में, मैं ऐसा नहीं कर सका। ऊपर चित्र में दिखाया गया है।

अब फ्रेम रेट के बारे में। जैसा कि मुझे पता चला है, नियमित रिपैकर "264" कंटेनर के किसी भी हेडर फील्ड तक नहीं पहुँच पाता है। यह वीडियो ब्लॉक और ऑडियो स्ट्रीम की संख्या के अनुपात की गणना करके फ्रेम दर का न्याय करता है। और गणना में यह मान निकटतम पूरे मूल्य के लिए भी नहीं है, जैसा कि ऊपर की आकृति (हरे रंग में परिक्रमा) से देखा जा सकता है। जैसा कि मुझे पता चला है, समय सीमा के अनुसार ऑडियो स्ट्रीम ब्लॉक की संख्या हमेशा और हर जगह (किसी भी फ़ाइल में) निश्चित होती है, अर्थात् प्रति सेकंड 25 ब्लॉक। यदि आप 20 फ्रेम / सेकंड की आवृत्ति के साथ वीडियो फ़ाइल की जांच करते हैं, तो संदर्भ फ्रेम (ब्लॉक) प्रत्येक 19 संपीड़ित फ़्रेम में होता है, और 25 फ्रेम / सेकंड के मामले में। - हर 24 संकुचित फ्रेम।

हम वीडियो स्ट्रीम के हेडर की संरचना का अध्ययन करना जारी रखते हैं। हमने पहले आठ बाइट्स का पता लगाया: यह संदर्भ या संपीड़ित फ्रेम प्लस "H264" का लेबल है। निम्नलिखित चार बाइट्स का वर्णन है, जैसा कि मुझे पता चला है, वीडियो स्ट्रीम की सामग्री का सटीक, लेकिन अनुमानित आकार नहीं है। एक नियमित प्रतिनिधि इस सामग्री के सभी बाइट्स को पूरी तरह से फेंक देता है, और फिर एवी कंटेनर के संबंधित क्षेत्रों में परिणामी आकार लिखता है। और यह मान स्रोत .264 फ़ाइल के संबंधित क्षेत्र में निर्दिष्ट मूल्य से अलग है।

आंशिक रूप से, मैंने ऑडियो स्ट्रीम ब्लॉक के हेडर के बाद जानकारी के बारह बाइट्स का अनुमान लगाया। किसी भी स्थिति में, मुख्य तत्व अंतिम 4 बाइट्स हैं, जिसके बाद ऑडियो स्ट्रीम शुरू होता है। ये दो 16-बिट संख्या हैं जो ADPCM से PCM तक चलने वाली डिकोडिंग योजना के प्रारंभिक मापदंडों का वर्णन करते हैं। डिकोडिंग ऑडियो स्ट्रीम के आकार को 4 गुना बढ़ा देता है। जब मैंने पहले से फाइलों की जांच की, तो मुझे पता चला कि पूर्णकालिक प्रतिनिधि ऑडियो को डीकोड करता है, लेकिन वीडियो की सामग्री को अपरिवर्तित छोड़ देता है।

गहन ज्ञान के बिना, मैंने लंबे समय तक यह पता लगाने की कोशिश की कि मेरे मामले में डिकोडिंग एल्गोरिथ्म का उपयोग किया गया था। सहज रूप से पहले से ही अनुमान लगाया गया कि एडीपीसीएम को संपीड़न विधि लागू किया गया था। अधिक सटीक रूप से, सहज रूप से नहीं, लेकिन एक सक्षम दृष्टिकोण के साथ, इस तथ्य पर आधारित है कि ऑडियो स्ट्रीम ठीक 4 बार संकुचित है। और जब मैं विभिन्न प्रारूपों में रॉ के रूप में एडोब ऑडिशन में एक खंड खोलता हूं (और एक नियमित कार्यक्रम के साथ पुनरावृत्ति के बाद उसी टुकड़े की तुलना करता है), तो एक बहुत ही समान (लेकिन सटीक नहीं) ध्वनि परिणाम मुझे ADPCM द्वारा दिया गया था। संपीड़न एल्गोरिथ्म का विश्लेषण करने के लिए, साइट wiki.multimedia.cx/index.php/IMA_ADPCM की जानकारी ने मेरी मदद की। यहां मैंने दो प्रारंभिक डिकोडिंग मापदंडों के बारे में सीखा, और फिर, "पोक विधि" का उपयोग करते हुए, मैंने महसूस किया कि ये प्रारंभिक पैरामीटर ऑडियो स्ट्रीम की शुरुआत से पहले 4 बाइट्स में दर्ज किए गए थे। मैं एल्गोरिथ्म के संचालन का वर्णन करूंगा और एक खराब गणितीय व्याख्या (स्पॉइलर के तहत) दूंगा।

ADPCM डिकोडिंग एल्गोरिथम विवरण

नमूनों का एक क्रम है

।

$x_0, x_1, x_2, \ dots।$ इसके अलावा, जैसा कि पहले ही उल्लेख किया गया है, दो प्रारंभिक पैरामीटर हैं

$y_0$ और

$s_0$ । एक नया नमूना अनुक्रम प्राप्त करने की आवश्यकता है

।

$y_0, y_1, y_2 \ dots।$ । जैसा कि आप पहले से ही अनुमान लगा सकते हैं, पहला आउटपुट नमूना पहले से ही ज्ञात है: यह प्रारंभिक मापदंडों में से एक के साथ मेल खाता है

$y_0$ । यह "प्रारंभिक विस्थापन" के अलावा कुछ और है। यह ध्यान देने योग्य है कि इनपुट (स्रोत) नमूने चार बिट्स में एन्कोड किए गए हैं। हस्ताक्षरित प्रकारों के लिए, पूर्णांक -8 से 7 तक, समावेशी, एन्कोडिंग के अंतर्गत आते हैं। सबसे महत्वपूर्ण बिट, वास्तव में, संख्या के संकेत के लिए जिम्मेदार है। आउटपुट पीसीएम नमूने, जो डिकोडिंग के बाद प्राप्त होते हैं, पर हस्ताक्षर किए गए 16-बिट मानक प्रारूप होते हैं।

C में एल्गोरिथ्म कोड का विश्लेषण करते हुए, आप दो तालिकाओं को देख सकते हैं। वे नीचे सूचीबद्ध हैं।

int ima_index_table[] = { -1, -1, -1, -1, 2, 4, 6, 8 };

 int ima_step_table[] = { 7, 8, 9, 10, 11, 12, 13, 14, 16, 17, 19, 21, 23, 25, 28, 31, 34, 37, 41, 45, 50, 55, 60, 66, 73, 80, 88, 97, 107, 118, 130, 143, 157, 173, 190, 209, 230, 253, 279, 307, 337, 371, 408, 449, 494, 544, 598, 658, 724, 796, 876, 963, 1060, 1166, 1282, 1411, 1552, 1707, 1878, 2066, 2272, 2499, 2749, 3024, 3327, 3660, 4026, 4428, 4871, 5358, 5894, 6484, 7132, 7845, 8630, 9493, 10442, 11487, 12635, 13899, 15289, 16818, 18500, 20350, 22385, 24623, 27086, 29794, 32767 };

इन दो "जादू" सरणियों को सारणीबद्ध कार्य कहा जा सकता है, जिन तर्कों में समान दो प्रारंभिक मापदंडों को प्रतिस्थापित किया जाता है। पुनरावृत्ति के दौरान, प्रत्येक चरण के साथ, इन तालिकाओं में मापदंडों को पुनर्गणना और प्रतिस्थापित किया जाता है। सबसे पहले, देखते हैं कि यह कोड में कैसे लागू किया जाता है।

हम सहायक चरों सहित आवश्यक घोषित करते हैं।

 int current1; int step; int stepindex1; int diff; int current; int stepindex; int value; //  ;

चलना शुरू करने से पहले, आपको वर्तमान चर को प्रारंभिक पैरामीटर असाइन करना होगा

$y_0$ , और चर stepindex है

$s_0$ । यह प्रश्न में एल्गोरिथ्म के बाहर किया जाता है, इसलिए मैं कोड के साथ इसे प्रतिबिंबित नहीं करता हूं। निम्नलिखित रूपांतरण हैं जो एक सर्कल में (एक लूप में) किए जाते हैं।

  value = read(input_sample); //   ; current1 = current; stepindex1 = stepindex; step = ima_step_table[stepindex1]; diff = step>>3; if(value & 1){ diff += step >> 2; } if(value & 2){ diff += step >> 1; } if(value & 4){ diff += step; } if(value & 8){ current1 -= diff; if(current1 < -32768){ //,  ""; current1 = -32768; } }else{ current1 += diff; if(current1 > 32767){ //,  ""; current1 = 32767; } } //      :   current1; stepindex1 += ima_index_table[value & 7]; if(stepindex1 < 0){ // ""; stepindex1 = 0; } if(stepindex1 > 88){ // ""; stepindex1 = 88; } output_sample = curent1; //   ; current = current1; stepindex = stepindex1;

Ima_step_table सरणी से सहायक चर चरण में, सूचकांक stepindex1 पर मान लिखा है। पहले पुनरावृत्ति के लिए, यह प्रारंभिक पैरामीटर है

$s_0$ , आगे पुनरावृत्तियों के लिए यह एक पुनर्गणित पैरामीटर है

$s_i$ । फिर इस ऐरे से मान को दाईं ओर एक बिट शिफ्ट ऑपरेशन द्वारा 8 (जाहिरा तौर पर, पूरी तरह से) से विभाजित किया जाता है और इस डिवीजन के परिणामस्वरूप वैरिएबल को आरंभिक रूप दिया जाता है। फिर, इनपुट नमूने के मूल्य के तीन सबसे महत्वपूर्ण बिट्स का विश्लेषण किया जाता है और, उनके राज्यों के आधार पर, अलग-अलग चर को तीन शब्दों के साथ समायोजित किया जा सकता है। शब्द 4 (>> 2), 2 (>> 1) द्वारा अंतर मान का एक समान पूर्णांक विभाजन है या बिना परिवर्तन के अलग है (इसे सामान्यीकरण के लिए 1 से विभाजन करें)। फिर, इनपुट नमूने के मूल्य का सबसे महत्वपूर्ण (हस्ताक्षरित) बिट का विश्लेषण किया जाता है। इसकी स्थिति के आधार पर, इससे पहले उत्पन्न किया गया वैरिएबल वैरिएबल या परिवर्ती करंट को घटाया जाता है। यह आउटपुट नमूने का मूल्य होगा। शुद्धता के लिए, मान ऊपर और नीचे तक सीमित हैं। तब stepindex1 शून्य से साइन बिट रीसेट के साथ इनपुट नमूने के मूल्य के सूचकांक द्वारा ima_index_table सरणी से मूल्य जोड़कर समायोजित किया जाता है। Stepindex1 मान भी एक सीमा के अधीन हैं। बहुत अंत में, इस एल्गोरिथ्म को दोहराने से पहले, वर्तमान और स्टेपिंडेक्स मानों को वर्तमान 1 और स्टेपइंडेक्स 1 के बस पुनरावर्ती मूल्यों को सौंपा गया है, और एल्गोरिथ्म को फिर से दोहराया गया है।

आप यह समझने की कोशिश कर सकते हैं कि लगभग भिन्न चर कैसे बनता है, यह समझने के लिए। चलो

$f_i = f (s_i)$ । ये तर्क के प्रत्येक i-वें चरण के चरण चर के मान हैं, तर्क के फ़ंक्शन (सरणी) के मान के रूप में

$s_i$ जहाँ

$i = 0, 1, 2, \ dots$ । सुविधा के लिए, हम इस रूप में भिन्न चर को निरूपित करते हैं

$ड$ । ऊपर वर्णित तर्क के तर्क के बाद, हमारे पास है:

$d_i = \ frac {f_i} {8} + x ^ {(0)} _ i \ frac {f_i} {4} + x ^ {(1)} _ i \ frac {f_i} [2} + x ^ {( 2)} _ if_i,$

जहाँ

$x_i ^ {(0)}, x_i ^ {(1)}, x_i ^ {(2)}$ - एक संख्या के कम 3 बिट्स

$x_i$ । एक आम भाजक के लिए अग्रणी, हम इस अभिव्यक्ति को और अधिक सुविधाजनक रूप में बदलते हैं:

$d_i = \ frac {f_i} 8 \ Bigg (1 + 2x_i ^ {(0)} + 4x_i ^ {(1)} + 8x_i ^ {(2)} \ Bigg) =$

$= \ frac {f_i} 8 \ Bigg (1 + 2 \ Big (x_i ^ {(0)} + 2x_i ^ {(1)} + 4x_i ^ {(2)} \ Big) \ Big \ _) f_i} {8} (2x_i + 1)$

अंतिम रूपांतरण इस तथ्य पर आधारित है कि, एक अर्थ में, एक संख्या के कम से कम तीन बिट्स (0 या 1)

$x_i$ प्रस्तुत गुणांक के साथ इस संख्या का निरपेक्ष मान लिखने के अलावा कुछ और है, और संख्या का सबसे महत्वपूर्ण बिट

$x_i$ पूरी अभिव्यक्ति के संकेत से मेल खाएगा। सूत्र के अनुसार आगे

$y_ {i + 1} = y_i + d_i$

एक नए नमूना मूल्य की गणना पुराने के आधार पर की जाती है। इसके अलावा, एक नया चर मूल्य गणना की जाती है।

$एस$ :

$s_ {i + 1} = s_i + t (! x_i |)।$

सूत्र में मॉड्यूल इंगित करता है कि चर

$x_i$ कार्य करता है

$टी$ सबसे महत्वपूर्ण साइन बिट को छोड़कर, जो कोड में परिलक्षित होता है। एक समारोह

$टी$ तर्कों के अनुरुप ima_index_table सरणी का मान है।

सूत्र के विवरण में, मैंने ऊपर और नीचे प्रतिबंध संचालन की उपेक्षा की। कुल पुनरावृत्ति योजना कुछ इस प्रकार है:

$y_0; \ s_0; \ \ x_0, x_1, x_2, \ dots$

$d_i = \ frac {f (s_i)} {8} \ बड़ा (2x_i + 1 बड़ा +);$

$y_ {i + 1} = y_i + d_i \;$

$s_ {i + 1} = s_i + t (| x_i |) \;$

$i = 0, 1, 2, \ dots।$

ADPCM एन्कोडिंग / डिकोडिंग के सिद्धांत में बहुत गहराई से मैंने नहीं डाला। हालाँकि, ima_step_table array (89 पीस) के टेबल वैल्यू, ग्राफ पर उनके रिफ्लेक्शन को देखते हुए (नीचे दिया गया आंकड़ा देखें), जीरो लाइन के सापेक्ष सैंपल के प्रोबेबिलिस्टिक डिस्ट्रीब्यूशन का वर्णन करते हैं। व्यवहार में, यह आमतौर पर ऐसा होता है: नमूना शून्य रेखा के जितना करीब होता है, उतना ही अधिक होता है। इसलिए, एडीपीसीएम एक संभाव्य मॉडल पर आधारित है, और किसी भी तरह से 16-बिट पीसीएम नमूनों के किसी भी स्रोत को 4-बिट एडीपीसीएम नमूनों में सही ढंग से परिवर्तित नहीं किया जा सकता है। सामान्यतया, ADPCM एक चर परिमाणीकरण कदम के साथ PCM है। बस, जाहिरा तौर पर, यह चार्ट इस चर संस्करण को दर्शाता है। वह सही ढंग से चुना गया है, व्यवहार में ऑडियो डेटा के वितरण के कानून के आधार पर।

अब एवी कंटेनर की संरचना का वर्णन करने के लिए आगे बढ़ते हैं। वास्तव में, यह एक जटिल पदानुक्रमित संरचना है।

लेकिन, एक विशेष मामले के लिए कार्य को सरल बनाते हुए, मैंने एवी संरचना को एक रैखिक रूप में प्रस्तुत किया। इसका परिणाम यह है: एवी फ़ाइल में एक बड़े हेडर, शून्य स्किप बाइट्स (JUNK), ऑडियो और वीडियो स्ट्रीम का एक क्षेत्र (उनके हेडर और सामग्री आकार के साथ), और अनुक्रमित की एक सूची शामिल है। उत्तरार्द्ध विशेष रूप से, खिलाड़ी में वीडियो के माध्यम से स्क्रॉल करने के लिए कार्य करता है। इस सूची के बिना, स्क्रॉल करने से काम नहीं होगा (चेक किया गया)। यह केवल सामग्री की एक तालिका है, जो स्ट्रीम ब्लॉक की शुरुआत के सापेक्ष स्ट्रीम ब्लॉक के प्रमुख नामों (ब्लॉक हेडर में नामों का मिलान), सामग्री के संगत आकार और ऑफ़सेट्स (पते) के मूल्यों को सूचीबद्ध करती है।

अब आप कार्यक्रम के विकास के लिए आगे बढ़ सकते हैं। समस्या का एक विशिष्ट विवरण इस प्रकार है।

खंड X के मूल में: "DVR" निर्देशिका है। इस निर्देशिका में कई गैर-रिक्त उपनिर्देशिकाएँ (और केवल उपनिर्देशिकाएँ) हैं जो कुछ तिथियों के अनुरूप हैं। इनमें से प्रत्येक उपनिर्देशिका में विभिन्न नाम और विस्तार "264" के साथ कई फाइलें हैं। अनुभाग Y में आवश्यक: "DVR" निर्देशिका बनाएं, और इसमें खंड X के समान उपनिर्देशिकाएं हैं:। इनमें से प्रत्येक उपनिर्देशिका को समान नाम वाली फ़ाइलों के साथ भरें, लेकिन एक्सटेंशन के साथ "264" नहीं, बल्कि "एवी"। इन एवी फ़ाइलों को मूल 264 फाइलों से उन्हें प्राप्त करना चाहिए, जो, एक तरह से या किसी अन्य, एक मौजूदा कार्यक्रम के एल्गोरिथ्म को दोहराता है। प्रसंस्करण में सीधे वीडियो स्ट्रीम को रीमैच करना, ऑडियो स्ट्रीम को डिकोड करना, एवीआई फ़ाइल को प्रारूपित करना शामिल है। प्रोग्राम को कमांड लाइन से निम्नानुसार लॉन्च किया जाना चाहिए: "264toavi.exe X: Y:", जहां "264toavi.exe" प्रोग्राम का नाम है, "X:" स्रोत अनुभाग है, "Y:" गंतव्य अनुभाग है।

वास्तव में, कार्य को सरल बनाने के लिए, एक प्रोग्राम लिखना संभव था जो केवल एक फ़ाइल के रूपांतरण (रीपैकेजिंग) से निपटेगा, जिससे यह दो दिन हो जाएगा: इनपुट फ़ाइल का नाम और आउटपुट फ़ाइल का नाम। और फिर, केवल समूह के रीपैकेजिंग को लागू करने के लिए, आप अन्य उपकरणों का उपयोग करके कमांड बैच फ़ाइल (बैट) लिख सकते हैं, उदाहरण के लिए, एक्सेल। लेकिन मैंने एक पूरा कार्यक्रम लागू किया, बहुत बोझिल। स्रोत कोड पाठकों का ध्यान आकर्षित करने की संभावना नहीं है। मैं प्रोग्राम कोड की संरचना का वर्णन करूंगा।

कार्यक्रम देव-सी ++ में सी में WinAPI तत्वों के साथ विकास के माहौल में लिखा गया है। कार्यक्रम तीन बड़े सहायक कार्यों को कार्यान्वित करता है: प्रारंभिक एवी हेडर उत्पन्न करने का कार्य, एक ऑडियो नमूना डिकोडिंग का कार्य, और शब्दों द्वारा स्रोत फ़ाइल "264" को स्कैन करने का कार्य। शब्दों में, मैं 4 बाइट्स के एक हिस्से को कॉल करता हूं। यह देखा गया है कि हेडर के आकार और सभी धाराओं की सामग्री चार बाइट्स की एक बहु है। स्कैन फ़ंक्शन पांच मान लौटा सकता है: 0 - यदि यह रीपैकेजिंग के लिए वीडियो स्ट्रीम का सामान्य 4 बाइट्स है, तो 1 - यदि यह संदर्भ फ्रेम के वीडियो स्ट्रीम के ब्लॉक का हेडर है, 2 - यदि यह संपीड़ित फ्रेम के वीडियो स्ट्रीम के ब्लॉक का शीर्षक है, 3 - यदि यह ऑडियो स्ट्रीम ब्लॉक का हेडर है, तो - 4। "भ्रष्ट" ब्लॉक को पुनरावर्ती के दौरान नजरअंदाज किया जाना चाहिए। बहुत, बहुत दुर्लभ, लेकिन ऐसा हुआ। क्षतिग्रस्त ब्लॉक (जैसा कि मैंने इसे कहा जाता है) एक हेडर है जैसे "\ 0 \ 0 \ 0 \ 0H264", जहां "\ 0" शून्य बाइट है। नियमित रूप से repacker इस तरह के ब्लॉक को अनदेखा करता है। बेशक, इस तरह के ब्लॉक की सामग्री काफी काम कर सकती है, लेकिन मैं अपने प्रोग्राम को मानक के करीब लाने के लिए ऐसे ब्लॉक की उपेक्षा करता हूं।

मुख्य फ़ंक्शन में, निर्देशिकाओं को व्यवस्थित करने के अलावा, इनपुट फ़ाइल को स्कैन फ़ंक्शन द्वारा पढ़ा जाता है। इस फ़ंक्शन के वापस आने के आधार पर, आगे की क्रियाएं होती हैं। यदि ये वीडियो स्ट्रीम के हेडर हैं, तो आउटपुट एवी फाइल में संबंधित हेडर बनते हैं। वहां उन्हें अलग तरीके से कहा जाता है: "00db" संदर्भ फ़्रेम के वीडियो स्ट्रीम के ब्लॉक का शीर्षक है, और "00dc" संपीड़ित फ़्रेम के लिए है। नए नवे हुए हेडर से पहले रिपैकिंग ऑपरेशन (शब्दों को फिर से लिखना) के बाद, रीपैकेड कंटेंट के आकार की गणना की जाती है और इस मान को फ़ील्ड में लिखा जाता है जो उस स्ट्रीम के हेडर का तुरंत अनुसरण करता है जिसे अभी प्रोसेस किया गया है। यदि स्कैनिंग के दौरान एक ऑडियो स्ट्रीम हेडर सामने आता है, तो हेडर का नाम "03wb" आउटपुट एवी फ़ाइल में उत्पन्न होता है और ऑडियो स्ट्रीम ADPCM से PCM तक लूप में उसी समय डिकोड किया जाता है, जब एविडी फ़ाइल में डीकोड की गई सामग्री लिखी जाती है। उपरोक्त सभी के साथ, एक संक्षिप्त जानकारी (सामग्री की तालिका) एक अस्थायी सूचकांक फ़ाइल "सूचकांक" में दर्ज की गई है। आप एक स्कैन फ़ंक्शन नहीं कर सकते, लेकिन मुख्य फ़ंक्शन में सब कुछ लिखें। लेकिन तब कार्यक्रम बहुत बोझिल हो जाएगा और लगभग पढ़ना मुश्किल होगा।

पूरे ऑपरेशन के अंत में, जब इनपुट फ़ाइल "264" समाप्त हो गई है, तो नई फ़ाइल पर जाने से पहले, प्रोग्राम सक्षम रूप से सभी ऑपरेशनों को पूरा करता है। पहले, एवी फ़ाइल के हेडर में कुछ फ़ील्ड्स को समायोजित किया जाता है, जिनमें से मान पढ़ी गई धाराओं के आकार और संख्या पर निर्भर करते हैं, और फिर अस्थायी "इंडेक्स" फ़ाइल की सामग्री लगभग समाप्त हो गई एवी फ़ाइल से जुड़ी होती है, जिसे तब हटा दिया जाता है। इन ऑपरेशनों के बाद, आउटपुट एवी फ़ाइल प्लेबैक के लिए तैयार है।

जब प्रोग्राम चल रहा होता है, तो कमांड लाइन पर एक टेक्स्ट विज़ुअलाइज़ेशन होता है, जो वर्तमान निर्देशिका, फ़ाइल, साथ ही साथ वीडियो स्ट्रीम की ब्लॉक संख्या प्रति संदर्भ फ्रेम और वीडियो के संबंधित समय बिंदु को मिनट और सेकंड में प्रदर्शित करता है। और अगर इनपुट फ़ाइल में एक मनमाना नाम नहीं है, लेकिन मूल एक (जिसमें चैनल संख्या, दिनांक और समय रिकॉर्डिंग शुरू हो गई है), तो डेट-टाइम अंकगणित पर आधारित एक अधिक इंटरैक्टिव विज़ुअलाइज़ेशन होता है।

कार्यक्रम का परीक्षण और डिबगिंग करते समय, ध्वनि डिकोडिंग के साथ काम करते समय मुझे जो मुख्य समस्याएं थीं। साधारण अंकगणित सही ढंग से काम नहीं करता है, यदि डिकोडिंग फ़ंक्शन में चर की घोषणा करते समय, मैं सही प्रकार से टाइप नहीं करूंगा। इस वजह से, ऑडियो स्ट्रीम के कुछ ब्लॉक टूट गए थे, और कान से क्लिक थे। मूल 264 फ़ाइल के कुछ अयोग्य हेडर फ़ील्ड जिन्हें मैं समझ नहीं पाया था कि वे परिणाम के प्रति असंवेदनशील थे। एक नियमित कार्यक्रम के विपरीत, मेरा कार्यक्रम रिपैकिंग ऑपरेशन से अंतिम अपूर्ण प्रवाह ब्लॉक को बाहर नहीं फेंकता है। हालांकि, इसकी अनुपस्थिति कोई व्यावहारिक भूमिका नहीं निभाएगी। एक अन्य नियमित कार्यक्रम, खदान के विपरीत, "कचरा" की थोड़ी मात्रा के पीछे छोड़ देता है (यह अंतिम धारा की सामग्री है) अनुक्रमित के बाद एवी फ़ाइल के बहुत अंत में। इस सब के लिए, वीडियो लगभग एक जैसा ही चलता है। और कार्यक्रम नियमित कार्यक्रम के रूप में उसी अवधि के लिए रिपैकिंग करता है।

अंत में, मैं .264 फ़ाइल (विन्हेक्स हेक्स एडिटर में) के प्रवाह के संगठन के प्रदर्शन को दर्शाने वाला चित्र एक उदाहरण के रूप में फ़ाइलों में से एक का उपयोग करके और उसमें खोली गई रीपैकेड जी फ़ाइल के साथ रिफ़पैड प्रोग्राम की उपस्थिति को दिखाऊंगा। इस कार्यक्रम ने एवी फ़ाइल की संरचना के अध्ययन की प्रक्रिया को बहुत सरल कर दिया है। यह स्पष्ट रूप से पदानुक्रमित संरचना को प्रदर्शित करता है, संरचना के प्रत्येक सदस्य की बाइट सामग्री को दिखाता है, और यहां तक कि चतुराई से मापदंडों की सूची के रूप में हेडर की सामग्री की व्याख्या करता है। चित्र, विशेष रूप से, इस तथ्य को प्रदर्शित करता है कि वीडियो स्ट्रीम की सामग्री बिना बदलाव के ओवरराइट की गई है।

QCM-08DL डैशबोर्ड के लिए एक 264 एवी वीडियो कनवर्टर का विकास

More articles: