संपीड़ित वीडियो और भी बड़ी फ़ाइल बनाते हैं


17

मैं GUI (राइट क्लिक => कंप्रेस) का उपयोग कर रहा हूं। 1.7gb (.H264 MP4s) कुल 3 वीडियो वाले .tar को ट्राइ और सेक करने के लिए। gzip, lrzip, 7z आदि सभी फ़ाइल के आकार के लिए कुछ नहीं करते हैं और संपीड़ित फ़ोल्डर भी 1.7 gb है।

मैंने तब कमांड लाइन से lrzip चलाने की कोशिश की (मामले में यह एक गुई समस्या थी), और -z ध्वज (चरम संपीड़न) का इस्तेमाल किया, और यह मेरा आउटपुट था।

यहां छवि विवरण दर्ज करें

जैसा कि सम्पीडन अनुपात दिखाता है, संकुचित फ़ोल्डर का वास्तविक आकार मूल से बड़ा है! मुझे नहीं पता कि मुझे कोई भाग्य क्यों नहीं है, विशेष रूप से lrzip यादृच्छिक समीक्षाओं के अनुसार प्रभावी होना चाहिए जो मैंने पढ़ा है और आधिकारिक डॉक्स (100mb से अधिक बड़ी फाइलें, जितना बड़ा बेहतर) - देखें https: //wiki.archlinux। org / index.php / Lrzip

मैं अपनी फ़ाइलों को संपीड़ित क्यों नहीं कर सकता / सकती?


2
व्यक्तिगत रूप से मैं mp4 वीडियो संग्रह करने से परेशान नहीं करूँगा क्योंकि उन वीडियो पहले से ही कोडेक द्वारा संकुचित हैं।
प्राम

और आप FFMpeg जैसे वीडियो कनवर्टर / कंप्रेसर टूल का उपयोग करके कम आकार प्राप्त कर सकते हैं ।
जेट

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

जवाबों:


25

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

एक अन्य नोट पर, यदि आप उन वीडियो के आकार को कम करना चाहते हैं, तो हैंडब्रेक जैसी किसी चीज़ का उपयोग करके वीडियो को पुन: एन्कोडिंग करने के बजाय देखें।


3
मुझे लगता है कि webm में सामान्य रूप से अच्छी संपीड़न दरें हैं। Mp4 से बहुत छोटा है।
सेठ

@Seth वास्तव में MP4 (जो या तो AVC उर्फ ​​h.264 है या नया और बेहतर h.265 उर्फ ​​HEVC कोडेक) एक ही गुणवत्ता (या एक ही फ़ाइल आकार में बेहतर गुणवत्ता) में छोटी फ़ाइलें देता है।
डेविड बालैसिक जूल

@ डेविडबेलिक हम सेब और सेब की तुलना यहाँ कर रहे हैं, जब हम संतरे के बारे में बात करना चाह रहे हैं। mp4 और webm दोनों कंटेनर हैं, उनका कम्प्रेशन से कोई लेना-देना नहीं है। आप रहे हों तो सही है कि 264 और H.265 mp4 कंटेनरों में दोनों आमतौर पर इस्तेमाल किया codecs हैं, लेकिन आप के लिए H.265 तुलना नहीं कर सकते webm । h.264 आमतौर पर webm कंटेनरों में उपयोग किए जाने वाले vp8 कोडेक के लिए तुलनीय है, जिस तरह h.265 vp9 कोडेक के लिए तुलनीय है, जो आमतौर पर webm द्वारा समाहित है। tl; dr; वेब में h.265 को mp4 और vp9 में उपयोग करें और आपको लगभग समान गुणवत्ता / दक्षता मिलेगी।
forresthopkinsa

13

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

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


12

आपके पास कोई भाग्य नहीं होने का कारण यह है कि mp4 पहले से ही संपीड़ित है, आप इसे आगे संपीड़ित नहीं कर सकते। आप जो कुछ भी कर रहे हैं वह संपीड़न प्रारूप की हेडर जानकारी को फ़ाइल में जोड़ रहा है।

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


5

यह कबूतर के सिद्धांत का एक अच्छा उदाहरण है ।

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


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

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

@ लिवियस विकिपीडिया लेख सही है: यह किसी भी दोषरहित संपीड़न एल्गोरिथ्म के लिए असंपीड़ित फ़ाइलों के अस्तित्व को साबित करने के लिए कबूतर सिद्धांत का उपयोग करता है। लेकिन आप किसी विशेष फ़ाइल की अक्षमता को केवल कबूतर सिद्धांत से प्राप्त नहीं कर सकते।
डेविड रिचरबी

@DavidRicherby हां, लेकिन यह तथ्य कि फ़ाइल किसी दिए गए एल्गोरिदम के दिए गए कार्यान्वयन से संकुचित नहीं है, यह इस बात का प्रमाण है कि यह संपीड़ित नहीं है। जब तक असंगत फ़ाइलों के अस्तित्व के अन्य कारण नहीं होते हैं, तब यह निम्नानुसार होता है कि संपीड़ित करने की विफलता पीपी के कारण होती है। केवल एक अन्य संभावित कारण यह होगा कि किसी दिए गए एल्गोरिथ्म को उसके आकार को कम करने का कोई तरीका नहीं दिखता है, जो फिर से "एल्गोरिथम की मान्यताओं के तहत" का मामला लगता है, समान जानकारी के साथ कोई छोटी फ़ाइल नहीं है; पीपी के कारण "।
लिवियस

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

4

यदि आप इन फ़ाइलों को संपीड़ित करना चाहते हैं, तो आपको गुणवत्ता कम करनी होगी

बिना ये जाने कि ये फाइलें कितने समय तक और किस प्रारूप और सामग्री के साथ हैं, यह बताने में मुश्किल है कि क्या इन फाइलों में बहुत अधिक गुणवत्ता वाले नुकसान के बिना कमरे को सिकोड़ना है।

1080p वीडियो के साथ BluRays 25GB से ऊपर हो जाता है, इसलिए इसकी संभावना नहीं है कि आप पहले से ही H.264 के लिए एक इष्टतम गुणवत्ता-से-आकार के अनुपात में हैं।

आप फ़ाइलों का उपयोग करके ffmpegया avconvपरिवर्तित करने का प्रयास कर सकते हैं ।

आप के साथ शुरू कर सकते हैं ffmpeg -i input_file.mp4 -preset slower -crf 20 -c:a copy output_file.mp4

anconvआदेश समान ही कार्य करेंगी।

  • -crfफ़ाइल आकार और गुणवत्ता को कम करने के लिए मूल्य बढ़ाएं , मैं 25 से अधिक की सिफारिश नहीं करता हूं।

  • आप प्रीसेट को बदल सकते हैं slowया mediumगति बढ़ा सकते हैं , लेकिन आपकी फ़ाइल का आकार ( slowerया veryslowयदि आप बहुत रोगी हैं) की तुलना में पीड़ित होंगे ।

  • अधिक सेटिंग्स यहां देखी जा सकती हैं: http://mewiki.project357.com/wiki/X264_Settings

  • मैं सबसे अधिक से दूर रहने की सलाह देता हूं क्योंकि प्रीसेट -tuneअपवाद होने के साथ साने चूक प्रदान करते हैं।

  • एक Denoiser प्रयास करें यदि आप सामग्री फिल्म है ( -vf hqdn3d) आप एक उच्च उपयोग की तुलना में दृश्य गुणवत्ता में सुधार कर सकते -crfमूल्य।

  • एन्कोडिंग की गति में सुधार और गुणवत्ता बनाए रखने के -vf scale=-1:720लिए 720p के लिए और -vf scale=-1:480480p के लिए अपनी सामग्री को नीचे रखें।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.