Здравствуйте. Имеется задача реализовать циклический буфер фреймов видео потока с usb камеры, заданного размера. Например наш FPS=30, VideoDuration=5000 ms. ( т.е. 5 сек). И того получается 150 фреймов на буфер, когда прилетает 151-й фрейм он также пишется в начало, но самый 1-й фрейм удаляется  и т.д. Подскажите какие типы стеков буфера использовать (fifo, ...), какие алгоритмы задействовать, как правильно организовать Callback фреймов? Заранее спасибо.

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

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

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

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

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

> Практический смысл?

собственно практический смысл описан выше.

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

чтобы в необходимый момент, всегда иметь возможность выгрузить буфер в цельный файл.

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


> Произошло какое то событие, эти файлы склеиваются в один
> видео файл (2, 3 и 4 фрагменты)

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


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

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

> накопленный буфер будет успевать сброситься на диск.

а если не текущий буфер, а по событию его дамп, затем уже сохранение дампа?

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

Я не понял фразы

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

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

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

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

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

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

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

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

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

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

Я бы напротив оставил 1 поток. Так проще. Синхронная схема. Все задачи должны завершаться за 30 мс. Т.е. суммарно все задачи за 30 секунд. Вот и делить большую задачу на маленькие. И профилировщик всегда покажет, что именно тормозит и где надо подкрутить.

Если учитывать, что средний HDD имеет 80 IOPS.
Примитивная схема.
1: Кадр записал.
2: Кадр для склеки считал
3: кадр для склейки записал.
Требует 90 IOPS и конечно будет тормозить. Чуть доработать и будет порядок.

> Pavia ©   (30.03.16 11:59) [15]


> Требует 90 IOPS

Кэширование операционной системы уменьшит необходимое количество IOPS