दोषरहित सार्वभौमिक वीडियो प्रारूप


14

मैं 1280x720 25fps वीडियो के लिए सबसे उपयुक्त दोषरहित वीडियो प्रारूप खोजने की कोशिश कर रहा हूं । वीडियो में 4 मिनट हैं। साउंड 320 केबीपीएस एमपी होगा, यह कोई बड़ी बात नहीं है। आदर्श स्थिति:

  • दोषरहित (अवधारणात्मक दोषरहित हो सकता है)
  • कंटेनर + कोडेक अधिकांश प्लेटफार्मों पर खेला जा सकता है
  • कंटेनर + कोडेक आधुनिक डीवीडी प्लेयर पर खेला जा सकता है (डीवीडी के अलावा अन्य स्वरूपों का समर्थन)
  • आकार 700 एमबी से कम है

क्या यह भी संभव है? तीन दिन पहले से ही संघर्ष कर रहे हैं, बिना किसी संतोषजनक परिणाम के, यहां तक ​​कि 12 जीबी फाइलें भी मिल रही हैं (बहुत कुछ लगता है - 3 जीबी / मिनट)।



4
मुझे क्षमा करें, लेकिन आप व्यावहारिक रूप से 700 एमबी से कम समय के लिए संकुचित 4 मिनट का एक (नेत्रहीन) 720p वीडियो नहीं प्राप्त कर सकते हैं (मैंने यहां मेगाबाइट मान लिया, न कि "एमबी" जिसका अर्थ "बिट" होगा)। आपके पास ऐसी अड़चन क्यों है? क्या विडियो h.264- एन्कोडेड नहीं हो सकता है?
slhck

हाँ, एमबी, भ्रम के बारे में खेद है। मुझे cca 5 वीडियो x 4 मिनट को 4 GB (मध्यम सीमा) में फिट करने की आवश्यकता है।
मर्कवा

2
चूंकि आपको 12GiB फाइलें मिल रही हैं, इसलिए मुझे लगता है कि आप 24 बिट रंग की गहराई का उपयोग करते हैं। असम्पीडित वीडियो डेटा स्ट्रीम प्रति मिनट 4GiB के बारे में है। यह डेटा की एक बड़ी राशि है। आप जो चाहते हैं वह प्रति मिनट 170MiB है। आपके द्वारा चुने गए कोडेक के बावजूद, आप इसे केवल एक स्थिर दृश्य के साथ ज्यादा आंदोलन के बिना प्राप्त कर सकते हैं। मुझे डर है कि आपको दोषरहित होने के लिए गर्भनाल को आराम करना होगा, फ्रेम दर को कम करना होगा या बड़े फ़ाइल आकार को सहन करना होगा।
मार्को

क्या आप स्पष्ट कर सकते हैं, "कंटेनर + कोडेक आधुनिक डीवीडी प्लेयर (डीवीडी की तुलना में अन्य स्वरूपों का समर्थन) पर खेला जा सकता है"?
ल्लगन

जवाबों:


24

सबसे अच्छा वास्तविक, गणितीय रूप से दोषरहित प्रारूप जो मुझे पता है कि हफ़्फ़ुवि है, लेकिन वह प्रफुल्लित करने वाली विशाल फ़ाइलों का उत्पादन करेगा, और बहुत कुछ के साथ संगत नहीं होगा। रिकॉर्ड के लिए, ffmpeg के साथ कर सकते हैं:

ffmpeg -i input -c:v huffyuv -c:a libmp3lame -b:a 320k output.avi

X264, ओपन-सोर्स h.264 एनकोडर, एक दोषरहित मोड है। यह एक MP4 कंटेनर के अंदर जा सकता है, और पिछले कुछ वर्षों में बनाए गए अधिकांश हार्डवेयर के साथ संगत होना चाहिए। पहला कमांड एक तेज एनकोड स्पीड देगा, लेकिन बड़ी फाइल; दूसरी कमांड में बहुत अधिक समय लगेगा, लेकिन फ़ाइल फास्ट-एन्कोडेड के आकार का लगभग आधा होना चाहिए (हालांकि यह अभी भी बहुत बड़ा होगा):

ffmpeg -i input -c:v libx264 -crf 0 -preset ultrafast -c:a libmp3lame -b:a 320k output.mp4

ffmpeg -i input -c:v libx264 -crf 0 -preset veryslow -c:a libmp3lame -b:a 320k output.mp4

यदि वह आपको एक छोटी सी पर्याप्त फ़ाइल नहीं देता है, तो 18 की एक crf को आमतौर पर 'नेत्रहीन दोषरहित' माना जाता है:

ffmpeg -i input -c:v libx264 -crf 18 -preset veryfast -c:a libmp3lame -b:a 320k output.mp4

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

X264 एन्कोडिंग के लिए अधिक गहराई से गाइड के लिए यहां देखें ।


2
veryfastहानिपूर्ण x264 के लिए एक अच्छे डिफ़ॉल्ट के रूप में सुझाव न दें । mediumएक अच्छा मध्य मैदान है, लेकिन मैं आमतौर पर veryslowकिसी भी चीज के अंतिम एनकोड के लिए उपयोग करता हूं । यह huffyuvभी बहुत तेज नहीं है, मैं इसे संगतता के अलावा किसी अन्य चीज के लिए अनुशंसित नहीं करूंगा।
पीटर कॉर्डेस

ffmpeg में कुछ अन्य दोषरहित कोडेक्स हैं जो कि [FFv1 के दिमाग में आते हैं] की कोशिश करने लायक हो सकते हैं। जीएल!
रेजरडैक

तुम दोनों दिशाओं में आधे से दो रंग चैनलों (YUV UV में) को libx264 डाउनसप्लिमेंट नहीं करते, भले ही आप 0 के CRF का उपयोग करते हों, इसलिए यह वास्तव में दोषरहित नहीं है। साथ ही, राउंडिंग त्रुटियों के साथ, डेटा को x264 संपीड़न के एक दौर के बाद बिट-फॉर-बिट इंडेंटिकल होने की गारंटी नहीं है।
अदिसक

1
Ffmpeg 3.4.1 के साथ मेरे प्रयोगों में, libx264 ने yuv444 पिक्सेल प्रारूप का उपयोग किया, जहां "444" का अर्थ है "यू, वी भाग को न घटाएं"। और, ओपी स्पष्ट रूप से गोलाई त्रुटियों को बुरा नहीं मानता: "अवधारणात्मक दोषरहित हो सकता है"। तो, @ Adisak, आपकी चिंताएँ वाजिब हैं, लेकिन इस उत्तर पर लागू नहीं हैं।
जिम डेलाउंट

YUV मोड में ffmpeg और libx264 इनपुट के आधार पर YUV पिक्सेल फॉर्मेट पर बातचीत करेगा। इसलिए यदि इनपुट YUV 4: 2: 0 है तो आउटपुट पिक्सेल फॉर्मेट है। यदि इनपुट YUV 4: 4: 4 या RGB है, तो आउटपुट YUV 4: 4: 4 है।
ज्ञान

2

इन दिनों मुझे वेबम पसंद है :

ffmpeg -i input.avi -c:v libvpx-vp9 -lossless 1 output.webm

मल्टी-कोर प्रोसेसर के साथ तेजी से कन्वर्ट करने के लिए, मैंने पढ़ा है कि यह एक कम धागा का उपयोग करने की सिफारिश की जाती है, जिसमें आपके पास असली कोर है। तो, 8 कोर के साथ आप इस तरह 7 धागे निर्दिष्ट कर सकते हैं:

ffmpeg -i input.avi -c:v libvpx-vp9 -threads 7 -lossless 1 output.webm

1
मैं उपयोग करने के लिए थ्रेड काउंट निर्धारित करने के लिए पर्यावरण चर% NUMBER_OF_PROCESSORS% का उपयोग करना पसंद करता हूं। यदि यह गिनती 1 या 2 है, तो मैंने सभी प्रोसेसर का उपयोग किया। यदि गिनती 3 या 4 है, तो मैं सभी लेकिन एक प्रोसेसर का उपयोग करता हूं। और यदि गिनती अधिक है, तो मैं थ्रेड गिनती के लिए सभी लेकिन दो प्रोसेसर का उपयोग करता हूं।
अदिसक

1
DOS अभिव्यक्तियों के रूप में, यह इस तरह दिखता है: यदि "% ADJUSTED_CPUCOUNT%" EQU "" (यदि% NUMBER_OF_PROCESSORS% EQU 1 (सेट ADJUSTED_CPUCOUNT = 1) यदि% NUMBER_OF_PROCESSORS% EQU 2 (सेट ADJUSTED_CPUCOUNT = 2 = यदि अन्य%) EQU 3 (सेट ADJUSTED_CPUCOUNT = 2) और यदि% NUMBER_OF_PROCESSORS% EQU 4 (सेट ADJUSTED_CPUCOUNT = 3) अन्य (सेट / A ADJUSTED_CPUCOUNT =% NUMBER_OF_PROCESSORS% -2)
Adisak

1
superuser.com/questions/155305/… का कहना है कि ffmpeg पहले से ही थ्रेड की अधिकतम संख्या चुनता है
बोरिस

वेबम (इन दिनों) से बेहतर विकल्प शायद एवी 1 प्रारूप है।
लोनीबेस्ट

-1
# कंटेनर

डीवीडी-खिलाड़ियों के साथ पूर्ण संगतता रखने के लिए, आपको एमपीईजी -2 प्रारूप, कंटेनर, प्रतिबंध, कोडेक्स का उपयोग करना होगा। मुझे लगता है, "आधुनिक खिलाड़ियों" का अर्थ है "mp4" संगतता, जो मूल रूप से और ज्यादातर एक mp4-फ़ाइल प्लेयर है - H.264, MPEG-4, AVC => libx264 और
पढ़ें: https://de.wikipedia.org/wiki /H.264

# वीडियो

Https://trac.ffmpeg.org/wiki/Encode/H.264 पर एक नज़र डालें , विशेष रूप से वह हिस्सा जहां यह "प्रोफ़ाइल" और "स्तर" के बारे में है, संगतता के लिए इसका
उपयोग करना -profile:v high -level 4.0चाहिए

# ऑडियो

हानिरहित कोडेक्स के साथ ऑडियो-पटरियों को फिर से एन्कोडिंग करने से बचें - कोई भी एमपी 3 प्रारूप हानिरहित है, यहां तक ​​कि 320kbps भी। इसके बजाय
उपयोग करें -c:a copy

अब तक, इसने मेरे लिए बहुत अच्छा काम किया। कोई समस्‍या नहीं है।
ऑडियो स्ट्रीम keyframes से बंधे नहीं हैं। सटीक कटौती संभव है।
यदि आपका ऑडियो-ट्रैक 44kHz नमूना-दर पर रिकॉर्ड किया गया है, तो अधिकतम का उपयोग करें। 256kbps

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

मैंने कुछ ऑडियो-सिंक मुद्दों के बारे में सुना है, लेकिन ऐसा लगता है कि मुख्य मुद्दा था, यह संरक्षित सामग्री (!) था।

# आखिरकार

मैं कुछ इस तरह पसंद करेंगे:
ffmpeg -i input -c:v libx264 -crf 5 -preset faster -profile:v high -level 4.0 -c:a copy output.mp4


विकल्प "-Lvel 4.0" की आवश्यकता नहीं है। एक्स 264 में स्तर संकल्प और एफपीएस के आधार पर निर्धारित किया जाता है, इसलिए आमतौर पर इसे मैन्युअल रूप से सेट करने का कोई मतलब नहीं है, इससे कुछ भी सुधार नहीं होगा। जहाँ तक मुझे पता है कि ffmpeg अपने आप सही स्तर सेट कर सकता है, इसलिए जब तक आपके पास इसे बाध्य करने का बहुत अच्छा कारण नहीं है और पूरी तरह से समझें कि FPS और रिज़ॉल्यूशन के आधार पर स्तर का चयन कैसे करें, आपको "-level" विकल्प का उपयोग नहीं करना चाहिए। यदि आप उच्चतम संगतता की परवाह करते हैं, तो "हाईलाइन" के बजाय "बेसलाइन" प्रोफाइल का उपयोग करें।
लिसनारो रेएन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.