घर
Top.Mail.Ru Yandeks.Metrika
मंच: "अन्य";
वर्तमान संग्रह: 2017.03.26;
डाउनलोड करें: [xml.tar.bz2];

नीचे

वीडियो स्ट्रीम बफर संगठन इसी तरह की शाखाएँ खोजें


d2pak ©   (2016-03-28 20:14) [0]

नमस्ते किसी दिए गए आकार के यूएसबी कैमरा से वीडियो स्ट्रीम फ्रेम के चक्रीय बफर को लागू करने का कार्य है। उदाहरण के लिए, हमारे FPS = 30, वीडियो अवधि = 5000 एमएस। (यानी 5 सेकंड)। और जो बफर पर 150 फ्रेम निकलता है, जब 151 फ्रेम आता है, तो इसे शुरुआत में भी लिखा जाता है, लेकिन 1 फ्रेम को ही हटा दिया जाता है, आदि। मुझे बताएं कि किस प्रकार के बफर स्टैक का उपयोग करना है (पेंडो, ...), क्या एल्गोरिदम का उपयोग करना है, कॉलबैक फ़्रेम को सही तरीके से कैसे व्यवस्थित करें? अग्रिम धन्यवाद।



Kilkennycat ©   (2016-03-28 23:01) [1]

CreateStreamBuffer (); जबकि (रोक नहीं) { GetFrame (); अगर (पोज़िशनस्ट्रीम बफ़र> = स्ट्रीमबफ़रसाइज़) स्थितिस्ट्रीमबफ़र = एक्सएनयूएमएक्स; WriteStreamBuffer (); }
वह संपूर्ण एल्गोरिथ्म है।



d2pak ©   (2016-03-29 08:53) [2]

हाँ, धन्यवाद। यह अभी स्पष्ट नहीं है कि क्यों पोज़िशनस्ट्रीमबफ़र = एक्सएनयूएमएक्स; क्योंकि उदाहरण के लिए:
           
बफर का आकार शुरू करें = 8 अंत
/ -------------- ^ -------------- \
- + - + - + - + - + - + - + - + - + - + - + - - -
23|24|25|26|27 |28|29|30|31|32 |33|34
- + - + - + - + - + - + - + - + - + - + - + - - -
<== फ्रेम दिशा ==



DVM ©   (2016-03-29 10:24) [3]

यह सब बफरिंग की आवश्यकता क्यों है? व्यावहारिक अर्थ? गति का पता लगाने के लिए प्रेडिकॉर्ड बफर?
आमतौर पर, दृश्य को बफ़र करने की आवश्यकता नहीं होती है, जैसा कि यह प्रकृति में असतत है, जिसे ध्वनि के बारे में नहीं कहा जा सकता है।
संक्षेप में, एक अतिव्यापी पुश विधि के साथ सामान्य टीक्यू या उसके उत्तराधिकारी।



d2pak ©   (2016-03-29 11:56) [4]


> DVM © (29.03.16 10: 24) [3]

एक कार्यक्रम है जो वर्तमान में एक परिपत्र बफर को इस प्रकार लागू करता है:
एक फ़ाइल 1 मिनट के भीतर लिखी जाती है, फिर दूसरी को सहेजा और लिखा जाता है (1 मिनट के दौरान भी), फिर तीसरा ... फिर जब चौथा बनता है, तो पहला हटा दिया जाता है। किसी प्रकार की घटना हुई, इन फ़ाइलों को एक वीडियो फ़ाइल (2, 3 और 4 टुकड़े) में सरेस से जोड़ा हुआ है, लेकिन परेशानी यह है कि चिपके हुए स्थानों में एक से दो सेकंड का ठहराव होता है, सबसे अधिक कारण प्रोसेसर समय के निर्माण / रिकॉर्डिंग संसाधनों / रिकॉर्डिंग संसाधनों का उपयोग करने पर खर्च होता है। फाइलें बंद करना। इस संबंध में, पूरे वीडियो को gluing के स्थानों में "कूद" के साथ प्राप्त किया जाता है।
फ्रेम के लिए ऊपर वर्णित बफर को व्यवस्थित करने का एक विचार है ताकि इस तरह के कूद न हों। आपका धन्यवाद



d2pak ©   (2016-03-29 11:58) [5]


> व्यावहारिक अर्थ?

वास्तविक व्यावहारिक अर्थ ऊपर वर्णित है।



d2pak ©   (2016-03-29 12:00) [6]


> फ्रेम के लिए ऊपर वर्णित बफर को व्यवस्थित करने के लिए एक विचार है,
> ताकि इस तरह के जंप न हों।

ताकि सही समय पर, हमेशा बफर को पूरी फाइल में उतार सकें।



DVM ©   (2016-03-29 13:08) [7]


> d2pak © (29.03.16 11: 56) [4]


> कुछ हुआ है, इन फ़ाइलों को एक में एक साथ चिपके हुए हैं
> वीडियो फ़ाइल (2, 3 और 4 टुकड़े)

मैंने अनुमान लगाया कि इसका मतलब है कि पूर्वगामी है।


> gluing के स्थानों में, एक से दो सेकंड का ठहराव, सबसे अधिक संभावना है
> उपयोग पर खर्च होने वाले CPU समय के कारण
> फाइल बनाने / लिखने / बंद करने के लिए संसाधन।

यदि आप वीडियो प्राप्त करने वाली उसी स्ट्रीम में ऐसा करने का प्रयास करते हैं, तो निश्चित रूप से अंतराल होगा, यदि एक अलग स्ट्रीम ग्लूइंग से निपटेगा, तो कोई समस्या नहीं होनी चाहिए, अगर कोई एक है, तो संभवतः किसी प्रकार की तार्किक त्रुटि है, ठीक है, या गति के लिए एक विकल्प के रूप में। HDD एक फाइल में समानांतर वीडियो रिकॉर्डिंग और अन्य फाइलों के ग्लूइंग अंशों के लिए पर्याप्त नहीं है। इस मामले में बफरिंग से मदद मिलेगी, लेकिन केवल अगर ग्लूइंग प्रक्रिया दुर्लभ है और इसकी अनुपस्थिति में, संचित बफर में डिस्क को फ्लश करने का समय होगा।



d2pak ©   (2016-03-29 13:16) [8]


> संचित बफर में डिस्क को फ्लश करने का समय होगा।

और यदि वर्तमान बफर नहीं है, लेकिन घटना से इसकी डंप है, तो डंप को बचाएं?



DVM ©   (2016-03-29 13:21) [9]


> d2pak © (29.03.16 13: 16) [8]

मुझे मुहावरा समझ में नहीं आया



d2pak ©   (2016-03-29 13:37) [10]


> इस मामले में बफरिंग से मदद मिलेगी, लेकिन केवल अगर
> यदि gluing प्रक्रिया शायद ही कभी और इसकी अनुपस्थिति में होगी
> संचित बफर में डिस्क को फ्लश करने का समय होगा।

स्मृति में एक बफर डंप बनाने के लिए समय पर यदि आवश्यक हो, तो डिस्क में फ्लश करने का प्रबंधन करने के लिए, ताकि मुख्य बफर के संसाधनों का उपयोग न करें और न केवल डंप को बचाएं।



d2pak ©   (2016-03-29 13:38) [11]

मैं एक फ्रेम बफर के आयोजन का समर्थक हूं, लेकिन अगर यह यथार्थवादी नहीं है, तो क्यों?



DVM ©   (2016-03-29 14:46) [12]


> मैं एक फ्रेम बफर के आयोजन का समर्थक हूं, लेकिन अगर यह है
> वास्तविक नहीं, क्यों?

वास्तव में क्यों नहीं, वास्तव में काफी, इस बारे में कुछ खास नहीं है।



NoUser ©   (2016-03-29 14:51) [13]

d2pak, आप कोड पर आते हैं, आपके विचार, आपकी समस्या का विवरण - वे आपको निर्देशित करेंगे!

प्रश्न:
"लिखित" क्या है और "आगे सहेजी गई" प्रक्रिया का निष्पादन समय क्या हो सकता है, ताकि
चक्र
> एक फाइल 1 मिनट के लिए लिखी गई है। फिर सहेजा गया है
डेटा नहीं खोया?

खतरा.
और फिर "क्यों StatusStreamBuffer = 0?" यह केवल "मैं अध्ययन नहीं करना चाहता हूं - मैं प्रोग्रामर के पास जाऊंगा", और यह, आप जानते हैं, एक पाप है)



Kilkennycat ©   (2016-03-29 16:41) [14]

जैसा कि मैं इसे समझता हूं, विचार भौतिक बदलाव, एक ला रजिस्टर के संदर्भ में काम करता है, इसलिए गलतफहमी है। हालांकि, हार्डवेयर जल्दी से बड़ी मात्रा में भी स्थानांतरित कर सकता है।
केवल यह नफिग आवश्यक नहीं है। सभी भौतिक "अनशिफ्टेड" सॉफ्टवेयर द्वारा नकाबपोश हैं।



Pavia ©   (2016-03-30 11:59) [15]


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

इसके विपरीत, मैं 1 स्ट्रीम छोड़ दूंगा। यह आसान है। सिंक्रोनस सर्किट। 30 ms में सभी कार्य पूरे होने चाहिए। यानी 30 सेकंड में सभी कार्य। इसलिए बड़े कार्य को छोटे में विभाजित करें। और प्रोफाइलर हमेशा दिखाएगा कि वास्तव में क्या धीमा है और इसे कसने के लिए कहां है।

यह देखते हुए कि औसत HDD में 80 IOPS है।
आदिम योजना।
1: फ्रेम दर्ज किया गया था।
2: चमकती हुई गिनती के लिए फ्रेम
3: ग्लूइंग के लिए फ्रेम रिकॉर्ड किया गया था।
90 IOPS की आवश्यकता है और निश्चित रूप से यह धीमा हो जाएगा। थोड़ा फाइनल करें और ऑर्डर होगा।



DVM ©   (2016-03-30 14:15) [16]


> पाविया © (30.03.16 11: 59) [15]


> 90 IOPS की आवश्यकता है

ऑपरेटिंग सिस्टम कैशिंग से IOPS की आवश्यकता कम हो जाएगी



पन्ने: 1 पूरी शाखा

मंच: "अन्य";
वर्तमान संग्रह: 2017.03.26;
डाउनलोड करें: [xml.tar.bz2];

ऊपर





मेमोरी: 0.62 एमबी
समय: 0.017 c
4-1282048057
mc.fly
2010-08-17 16:27
2017.03.26
मेमोरी में बफर इमेज कैसे बनाएं? वीसीएल के बिना।


4-1282063966
Kolj
2010-08-17 20:52
2017.03.26
टर्मिनल सर्वर पर प्रोग्राम के सभी इंस्टेंस को कैसे बंद करें।


15-1459502027
KSergey
2016-04-01 12:13
2017.03.26
विंडोज "बातूनी": एपीआई के माध्यम से एक पुरुष या महिला आवाज सीखते हैं?


11-1265470866
Lirrk
2010-02-06 18:41
2017.03.26
फोंट के साथ समस्या


15-1458782603
Kilkennycat
2016-03-24 04:23
2017.03.26
उपभोक्ता संरक्षण





अफ्रीकी अल्बानियन अरबी भाषा अर्मेनियाई आज़रबाइजानी बस्क बेलारूसी बल्गेरियाई कैटलन सरलीकृत चीनी) चीनी पारंपरिक) क्रोएशियाई चेक डेनिश डच अंग्रेज़ी एस्तोनियावासी फिलिपिनो फिनिश फ्रेंच
गैलिशियन् जॉर्जियाई जर्मन यूनानी हाईटियन यहूदी हिंदी हंगरी आइसलैंड का इन्डोनेशियाई आयरिश इतालवी जापानी कोरियाई लात्वीयावासी लिथुआनियाई मेसीडोनियन मलायी मोलतिज़ नार्वेजियन
फ़ारसी पोलिश पुर्तगाली रोमानियाई रूसी सर्बियाई स्लोवाक स्लोवेनियाई स्पेनिश स्वाहिली स्वीडिश थाई तुर्की यूक्रेनी उर्दू वियतनामी वेल्श यहूदी बंगाली बोस्नियाई
सिबुआनो एस्पेरांतो गुजराती हौसा हमोंग ईग्बो जावानीस कन्नड़ खमेर लाओ लैटिन माओरी मराठी मंगोलियन नेपाली पंजाबी सोमाली तामिल तेलुगु योरूबा
ज़ुलु
Английский Французский Немецкий Итальянский Португальский Русский Испанский