Время в кадре : чем проверить?

[Александр Недилько]

Делаю сейчас фиксацию времени в кадре под DirectShow. Метод довольно точный, если не плавает тактовая частота процессора. Но хотелось бы как-то проверить. Вот думаю снимать часы  . Вот только какие есть , чтоб сами достаточно точные и с миллисекундами?

[Net]

Как я понял, Вам нужно в момент сьемки на кадр поставить точное время сьемки этого же кадра?
И это будет одиночный кадр (раз в несколько секунд) или видеопоток? Подозреваю, что видео...

[Александр Недилько]

Это будет видео. Смысл таков: вначале мы синхронизируем часы компа с точным временем. Но они из-за своей неточности начнут "уходить" да и "шаг" их крупноват. Поэтому в начале съемки мы синхронизируем с часами счетчик высокого разрешения и в процессе съемки выводим в кадр время, основанное уже на его показаниях. Т.е. если синхронизацию часов с точным временем произвести как можно ближе к началу съемки, то точность должна быть удовлетворительна. Но вот насколько стабильно работает счетчик высокого разрешения (он завязан на тактовую частоту процессора)? Это и хочу проверить.

[Andrey Prokopovich]

Делаю сейчас фиксацию времени в кадре под DirectShow. Метод довольно точный, если не плавает тактовая частота процессора. Но хотелось бы как-то проверить. Вот думаю снимать часы  . Вот только какие есть , чтоб сами достаточно точные и с миллисекундами?

А RTC компа не имеют милисекундных значений? Может с ними сравнивать? Они-то не зависят от процессора совсем.

[Net]

Счетчик тактов RDTSC будет точным. Неточности будут при приведении тиков в секунды, из-за того что в современных процах тактовая частота может изменяться самим процессором по причине терморегулирования (естественно эта фича отключается ). Да и из-за неточного определения частоты проца тоже можно потерять - на 1 Ггц проце прогрешность в 1 мгц даст 1 мс.

Вот интересная есть еще тема на wasm.

[Александр Недилько]

Сейчас это стало чуть по другому называться, а вот как работает - не знаю. Вместо RDTSC используется PerfCounter. И в нем количество тиков в секунду не меняется. Насчет изменения частоты не знал - поэтому это тоже вопрос, будет ли это влиять на PerfCounter. Также интересно измерить время задержки в обработке кадра, ведь мы фиксируем все же не время поступления кадра в камеру, а время поступления кадра в фильтр. Это все хочу приспособить к наблюдениям покрытий, поэтому системные часы в топку  .
Так что нужно провести исследования с секундомером в кадре - какие они бывают , какова их точность?

[Штрель > 1]

Синхронометр, однако, нужен. (с) Чукча.

Коротко говоря, Вам нужно проверить стабильность кварца в компе? Может, попробовать синхронизацию через GPS?
Моменты синхронизации известны, поправки тоже. Потом сравниваете интервалы по Вашим тикам и по GPS.

Вообще, идея "архинужная и архиважная" (с) Ленин.

[Штрель > 1]

Нет таких часов. Даже если и есть, то инерционность индикатора все замоет. Слишком у Вас разрешение высокое заложено.

Не могли бы поподробнее, как реализовано все в железе. Я бы поимел, если можно.

[Net]

Сейчас это стало чуть по другому называться, а вот как работает - не знаю. Вместо RDTSC используется PerfCounter.

QueryPerformanceCounter и QueryPerformanceFrequency? Обе через rdtsc работают. Вторая вроде выдает константу, которую вычисляет при загрузке ядра или еще на каком-то этапе , главное что однократно. А можно и самому вычислять кол-во тиков в секунду, скажем, раз 500, и все усреднить. Тогда проблема перевода должна отпасть.

Также интересно измерить время задержки в обработке кадра, ведь мы фиксируем все же не время поступления кадра в камеру, а время поступления кадра в фильтр.

Согласен, тут вопрос более философский. Но что входит в это время - регистрация сигналов на матрице, пересылка в фильтр. Думаю, время это будет всегда одинаковое, либо различаться микросекундами. Разве что еще в разрешении вопрос.

p.s. Всё это разрешение в 0.5-1 мс должно дать "аж бегом"

[Александр Недилько]

Да никакого железа  . Чистый софт. Имеем любой источник видео сигнала ( веб-камера, тв-тюнер с охранкой), вообщем, любое, что имеет дрова, которые будут работать под DirectShow. А мой граббер все запишет вместе со временем. Нужно иметь объективные данные, как искажается время при записи. А потом может что и до ума довести. Но нужна точка отсчета, так сказать.

[Serj]

Ой как интересно! Сразу несколько вопросов:
1) Видеосигнал в формате DirectShow, т.е. поддерживается любая вебкамера или ТВ-тюнер?
2) Откуда берёте эталонное время? NTP, GPS, другое?

Может, попробовать синхронизацию через GPS?
Моменты синхронизации известны, поправки тоже. Потом сравниваете интервалы по Вашим тикам и по GPS.

Про синхронизацию часов компа с GPS можно глянуть тут: http://www.geocities.com/kiwi_36_nz/kiwi/kiwi.htm

Ещё можно поснимать светодиод на выходе приёмника настроенного на спец.радиостанцию, РВМ например (4996кГц, 9996кГц) - с 10 до 20, и с 40 до 50 минуты каждого часа транслирует секундные метки. хотя в Ростове не уверен что её берёт.

Вообще, идея "архинужная и архиважная" (с) Ленин.

Эт точно! (с) Сухов

[Штрель > 1]

Да никакого железа  . Чистый софт. Имеем любой источник видео сигнала ( веб-камера, тв-тюнер с охранкой), вообщем, любое, что имеет дрова, которые будут работать под DirectShow. А мой граббер все запишет вместе со временем. Нужно иметь объективные данные, как искажается время при записи. А потом может что и до ума довести. Но нужна точка отсчета, так сказать.

Понятно! Аппаратная задержка сигнала в тракте.

Если у вас заложены миллисекунды, то задержка в тракте, скорее всего, будет микросекунды, и я бы не заморачивался.

Теоретически решение задачи имеется такое: Вы снимаете экран монитора, видеокамерой. В результате видите картинку в картинке: уменьшающееся изображение монитора. Смотрите на код времени в соседних картинках, разница показаний даст Вам задержку в тракте.

[Алексей_Лосюк]

Делаю сейчас фиксацию времени в кадре под DirectShow. Метод довольно точный, если не плавает тактовая частота процессора. Но хотелось бы как-то проверить. Вот думаю снимать часы . Вот только какие есть, чтоб сами достаточно точные и с миллисекундами?

Если нужно просто снимать равномерно идущие часы с целью проверить стабильность тактовой частоты процессора, то подошёл бы кварцевый частотомер-хронометр. Такие приборы имеются в лабораториях. Только нужен вариант с газоразрядными индикаторами: светодиодные (а тем более жидкокристаллические) могут иметь чересчур большое время перехода из одного состояния в другое ("время отклика"). И чтобы кварц был термостабилизирован.

Если же речь идёт о проверке качества синхронизации аппаратуры с текущим временем, то потребуется ещё и приёмник-компаратор. Он позволяет синхронизироваться с эталонными сигналами частоты и времени, передаваемым специальными радиостанциями, с погрешностью не более 1 мс. В областных городах имеются центры метрологии и стандартизации, и в них такое оборудование имеется.

К сожалению, бытовые модели GPS-приёмников для этой цели непригодны. Такой GPS может "сообщать" не текущие моменты времени, а те моменты времени, в которые был им произведён замер координат и скорости. Тут нужны профессиональные модели GPS – типа того, что описан в работе http://www.navgeocom.ru/oem/projects/astro/index.htm.

Но, может быть, поискать способ решения проблемы не "в лоб", а каким-нибудь более простым "обходным" путём? Остроумный способ исследования задержки сигнала цифровой видеокамерой нашёл, например, Иван Мхитаров (http://www.starlab.ru/showpost.php?p=101776&postcount=108). Стабильность кадровой развёртки видеокамеры исследовали астрономы Одесского университета (http://www.astronomy.odessa.ua/article/teleoserv1.pdf). Подобную работы выполнил также Gerhard Dangl (Австралия): http://www.dangl.at/ausruest/vid_tim/vid_tim1.htm.

[Алексей_Лосюк]

Ещё можно поснимать светодиод на выходе приёмника настроенного на спец.радиостанцию

Только при этом тракт приёмника внесёт свою задержку (мой вносил на 1.9 мс), и светодиод внесёт свою (величина зависит от марки диода). Кроме того, диод будет вспыхивать от каждой помехи, да и фронт сигнала будет "плавать". Короче, такая самоделка будет не очень надёжной...

РВМ, например, (4996кГц, 9996кГц) - с 10 до 20, и с 40 до 50 минуты каждого часа транслирует секундные метки. Хотя в Ростове не уверен что её берёт.

В 1970-е годы в Ростове-на-Дону РВМ принималась. Экспериментально установленный научный факт... (Я там в университете учился.)

[Александр Недилько]

Спасибо всем откликнувшимся, буду изучать ссылки!

[Александр Недилько]

Нет , ну я конечно знал, что вебки в смысле передачи данных - не совсем то, но такое... Я понимаю, когда кадр дропается, но когда кадр как-бы новый , но на самом деле старый,тот же самый, что и предыдущий и так несколько раз - не понимаю, может это особенность этой модели - Philips ToU Cam 730. Короче говоря, надо экспериментировать с тв-тюнером и аналоговой камерой.

[Александр Недилько]

Сейчас обратил внимание, что номер фрейма тот же самый. Странно

[Штрель > 1]

Мда, интересный результат. Сама тормознутость вебки была бы не так страшна, если была бы постоянна. А уж про задержку в микросекунды речь вообще не идет.

[Александр Недилько]

Ну про микросекунды речь никогда и не шла  . Этож не чисто железяное решение. Тут можно говорить только о десятках миллисекунд - около 30-40.

[Serj]

  Да уж, очень странно. То что номера фреймов на записи 81-81-81-82 похоже на выпадение, но вот то что на экране везде по 00 совсем неожиданно. А при записи картинка на экране обновляется?

Короче говоря, надо экспериментировать с тв-тюнером и аналоговой камерой.

Дык этого есть у меня. Надеюсь программа некоммерческая. Тогда высылайте.