वीडियो और कोडेक
वीडियो फ़ाइलों के बारे में लगभग हर उलझाने वाली बात एक फ़र्क़ से आती है — बॉक्स और उसके अंदर क्या है, इनके बीच। यह दोनों के लिए शब्द हैं, और उन कामों के लिए जो इनके बीच चीज़ें ले जाते हैं।
-
कंटेनर
wrapper, format -
वह फ़ाइल संरचना जो वीडियो, ऑडियो और सबटाइटल ट्रैक को साथ रखती है और बताती है हर एक कहां है। MP4, MKV, AVI और WebM कंटेनर हैं। कोई कंटेनर कुछ भी कंप्रेस नहीं करता।
इसे कंटेंट लेबल वाले एक फ़ाइलिंग बॉक्स की तरह सोचें। बॉक्स कहता है: यहां एक वीडियो ट्रैक है, इस तरह एन्कोड किया गया; वहां दो ऑडियो ट्रैक, इन भाषाओं में; इस ऑफ़सेट पर सबटाइटल। इसकी कोई राय नहीं होती इनमें से किसी को कैसे कंप्रेस किया गया।
यही वजह है कि एक ही वीडियो एक MP4 और एक MKV में बिल्कुल एक जैसी पिक्चर क्वालिटी और एक जैसे फ़ाइल साइज़ के साथ मौजूद हो सकता है, और यही वजह है कि इनमें से एक iPhone पर खुलता है और दूसरा नहीं। फ़र्क़ बॉक्स का है, कंटेंट का नहीं।
-
कोडेक
coder-decoder -
किसी वीडियो या ऑडियो स्ट्रीम को कंप्रेस करने का तरीक़ा, और प्लेबैक के लिए इसे दोबारा डीकंप्रेस करने का। H.264, HEVC, AV1, AAC और MP3 कोडेक हैं। कोडेक कोई फ़ाइल फ़ॉर्मैट नहीं है।
यह नाम coder-decoder का छोटा रूप है। एन्कोडिंग इस तरह डिटेल फेंकती है कि नोटिस करना मुश्किल हो, और डिकोडिंग जो बचाया गया उससे ओरिजिनल का एक अंदाज़ा दोबारा बनाती है। कोडेक जितना बेहतर, दिए साइज़ पर नुक़सान उतना कम नज़र आता है।
एक डिवाइस फ़ाइल तब चलाती है जब वह कंटेनर पढ़ सके *और* इसके अंदर हर कोडेक डिकोड कर सके। दोनों हिस्से ज़रूरी हैं, और जब फ़ाइल खुलती है पर कुछ नहीं दिखाती, दूसरा हिस्सा ही फेल हुआ है।
यह भी देखें: कंटेनरहार्डवेयर डिकोडिंग
-
H.264
AVC, MPEG-4 Part 10 -
वह वीडियो कोडेक जिसे सब कुछ डिकोड कर सकता है। 2003 में प्रकाशित, अब भी कम्पैटिबिलिटी के लिए सबसे सुरक्षित विकल्प, और पिछले पंद्रह साल में बने हर फ़ोन, कंप्यूटर और TV पर हार्डवेयर-एक्सेलरेटेड।
H.264 इतनी पूरी तरह जीता कि "क्या यह हर जगह चलेगा" और "क्या यह H.264 है" लगभग एक ही सवाल हैं। यह उपलब्ध सबसे कुशल कोडेक नहीं है — HEVC और AV1 दोनों कम बिट्स में ज़्यादा करते हैं — पर सपोर्ट की चौड़ाई में इसके पास कुछ नहीं आता।
इसके प्रोफ़ाइल हैं, और इनमें से एक Apple डिवाइस पर मुसीबत खड़ी करता है: High 10, अक्सर Hi10P लिखा जाता है, हर रंग चैनल के लिए आठ के बजाय दस बिट एन्कोड करता है। हार्डवेयर डिकोडर सिर्फ़ 8-बिट होते हैं, तो एक Hi10P फ़ाइल उस डिवाइस पर बिना तस्वीर के आवाज़ चलाती है जिसमें कोई सॉफ़्टवेयर फ़ॉलबैक नहीं है।
यह भी देखें: HEVCहार्डवेयर डिकोडिंग10-bit
-
HEVC
H.265 -
H.264 का उत्तराधिकारी, एक जैसी क्वालिटी के लिए लगभग आधे साइज़ का। 2015 से आगे का हर Apple डिवाइस इसे हार्डवेयर में डिकोड करता है, और iPhone इसी में रिकॉर्ड करता है।
HEVC ने फ़ोन पर 4K को व्यावहारिक बनाया: लगभग आधी बिटरेट पर वही तस्वीर। Apple ने इसे जल्दी और पूरी तरह अपनाया, तो Apple हार्डवेयर पर यह H.264 जितना सुरक्षित विकल्प है।
बाक़ी जगह यह ज़्यादा गड़बड़ है। HEVC के इर्द-गिर्द पेटेंट लाइसेंसिंग इतनी विवादित रही कि वेब ब्राउज़र इसे सपोर्ट करने में धीमे रहे, और यही वह जगह है जिसे भरने के लिए AV1 बनाया गया।
-
AV1
-
2018 में प्रकाशित एक रॉयल्टी-फ़्री कोडेक, HEVC से ज़्यादा कुशल और, इसके उलट, लाइसेंसिंग विवादों से मुक्त। हार्डवेयर डिकोडिंग Apple डिवाइस पर सिर्फ़ iPhone 15 Pro के साथ आई।
AV1 इसलिए मौजूद है क्योंकि HEVC की लाइसेंसिंग ने सबसे बड़ी स्ट्रीमिंग और वेब ब्राउज़र कंपनियों को एक ऐसा विकल्प चाहिए बना दिया जिसे वे बिना किसी को पैसे दिए शिप कर सकें। अब वेब का बहुत सारा वीडियो इसी में डिलीवर होता है।
दिक़्क़त डिकोडिंग की लागत है। बिना हार्डवेयर सपोर्ट के, AV1 सॉफ़्टवेयर में डिकोड होता है, जो संभव है पर बैटरी साफ़ ख़त्म करता है और ज़्यादा रिज़ॉल्यूशन पर अटक सकता है। पुराने डिवाइस पर, उसी वीडियो का H.264 वर्शन बेहतर फ़ाइल है।
यह भी देखें: HEVCहार्डवेयर डिकोडिंग
-
बिटरेट
-
वीडियो या ऑडियो का एक सेकंड कितना डेटा इस्तेमाल करता है, आमतौर पर मेगाबिट प्रति सेकंड में। यही मुख्य चीज़ है जो फ़ाइल साइज़ और डिवाइस को कितना काम करना है, दोनों तय करती है।
ध्यान रिज़ॉल्यूशन पर जाता है, पर बिटरेट तय करती है कि फ़ाइल असल में कैसी दिखती है। कम बिटरेट पर एक 4K फ़ाइल ज़्यादा बिटरेट पर एक 1080p फ़ाइल से बदतर दिखती है, क्योंकि एन्कोडर को अपने लक्ष्य तक पहुंचने के लिए ज़्यादा छोड़ना पड़ा।
यही वह वजह भी है जिसके पीछे अटकती फ़ाइल आमतौर पर होती है। जब वीडियो कंप्यूटर पर चलता है और फ़ोन पर अटकता है, फ़ाइल में कुछ ग़लत नहीं है: यह बस उस चिप की चाहत से ज़्यादा डिकोडिंग काम प्रति सेकंड मांग रहा है।
यह भी देखें: कोडेकअडैप्टिव बिटरेट
-
रीमक्स
rewrap -
मौजूद वीडियो और ऑडियो स्ट्रीम को बिना दोबारा एन्कोड किए एक कंटेनर से दूसरे में ले जाना। लॉसलेस, और इतना तेज़ कि प्रोसेसर के बजाय डिस्क स्पीड ही सीमा बने।
एक रीमक्स स्ट्रीम की कॉपी बनाता है; यह एक भी फ़्रेम नहीं छूता। H.264 और AAC रखने वाली एक घंटे की MKV सेकंडों में MP4 बन जाती है, पिक्चर और साउंड में बिट-फ़ॉर-बिट एक जैसी।
यह सिर्फ़ तब काम करता है जब टारगेट कंटेनर वह स्वीकारे जो सोर्स रखता है — MP4 H.264 और AAC लेगा, और VP9 या Vorbis नहीं लेगा। जब लोग कहते हैं एक कन्वर्ज़न "तुरंत" हुआ, उन्होंने रीमक्स किया। जब इसमें एक घंटा लगा, कुछ दोबारा एन्कोड हुआ।
-
ट्रांसकोड
re-encode, convert -
एक स्ट्रीम को डिकोड करना और इसे दोबारा एन्कोड करना, आमतौर पर एक अलग कोडेक में या कम बिटरेट पर। धीमा, और हर बार लॉसी — क्वालिटी कभी वापस नहीं आती।
ट्रांसकोडिंग वह है जिसे लोग "वीडियो कन्वर्ट करना" कहते हैं, और यह असल में एक महंगा ऑपरेशन है: हर फ़्रेम डिकोड, प्रोसेस और दोबारा कंप्रेस होता है। यह सही जवाब है जब कोडेक सच में अनसपोर्टेड है, या जब फ़ाइल को छोटा बनाना ज़रूरी है।
यह "मेरा फ़ोन इसे नहीं खोलेगा" का ग़लत जवाब है, जब एक रीमक्स काफ़ी होता, और यह उस फ़ाइल का ख़राब जवाब है जिसकी इकलौती समस्या एक DTS ऑडियो ट्रैक है — सिर्फ़ एक ट्रैक बदलना पिक्चर को बिना छुए छोड़ देता है।
-
हार्डवेयर डिकोडिंग
-
मेन प्रोसेसर के बजाय एक समर्पित चिप पर वीडियो डिकोड करना। कहीं ज़्यादा तेज़, कहीं ज़्यादा ठंडा और बैटरी पर कहीं ज़्यादा दयालु — पर यह सिर्फ़ वे कोडेक संभालता है जिनके लिए इसे बनाया गया।
हर फ़ोन में एक फ़िक्स्ड-फ़ंक्शन वीडियो डिकोडर होता है जो H.264 और HEVC बेहद कुशलता से करता है। जो कुछ यह सपोर्ट नहीं करता वह सॉफ़्टवेयर पर जाता है, जो काम करता है पर बैटरी और गर्मी की क़ीमत लेता है, और ज़्यादा रिज़ॉल्यूशन पर साथ नहीं दे सकता।
यही वजह है कि फ़ोन पर फ़ॉर्मैट सपोर्ट एक सीधा हां या ना नहीं है। एक डिवाइस एक कोडेक को 1080p पर सॉफ़्टवेयर में बिल्कुल ठीक चला सकती है और उसी कोडेक को 4K पर फेल कर सकती है, और इनमें से कोई नतीजा यह नहीं कहता कि फ़ाइल ग़लत है।
-
10-bit
Hi10P, High 10 -
वीडियो हर रंग चैनल के लिए आठ के बजाय दस बिट स्टोर करता है, ज़्यादा मुलायम ग्रेडिएंट के लिए। HEVC में यह सामान्य और अच्छी तरह सपोर्टेड है; H.264 में यह उस फ़ाइल की सबसे आम वजह है जिसमें iPhone पर आवाज़ है पर तस्वीर नहीं।
हर चैनल में ज़्यादा बिट का मतलब है शेड्स के बीच बारीक़ क़दम, जो अंधेरे आसमान और धीमे फ़ेड में दिखने वाली बैंडिंग हटाता है। HDR के लिए यह एक ज़रूरत है, कोई निखार नहीं।
समस्या ख़ासतौर पर H.264 है। दस-बिट H.264 उससे बाहर है जो हार्डवेयर डिकोडर लागू करते हैं, और Apple के सिस्टम प्लेयर के पास इसके लिए कोई सॉफ़्टवेयर रास्ता नहीं, तो ऑडियो चलती है और तस्वीर कभी नहीं पहुंचती। एनिमे रिलीज़ इसे भारी इस्तेमाल करती हैं, यही वजह है कि यह फ़ॉर्मैट के कुल हिस्से से कहीं ज़्यादा बार सामने आता है।
यह भी देखें: H.264हार्डवेयर डिकोडिंग
-
की-फ़्रेम
I-frame -
एक फ़्रेम जो पहले वाले फ़्रेम से एक अंतर के बजाय पूरी तरह स्टोर किया जाता है। सीक करना सिर्फ़ एक पर उतर सकता है, यही वजह है कि वीडियो कभी-कभी आपके मांगे पल से थोड़े अलग पल पर कूदता है।
वीडियो कंप्रेशन ज़्यादातर फ़्रेम को अपने पड़ोसियों से बदलाव के रूप में बताकर काम करता है। सिर्फ़ की-फ़्रेम अकेले खड़े होते हैं, और आमतौर पर हर दो से दस सेकंड में आते हैं।
जब आप स्क्रब बार खींचते हैं, प्लेयर सबसे नज़दीकी की-फ़्रेम ढूंढता है और वहीं से शुरू करता है। दूर-दूर बैठे की-फ़्रेम फ़ाइल को छोटा और सीक करना मोटा बनाते हैं; यह समझौता एन्कोडिंग के समय तय होता है और बाद में बिना दोबारा एन्कोड किए बदला नहीं जा सकता।