История изменений
Исправление wolverin, (текущая версия) :
последний - тот что с камеры последним считался, для архива одни требования по потоку, для просмотра текущего видео - другие.
может 10 фпс или 100 мс это нисколько, но 30 фпс или 33 мс - это 33% времени ничего не делается кроме чтения с камеры и это пока предельное разрешение (пока фактически не используемое, используется вариант в 15-20 фпс, хотя можно и все 30 брать на меньшем разрешении), может cedrus удастся прикрутить для h264 и что то придумать аппаратное для mjpeg и не переделывать потом очередь, которая окажется не очередь.
и про вектор думаю, но это нужно будет постоянно удалять-вставлять данные, на векторе я держу массив временных меток соответствующих ардесам на диске, для быстрого поиска места воспроизведения архива, но там и скорость записи как раз «нисколько» и однопоточная задача
Исправление wolverin, :
последний - тот что с камеры последним считался, для архива одни требования по потоку, для просмотра текущего видео - другие.
может 10 фпс или 100 мс это нисколько, но 30 фпс или 33 мс - это 33% времени ничего не делается кроме чтения с камеры и это пока предельное разрешение (пока фактически не используемое, используется вариант в 15-20 фпс, хотя можно и все 30 брать на меньшем разрешении), может cedrus удастся прикрутить для h264 и что то придумать аппаратное для mjpeg и не переделывать потом очередь, которая окажется не очередь.
и про вектор думаю, но это нужно будет постоянно удалять-вставлять данные, на векторе я держу массив временных меток соответствующих ардесам на диске, для быстрого поиска место воспроизведения архива, но там и скорость записи как раз «нисколько» и однопоточная задача
Исправление wolverin, :
последний - тот что с камеры последним считался, для архива одни требования по потоку, для просмотра текущего видео - другие.
может 10 фпс или 100 мс это нисколько, но 30 фпс или 33 мс - это 33% времени ничего не делается кроме чтения с камеры и это пока предельное разрешение (пока фактически не используемое, используется вариант в 15-20 фпс, хотя можно и все 30 брать на меньшем разрешении), может cedrus удастся прикрутить для h264 и что то придумать аппаратное для mjpeg и не переделывать потом очередь, которая окажется не очередь.
и про вектор думаю, но это нужно будет постоянно удалять-вставлять данные, на векторе я держу массив временных меток соответствующих ардесам на диске, для быстрого поиска времени архива, но там и скорость записи как раз «нисколько» и однопоточная задача
Исправление wolverin, :
последний - тот что с камеры последним считался, для архива одни требования по потоку, для просмотра текущего видео - другие.
может 10 фпс или 100 мс это нисколько, но 30 фпс или 33 мс - это 33% времени ничего не делается кроме чтения с камеры и это пока предельное разрешение (пока фактически не используемое, используется вариант в 15-20 фпс, хотя можно и все 30 брать на меньшем разрешении), может cedrus удастся прикрутить для h264 и что то придумать аппаратное для mjpeg и не переделывать потом очередь, которая окажется не очередь.
и про вектор думаю, но это нужно будет постоянно удалять-вставлять данные
Исходная версия wolverin, :
последний - тот что с камеры последним считался, для архива одни требования по потоку, для просмотра текущего видео - другие.
может 10 фпс или 100 мс это нисколько, но 30 фпс или 33 мс - это 33% времени ничего не делается кроме чтения с камеры и это пока предельное разрешение (пока фактически не используемое, используется вариант в 15-20 фпс, хотя можно и все 30 брать на меньшем разрешении), может cedrus удастся прикрутить для h264 и что то придумать аппаратное для mjpeg и не переделывать потом очередь, которая окажется не очередь.