Под очередью я понимаю ваш рендерер, построенный на очереди оконных сообщений. Причем тут ffmpeg, применительно к очереди?

Увидите как реально работает очередь.

Для начала, достаточно будет с помощью, того же, ffmpeg декодировать какой-нибудь видео-клип размером 1280х1024 и убедиться что тайминги также стоят как вкопанные.

Я в этих цифрах не вижу ни «задержки больше чем 10 мс на кадр» ни того что бы «задержка при показе кадров плавала от 0мс до 40мс»..
Так, я все понял. Исходя из ваших ответов, вы не правильно представляете себе как работают современные операционные системы. Задержки берутся не из воздуха, задержки появляются тогда, когда планировщик распределяет общее время между несколькими работающими потоками. Если у вас нет загрузки системы, то и задержкам взяться не от куда.
Все это я лишь привожу для того что бы показать что очередь сообщений являясь архаичным, но 100% переносимым по причине своей фундаментальности, механизмом в состоянии выполнять свои функции.
Вы этим тестом показали лишь то, что без нагрузки процессор занят только вашей «логикой» и выполняет ваш код без прерываний на параллельные задания. Все. Больше этот тест ничего не показывает. Как только вы напишите «боевой» код и нагрузите процессор, ваши тайминги сразу же поплывут.

Ну и зачем такие синтетические тесты?! Рендерер, в моем понимании, это компонент, который сглаживает неравномерную загрузку, в том числе. Как можно говорить о том, что он плавно работает, если нет загрузки?!.. И потом 4% и 4мс, при холостом выводе, это очень много. Нужно ориентироваться на 0%.и микро секунды. Ну сами подумайте, вы выводите 25 раз в секунду с паузами между этими выводами. Для современного процессора и для видео процессора это вечность, они просто стоят и курят в сторонке. Для ссылки: средненький аппаратный декодер спокойно декодирует H264 со скоростью 500 кадров в секунду, а уж выводить на экран битмапки 1280х1024 — это тысячи.

Да я сам читаю, что не нужно переусложнять там, где можно обойтись более простым решением. Так все-таки, вы можете подтвердить, что ваши одна HD камера и 9 SD которые работаю одновременно для кругового обзора, дают такой же результат, как вы привели. Если да, то замечательно и больше тут ничего не нужно, задача решена.

Теория здесь как-раз важнее, так как у вас нет возможности проверить ваш софт на огромном парке машин. Никто не спорит, что на отдельно взятой машине, в вакуме, в идеальных условиях, где кроме одного приложения с одним окном видео больше ничего не работает, вы увидите вышеописанную картину. Вы не приводите ни разрешение видео, ни разрешение с которым оно показывается, ни текущую загрузку CPU в вашем тесте. Загрузите машину хорошо, процентов на 50, выведите 2 HD видео одновременно и еще 8 SD дополнительно. Желательно проделать данный эксперимент на 10 машинах с разной конфигураций. Только, когда во всех этих условиях вы получите идеальный результат, можно будет о чем-то говорить. Количество машин, на которых мы отлаживали систему, порядка сотни, и поверьте, написать хороший рендерер, это не такая простая задача как вам кажется.

Как раз в занятости и проблема. Тема мультимедиа обширна и требуют некоторого начального багажа для понимания. Из-за этого всегда стоит дилемма, писать полностью с нуля, чтобы было интересно читать всем, или подразумевать что статья уже для продвинутых, сужая этим охват.
Приведу пример: вот хотим мы написать статью о том как правильно писать фильтры разных типов под DirectShow. Вроде бы все знаем, кода куча — короче, садись и пиши. И тут начинается. А там COM.
А о нем нужно рассказывать?! А там жуткая многопоточность, навязанная самой архитектурой. А про многопоточность нужно рассказывать, или предполагается, что человек знает что это такое и представляет какие есть примитивы в WinAPI ?! Для быстрой разработки у нас кругом свои обертки и врапперы. А наверное интереснее будет на голом С?! Значит нужно все переписывать и тестировать. В общем, я хочу сказать, нужно четкое понимания для кого писать и какая задача ставится. Для себя, я уже давно понял, что написание статей это отдельная большая и кропотливая работа, которая требует уйму времени.

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

Нет ли случаем полезных ссылок под рукой по DXVA силами ffmpeg?
Нет, вся информация собиралась по крупицам. Советую посмотреть исходники утилиты ffmpeg, файл ffmpeg_dxva2.c, если не ошибаюсь. Благо он один и вся работа с DXVA там сконцентрирована.
И, кстати, DirectShow вообще не используете?
У нас написана библиотека для проигрывания различных данных и используется в софте наподобие нелинейных редакторов. Библиотека написана на С++ и архитектура там своя, а вот компоненты библиотеки; источники, демуксеры, декодеры и т.д. используют как на ffmpeg, так и DirectShow фильтры. За счет единого интерфейса их можно комбинировать как угодно друг с другом. Т.е. сплиттер может быть ffmpeg, а декодер DirectShow, и наоборот. Рендереры все свои. В результате можно играть данные произвольных форматов, вперемешку, с произвольной скоростью, вперед и назад.
Какие преимущества/недостатки в использовании ffmpeg + Angle перед DirectShow?
ffmpeg — более гибкий, всегда можно посмотреть что и где неправильно работает, поддержка кучи экзотических форматов используемых в камерах и оборудовании.
DirectShow — проще использовать, но: платные компоненты, медленный старт-стоп, жрет ресурсы системы (память, хендлы и т.д.). Пришлось изобретать wrapper для фильтров, наподобие струпцины, чтобы пихать и забирать данные.

Да. Microsoft продолжает продвигать свои продукты и разработки и их можно понять — конкуренция. По-этому, что бы делать interop DXVA (проприетарная технология которая, в свою очередь, требует Direct-X) и OpenGL (которая используется в QT) приходится компилировать QT с Angle. Так можно в рамках Angle конвертировать Direct3D поверхности в OpenGL поверхности, которые, в свою очередь, находятся в видео-памяти, без копирования.

Попробую задать вопрос понятнее: где можно посмотреть какие теги поддерживаются и как оформлять ответы. Если ли подсказка? Я тут первый раз просто.

С вертикальной синхронизацией сейчас все плохо, т.к. сигнал эмулируется на современных цифровых интерфейсах и может быть задан каким угодно. Он оставлен для обратной совместимости со старым софтом. Проблема не в точности таймера, можно использовать хоть Sleep, проблема в точности планировщика потоков windows, то, как быстро он пробуждает поток после поступления сигнала. Тут лучше использовать мультимедийный таймер. Как только вы задаете частоту его срабатывания, windows меняет размер кванта потоков данного процесса в соответствии с заданной частой таймера со стандартной (порядка 15мс) до заданной.Другими словами, если вы создадите в процессе мультимедийный таймер с частотой срабатывания 1мс, то все потоки начнут планироваться и срабатывать с заданной частотой 1мс. Сам таймер можно использовать любой. В DirectShow например он выбирается динамически, сначала пытается брать часы источника (если есть) потом часы рендерера (если есть).

Я готов ответить, но:
1. Не пойму что нужно, пример кода? Типа взяли буфер из памяти и нарисовали в нужном месте через Direct3D? Не многовато кода будет в ответе?
2. Где можно посмотреть теги или что-то подобное для оформления ответов на habr-е?

Еще хотелось бы добавить по поводу вывода сразу на поверхности в видеопамяти:
В плане интерфейса, нет практически никаких ограничений. Мы например используем QT и рендерим через ANGLE.Так вот видео поверхности, без проблем, можно комбинировать с QT виджетами и рисовать над и под видео.

По скорости вывода битмапов GDI сравним с DirectX. В DirectX просто больше контроля данного процесса.
По поводу Intel: я их привел просто для примера. Под windows вообще лучше использовать DXVA, тогда вам будет все-равно что использовать для ускорения Intel, NVidia, AMD. Он сам позаботится об этом. Для проверки скорости я бы не рекомендовал ffplay. Я не знаю как он реализован внутри. Для сравнения лучше использовать windows mdia player, mpc, vlc или вообще GraphEdit из WindowsSDK. Выбрать в настройках поддержку аппаратного ускорения и самому убедиться в загрузке.

Это было сказано применительно к кодированию, в общем. Я видел код, и пытаюсь объяснить вам в чем будут проблемы при таком подходе. На практике, нужно очень хорошо представлять что кроется за вызовом той или иной функции. Direct-X более детерминированный путь по контролю за выводом графики чем очередь сообщений. Задача сгладить все неровности в распределении времени системой. Далее, я вас уверяю, что вы заблуждаетесь насчет практики и реально все работает и не жрет CPU. Про рекламу я не понял.

Ну так устроен ffmpeg/ Для кодирование все работает именно так, как вы хотите, все «внизу». Для декодирования это невозможно, так как ffmpeg не заниматся рендерингом. Он не знает какие API, платы, вы будете использовать для показа и как плотно интегрированы с GUI. Вам нужно, немного, ему помочь с аппаратными буферами, куда нужно будет класть декодированные кадры.

Возможно требуется собрать с поддержкой QSV, например, это да. Просто — с точки зрения API. Все что от вас требуется — это настроить нужный аппаратный кодек, как и любой другой, и преобразовать кадры в формат NV12.

Сложно сказать без конкретики, нужно смотреть. В идеале, декодирование HD отнимает 0% — 2% CPU. Кодирование побольше, так как, просто копирование (поставка) раскомпрессированого потока уже будет что-то занимать. Плюс, по словам Intel, например, некоторые промежуточные операции выполняются на CPU. При декодировании CPU почти не участвует. Могу лишь предположить, что вы пытаетесь копировать раскомпрессированный кадр обратно в RAM (copyback) чего делать не стоит. При декодировании, все, чем занимается CPU — это копирует несколько килобайт сжатого потока в буфера декодера и в нужный момент вызывает Blit. CPU там нечего делать.

К счастью, для вас, кодирование с ускорением, с использованием ffmpeg, намного проще чем декодирование. Для кодирования вообще ничего особенного не нужно делать, только указать qsv encoder, например. Декодирование с ускорением, существенно сложнее (для ffmpeg, но можно использовать DirectShow). Это связано с тем, что декодирование (в общем виде) происходит во внутренние буфер видеокарты (copy-back очень затратная операция), и эти буфера нужно будет готовить и обслуживать самостоятельно. Но, при желании, в этом можно разобраться.