Evey प्लेबैक का तरीका कैसे चुनता है¶
कोई फ़िल्म TV पर बिना बदले क्यों चलती है, लेकिन फ़ोन पर बदल दी जाती है?
कम शब्दों में:
- आपको कभी क्वालिटी नहीं चुननी पड़ती। जब आप चलाएँ दबाते हैं, तो सर्वर फ़ाइल को देखता है, यह देखता है कि आपका डिवाइस क्या चला सकता है, और यह भी कि सर्वर अभी कितना व्यस्त है। फिर वह सबसे हल्का तरीका चुनता है जो काम करे।
- तीन तरीके हैं: डायरेक्ट प्ले (फ़ाइल जैसी है वैसी), रीमक्स (वही तस्वीर और आवाज़, दूसरे फ़ाइल फ़ॉर्मेट में दोबारा पैक की हुई), और ट्रांसकोड (फ़िल्म का कुछ हिस्सा बदला हुआ, अक्सर सिर्फ़ आवाज़)।
- इसलिए एक ही फ़िल्म किसी डिवाइस पर बिना बदले जा सकती है और किसी दूसरे के लिए बदली जा सकती है, या उसी डिवाइस पर तब अलग तरह से चल सकती है जब सर्वर व्यस्त हो।
- आम तौर पर आपको कुछ नहीं करना होता। आपको कौन सा तरीका मिला, और क्यों, यह देखने के लिए प्लेयर में स्ट्रीम जानकारी खोलें: देखें स्ट्रीम जानकारी पढ़ना।
पहले तीनों तरीके और स्ट्रीम जानकारी पढ़ने का तरीका आता है। उसके बाद वे सटीक नियम आते हैं जो सर्वर लगाता है, उस पाठक के लिए जो उन्हें समझना या बदलना चाहता है।
तीन नतीजे¶
| स्ट्रीम जानकारी में | प्लेयर को क्या मिलता है | सर्वर पर कितना बोझ |
|---|---|---|
| डायरेक्ट प्ले | असली फ़ाइल, बाइट-दर-बाइट। | बस फ़ाइल पढ़ना। |
| रीमक्स | असली वीडियो और ऑडियो, दूसरे कंटेनर में। कुछ भी दोबारा एन्कोड नहीं होता। | दोबारा पैक करना, जहाँ हो सके सर्वर के अंदर MKVGo से, नहीं तो FFmpeg की कॉपी से। |
| ट्रांसकोड | कम से कम एक ट्रैक दोबारा एन्कोड होता है। अक्सर सिर्फ़ ऑडियो, वीडियो असली ही रहता है। | एक एन्कोड। सिर्फ़ वीडियो का दोबारा एन्कोड ही एक ट्रांसकोडिंग स्लॉट लेता है। |
सर्वर इन्हें इसी क्रम में आज़माता है, और ट्रांसकोड में भी वह सिर्फ़ उन्हीं ट्रैक को दोबारा एन्कोड करता है जिन्हें इसकी ज़रूरत है।
स्ट्रीम जानकारी पढ़ना¶
स्ट्रीम जानकारी (प्लेयर के कंट्रोल में जानकारी वाला बटन, (i); TV पर, प्लेयर के विकल्प वाले मेन्यू में) पहले विधि दिखाती है, फिर हर ट्रैक और उसका फ़ैसला (कॉपी किया गया, ट्रांसकोड किया गया, या उस ऑडियो के लिए क्लाइंट पर डिकोड किया गया जिसे वेब प्लेयर खुद डिकोड करता है), और सीधा प्लेबैक क्यों नहीं के नीचे कारण।
कारण चार समूहों में आते हैं:
| कारण कहाँ से आता है | जैसे दिखते हैं, उसके उदाहरण |
|---|---|
| प्लेयर ट्रैक को जैसा है वैसा इस्तेमाल नहीं कर सकता | वीडियो कोडेक जिसे यह प्लेयर डिकोड नहीं कर सकता · ऑडियो कोडेक जिसे यह प्लेयर डिकोड नहीं कर सकता · रिज़ॉल्यूशन प्लेयर की सीमा से अधिक · इस प्लेयर के समर्थन से अधिक ऑडियो चैनल · पिक्सेल फ़ॉर्मेट जिसे प्लेयर डिकोड नहीं कर सकता (10-बिट H.264, 4:2:2) · कंटेनर सीधे चलने योग्य नहीं (HLS में री-पैक किया गया) |
| इस सेशन पर लगी कोई सीमा | बिटरेट अनुमत सीमा से अधिक · क्लाइंट द्वारा मापी गई लाइन कॉपी नहीं ले सकती |
| तस्वीर या आवाज़ पर कोई असर | HDR को SDR में बदला गया (टोन-मैपिंग) · उपशीर्षक चित्र में स्थायी रूप से जोड़े गए · ऑडियो पुनः-सिंक का अनुरोध किया गया |
| कोई सेटिंग, या पहले से लिया गया फ़ैसला | पसंदीदा वीडियो कोडेक (प्रोफ़ाइल सेटिंग) · इस सत्र के लिए चुनाव स्थिर किया गया |
सिर्फ़ उसी ऑडियो ट्रैक को जाँचा जाता है जो चल रहा है। अगर किसी फ़ाइल का कमेंट्री ट्रैक DTS में है और वह चुना नहीं गया है, तो उसकी वजह से फ़ाइल ट्रांसकोड नहीं होती।
स्ट्रीम जानकारी प्लेबैक शुरू होते समय तैयार होती है। सिर्फ़ एक स्थिति वह पहले से नहीं देख सकती: स्ट्रीम शुरू होते समय ग्राफ़िक्स कार्ड पूरी तरह व्यस्त हो। तब स्ट्रीम प्रोसेसर पर चली जाती है, और एडमिन → अभी चल रहा है असल में इस्तेमाल हुआ बैकएंड दिखाता है।
हर पक्ष क्या लाता है¶
फ़ाइल। कोडेक, रिज़ॉल्यूशन, बिट डेप्थ, HDR फ़ॉर्मेट, बिटरेट, और ऑडियो व उपशीर्षक ट्रैक, जो फ़ाइल स्कैन होते समय पढ़े गए थे।
प्लेयर। प्लेबैक शुरू होने पर ऐप बताता है कि उसका डिवाइस क्या डिकोड कर सकता है: वह किन कोडेक परिवारों को सपोर्ट करता है, कौन से कंटेनर खोलता है, उसका सबसे ऊँचा रिज़ॉल्यूशन, उसकी स्क्रीन HDR दिखाती है या नहीं, वह कितने ऑडियो चैनल बाहर भेजता है, और कुछ डिवाइस के लिए H.264 की कम सीमा या लेवल। वेब ऐप यह ब्राउज़र से पूछता है; Android और Android TV ऐप डिवाइस के डिकोडर और डिस्प्ले से पूछते हैं। Evey सपोर्ट किए गए डिवाइस की कोई सूची नहीं रखता: वह वही इस्तेमाल करता है जो प्लेयर बताता है। कास्ट सेशन के बारे में रिसीवर खुद बताता है, जब वह अपनी क्षमताएँ बता सकता है, और नहीं तो एक सावधान प्रोफ़ाइल इस्तेमाल होती है: देखें Chromecast पर कास्ट करना।
सेशन। प्रोफ़ाइल की पसंद (सबसे ज़्यादा बिटरेट, सबसे ज़्यादा ऑडियो चैनल, उपशीर्षक कैसे दिखें) और इस दर्शक पर लगने वाली सीमाएँ, जो नीचे दी गई हैं।
सर्वर। क्या वह इसे रियल टाइम में एन्कोड कर सकता है, अपने ग्राफ़िक्स कार्ड पर या प्रोसेसर पर, और क्या कोई ट्रांसकोडिंग स्लॉट खाली है। यह मान नहीं लिया जाता, नापा जाता है: देखें ट्रांसकोडिंग और सर्वर की क्षमता।
एक फ़ाइल, तीन नतीजे¶
HDR10 में एक 4K HEVC फ़िल्म, 70 Mb/s पर, Dolby TrueHD 7.1 ट्रैक के साथ। उसे एक ऐसे Android TV पर चलाया जाता है जिसका डिकोडर HEVC संभालता है और जिसकी स्क्रीन HDR दिखाती है:
- कोई बिटरेट सीमा नहीं। TV वीडियो डिकोड करता है और HDR दिखाता है, इसलिए वीडियो जैसा है वैसा रहता है। वह TrueHD डिकोड नहीं करता, इसलिए सिर्फ़ ऑडियो दोबारा एन्कोड होता है। स्ट्रीम जानकारी ट्रांसकोड दिखाती है, और वीडियो कॉपी किया गया होता है।
- 20 Mb/s की सीमा, और एक ग्राफ़िक्स कार्ड जो HDR के साथ HEVC 10-बिट एन्कोड करता है। वीडियो को सीमा में लाने के लिए दोबारा एन्कोड करना पड़ता है। सर्वर उसे HEVC में दोबारा एन्कोड करता है और HDR रखता है, क्योंकि TV और कार्ड दोनों यह कर सकते हैं।
- वही सीमा, लेकिन ग्राफ़िक्स कार्ड व्यस्त है या इस टाइटल के लिए उपलब्ध नहीं। प्रोसेसर काम संभालता है। वह H.264 एन्कोड करता है, जो यहाँ HDR नहीं ले जाता, इसलिए तस्वीर को टोन-मैप करके SDR में बदला जाता है, उस क्वालिटी पर जो प्रोसेसर लगातार दे सके।
फ़ाइल और TV नहीं बदले। सेशन की सीमा और सर्वर की हालत बदली।
सेशन पर लगी सीमाएँ¶
जिस टाइटल का बिटरेट (वीडियो और चल रहा ऑडियो ट्रैक मिलाकर) इन सीमाओं में से सबसे छोटी सीमा से ऊपर है, उसे ट्रांसकोड करके उस सीमा तक लाया जाता है:
- प्लेयर जो सबसे ज़्यादा बताता है;
- खाते का अधिकतम बिटरेट, जो कोई एडमिन तय करता है;
- प्रोफ़ाइल का अधिकतम स्ट्रीमिंग बिटरेट, और जब फ़ोन बताता है कि वह मोबाइल डेटा पर है, तो उसका अधिकतम सेल्युलर बिटरेट;
- अधिकतम रिमोट बिटरेट (एडमिन → रिमोट एक्सेस) और वीडियो बिटरेट सीमा, दूरस्थ दर्शक (एडमिन → ट्रांसकोडिंग), इन दोनों में से छोटी, जब दर्शक का पता पब्लिक हो और LAN नेटवर्क के बाहर हो। प्राइवेट पते पर कभी सीमा नहीं लगती।
चल रहा ऑडियो ट्रैक तब दोबारा एन्कोड होता है जब उसमें प्लेयर के बताए चैनलों से, या प्रोफ़ाइल के अधिकतम ऑडियो चैनल से ज़्यादा चैनल हों। दोबारा एन्कोड हुआ ट्रैक 5.1 चैनल तक रखता है, इससे ज़्यादा कभी नहीं: देखें ऑडियो।
सर्वर खुद कौन सी पाबंदियाँ लगाता है¶
कुछ सीमाएँ आज प्लेयर नहीं बताते, और सर्वर उन्हें सावधानी वाले एक कम्पैटिबिलिटी नियम की तरह लगाता है, जो हर प्लेयर के लिए एक जैसा है: 10-बिट H.264, और 4:2:2, 4:4:4 या 12-बिट में कोई भी वीडियो, दोबारा एन्कोड होता है; जबकि 10-बिट 4:2:0 तक के HEVC, VP9 और AV1 का फ़ैसला प्लेयर के कोडेक सपोर्ट पर छोड़ा जाता है। Dolby Vision सिर्फ़ उसी रूप में रखा जाता है जिसे प्लेयर सही ढंग से दिखा सके: देखें HDR और Dolby Vision।
फ़िल्म के बीच में तरीका कम ही क्यों बदलता है¶
फ़ैसला प्लेबैक शुरू होते समय लिया जाता है और पूरे सेशन के लिए रखा जाता है, ताकि प्लेयर को कभी दो अलग एन्कोडिंग के सेगमेंट न मिलें। ऑडियो या उपशीर्षक ट्रैक को ऐसे बदलने पर जिसके लिए यह ज़रूरी हो, या टाइटल को फिर से शुरू करने पर, एक नया फ़ैसला लिया जाता है।
कोई तरीका ज़बरदस्ती चुनना¶
कोई तरीका ज़बरदस्ती नहीं चुना जा सकता: सर्वर उसे हमेशा फ़ाइल और प्लेयर को देखकर चुनता है। जो आप सीमित कर सकते हैं वह क्वालिटी है, हर डिवाइस के लिए अलग, सेटिंग्स → प्लेबैक → डेटा बचत (यह डिवाइस) से। यह सिर्फ़ उसी डिवाइस की स्ट्रीम सीमित करता है; खाते के बाकी डिवाइस अपनी सेटिंग रखते हैं। बंद कोई सीमा नहीं लगाता। बचत ज़्यादा से ज़्यादा 720p, 3 Mbps और स्टीरियो आवाज़ माँगता है। यात्रा / कम डेटा ज़्यादा से ज़्यादा 480p, 1 Mbps और स्टीरियो आवाज़ माँगता है। सीमा से ऊपर के टाइटल को उस सीमा तक ट्रांसकोड किया जाता है, और स्ट्रीम जानकारी वजह के तौर पर वह सीमा दिखाती है।
प्लेयर की सेटिंग्स में गुणवत्ता अलग चीज़ है: वह ट्रांसकोड की हुई स्ट्रीम की क्वालिटी में से चुनती है। स्वचालित कनेक्शन के हिसाब से चलता है; कोई ऊँचाई (1080p, 720p...) उसी क्वालिटी पर टिकी रहती है; मूल ऊँचाई की वह सीमा हटा देता है जो प्लेयर अन्यथा माँगता।
और जानें¶
- नियम विस्तार से: HDR और Dolby Vision · ऑडियो · सबटाइटल · Chromecast पर कास्ट करना
- सर्वर अपनी क्षमता कैसे बाँटता है: ट्रांसकोडिंग और सर्वर की क्षमता
- सर्वर के अंदर FFmpeg के बिना क्या चलता है: Evey में MKVGo
- अंदर का काम: प्लेबैक पाइपलाइन