Конечно, то что я сейчас скажу спекуляция, но всегда новые велосипеды без устали пишут днём и ночью те кто в струе технологий потому что технологии дают дуба быстрее чем хотелось бы, и велосипеды эти реально очень быстрые, но только на трассе для формулы один, а на обычной дороге едут так же как и мой деревянный самокат ;)
Кажется я понял идеологические предпосылки этой ветки обсуждения. Давайте я ещё раз озвучу три принципиальных момента.
1 — я знаю и согласен с вами что аппаратное кодирование / декодирование и вывод на экран средствами DirectX / SDL / иного_специализированного_решения более эффективен, однако, как вы сами знаете, эти методы имеют более высокую планку входа, сильнее зависят от аппаратного обеспечения и программной среды в которой исполняется приложение, несут с собой целый ряд побочных задач никак не связанных с основной, но обязательных для решения (первое что приходит в голову — построение графического интерфейса пользователя и реализация несколько отличающегося от традиционно принятого в Windows механизма работы с окнами требуемого по условиям задачи).
2 — поставлена задача получить приложение здесь и сейчас, а не через шесть месяцев которые потребуются на углубленное изучение новых инструментов тем более что ещё через шесть месяцев эти инструменты из-за прихоти менеджмента выпускающих их корпораций могут быть просто списаны в ноль.
3 — после того как инструменты определены работает только логика которая в руках любого человека даст ту архитектуру которая описана:
-декодирование (в отдельном потоке);
-отображение кадров посредством периодической перерисовки формы (процедура перерисовки вызывается в отдельном потоке, сам вызов синхронизируется с потоком графического интерфейса пользователя так как этого требует документация среды разработки);
-собственно рисование кадра реализовано посредством перекрытия обработчика сообщения WM_PAINT так как это самый низкоуровневый способ из доступных при такой реализации.
Таким образом приведённое решение приближено к идеальному в своём классе, но не в глобальном плане (как и любое другое — нет серебряной пули).
Какое-то логическое зацикливание и бег по кругу… ОС построена на очередях… Речь идет об очереди сообщений окна? Сомневаюсь в том что приложения интенсивно не обращающиеся к этому механизму к коим я причисляю и ffmpeg что-то там способны оттяпать. Они способны оттяпать кванты — очередь им до лампочки.
Я отдаю себе отчет в том что при оценке нагрузки 2 + 2 может не оказаться равным 4. Я затрудняюсь определить как именно мне нагрузить процессор что бы тест был признан вами правильным. Очевидно, что мне нужно просто «повесить» систему и отрапортовать о том, что тайминги действительно поплыли. Только тогда все будет признано достоверным.
Синтетический тест нужен что бы отделить пену от воды. Перед вами конкретные цифры которые приведены для отдельно взятой подсистемы которую вы оценили критически. Согласно этим цифрам на рисование тратится 5 мс при стабильных интервалах между кадрами 40 мс. Я в этих цифрах не вижу ни «задержки больше чем 10 мс на кадр» ни того что бы «задержка при показе кадров плавала от 0мс до 40мс». Я согласен с вами в том что аппаратная реализация быстрее. Все это я лишь привожу для того что бы показать что очередь сообщений являясь архаичным, но 100% переносимым по причине своей фундаментальности, механизмом в состоянии выполнять свои функции.
Понаблюдать за работой системы в полной комплектации пока к сожалению не доводилось — негде просто взять столько камер. В статье лишь указано на такую возможность и на то, что полная комплектация начнет упираться в ограничения по транспортировке данных. Кроме того учитывая показатели загрузки процессора приведенные в статье запускать программу обслуживающую полную комплектацию придется как минимум на в два раза более производительном Intel Core2 Quad Q9400 2.66 ГГц. Таким образом поразить вас и себя фразой «все работает» мне не удастся. В дополнение лишь уточню, что тест задержек который я привел проводился для разрешения использованного в статье (1280 x 1024, одно окно просмотра), время работы процедуры WMPaint при этом стабильно находилось на уровне 4,2-5,0 мс, нагрузка на процессор составляла 4-5% (декодирование не проводилось, это был тест без потока — исключительно для проверки подсистемы вывода на экран).
Я не спорю с теорией просто в ряде случаев оптимизация превращается в пугало. Когда поставят задачу запустить 100 видео-потоков на кофеварке я конечно же задумаюсь где сэкономить еще 1 мс родив в результате непереносимого и несопровождаемого монстра эффективное решение. Относительно сферичности теста — запуск шел на железе которое как бы нельзя назвать топовым поэтому обоснованным является предположение о том что тест пройдет не менее успешно и на других машинах. Пока я еще не вижу в себе сил и не пытаюсь написать рендерер сопоставимый с теми что выпускаются компаниями которые специализируются в данной области.
На самом деле насущная проблема — это аппаратное кодирование и, возможно, движения в сторону отлова вертикальной синхронизации. Как я понял это требуют танцев со сборкой и обнимашек с DX. А гуру не хотят делится двумя с половиной строчками кода ;)…
«Опровержение слухов — слушайте факты» (С)
Как и говорилось ранее выводы о наличии дополнительных задержек связанных с работой очереди сообщений, синхронизацией потока с потоком GUI и рисованием на форме являются лишь теоретически верными, но практически не влияющими на работу программы. Тема заинтересовала меня и сегодня провел дополнительное тестирование — замерил время между вызовами WMPaint (то есть время между реальным рисованием кадров в окне) — пытался увидеть указанный вами эффект рывков и плавания задержек. Ничего не подтвердилось. Ни рывков ни дрейфа задержек нет. Во всяком случае на Intel Core2 Duo E8300 2.83 ГГц. Разность отметок между кадрами остается постоянной и равной фактическому периоду с которым поступают кадры — 40 мс. Единичные отклонения амплитудой до 180 мкс могут быть связаны с колебаниями загрузки, точностью отметок времени, описанными вами задержками или фазой Луны. На графике по оси X время в мс, по оси Y задержка между вызовами WMPaint в мс.
Да, найти время и терпение для статьи нелегко. С момента внедрения приложения до выпуска этой статьи прошло 3-4 месяца. Надеюсь занятость не отнимет у нас ваш глубокий опыт в этом вопросе.
Я наверное понял о чем вы — декодирование на стороне карты не только выгоднее из-за аппаратной поддержки но и потому что кадр уже будет сформирован там где будет отображаться? Но мне нужно наложить на него свои элементы и вообще накапливать кадры для сглаживания вывода — получается что использовать оба преимущества я не смогу — только аппаратную поддержку, но не разгрузку шины, верно?
1 — я знаю и согласен с вами что аппаратное кодирование / декодирование и вывод на экран средствами DirectX / SDL / иного_специализированного_решения более эффективен, однако, как вы сами знаете, эти методы имеют более высокую планку входа, сильнее зависят от аппаратного обеспечения и программной среды в которой исполняется приложение, несут с собой целый ряд побочных задач никак не связанных с основной, но обязательных для решения (первое что приходит в голову — построение графического интерфейса пользователя и реализация несколько отличающегося от традиционно принятого в Windows механизма работы с окнами требуемого по условиям задачи).
2 — поставлена задача получить приложение здесь и сейчас, а не через шесть месяцев которые потребуются на углубленное изучение новых инструментов тем более что ещё через шесть месяцев эти инструменты из-за прихоти менеджмента выпускающих их корпораций могут быть просто списаны в ноль.
3 — после того как инструменты определены работает только логика которая в руках любого человека даст ту архитектуру которая описана:
-декодирование (в отдельном потоке);
-отображение кадров посредством периодической перерисовки формы (процедура перерисовки вызывается в отдельном потоке, сам вызов синхронизируется с потоком графического интерфейса пользователя так как этого требует документация среды разработки);
-собственно рисование кадра реализовано посредством перекрытия обработчика сообщения WM_PAINT так как это самый низкоуровневый способ из доступных при такой реализации.
Таким образом приведённое решение приближено к идеальному в своём классе, но не в глобальном плане (как и любое другое — нет серебряной пули).
эм…
0.0
декодирование у меня идет в отдельном потоке и никак не взаимодействует с очередью сообщений. Вы смотрели код вообще?
непереносимого и несопровождаемого монстраэффективное решение. Относительно сферичности теста — запуск шел на железе которое как бы нельзя назвать топовым поэтому обоснованным является предположение о том что тест пройдет не менее успешно и на других машинах. Пока я еще не вижу в себе сил и не пытаюсь написать рендерер сопоставимый с теми что выпускаются компаниями которые специализируются в данной области.Как и говорилось ранее выводы о наличии дополнительных задержек связанных с работой очереди сообщений, синхронизацией потока с потоком GUI и рисованием на форме являются лишь теоретически верными, но практически не влияющими на работу программы. Тема заинтересовала меня и сегодня провел дополнительное тестирование — замерил время между вызовами WMPaint (то есть время между реальным рисованием кадров в окне) — пытался увидеть указанный вами эффект рывков и плавания задержек. Ничего не подтвердилось. Ни рывков ни дрейфа задержек нет. Во всяком случае на Intel Core2 Duo E8300 2.83 ГГц. Разность отметок между кадрами остается постоянной и равной фактическому периоду с которым поступают кадры — 40 мс. Единичные отклонения амплитудой до 180 мкс могут быть связаны с колебаниями загрузки, точностью отметок времени, описанными вами задержками или фазой Луны. На графике по оси X время в мс, по оси Y задержка между вызовами WMPaint в мс.
Тег я думаю тут будет один — C++ код — кнопочка выглядит так </>