The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
Захват данных с камеры, !*! steveg, 16-Мрт-15, 20:25  [смотреть все]
Здравствуйте!!  У меня такого рода вопрос. На руках камера Evidence, с которой я библиотекой live555 забираю поток rtp over udp. Камера наведена на консоль с текущим временем системы, но время , когда кадр получен библиотекой, отличается на 0.3 секунды от времени с консоли (текущего системного). Естественно, время кадра больше, чем время на кадре. С чем бы это могло быть связано? С особенностями камеры, с особенностями потока, или это все библиотека портит?
  • Захват данных с камеры, !*! Pahanivo, 08:05 , 17-Мрт-15 (1) +1
    > С особенностями камеры, с особенностями потока,
    > или это все библиотека портит?

    Все портит ваша глупость и непонимание того что кадр не может одновременно проецироваться на матрицу, цифроваться, постобрабатываться, компоноваться в поток, передоваться и записываться - все эти операции последовательны! (мож что забыл, дак простите)

  • Захват данных с камеры, !*! PavelR, 08:09 , 17-Мрт-15 (2)
    > Здравствуйте!!  У меня такого рода вопрос. На руках камера Evidence, с
    > которой я библиотекой live555 забираю поток rtp over udp. Камера наведена
    > на консоль с текущим временем системы, но время , когда кадр
    > получен библиотекой, отличается на 0.3 секунды от времени с консоли (текущего
    > системного). Естественно, время кадра больше, чем время на кадре.

    Я думаю, что есть вариант, который вы даже не пытались рассмотреть - время на экране ("время с консоли") и "текущее системное" - не одно и то же. Т.е., как вариант, тормозит вывод времени на консоль.

    > С чем бы это могло быть связано? С особенностями камеры, с особенностями потока,
    > или это все библиотека портит?

    Объясните пожалуйста, почему вы интересуетесь вопросом и что собираетесь делать со всем этим дальше.


    В общем случае, рекомендую начать задумываться "как это работает, детально".

    • Захват данных с камеры, !*! steveg, 11:13 , 17-Мрт-15 (3)
      >[оверквотинг удален]
      >> системного). Естественно, время кадра больше, чем время на кадре.
      > Я думаю, что есть вариант, который вы даже не пытались рассмотреть -
      > время на экране ("время с консоли") и "текущее системное" - не
      > одно и то же. Т.е., как вариант, тормозит вывод времени на
      > консоль.
      >> С чем бы это могло быть связано? С особенностями камеры, с особенностями потока,
      >> или это все библиотека портит?
      > Объясните пожалуйста, почему вы интересуетесь вопросом и что собираетесь делать со всем
      > этим дальше.
      > В общем случае, рекомендую начать задумываться "как это работает, детально".

      Проблема в том,что все, что вы оба мне перечислили уже рассматривалось. Rtp over udp рассматривается как поток , наилучший для real-time приложений. Оцифровка, передача, декодирование, задержки в портах и в канале тоже учитываются, но это бред, если задержка 0.3 секунды существует. ну 0.05 еще более менее. для real-time 3 десятых это ахтунг. Время на консоли тормозит - вполне может быть, но иначе я не знаю,как узнать задержку.. может вы подскажете?

      имхо , либо камера не готова работать в real-time и не может выдавать данные оперативно ( а это и значит, что формируется изо на матрице, выполняются все преобр и тд - долго, как справедливо отметил первый отписавшийся), либо библиотека. Вопрос по сути и был в этом. Всем,кто спрашивал о задержках с evidence советовали переходить на rtp over udp, то есть с камерой я уже ничего не могу поделать

      • Захват данных с камеры, !*! steveg, 11:16 , 17-Мрт-15 (4)
        Если подскажете ,как засекать время формирования кадра точно - буду оч благодарен. Время в системе синхронизируется ntpd. На камере левое время.
      • Захват данных с камеры, !*! Pahanivo, 16:07 , 17-Мрт-15 (6)
        > Проблема в том,что все, что вы оба мне перечислили уже рассматривалось. Rtp
        > over udp рассматривается как поток , наилучший для real-time приложений. Оцифровка,
        > передача, декодирование, задержки в портах и в канале тоже учитываются, но
        > это бред, если задержка 0.3 секунды существует. ну 0.05 еще более
        > менее. для real-time 3 десятых это ахтунг. Время на консоли тормозит
        > - вполне может быть, но иначе я не знаю,как узнать задержку..
        > может вы подскажете?

        родной, о каких 0.05 задержки ты говоришь когда это скорость оцифровки одного кадра только на матрице ...
        переходи на VHS и аналоговые камеры )) там задержки минимальны ))

        > имхо , либо камера не готова работать в real-time и не может
        > выдавать данные оперативно ( а это и значит, что формируется изо
        > на матрице, выполняются все преобр и тд - долго, как справедливо
        > отметил первый отписавшийся), либо библиотека. Вопрос по сути и был в
        > этом. Всем,кто спрашивал о задержках с evidence советовали переходить на rtp
        > over udp, то есть с камерой я уже ничего не могу
        > поделать

        реал тайм это как бы не система где все происходит мгновенно - скорость света с которой проходит пакет по кабелю как бы никто не отменял, а она таки конечная величина, те задержку дает. в реал тайм системе тебе гарантируют некоторую максимальную величину времени реакции системы на запрос, боюсь что ты просто неправильно понимаешь термин real-time как таковой.

      • Захват данных с камеры, !*! pavlinux, 01:15 , 05-Апр-15 (7)
        > для real-time 3 десятых это ахтунг.

        Операционка реалтайм? Дрова камерные реалтайм? либа реалтайм? Нет? Нуахуле :)

        1. Ядрище 3.2.68 + RT патч.
        2. До усрачки (10 мкс) тюнинговать систему (latency), таймауты, буфера, сеть.
        3. Рефорсить библиотеку под реалтаем.
        4. Железо нормальное (PPC, MIPS, ну на крайняк ARM), с аппаратными RT часами
        ...
        65536. на асме переписать кодек;

        года полтора траха.

        вот тогда и готово для продкашена.  

    • Захват данных с камеры, !*! steveg, 13:41 , 17-Мрт-15 (5)
      Или предпоследнее сообщение вот тут -> http://ffmpeg.gusari.org/viewtopic.php?f=12&t=762

      Вы целиком одобряете?




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру