ख़राब या करप्ट वीडियो ब्राउज़र में ठीक करें

यह पेज असल में क्या जाँचता है

वीडियो चुनें, और यह पेज पूरी स्ट्रीम को शुरू से आख़िर तक जाँचकर वे फ़्रेम खोजता है जिनका डेटा टूटा हुआ है, फिर टाइमलाइन पर दिखाता है कि वे कहाँ हैं। रिपेयर करने पर एक नई फ़ाइल बनती है जिसमें सिर्फ़ वे फ़्रेम होते हैं जो ठीक से डिकोड होते हैं, इसलिए नतीजा बिना अटके चलता है। सब कुछ आपके डिवाइस पर चलता है — कुछ भी अपलोड नहीं होता।

MP4 या MOV के अंदर हर H.264 या HEVC फ़्रेम एक कड़ी के रूप में रखा जाता है: पहले एक लंबाई की संख्या, फिर उतने बाइट तस्वीर का डेटा, फिर अगली लंबाई, और यही क्रम तब तक चलता है जब तक उस फ़्रेम का डेटा ख़त्म न हो जाए। यह कड़ी ठीक आख़िरी बाइट पर ख़त्म होनी चाहिए। अगर कोई लंबाई शून्य है, या उस जगह से आगे जाती है जहाँ डेटा ख़त्म होता है, तो उस फ़्रेम के बाइट वैसे नहीं हैं जैसा फ़ाइल दावा करती है।

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

अगर आपने कभी किसी ख़राब वीडियो को ffmpeg से चलाया है और Invalid NAL unit size (0 > 1241) जैसी लाइनें गुज़रती देखी हैं, तो यह वही स्थिति है। प्लेयर आम तौर पर ऐसे में अटक जाते हैं, आगे कूद जाते हैं, या चौकोर धब्बों वाली बिगड़ी तस्वीर दिखाते हैं — क्योंकि जो बाइट मौजूद ही नहीं, उनके साथ वे इतना ही कर सकते हैं।

जाँच के लिए वीडियो के कोडेक का डिकोडर चाहिए। जो ब्राउज़र वीडियो डिकोड नहीं कर सकता, वह रिपेयर की गई कॉपी की जाँच भी नहीं कर सकता।

दो तरह की ख़राबी, और दोनों अलग दिखती हैं

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

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

इन दोनों को अलग समझना ज़रूरी है, क्योंकि दोनों में अलग-अलग उम्मीद रखनी चाहिए। बिखरे हुए नुक़सान में अक्सर यहाँ-वहाँ एक-एक सेकंड जाता है। जो फ़ाइल 40% पर ही कट गई, उसमें वीडियो का 60% हिस्सा है ही नहीं, और जो कभी लिखा ही नहीं गया, उसे कोई टूल नहीं बना सकता।

रिपेयर की गई फ़ाइल छोटी क्यों होती है

वीडियो के फ़्रेम एक-दूसरे से स्वतंत्र नहीं होते। कीफ़्रेम अपने आप में पूरा होता है, पर उसके बाद के फ़्रेम उससे हुए अंतर के रूप में सेव होते हैं — इसलिए अगर किसी कीफ़्रेम का डेटा टूटा है, तो उस पर निर्भर हर फ़्रेम भी बेकार हो जाता है, भले ही उनके अपने बाइट बिलकुल ठीक हों। इसीलिए दस टूटे फ़्रेम वाली फ़ाइल से दस से कहीं ज़्यादा फ़्रेम जा सकते हैं।

रिपेयर करने पर सिर्फ़ वे फ़्रेम रखे जाते हैं जो सचमुच डिकोड हो सकते हैं, और बीच के गैप हटाकर बाक़ी हिस्से आपस में जोड़ दिए जाते हैं, ताकि नतीजा ख़राबी वाली जगह पर रुकने के बजाय शुरू से आख़िर तक चले। बदले में आउटपुट मूल से उतना छोटा हो जाता है जितना हिस्सा हटाया गया। पेज यह संख्या आपके आगे बढ़ने से पहले बताता है, और नतीजे के साथ फिर से।

डिफ़ॉल्ट मोड में रखे गए फ़्रेम बिना दोबारा एनकोड किए कॉपी होते हैं। पूरी डिकोडिंग जाँच में समय लगता है; वैकल्पिक “अधूरी तस्वीर वाले फ़्रेम भी रखें” मोड रखे गए वीडियो को दोबारा एनकोड करता है।

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

यह क्या नहीं कर सकता

जो फ़ाइल खुलती ही नहीं, वह यहाँ ठीक नहीं हो सकती। हर MP4 में एक इंडेक्स होता है जो बताता है कि हर फ़्रेम कहाँ रखा है। अगर वह इंडेक्स ख़राब है या ग़ायब है — जो तब आम है जब रिकॉर्डिंग ठीक से पूरी (फ़ाइनलाइज़) हुए बिना रुक जाती है — तो फ़ाइल को पढ़ने का कोई नक्शा ही नहीं बचता, और यह पेज बेवजह अटके रहने के बजाय साफ़ बता देगा। ऐसी फ़ाइलों को बचाने के लिए मूल स्रोत चाहिए, या ऐसा टूल जो फ़्रेम की सीमाओं का अंदाज़ा लगाकर इंडेक्स दोबारा बनाता हो।

ऑडियो में ख़राबी की जाँच नहीं होती। मौजूदा ऑडियो पैकेट कॉपी किए जाते हैं और रखे गए वीडियो के हिसाब से काटे जाते हैं। ख़राब या पहले से ग़ायब ऑडियो इस प्रक्रिया से वापस नहीं आ सकता।

सिर्फ़ H.264 और HEVC। यही वे कोडेक हैं जो फ़्रेम को लंबाई वाले प्रीफ़िक्स के साथ रखते हैं, और यह जाँच वही प्रीफ़िक्स पढ़ती है। MJPEG, MPEG-4 Part 2 और दूसरे कोडेक फ़्रेम को अलग तरह से रखते हैं — इस पैमाने से नापने पर वे सब टूटे हुए दिखेंगे, इसलिए यह पेज उन्हें लेने से मना कर देता है।

FAQ