एच .264 फ्रेम्स मेमोरी लीक कुछ डिकोडर्स

Question

मुझे अपने एसडीके का उपयोग करके एक डीवीआर से H.264 stream प्राप्त हो रहा है। स्मृति रिसाव थे और मैंने सोचा था कि यह एसडीके था जो सभी रिसावों का कारण बनता था। लेकिन जब मैंने स्ट्रीम रिकॉर्ड की और फ्रेम से एक को पढ़ने के लिए फ्रेम चलाया (बिना किसी तीसरे पक्ष के डीएलएस के), मैंने देखा कि समस्या डीएलएल नहीं बल्कि धारा ही है।

अजीब पर्याप्त, DivX H264 Decoder एकमात्र कोडेक है जो स्मृति रिसाव का कारण नहीं बनता है, लेकिन जब स्ट्रीम लंबे समय तक चलती है, तो कभी-कभी DivX डिकोडर भी क्रैश हो जाता है। मैं Microsoft DTV-DVD Video Decoder का उपयोग करना पसंद करूंगा लेकिन यह बड़ी मेमोरी लीक का कारण बनता है और बहुत सारे फ्रेम छोड़ देता है। मैंने कोशिश की है कि कई अन्य H.264 डिकोडर्स वैसे ही व्यवहार करते हैं।

मैंने कुछ h.264 parsers का उपयोग करके कुछ अन्य समस्या मुक्त धाराओं की तुलना में h.264 frames की जांच की लेकिन मुझे लॉग से कुछ भी स्पष्ट नहीं देखा।

चूंकि मेरी समस्या h.264 फ्रेम संरचना के बारे में है, इसलिए मैंने FramesFromFileSourceFilter नामक एक स्रोत फ़िल्टर तैयार किया है जिसे आप नीचे डाउनलोड कर सकते हैं।

http://www.akaydin.com/directshow/FramesFromFileSourceFilter.zip

यह एक Visual Studio 2008 परियोजना है और सभी निर्भरता अपेक्षाकृत स्थित फ़ोल्डर (264 फ्रेम सहित) में ज़िप फ़ाइल में शामिल कर रहे हैं। इसलिए, आपको केवल परियोजना को संकलित करना है, आउटपुट को regsvr32.exe के साथ पंजीकृत करें और फ़िल्टर को किसी भी एच .264 डीकोडर के साथ चलाएं जिसे आप GraphEdit या GraphStudio से चाहते हैं। उदाहरण ग्राफ नीचे हैं।

इसके अलावा h264 फ्रेम लिंक जो नीचे वीएलसी द्वारा चलाया जा सकता है पर एक भी कच्चे h264 फ़ाइल के रूप में उपलब्ध हैं (मूल के बाद से गलत एफपीएस के साथ 12 एफपीएस) था।

http://www.akaydin.com/directshow/stream.zip

प्रश्न:

क्या डिवएक्स विकोडक को छोड़कर कई प्रसिद्ध H264 डिकोडर्स साथ स्मृति रिसाव समस्याओं का कारण हो सकता है। इस धारा के साथ क्या गलत है?

अद्यतन 1

पढ़ना डेटा धागा निकाल दिया जाता है और कार्यक्षमता किसी भी प्रतिरोधक और झंडे का उपयोग किए बिना FillBuffer में चले गए। समस्या वही बना है।

http://www.akaydin.com/directshow/FramesFromFileSourceFilterUpdate1.zip

अद्यतन 2

Update1 FillBuffer() समारोह जो कुछ समस्या पैदा कर रहा था में Sleep() उपयोग कर रहा था। अब मैंने Sleep() हटा दिया है और ~ 12 एफपीएस रखने के लिए SetTime() का उपयोग किया है। इसने Microsoft DTV-DVD Video Decoder के ड्रॉप फ्रेम मुद्दों को भी हल किया लेकिन स्मृति समस्याओं को हल नहीं किया।

http://www.akaydin.com/directshow/FramesFromFileSourceFilterUpdate2.zip

मेमोरी वृद्धि केवल Working Set पर होता है। Virtual Bytes और Private Bytes स्थिर प्रतीत होता है।क्या Working Set स्मृति वृद्धि के कारण हो सकता है जो केवल Microsoft DTV-DVD Video Decoder के साथ होता है?

Answer 1

आप अपने चर

BYTE* m_buffer; 
DWORD m_bufferSize; 
bool isFrameReady; 

के आसपास किसी भी तुल्यकालन ऐसा नहीं करते हैं और वे दो समवर्ती धागे से किया जाता है। आप इस गलत आवंटन/विलोपन और/या पहुंच उल्लंघन पर अपने कोड दुर्घटनाग्रस्त होने से बस अपनी याददाश्त को रिसाव करते हैं। आपके डीएलएल का डीबग बिल्ड आपको अपना परीक्षण चलाने के दौरान "ढेर भ्रष्टाचार" चेतावनी दिखाकर इंगित करता है। रनटाइम व्यवहारकर्ता डिकोडर्स और पर्यावरण के साथ भिन्न हो सकता है, हालांकि यह निश्चित रूप से तय करने के लिए एक गंभीर बग है।

उदाहरण के लिए, आप अपने थ्रेड में CAutoLock cAutoLock(m_pLock); का उपयोग कर सकते हैं जो फ़ाइल से डेटा पढ़ने के दौरान थ्रेड एक्सेस स्ट्रीमिंग को रोकने के लिए बफर भरता है।

ध्यान दें कि आप एक ही बफर पॉइंटर में अगली फ्रेम को बिना किसी जांच के पढ़ते हैं कि क्या पहले आवंटित स्मृति मुक्त हो गई है या नहीं, आप संभवत: एक रिसाव छोड़ने वाले सूचक को ओवरराइट करते हैं।

स्मृति रिसाव/कार्य सेट अद्यतन: अब, जब कोड मुद्दों को हल कर रहे हैं, अवांछित क्रम व्यवहार Working Set आकार में वृद्धि हुई है। यह एक रिसाव नहीं है। यह एक संकेत है कि विंडोज प्रक्रिया को प्राथमिकता के रूप में मानता है (क्यों नहीं? यह सक्रिय है और स्मृति के साथ काम करता है) और इसके प्रदर्शन को सुविधाजनक बनाने के लिए इस प्रक्रिया की ओर अधिक वास्तविक पृष्ठ फेंकता है। प्रक्रिया मेमोरी मेट्रिक्स को एप्लिकेशन में मेमोरी लीक के अनुरूप कैसे किया जाता है, इस बारे में अच्छी व्याख्या के लिए this answer देखें।

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