Сорри, даже не глянул, раненько было :dntknw:...

Пробовал на чистой системе и без доп железа с юсб - типа гпс и т.д.?

Кодек в первом посту - один из стабильнейших по распаковке МПЕГа!
В том видео, которое ты присылал, рывков не было. Отсюда делаем вывод что у тебя просто бардак в кодеках или DirectShow, возмоно какой-то левый ActiveX компонент это вытворяет. Попробуй удали все кодеки из системы и поставь только необходимые!

Опа-па... Серьезно, не было рывков???
Очень интересный вывод... Спасибо!
Пошел разбираться с кодеками :)

2 ashu

А как железка ведет себя при использовании ждущего режима? Здесь довольно часто грешили на USB-устройства и их некорректную отработку выхода из хибернейта, да и с CG во всех его версиях на моем, во всяком случае железе, система стартовать из ждущего так и не смогла...

Ждущий режим не пробовал, спящий, вроде бы, отрабатывалал хорошо.
Сейчас железка пока отключена - до полного разбирательства с системой... Когда верну, тогда еще раз проверю.

Кстати, при отключенной даззле CG при запуске валится с ошибками. Надо б как-то поправить - чтобы или не запускался вовсе, или красиво сообщал об отсутствии видео-захвата.

Впринципе так и должно быть - уточню!

Проверь еще по ошибке, по которой CG вываливается при выключении компа - не мешает, конечно, но это как-то не очень красиво ;)

Пытаюсь, на рабочем ноуте все окей. Попробую на другой машине!

Здравствуйте, начитался вашего сайта, начал собирать карпутер на "intel глюк" материнке.

Купил Dazzle 130, поставил драйвера правильные.
Заценил прогу CamGrabber, по-моему супер прога! мне как программеру сразу куча хотелок придумалось (не удалять avi файлы при старте, а удалять их только по условию, возможность выбирать битрейт для записи), часть я их и сам реализую. Кстати, судя по Spy++ и другим мыслЯм, прога написана на Delphi, я на ней же программлю, мож помочь с чем-то? Я могу.

Обнаружил несколько проблемок:

1. Пробую записывать видео CamGrabber, он пишет в разрешенке 640х480 нормально, правда кушая 35-40% процессора. Но если на секунду весь процессор окажется занят какой-то другой работой (к примеру, запуском centrafuse), то дальше CamGrabber начинает кушать всего 3-5% процессора, при этом время от времени пропуская кадры. Как только начинается запись нового видео-файла (таймаут истекает 300 секунд по умолчанию который), ситуация опять та же - 35-40% процессора и все кадры на месте. Эту ситуацию можно обойти, только выставив у CamGrabber'а Real time приоритет.

DVCCap поступает честнее, он дерется за процессорное время, но как только процессор освобождается, он нормализует работу.

2. Еще у меня сложилось полное впечатление, что CamGrabber в любом случае декодирует идущий в него видео поток, поскольку даже при
Cam1MotionDetect=false
загрузка процессора не зависит от того, в свернутом режиме работает CamGrabber или нет. Может можно как-то не декодировать видео поток?
DvcCap декодирует его только если показывает видео, что очень четко видно по загрузке процессора.

3. ну и совсем нахальство, можно прикрутить выбор битрейта для аппаратного кодирования? :-)

(ушел искать сурсы от прог видеозаписи)
...
(чуть позже.)
покурил TVideoGrabber и все понял :-)

Привет. Спасибо.

1. CamMotionDetect тут не причем. Потом не декодируется если включено аппаратное кодирование, Cam1MPEGDevice=True.
Программа действительно написана на Дельфи 2005.
2. Насчет приоритета - можно всмтроить такую фичу в интерфейс настройщика и менять приоритет CG. Давно уже думаю это сделать.
3. Насчет выбора битрейта для аппаратного кодирования - он есть, вызывается свойством потока. У меня на моем даззле по крайней мере именно так.

И все таки не очень отчетливо понял про загрузку проца. В чем именно проблема? При свертывании в трей?