मैं इस लेख को पढ़ रहा था और मैंने देखा कि एक सीपीयू से वीडियो संपीड़न के लिए सीपीयू बेहतर है।
लेख केवल यह कहता है कि ऐसा इसलिए होता है क्योंकि प्रोसेसर GPU से अधिक जटिल एल्गोरिदम को संभाल सकता है, लेकिन मुझे अधिक तकनीकी स्पष्टीकरण चाहिए, मैंने इंटरनेट पर कुछ खोज की लेकिन मुझे कुछ भी नहीं मिला।
तो, किसी को समझाने के लिए या किसी साइट को लिंक करने के लिए पता है जो मुझे इस बारे में अधिक गहराई से समझा गया था?
जवाबों:
आपके द्वारा जोड़ा गया लेख बहुत अच्छा नहीं है।
आम तौर पर, एकल पास बिटरेट एन्कोडिंग आपकी बिटरेट को अधिकतम बिटरेट सीमा के साथ एक आरएफ मान में परिवर्तित करता है और इसे वहां से ले जाता है।
x264 का एक-पास ABR रेटकंट्रोल CRF + सीमा के रूप में लागू नहीं किया गया है। वह सही है कि 2 बाईपास लक्ष्य बिटरेट को हिट करने का सबसे अच्छा तरीका है, हालांकि।
और वह स्पष्ट रूप से महसूस नहीं करता है कि वह x264 को थ्रेड = 3 या कुछ के साथ शुरू कर सकता है, अन्य कार्यों के लिए कुछ सीपीयू समय मुक्त करने के लिए। या बहुत कम करने के लिए x264 की प्राथमिकता निर्धारित करें, इसलिए इसे केवल सीपीयू समय मिलता है जो कोई अन्य कार्य नहीं चाहता है।
वह CUDA, या कुछ का उपयोग करके थ्रेड = 1 को भी मिलाता है। कोई आश्चर्य नहीं कि आपके पास प्रश्न हैं, क्योंकि उस लेख में एक स्पष्ट विवरण है। पूरा लेख मूल रूप से उबलता है: उपयोग x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv, या शायद इनपुट एविसिंथ स्क्रिप्ट के साथ कुछ प्रकाश फ़िल्टरिंग का उपयोग करें। वह वास्तव में "प्लेसबो" की सिफारिश करता है। यह प्रफुल्लित करने वाला है। मैंने प्लेसीबो के साथ कभी भी पायरेटेड फ़ाइल को एनकोडेड नहीं देखा है। (आप से बता सकते हैं me=esaया me=tesa, के बजाय me=umhसभी अच्छी गुणवत्ता प्रीसेट के लिए, सही करने के लिए veryslow।
उन्होंने यह भी 10bit रंग गहराई का उपयोग कर उल्लेख नहीं करता है। सांकेतिक शब्दों में बदलना और डिकोड करने के लिए धीमा, लेकिन वापस 8bit में नीचे बदलने के बाद भी, आप बेहतर 8-बिट SSIM प्राप्त करते हैं। मोशन वैक्टर के लिए अधिक सटीक होने से स्पष्ट रूप से मदद मिलती है। इसके अलावा, बिल्कुल 8 बिट मूल्य के लिए राउंड ऑफ नहीं होने से मदद मिलती है। आप गति-हैक के रूप में प्रति घटक 8-बिट के बारे में सोच सकते हैं; आवृत्ति-डोमेन में परिमाणित करना और फिर CABAC के साथ संपीड़ित करने का मतलब है कि उच्च बिट गहराई गुणांक को अधिक स्थान नहीं लेना है।
(BTW, h.265 को 8-बिट वीडियो के लिए 10-बिट एन्कोड से कम लाभ मिलता है, क्योंकि इसमें पहले से ही मोशन वैक्टर के लिए अधिक सटीक है। यदि 8-बिट वीडियो इनपुट के लिए 10-बिट x265 का उपयोग करने का लाभ है, तो यह उससे छोटा है। x264 के साथ। इसलिए यह संभावना कम है कि गति दंड इसके लायक होगा।)
संपादित करें: doom9 अब फिर से है, इसलिए मैं लिंक को व्यवस्थित करूंगा। किसने क्या कहा उचित उद्धरण के लिए इसके पास जाएं।
http://forum.doom9.org/showthread.php?p=1135399#post1135399
Google केवल बेवकूफ प्रिंट संस्करण को कैश करता है जो ठीक से उद्धरण नहीं दिखाता है। मुझे पूरा यकीन नहीं है कि इन संदेशों के कौन से हिस्से उद्धरण हैं, और जिनका श्रेय खुद उस व्यक्ति को जाता है।
अत्यधिक अनियमित ब्रांचिंग पैटर्न (मोड छोड़ें) और बिट हेरफेर (मात्रा का ठहराव / एन्ट्रापी कोडिंग) वर्तमान जीपीयू के अनुरूप नहीं है। IMO इस समय एकमात्र बहुत अच्छा अनुप्रयोग है, पूर्ण खोज ME एल्गोरिदम, अंत में हालांकि त्वरित पूर्ण खोज अभी भी धीमी है, भले ही यह सीपीयू से तेज हो।
- MfAवास्तव में, मूल रूप से सब कुछ GPU पर CABAC को छोड़कर किया जा सकता है (जो किया जा सकता है, यह सिर्फ समानांतर नहीं किया जा सकता)।
x264 CUDA एक फुलपेल और सबपेल ME एल्गोरिथ्म को शुरू में लागू करेगा; बाद में हम CABAC के बजाय बिट-कॉस्ट सन्निकटन के साथ RDO जैसा कुछ कर सकते थे।
क्योंकि इसे एकल परिशुद्धता फ्लोटिंग पॉइंट
- MfA पर सब कुछ करना हैगलत, CUDA पूर्णांक गणित का समर्थन करता है।
- डार्क शिकारी
डार्क शिकारी x264 अनुरक्षक है, और 2007 या उसके बाद से अधिकांश विशेषताओं का डेवलपर है।
AFAIK, इस CUDA परियोजना ने पैन नहीं किया। ओपनहेड थ्रेड से कुछ काम को बंद करने के लिए ओपनसीएल का उपयोग करने के लिए समर्थन है (त्वरित I / P / B निर्णय, फ्रेम का एक उच्च गुणवत्ता वाला अंतिम एनकोड नहीं)।
मेरी समझ यह है कि वीडियो एन्कोडिंग के लिए खोज स्थान SO इतना बड़ा है कि CPU पर खोज पथों की शीघ्र समाप्ति के लिए स्मार्ट उत्तराधिकारियों ने मूक-बल के GPU को मेज पर लाकर, कम से कम उच्च गुणवत्ता वाले एन्कोडिंग के लिए हरा दिया। यह केवल उसी जगह की तुलना में है -preset ultrafastजहाँ आप यथोचित रूप से x264, HW पर HW एन्कोडिंग का चयन कर सकते हैं। अगर आपके पास एक धीमा सीपीयू है (जैसे डुअल कोर वाला लैपटॉप और कोई हाइपरथ्रेडिंग नहीं)। एक तेजी से सीपीयू (हाइपरथ्रेडिंग के साथ i7 क्वाड कोर) पर, x264 superfastशायद उतना ही तेज होगा, और बेहतर (एक ही बिटरेट पर) दिखाई देगा।
यदि आप एक सांकेतिक शब्दों में बदलना कर रहे हैं जहां दर-विरूपण (फ़ाइल आकार के अनुसार गुणवत्ता) सभी पर मायने रखती है, तो आपको x264 -preset mediumया धीमे का उपयोग करना चाहिए । यदि आप किसी चीज़ को संग्रहित कर रहे हैं, तो थोड़ा अधिक सीपीयू समय बिताने से बाइट्स को तब तक बचाएंगे जब तक आप उस फ़ाइल को इधर-उधर रख रहे हैं।
ध्यान दें, यदि आप कभी वीडियो मंच पर डेडरेट्स के संदेश देखते हैं, तो यह उपयोगी नहीं होगा। वह सबसे अधिक सामान के बारे में गलत है जिसे वह हर उस धागे के बारे में बात कर रहा है जो मैंने कभी देखा है। उनके पोस्ट एक युगल सूत्र में बदल गए, जिन्हें मैंने x264 GPU एन्कोडिंग के बारे में बताया। जाहिर तौर पर वह समझ नहीं पाता कि यह आसान क्यों नहीं है, और कई बार पोस्ट किया है कि x264 डेवलपर्स को बताएं कि वे गूंगे क्यों हैं ...
2017 अपडेट:
ffmpeg h264 और h265 NVENC GPU- त्वरित वीडियो एन्कोडिंग का समर्थन करता है । आप उस गुणवत्ता पर 1-पास या 2-पास एन्कोडिंग कर सकते हैं जिसे आप चुनते हैं, या तो hevc_nvenc या h264_nvenc के लिए, या यहां तक कि एक एंट्री-लेवल GPU के साथ यह गैर-त्वरित एन्कोडिंग और इंटेल त्वरित त्वरित त्वरित एन्कोडिंग की तुलना में बहुत तेज़ है।
2-उच्च गुणवत्ता वाले एन्कोडिंग:
ffmpeg -i in.mp4 -vcodec h264_nvenc -preset slow out.mp4
1-पास डिफ़ॉल्ट एन्कोडिंग:
ffmpeg -i in.mp4 -vcodec h264_nvenc out.mp4
NVENC ffmpeg मदद और विकल्प:
ffmpeg -h encoder=nvenc
इसका उपयोग करें, यह सीपीयू एन्कोडिंग की तुलना में बहुत तेज है।
यदि आपके पास GPU नहीं है तो आप Intel Quick Sync कोडेक, h264_qsv, hevc_qsv, या mpeg2_qsv का उपयोग कर सकते हैं, जो गैर-त्वरित एन्कोडिंग की तुलना में बहुत तेज़ हैं।
ffmpegकरने -vcodec h264_qsvसे प्रतिपादन बहुत तेज हो गया!
पीटर जो कहते हैं, उस पर थोड़ा और विस्तार करने के लिए, सामान्य रूप से कई प्रोसेसर का उपयोग करने से उन मामलों में मदद मिलती है जहां आपके पास कई स्वतंत्र कार्य हैं जो सभी करने की आवश्यकता है, लेकिन एक दूसरे पर निर्भरता नहीं है, या एक कार्य जहां आप एक ही प्रदर्शन कर रहे हैं भारी मात्रा में डेटा पर गणित।
यदि, हालांकि, आपको गणना B के इनपुट के रूप में गणना A के आउटपुट की आवश्यकता है, और गणना C के इनपुट के रूप में गणना B के आउटपुट की आवश्यकता है, तो आप प्रत्येक कार्य पर एक अलग मूल कार्य करके इसे गति नहीं दे सकते ( A, B, या C) क्योंकि एक दूसरे के खत्म होने तक शुरू नहीं हो सकता है।
हालांकि, उपरोक्त मामले में भी, आप इसे दूसरे तरीके से समानांतर करने में सक्षम हो सकते हैं। यदि आप अपने इनपुट डेटा को विखंडू में तोड़ सकते हैं, तो आपके पास A करने पर एक कोर काम हो सकता है, फिर B, फिर C एक डेटा के साथ, जबकि A, फिर B पर एक और कोर काम करता है, तो C एक अलग डेटा पर ।
अन्य विचार भी हैं। हो सकता है कि आपको गणनाओं को समानांतर करने का एक तरीका मिल जाए, लेकिन बस डिस्क, या नेटवर्क पर डेटा पढ़ना, या इसे GPU पर भेजना गणना करने में अधिक समय लगेगा। उस स्थिति में, इसे समानांतर करने का कोई मतलब नहीं है क्योंकि सिर्फ मेमोरी में डेटा प्राप्त करने से आपको गणना में समानांतर रूप से बचत करने में अधिक समय लगता है।
दूसरे शब्दों में, यह एक कला जितना ही एक विज्ञान है।
-c:v libx264 -preset slowerनहीं पाएंगे (जो कि धीमी नहीं है, जैसे कि स्काइलेक i7-6700k पर 1920x1080p24 के लिए रियलटाइम के पास।)