परीक्षण वीडियो कोडेक। एपिसोड II: एनकोडर्स अटैक

हम वीडियो कोडेक्स के परीक्षण के रहस्यों को सीखना जारी रखते हैं। इस बार, एनकोडर के बारे में बात करते हैं।
पहले भाग का लिंक


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

मॉस्को स्टेट यूनिवर्सिटी के लोगों द्वारा महान तुलनाएं की जाती हैं, आप यहां देख सकते हैं: संपीड़न

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

यह तीसरे पक्ष के टूल द्वारा सबसे अच्छा किया जाता है - इसलिए तीसरे पक्ष के उपयोगकर्ताओं के लिए रेटिंग में विश्वास अधिक है।

लेकिन पहल हमेशा दंडनीय नहीं है: एक इच्छा है - आप फ़ाइल को इसके घटकों में पार्स भी कर सकते हैं और सब कुछ डबल-चेक कर सकते हैं। यह सुनिश्चित करने के लिए भी किया जाना चाहिए कि हमारे एनकोडर ने सभी मापदंडों को उस तरह से रिकॉर्ड किया जिस तरह से हम चाहते थे, और किसी भी तरह से नहीं। बेशक, इस मामले में हम "knobs" तक सीमित हैं कि हम एनकोडर सेटिंग्स में "चिकोटी" कर सकते हैं।

X264 प्रशंसकों को कम स्विच के साथ रखना होगा

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

दोहरी त्रुटियों से बचने के लिए अधिमानतः तृतीय-पक्ष, संदर्भ

जिसकी मदद से हमें एक असम्पीडित वीडियो अनुक्रम मिलता है जिसकी तुलना हम मूल मैट्रिक्स के साथ कर सकते हैं जिसका उपयोग हम पहले से ही जानते हैं - PSNR और SSIM।
हालाँकि, हम यहाँ एक महत्वपूर्ण प्रश्न पर आते हैं: वीडियो की "समानता" की सीमा क्या होनी चाहिए? दूसरे शब्दों में, कौन से PSNR / SSIM मूल्य हमें संतुष्ट करते हैं और कौन से नहीं? सामान्य तौर पर, अच्छा तब होता है जब वह बुरा न हो, अर्थात कोई कलाकृतियाँ, विकृतियाँ और सब कुछ नहीं है जो आँख को पसंद नहीं है। और यह अच्छा है अगर हमारे मेट्रिक्स ने इसे पकड़ लिया। गुप्त स्थान पर वांछित संख्या लिखना न भूलें और अगले चेक के दौरान इसका उपयोग करें - और अचानक कुछ टूट गया। लेकिन "ब्रेकिंग" अलग-अलग तरीकों से किया जा सकता है।
तो, मान लें कि कल हमारे एनकोडर ने Y बिटरेट पर X dB दिया (हम एक निरंतर बिटरेट के साथ सांकेतिक शब्दों में बदलना होगा)

हम अन्य सभी मापदंडों को ध्यान में नहीं रखेंगे, हम उन्हें निश्चित छोड़ देंगे

आज, हमारे एनकोडर एक ही बिटरेट पर X1 dB का उत्पादन करते हैं। क्या हो रहा है? हम अलार्म ध्वनि? मिनट, लेकिन X X से बड़ा है? यदि ऐसा है, तो सब कुछ ठीक है, एनकोडर बेहतर काम करना शुरू कर दिया! या नहीं? सब कुछ उतना सरल नहीं है जितना हम चाहेंगे: जब एक निरंतर बिटरेट का उपयोग करते हुए कोई गारंटी नहीं है कि यह वास्तव में स्थिर होगा - मामूली विचलन संभव हैं (दोनों दिशाओं में)। अब कल्पना करें कि बढ़ी हुई बिटरेट के कारण माना जाता है कि उच्चतर गुणवत्ता है। और इसका मतलब यह है कि कोई वास्तविक सुधार नहीं है: एनकोडर "धोखा" अधिक बिट्स ले रहा है, जो कि गुणवत्ता में सुधार करता था। इसके अलावा, एक्स की तुलना में एक्स 1 के मूल्य में कमी एनकोडर के बिगड़ने का संकेत नहीं देती है - शायद यह हमारे बिट्स को बचाता है। नैतिक: अधिक का मतलब बेहतर नहीं है, कम का मतलब बुरा नहीं है।

लेकिन हम सभी चित्र गुणवत्ता के बारे में क्या हैं? डिकोडर्स के बारे में भी सोचने का समय है, फिर उन्हें इन सभी एनकोडेड ड्रेग्स को अलग करना चाहिए। क्या एनकोडर ने सभी आवश्यक मापदंडों को धारा में डाल दिया? क्या उसने उन्हें सही किया? क्या आपने वर्णित मानक में सभी आवश्यकताओं और आवश्यकताओं का अनुपालन किया है?

यह सब और बहुत कुछ जांचा, डबल-चेक किया जाना चाहिए, और फिर स्पष्ट किया जाना चाहिए। और इसलिए हर बार, हर एनकोडर के साथ। लेकिन हम पहले ही इस बारे में थोड़ी बात कर चुके हैं, हम इस पर ध्यान नहीं देंगे

और ऐसा लगता है कि इस पर सब कुछ समाप्त हो सकता है, लेकिन एक बात है लेकिन: हमारे पास एक ही एसडीके है! इसका मतलब है कि मेमोरी, थ्रेड्स और अन्य सभी चीजों के साथ काम करने के लिए जो उपयोगकर्ता बदल सकते हैं, सभी विकल्पों की जांच होनी चाहिए। सिद्धांत रूप में, ज्यादातर मामलों में, एसडीके का उपयोग करने के सभी तरीकों का एक ही परिणाम होना चाहिए।

ठीक है, सच्चाई यह है कि यदि उपयोगकर्ता सिस्टम मेमोरी के बजाय डी 3 डी मेमोरी का उपयोग करता है, तो गुणवत्ता को क्यों नुकसान उठाना चाहिए? या अतुल्यकालिक की गहराई को बदल दिया जाता है। या उन्होंने अधिक (या कम) थ्रेड्स का उपयोग करने का निर्णय लिया।

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

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

युपीडी
वीडियो प्री-प्रोसेसिंग टेस्टिंग दृष्टिकोण की समीक्षा के बारे में लेख ISN पर पढ़ा जा सकता है