घर
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();

while (not Stop) {
  GetFrame();
  If (PositionStreamBuffer >= StreamBufferSize)
     PositionStreamBuffer = 0;
  WriteStreamBuffer();
}

вот и весь алгоритм.



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

ага, спасибо. только не понятно почему PositionStreamBuffer = 0; , т.к. например:
           
begin      buffer size = 8      end
  /--------------^--------------\
--+--+--+--+--+--+--+--+--+--+--+--
23|24|25|26|27 |28|29|30|31|32 |33|34
--+--+--+--+--+--+--+--+--+--+--+--
    <== frame direction ==



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

Зачем эта вся буферизация нужна? Практический смысл? Буфер предзаписи для детектора движения?
Обычно виде не нуждается в буферизации, т.к. по своей природе дискретно, чего не скажешь о звуке.
По сути вопроса обычная TQueue или ее наследник с перекрытым методом Push.



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


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

есть программа, которая на данный момент реализует циклический буфер следующим образом:
Пишется файл в течении 1 мин., далее сохраняется и пишется второй (также в течении 1 мин), далее третий... Потом когда создается четвертый, первый удаляется. Произошло какое то событие, эти файлы склеиваются в один видео файл (2, 3 и 4 фрагменты), но вот беда, в местах склейки пауза в одну - две секунды, скорее всего из-за затраченного процессорного времени на использование ресурсов создания/записи/закрытия файлов. В связи с этим, целое видео получается с "перескоками" в местах склейки.
Есть идея организовать выше описываемый буфер для фреймов, чтобы не было таких перескоков. Спасибо.



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 фрагменты)

Я угадал значит, предзапись и есть.


> в местах склейки пауза в одну - две секунды, скорее всего
> из-за затраченного процессорного времени на использование
> ресурсов создания/записи/закрытия файлов.

Если пытаться это делать в том же потоке, который принимает видео, то разумеется будут пропуски, если же отдельный поток будет заниматься склейкой, то проблемы не должно быть, если же она есть, то вероятно есть какая то логическая ошибка, ну или как вариант скорости 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]


> Буферизация в этом случае поможет, но только в том случае,
>  если процесс склейки будет возникать редко и в его отсутствии
> накопленный буфер будет успевать сброситься на диск.

Чтобы успевал сбрасываться на диск, если в необходимый момент времени создавать дамп буфера в памяти, чтобы не отнимать и не использовать ресурсы основного буфера, а сохранять лишь только дамп.



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

Я сторонник организовать именно буфер фреймов, но если это не реально, то почему?



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


> Я сторонник организовать именно буфер фреймов, но если это
> не реально, то почему?

Почему не реально, реально вполне, ничего в этом особенного нет.



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

d2pak, ты код давай, свои мысли, свою постановку задачи - тебя и направят!

प्रश्न:
Что такое "Пишется" и какое может быть время выполнения процедуры "далее сохраняется", чтобы
चक्र
> Пишется файл в течении 1 мин., далее сохраняется
не терял данные?

खतरा.
А то "почему PositionStreamBuffer = 0?" говорит лишь о "не хочу учиться - пойду в программисты", а это, знаешь ли, грех ))



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

Я так понимаю, мысля работает в плане физического сдвига, а-ля регистр, отсюда и непонимание. Впрочем, аппаратные средства могут и большие объемы быстренько сдвинуть.
Только это вот нафиг не нужно. Вся физическая "несдвинутось" маскируется программно.



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


> Если пытаться это делать в том же потоке, который принимает
> видео, то разумеется будут пропуски, если же отдельный поток
> будет заниматься склейкой, то проблемы не должно быть, если
> же она есть, то вероятно есть какая то логическая ошибка,
>  ну или как вариант скорости HDD недостаточно для параллельной
> записи видео в один файл и склейки фрагментов других файлов.
>  Буферизация в этом случае поможет, но только в том случае,
>  если процесс склейки будет возникать редко и в его отсутствии
> накопленный буфер будет успевать сброситься на диск

Я бы напротив оставил 1 поток. Так проще. Синхронная схема. Все задачи должны завершаться за 30 мс. Т.е. суммарно все задачи за 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.63 एमबी
समय: 0.029 c
2-1437985170
ग्रे-ग्रे
2015-07-27 11:19
2017.03.26
डेल्फी XE8 प्रोजेक्ट एरर, क्रिएटिन VCL फॉर्म एप्लीकेशन


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


2-1437734169
कोको-239
2015-07-24 13:36
2017.03.26
पीसी विवरण


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


2-1437193956
xayam
2015-07-18 07:32
2017.03.26
डेल्फी XE8 + Android





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