पेश है दुनिया का सबसे तेज VP8 डिकोडर: ffvp8

यहां तक ​​कि उस समय जब मैं VP8 की प्रारंभिक समीक्षा लिख रहा था, मैंने देखा कि आधिकारिक डिकोडर, libvpx , बहुत धीमा है। कोई विशेष कारण नहीं हैं कि यह एक अच्छा H.264 डिकोडर की तुलना में काफी तेज क्यों होना चाहिए, लेकिन यह भी इतना धीमा होने के लिए कुछ भी नहीं है! इसलिए मेरे पास रोनाल्ड बॉल्टजे और डेविड कॉनराड के साथ FFmpeg के लिए सबसे अच्छा संस्करण लिखने की योजना थी। डिकोडर के इस कार्यान्वयन को समुदाय द्वारा विकसित किया जाना था और यह शुरुआत से ही मुक्त था, मालिकाना कोड के डंप के विपरीत, जो कि libvpx लाइब्रेरी था। कुछ हफ़्ते पहले, डिकोडर libvpx के साथ वीडियो स्ट्रीम की द्विआधारी संगतता सुनिश्चित करने के लिए पर्याप्त रूप से पूर्ण था, जिसने इसे VP8 डिकोडर का पहला स्वतंत्र और मुफ्त कार्यान्वयन बना दिया । अब जब हमने अनुकूलन का पहला चक्र पूरा कर लिया है, तो इसे वास्तविक परिस्थितियों में उपयोग के लिए तैयार होना चाहिए। मैं बाद में विकास प्रक्रिया के विवरण के बारे में बात करूंगा, लेकिन अब इस पोस्ट के बहुत नमक पर चलते हैं: कोडेक प्रदर्शन के तुलनात्मक परीक्षण के परिणाम।



हमने दो 1080p क्लिप पर डिकोडर का परीक्षण किया: कंप्यूटर पर बनाया गया पार्कजॉय , शॉट लाइव और सिंटेल ट्रेलर । परीक्षण निम्नानुसार किया गया था:



time ffmpeg -vcodec {libvpx or vp8} -i input -vsync 0 -an -f null -







हमने इस पोस्ट के समय SVN से नवीनतम FFmpeg बिल्ड का उपयोग किया था, अंतिम संशोधन जिसमें VP8 डिकोडर ऑप्टिमाइज़ेशन r24471 था।











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



याद रखें कि ffvp8 का विकास वहाँ समाप्त नहीं होता है, हम इसे सुधारना और इसे गति देना जारी रखेंगे। हमारे पास अभी भी अनुकूलन की एक कतार है जो अभी तक मुख्य विकास शाखा में शामिल नहीं हुई है।

Ffvp8 विकास

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



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



मैंने x86 के लिए SIMD के साथ रोनाल्ड की मदद की, और अधिकांश गति क्षतिपूर्ति, आंतरिक भविष्यवाणी और उलटा रूपांतरों का हिस्सा भी लिखा। रोनाल्ड ने शेष उलटा रूपांतरण और गति क्षतिपूर्ति भाग लिखा। उन्होंने सबसे मुश्किल हिस्सा भी किया: डीबॉकिंग फ़िल्टर। ये फ़िल्टर हमेशा कठिन हिस्सा होते हैं, क्योंकि वे प्रत्येक कोडेक में भिन्न होते हैं। गति क्षतिपूर्ति का कार्यान्वयन, आमतौर पर अलग-अलग कोडेक्स में बहुत अलग नहीं होता है: 6-टैप फ़िल्टर किसी भी मामले में 6-टैप फ़िल्टर होगा, और अंतर केवल गुणांक में होता है।



SIMD डीबगिंग फ़िल्टर में सबसे बड़ी कठिनाई "अनपैकिंग" से बचने के लिए थी, अर्थात। 8 बिट्स से 16 तक संक्रमण। इस तरह के फिल्टर में कई ऑपरेशनों को शुरू में सटीकता के 8 बिट्स की आवश्यकता होती है। X86 के लिए एक सरल उदाहरण एब्स (एबी) है, जहां ए और बी 8-बिट अहस्ताक्षरित पूर्णांक हैं। परिणाम "अब" को एक संकेत के साथ 9 बिट्स की सटीकता की आवश्यकता होती है (क्योंकि यह -255 और 255 के बीच कहीं भी हो सकता है), इसलिए यह 8 बिट्स में फिट नहीं हो सकता है। लेकिन "अनपैकिंग" के बिना इस समस्या को हल करना काफी संभव है: (सत्सुब (ए, बी) | सत्सुब (बी, ए)), जहां "सत्सुब" दो मूल्यों के बीच संतृप्ति के साथ अंतर की गणना करता है। यदि अंतर सकारात्मक है, तो परिणाम वापस आ जाता है, अन्यथा यह शून्य है, इसलिए तार्किक या इन कार्यों के परिणामों के बीच प्रदर्शन करना हमें वही देता है जिसकी हमें आवश्यकता है। इसके लिए 4 x86 कोडांतरक निर्देशों की आवश्यकता होती है, "अनपैकिंग" के लिए वास्तविक "अनपैकिंग" और "पैकिंग" चरणों सहित कम से कम 10 की आवश्यकता होगी।



इसके बाद C कोड का SIMD ऑप्टिमाइज़ेशन हुआ, जिसके निष्पादन ने अभी भी डिकोडिंग समय का एक महत्वपूर्ण हिस्सा लिया। मेरी सबसे बड़ी आशाओं में से एक स्मार्ट प्रीफैच का जोड़ था, जो कैश मिस की संख्या को कम करता है। ffvp8 पूर्व-प्रश्न फ़्रेम वर्तमान एक ("PREVIOUS", "GOLD", और "वैकल्पिक लिंक") द्वारा संदर्भित किया जाता है, वे भी PREVIOUS, GOLD और ALTREF हैं), लेकिन केवल वे ही वास्तव में मूर्त रूप से इस फ्रेम में उपयोग किए जाते हैं। यह हमें उन सभी चीज़ों की प्री-क्वेरी करने की अनुमति देता है जिनकी हमें आवश्यकता है और जो हम उपयोग करने की संभावना नहीं है, उसका अनुरोध करने के लिए नहीं। libvpx, एक नियम के रूप में, उन फ़्रेमों को एनकोड करता है जो लगभग कभी नहीं (लेकिन इसे "कभी नहीं" के रूप में नहीं समझते हैं) GOLDEN या ALTREF फ्रेम का उपयोग करते हैं, इसलिए यह अनुकूलन कई वास्तविक वीडियो में पूर्व-अनुरोधों पर खर्च किए गए समय को काफी कम कर देता है। इसके अलावा, हमने कोड के विभिन्न स्थानों में इतनी अधिक अनुकूलन किया है कि हम उन सभी को यहां सूचीबद्ध नहीं कर सकते हैं, उदाहरण के लिए, डेविड द्वारा बनाए गए एन्ट्रापी डिकोडर का अनुकूलन। मैं इनमें से अधिकांश सुधारों के प्रदर्शन का परीक्षण करने में उनकी अमूल्य मदद के लिए एली फ्रीडमैन को धन्यवाद देना चाहूंगा।



आगे क्या है? अल्टिवेक असेंबली कोड ( PPC ) वस्तुतः अनुपस्थित है; डेविड की गति क्षतिपूर्ति कोड से कुछ ही विशेषताएं हैं। NEON ( ARM ) के लिए कोई असेंबली कोड बिल्कुल नहीं है, और हमें इसे जल्दी और मोबाइल डिवाइस पर काम करने की आवश्यकता है। बेशक, यह सब समय के साथ होगा, और, हमेशा की तरह, हम हमेशा पैच से खुश होते हैं!

आवेदन: नंगे नंबर

प्रति सेकंड फ़्रेम में और मानक त्रुटियों के साथ, ऊपर दिए गए ग्राफ़ के अनुरूप संख्याएँ इस प्रकार हैं :



कोर i7 620QM (1.6Ghz), विंडोज 7, 32-बिट:

पार्कजॉय ffvp8: 44.58। 0.44

पार्कजॉय libvpx: 33.06: 0.23

सिंटेल ffvp8: 74.26 v 1.18

सिंटेल libvpx: 56.11 ± 0.96



कोर i5 520M (2.4Ghz), लिनक्स, 64-बिट:

पार्कजॉय ffvp8: 68.29 p 0.06

पार्कजॉय लिबबॉक्स: 41.06: 0.04

सिंटेल ffvp8: 112.38। 0.37

Sintel libvpx: 69.64 el 0.09



कोर 2 T9300 (2.5Ghz), मैक OS X 10.6.4, 64-बिट:

पार्कजॉय ffvp8: 54.09 p 0.02

पार्कजॉय libvpx: 33.68: 0.01

सिंटेल ffvp8: 87.54 v 0.03

Sintel libvpx: 52.74 px 0.04



कोर डुओ (2Ghz), मैक ओएस एक्स 10.6.4, 32-बिट:

पार्कजॉय ffvp8: 21.31 p 0.02

पार्कजॉय libvpx: 17.96 lib 0.00

सिंटेल ffvp8: 41.24 v 0.01

सिंटेल libvpx: 29.65 el 0.02



एटम N270 (1.6Ghz), लिनक्स, 32-बिट:

पार्कजॉय ffvp8: 15.29 p 0.01

पार्कजॉय libvpx: 12.46: 0.01

सिंटेल ffvp8: 26.87 v 0.05

Sintel libvpx: 20.41 px 0.02

---

अनुवादक के नोट्स

कुछ शब्द मेरे लिए एक रहस्य बने हुए हैं, उदाहरण के लिए, यदि कोई मुझे 6-टैप फ़िल्टर का सही रूसी अनुवाद बता सकता है, तो मैं बहुत आभारी रहूंगा।



नीचे, टिप्पणी पर टिप्पणी में, लेखक पाठकों के कुछ सवालों के जवाब देता है, जिनमें से कुछ को मैंने यहां देना उचित समझा। यह सवालों और जवाबों का सीधा अनुवाद नहीं है, बल्कि उनके सार का सारांश है।



प्र: क्या ffvp8 libvpx में किए गए सुधारों का उपयोग कर सकता है?

ए: वास्तव में, सभी अनुकूलन जो दिलचस्प लग रहे थे, पहले से ही वहां से लिए गए हैं। लेकिन आपको यह समझने की आवश्यकता है कि स्रोत का एक सरल मर्ज पर्याप्त नहीं है, क्योंकि डिकोडर्स की वास्तुकला मौलिक रूप से अलग है।



प्रश्न: क्या कोई खतरा है कि ffvp8 libvpx प्रयोगात्मक विकास शाखा के साथ संगतता बनाए रखने में सक्षम नहीं होगा?

A: ऐसा कार्य इसके लायक नहीं है, क्योंकि इस समय प्रायोगिक शाखा वास्तविक परिस्थितियों में उपयोग के लिए अभिप्रेत नहीं है। यहां तक ​​कि वर्तमान libvpx के साथ प्रयोगात्मक शाखा की संगतता की गारंटी नहीं है।



प्रश्न: FFmpeg के विकास को कौन प्रायोजित करता है?

एक: पूरी परियोजना कोई भी नहीं है, लेकिन कुछ डेवलपर्स विशिष्ट ग्राहकों द्वारा आवश्यक सुविधाओं के कार्यान्वयन के लिए धन प्राप्त करते हैं। जहां तक ​​लेखक को पता है, ffvp8 का विकास पूरी तरह से गैर-लाभकारी था।



प्रश्न: प्रदर्शन में वृद्धि libvpx के एक प्रकार के वैश्विक नुकसान के कारण है, या यहाँ और वहाँ बहुत सारे अनुकूलन किए गए हैं?

ए: सामान्य तौर पर, बल्कि दूसरा। लेकिन मुख्य प्रदर्शन लाभ इस तथ्य के कारण था कि libvpx फ्रेम के माध्यम से कई बार गुजरता है (सभी पिछले On2 कोडक भी ऐसा ही करते हैं), और ffvp8 सभी ऑपरेशन एक पास में करता है।



प्रश्न: क्या आप FFmpeg में अपना VP8 एनकोडर विकसित करने की योजना बना रहे हैं?

A: यह एक बहुत बड़ा काम है, और ईमानदार होने के लिए, मुझे संदेह है कि यह कभी भी किया जाएगा। वास्तव में, FFmpeg का एकमात्र "देशी" एनकोडर mpeg एनकोडर है, और मौजूदा फ्रेमवर्क के आधार पर VP8 एनकोडर बनाने का शायद ही कोई तरीका हो, किसी भी स्थिति में, यह विधि सरल नहीं होगी। लेकिन निश्चित रूप से, अगर कोई कोशिश करना चाहता है ...



प्रश्न: लेकिन यदि केवल देशी एनकोडर के एफएफएमपी के लिए एमपीईजी है, तो यह लाइब्रेरी न केवल एमपीईजी में, बल्कि WMV 7/8, H.261 / 3 और अन्य प्रारूपों में अन्य पुस्तकालयों का उपयोग किए बिना वीडियो एन्कोडिंग का समर्थन कैसे करती है?

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

यह, वैसे, FFmpeg में WMV9 एनकोडर की कमी की व्याख्या करता है - यह एल्गोरिथ्म पिछले संस्करणों से बहुत अलग है जिसे आसानी से लागू किया जा सकता है।



Q: Ffvp8 VP4, 5, 6 और 7 को भी डिकोड कर सकता है?

A: हो सकता है, लेकिन केवल VP4, 5 और 6, क्योंकि किसी ने भी अभी तक VP7 को रिवर्स-इंजीनियर नहीं किया है। लेकिन, सबसे अधिक संभावना है, VP7 समर्थन निकट भविष्य में दिखाई देगा, VP8 के उद्घाटन को देखते हुए, क्योंकि मुझे संदेह है कि VP7 और VP8 ज्यादातर समान हैं।



प्रश्न: मुझे नए विंडोज डिकोडर पर खुद के लिए देखने के लिए मीडिया प्लेयर क्लासिक होमकिनिमा और एफएफडॉश ट्राउट की ताजा एसवीएन असेंबली कहां मिल सकती है?

के बारे में: xhmikosr.1f0.de



यदि आपके पास नोट के लेखक के लिए कोई प्रश्न है, तो मैं उनका अनुवाद करने और अपने ब्लॉग में प्रकाशित करने के लिए तैयार हूं।