Я сравнивал скорость с ffplay просто для того что бы убедиться в том что производительность программы сопоставима с производительностью приложения от разработчика библиотеки. Иными словами я хотел убедить сам себя в том что я правильно работаю с функциями библиотеки и не вношу существенных задержек в процесс из-за того что рисую традиционными средствами. Этой проверки для меня достаточно — то есть я не ставил задачу сравнить решения примененные в программе со всеми возможными решениями. Для визуального восприятия привожу снимки экрана полученные только что. По ним видно что ffplay, программа и VLC имеют приблизительно одинаковые скорости. Незначительные отличия связаны с дрейфом загрузки. Аппаратное ускорение не включалось. Точнее я не знаю включено ли оно в VLC или где либо еще.
Да, это не DX. Это сделано по совсем другим принципам. Безусловно DX более прогрессивен чем рисование на форме однако программа не нарушает «законов» системы и не смотря на то что это менее производительное решение программа выполняет свои функции. Что на самом деле радует — можно сделать то что делает DX и иные тяжелые по уровню входа решения просто рисуя на форме.
Про рекламу я имел ввиду фразу «по словам Intel» — слова это хорошо, но ими оперировать не совсем честно в дискуссии ибо в этом случае обсуждение превращается в конкурс цитат в котором конечно же победит компания Intel — я не настолько мощен что бы завалить ее своими словами ;)
Не совсем понял как можно заблуждаться насчет практики если я вижу что нагрузка процессора при работе программы и при работе ffplay практически одинаковая — я же не голословно это утверждаю.
Безусловно это просто если слово просто означает «напишите код в соответствии с API аппаратного ускорителя». Но мне не ясно почему они просто не могли реализовать это в самом низу? То есть почему я не мог указать в словаре что хочу использовать аппаратное ускорение и продолжать использовать имеющийся код вызывающий avcodec_decode_video без изменений, но с большей производительностью? Зачем они сделали так, что я должен модифицировать код? Безусловно на это были причины. Просто жаль.
Я не пытаюсь ничего обратно копировать — где вы это увидели? Все остальные приложения включая сам FFMPEG — тоже этим занимаются? Я допускаю что неверно интерпретирую данные, но ваше альтернативное объяснение пока никак не ложится на то что наблюдается. Про CPU и Blit не понял. CPU в любом случае лишь исполнительное устройство. Копирует и вызывает если можно так выразится программа. Да, она так и делает — вызывает функцию декодирования когда приходит новая порция сжатого потока до тех пор пока функция не сообщит о том что кадр получен. После этого готовый кадр копируется из буфера декодера. После этого в нужный момент вызывается BitBlt. Все это происходит в коде. Теория и рекламные статьи — это хорошо, но я вижу то что описал.
Обсуждение достоинств и недостатков того или иного инструмента уведет нас в совсем ненужные дебри. Для меня достаточно того что «новые и бесплатные версии» жрут мое время — я должен выкачать все эти гигабайты, войти в учетную запись и… получить продукт который Hello world собирает аномальное количество времени и то после того как ему перебрали половину двигателя. Я уверен что это не ваш случай и на вашем оборудовании и с вашим опытом все работает хорошо.
Относительно RAII покажите мастер-класс: выделите проблемный участок и приведите ваше видение его реализации. Может мы просто не понимаем друг друга.
Особенно настораживает документация FFMPEG в которой прописано о необходимости "...build, configure with..." — то есть эта шутка вроде как по умолчанию не стоит и нам предлагают пересобрать FFMPEG (
Посмотрел. Нет, гугл все тот же. Поверьте — если по отношению к вам как знающему человеку уместно такое обращение — в случае включения аппаратной поддержки придется конкретно полазать под капотом — одним волшебным флажком там не обошлось.
Если бы задержка плавала 0-40 мс это было бы видно так что у людей бы глаза повыбивало. Судя по всему описанные вами эффекты в моем случае не проявляются, а вполне обоснованные предположения о задержках весьма преувеличены.
Значит не тот гугл я смотрел, пойду перечитаю почему кодирование показалось мне сложным. Странно, если там все так хорошо и аппаратная поддержка реализована на сколько-нибудь значимом количестве железок почему просмотр и кодирование видео как правило не сильно быстро происходят? Во всяком случае не с нагрузкой 0% как вроде бы должно было быть, а приблизительно с такой нагрузкой с какой работает и моя программа…
Как вы совершенно правильно пишите все операции подготовки выполняются у меня в отдельном потоке обслуживающим камеру. Вывод идет в другом потоке и не делает с кадром ничего кроме самого вывода (от этой операции никуда не уйти учитывая назначение этого потока). Задержек такого порядка как вы описали я не наблюдал. Относительно максимальной быстроты вывода: как я уже сказал если поток вывода вывел кадр за 5 мс и спит 35 мс, то чем это отличается от ситуации когда он вывел кадр за 1 мс и спит 39 мс?
1 У меня ещё не было возможности разобраться с этим. Если у вас есть наработки я думаю былобы интересно их оформить статьей.
2 DX я не использую — пока ещё не было необходимости разбираться с этим — на мой вкус он достаточно тяжёл для входа. Посылка сообщения через функцию синхронизации действительно останавливает поток, я об этом знаю и это не влияет на производительность — поток который шлёт эти сообщения либо рисует либо спит — зачем мне рисовать быстрее если кадры идут с такой частотой с которой он справляется и после рисования все равно спит? Артефакты на видео (если вам не сложно укажите место где вы их заметили что бы я смог дополнительно проанализировать этот момент) скорее всего связаны не с работой программы, а с тяжёлыми условиями транспорта данных.
Пока больше приглядывался именно к кодированию как к более нагружающему процессу и разбор кода для FFMPEG по данному вопросу не внушал оптимизма — для его поддержки придется скорее всего переписывать значительную часть кода что не совсем радует.
Почему то у меня отложилось в памяти что проблемы синхронизации исчезли вместе с мониторами отличными от LCD… Или такое понятие и сама проблема все еще имеется?
Про рекламу я имел ввиду фразу «по словам Intel» — слова это хорошо, но ими оперировать не совсем честно в дискуссии ибо в этом случае обсуждение превращается в конкурс цитат в котором конечно же победит компания Intel — я не настолько мощен что бы завалить ее своими словами ;)
Не совсем понял как можно заблуждаться насчет практики если я вижу что нагрузка процессора при работе программы и при работе ffplay практически одинаковая — я же не голословно это утверждаю.
Относительно RAII покажите мастер-класс: выделите проблемный участок и приведите ваше видение его реализации. Может мы просто не понимаем друг друга.
2 DX я не использую — пока ещё не было необходимости разбираться с этим — на мой вкус он достаточно тяжёл для входа. Посылка сообщения через функцию синхронизации действительно останавливает поток, я об этом знаю и это не влияет на производительность — поток который шлёт эти сообщения либо рисует либо спит — зачем мне рисовать быстрее если кадры идут с такой частотой с которой он справляется и после рисования все равно спит? Артефакты на видео (если вам не сложно укажите место где вы их заметили что бы я смог дополнительно проанализировать этот момент) скорее всего связаны не с работой программы, а с тяжёлыми условиями транспорта данных.