वीडियो और उपशीर्षक · उपशीर्षक टूलकिट
उपशीर्षक फ़ाइल में भटके हुए टैग प्लेटफ़ॉर्म कैप्शन अपलोड को क्यों बाधित कर सकते हैं?
· यह क्यों मायने रखती है
उपशीर्षक पाठ प्रसंस्करण webvtt
प्लेटफ़ॉर्म कैप्शन अपलोड को सख्ती से और अक्सर चुपचाप पार्स करते हैं। यह पोस्ट उन सामान्य कारणों के बारे में बताती है जिनके कारण उपशीर्षक फ़ाइल अस्वीकार कर दी जाती है या अजीब तरह से प्रदर्शित होती है, क्यों फ़ॉर्मेटिंग टैग और कोड सामान्य अपराधी हैं और कैसे एक साफ़, मानक फ़ाइल समस्या से बचती है।
अपलोड स्वीकार कर लिया गया और कैप्शन शाब्दिक टैग दिखाते हैं - एक अशुद्ध फ़ाइल की शांत विफलता
सबसे बुरा परिणाम अस्वीकृति नहीं है. एक अस्वीकृत अपलोड आपको बताता है कि कुछ गलत है जबकि आप अभी भी फॉर्म देख रहे हैं। सामान्य परिणाम स्वीकृति है जिसके बाद कैप्शन होते हैं जो दर्शकों को अपना स्वयं का मार्कअप प्रदर्शित करते हैं, क्योंकि अपलोड जांच और रेंडरिंग पथ सॉफ्टवेयर के अलग-अलग टुकड़े हैं जो अलग-अलग प्रश्न पूछते हैं।
अपलोड जांच आमतौर पर पूछती है कि क्या फ़ाइल संकेतों में पार्स हो गई है। रेंडरिंग पूछता है कि प्रत्येक क्यू की सामग्री के साथ क्या करना है, और एक पार्सर जो एक अपरिचित टैग को अनदेखा करता है वह इसे टेक्स्ट के रूप में खींचता है। दोनों चरणों ने वही किया जिसके लिए उन्हें डिज़ाइन किया गया था।
प्लेटफ़ॉर्म वास्तव में क्या स्वीकार करते हैं - पूर्वानुमानित संरचना के साथ सादा SRT और WebVTT, और अतिरिक्त के लिए थोड़ी सहनशीलता
प्लेटफ़ॉर्म जो स्वीकार करते हैं वह टूल द्वारा उत्सर्जित की तुलना में संकीर्ण होता है। व्यवहार में इसका मतलब है सादा SRT या WebVTT एक पूर्वानुमेय आकार के साथ: रिक्त रेखाओं, एक टाइमकोड लाइन, टेक्स्ट लाइनों और कुछ अन्य द्वारा अलग किए गए ब्लॉक। अतिरिक्त चीजों के प्रति सहनशीलता कम है और, अधिक महत्वपूर्ण बात यह है कि यह अप्रलेखित है, इसलिए सुरक्षित धारणा यह है कि उस आकार से परे कुछ भी एक विशेषता के बजाय एक जोखिम है।
यह अपने आप में रूढ़िवादिता नहीं है। एक प्लेटफ़ॉर्म जिसने मनमाना मार्कअप स्वीकार किया है, उसे यह तय करना होगा कि इसे वेब, मोबाइल और टेलीविज़न क्लाइंट्स पर लगातार कैसे प्रस्तुत किया जाए, जो एक कैप्शन फ़ाइल को स्वीकार करने की तुलना में बहुत बड़ी प्रतिबद्धता है।
सामान्य अपराधी - HTML-जैसे टैग, ASS-शैली कोड, BOM, मिश्रित पंक्ति अंत और रिक्त संकेत
बार-बार आने वाले अपराधी कम हैं. इटैलिक, स्पीकर वॉयस और क्यू क्लास के लिए एंगल-ब्रैकेट टैग उन प्रारूपों से रूपांतरण से बचते हैं जो उनका समर्थन करते हैं। ब्रेस-सीमांकित ओवरराइड कोड सबस्टेशन प्रारूपों से आते हैं और उनके बाहर इसका कोई मतलब नहीं है। फ़ाइल की शुरुआत में एक बाइट ऑर्डर चिह्न पहले इंडेक्स नंबर से जुड़ जाता है। क्रॉस-प्लेटफ़ॉर्म संपादन ब्रेक ब्लॉक विभाजन से मिश्रित पंक्ति अंत। जिन संकेतों का पाठ मार्कअप हटा दिए जाने के बाद खाली हो गया, वे टाइमस्टैम्प्ड रिक्त स्थान के रूप में बने रहेंगे।
इनमें से कोई भी विदेशी नहीं है. वे एक रूपांतरण श्रृंखला के सामान्य आउटपुट हैं जहां प्रत्येक चरण व्यक्तिगत रूप से उचित था, यही कारण है कि वे उन फ़ाइलों में दिखाई देते हैं जो एक एडिटर में ठीक दिखते हैं।
एक प्लेटफ़ॉर्म उस चीज़ को क्यों सहन करता है जिसे दूसरा अस्वीकार करता है - समान अपलोड फ़ॉर्म के पीछे अलग-अलग पार्सर
अलग-अलग प्लेटफ़ॉर्म अलग-अलग उपसमुच्चय को सहन करते हैं, और यही कारण है कि दोष का निदान करना भ्रमित करने वाला होता है। एक ही फ़ाइल एक सेवा पर साफ़-साफ़ अपलोड हो सकती है और सही ढंग से प्रस्तुत हो सकती है, दूसरी सेवा पर मार्कअप अपलोड और प्रस्तुत हो सकती है, और तीसरे द्वारा अस्वीकार कर दिया जा सकता है, बिना किसी त्रुटि संदेश के जो वास्तविक कारण बताता है। प्रयासों के बीच फ़ाइल नहीं बदली; तीन पार्सर्स असहमत थे।
इसलिए एक मंच को संदर्भ मानना गलत प्रवृत्ति है। एक फ़ाइल जो सबसे अधिक अनुमेय सेवा पर काम करती है वह आपको दूसरों के बारे में कुछ नहीं बताती है, और सबसे सख्त पार्सर वह है जो परिभाषित करता है कि कोई फ़ाइल पोर्टेबल है या नहीं।
व्यावहारिक उदाहरण: एक फ़ाइल, तीन अपलोड - कैसे एक ही अव्यवस्था अलग-अलग तरह से दिखाई देती है और सफाई के बाद गायब हो जाती है
साठ संकेतों पर शीर्ष-फ़्रेम ओवरराइड कोड, चालीस पर ज़ोर टैग और एक बाइट ऑर्डर चिह्न वाला एक निर्यात लें। तीन सेवाओं पर अपलोड किया गया इसे हर जगह स्वीकार किया जा सकता है। पहले टैग को सम्मानित किया जाता है और ओवरराइड कोड को शाब्दिक रूप से तैयार किया जाता है। दूसरे पर दोनों पाठ के रूप में दिखाई देते हैं। तीसरे पर निशान पहले संकेत के बराबर होता है, जो कभी प्रकट नहीं होता है, और कोई भी नोटिस नहीं करता है क्योंकि प्रारंभिक पंक्ति आमतौर पर एक शीर्षक होती है।
एक बार सफाई करने से स्रोत पर मौजूद सभी तीन वर्ग हट जाते हैं। कोण-ब्रैकेट टैग और ब्रेस कोड को प्रतिस्थापित कर दिया जाता है, पीछे छोड़े गए खाली स्थान को ढहा दिया जाता है, निष्कासन द्वारा खाली किए गए संकेतों को टाइमस्टैम्प्ड रिक्त स्थान के रूप में उत्सर्जित करने के बजाय हटा दिया जाता है, और फ़ाइल को एक से लगातार पुन: क्रमांकित संकेतों के साथ फिर से लिखा जाता है। फिर वही आउटपुट तीनों सेवाओं को जाता है।
इसमें क्या शामिल नहीं है - प्लेटफ़ॉर्म-विशिष्ट शैली गाइड, प्रति पंक्ति वर्ण सीमाएँ और बर्न-इन कैप्शन
इसमें संरचनात्मक पोर्टेबिलिटी शामिल है, न कि एडिटरीय अनुरूपता। लाइन की लंबाई, अधिकतम वर्ण, स्पीकर लेबल की स्थिति और ध्वनि प्रभावों को संभालने पर प्लेटफ़ॉर्म स्टाइल गाइड अलग-अलग आवश्यकताएं हैं जो एक साफ़ फ़ाइल स्वचालित रूप से संतुष्ट नहीं होती हैं। संरचनात्मक रूप से उत्तम कैप्शन फ़ाइल अभी भी स्टाइल गाइड का उल्लंघन कर सकती है।
बर्न-इन कैप्शन पूरी तरह से एक अलग तंत्र है। वीडियो फ़्रेम में रेंडर किया गया टेक्स्ट कैप्शन फ़ाइल नहीं है, इसे टॉगल नहीं किया जा सकता है, और यहां वर्णित किसी भी चीज़ से अप्रभावित है।
टेकअवे: एक बार साफ करें, कहीं भी अपलोड करें - कैसे उपशीर्षक टूलकिट की साफ और परिवर्तित सुविधाएं एक प्लेटफ़ॉर्म-अनुकूल फ़ाइल का निर्माण करती हैं
एक बार साफ़ करें और हर जगह एक ही फ़ाइल अपलोड करें। विकल्प, प्रति प्लेटफ़ॉर्म एक अलग निर्यात बनाए रखना, उन फ़ाइलों की संख्या को कई गुना बढ़ा देता है जो मास्टर के साथ सिंक से बाहर हो सकती हैं और उनमें से किसी से भी अंतर्निहित अव्यवस्था को दूर नहीं करती है।
क्लीन चलाएँ और कन्वर्ट एक साथ करें, फिर रिपोर्ट की गई समस्याओं को बाद के बजाय अपलोड करने से पहले पढ़ें। मुद्दों के नाम संख्या के आधार पर संकेत देते हैं, जो यह जानने के बीच का अंतर है कि किसी फ़ाइल में कोई समस्या है और यह जानना कि किस पंक्ति को देखना है।