Пользовался kmplayer, он тоже ffdshow DXVA (как и mpc-hc) использует. Тут дело вкуса, мне показалось, что он слишком перегружен настройками, кроме того у него какая-то мутная биография, потом какие-то другие люди стали его развивать после большого перерыва. Но это субъективно, если у вас работает и все хорошо, то и замечательно.
На Quad — возможно. На Core 2 Duo E8500 это не всегда помогало, кроме того изредка сталкивался с артефактами декодирования, которые возникали именно в многопоточной версии. Конечно баги постепенно правили и может уже такого нет, но принципиально это проблемы не снимало.
Про новый CoreAVC я не в курсе, а где-то год назад он славился своей скоростью, я интересовался этим вопросом. Но его ругали за качество декодирования, по видимому это было вызвано какими-то оптимизациями связанными с компромиссами по качеству. Он может дать дополнительный резерв по производительности, но врядли может принципиально снять проблему на слабом железе. Мне кажется куда проще купить low end дискретную видеокарту и забыть о возможных тормозах. Еще один момент — этот кодек платный.
Да, настроить можно и конечно же как и большинство проектов он использует готовые компоненты, в частности кодеки. Но я бы не стал преуменьшать сложность и этого проекта, проект весьма серьезный и объемный, в этом можно убедиться посмотрев на его исходный код.
Утверждение, что что-то созданное на основе другого будет иметь изъян. В программировании модульный принцип является основополагающим. В данном конкретном случае могут быть частные причины, но это не может быть принципом.
Насчет DXVA я вас понял, здесь рассматривается Windows платформа.
Интересно какие именно кодеки для H.264 вы исользуете?
MPC-HC — это можно сказать MPC с предустановленным набором кодеков. Для H264 там используется модификация ffdshow с поддержкой DXVA (но есть и простой вариант). В отличии от кодек паков все эти кодеки в системе не видны, они видны только внутри MPC-HC.
Не буду утверждать, что кодек паки это однозначное зло, есть конечно масса положительных примеров использования, но есть и обратное, причем в изобилии. Я бы предпочел без необходимости кодеки в систему не внедрять.
SMPlayer и UMPlayer базируются на MPLayer, поэтому он тут незримо присутствует. Но DXVA кодеки MPlayer не поддерживают. Говорить лучше они или лучше не буду, я лично проблем с ними практически не имел, а главный недостаток — отсутствие поддержки DXVA в кодеках.
Это конечно интересно посмотреть, но реально можно будет сравнить, когда до пользователей дойдет этот инструмент. А вообще рекомендую видео с Herb Sutter — там демонстрируется работа моделирования частиц, GFlops-ы на экран выводятся и на разном железе показано как это все работает, какое ускорение.
PPL (Parallel Patterns Library)
Это аналог OpenMP от Microsoft, реализован в виде библиотеки средствами языка C++11 (lambda-выражения передаются параметрами функций). Весьма вероятно, что спецификации открыты, но учитывая недостаточную распространенность C++11 и существование OpenMP это дело возможно есть только в vs2010.
Намного более интересна другая вещь — C++ Accelerated Massive Parallelism (C++ AMP). Это замена OpenCL, но с использованием C++, как и PPL — это просто библиотека, которая работает в рамках языка C++11. Это дело недавно демонстрировали в работе, синтаксис немного показали, будет доступно в следующей версии Visual Studio. Важно, что спецификация будет точно открытой.
Некоторые ссылки:
C++ Accelerated Massive Parallelism
Человек с Kinect-ом не может мгновенно переместится в другое место, за счет этого они так быстро совмещают (регистрируют в терминологии реверса) облако точек с существующей сеткой. Для совмещения используется алгоритм ICP, это по сути специальный тип минимизации для которой самое важное — хорошее начальное приближение. При локальном движении им удалось достаточно эффективно находить это начальное приближение.
Вот и получается, что обновление сетки носит локальный характер, а для работы с большими моделями типа целых зданий нужно реализовать эффективный механизм подгрузки геометрии, ну и конечно LOD нужен, чтобы видеть то что вдали находится.
Не знаю уж насколько критична проблема выбора начального приближения у них, но например за счет добавления акселерометров можно точность выбора начального приближения повысить, тем самым сократив число итераций ICP и ускорив алгоритм. Но повторю — может это и не является узким местом.
В общей задаче reverse engineering CAD модели (облако точек -> сетка -> параметрические поверхности) первым шагом строят сетку из облака точек, там существует ряд подходов, можно поискать по словам «triangle mesh point cloud». Как часть этих алгоритмов или как отдельный метод существуют подходы для аппроксимации нормалей. Как вариант — берем точку с соседями и пытаемся построить поверхность, потом вычисляем нормаль. Искать можно по «point cloud normals».
Для серьезных задач найдется масса применений. Интерес подогреется и можно будет выпускать версию подороже не для игровых применений с более продвинутой камерой — разрешение побольше, оптика с настройками, разрешение по глубине побольше.
Да, если сканировать с высоким разрешением, то поток данных может быть огромным. При работе сканера постобработку оставляют на потом, а здесь им удалось строить модель сразу, что очень экономно, т.к. они нигде не хранят поток точек 640x480 30 fps, но с другой стороны возникнет ограничение на сложность самой сетки, когда система начнет подтормаживать, тогда придется применять всякие ухищрения.
По детализации мне кажется они упираются в число сканирующих точек в датчике глубины. Еще конечно влияет зашумленность данных и необходимость аппроксимации нормали к поверхности по окрестности точки, т.е. получается, что разрешение по точкам должно быть с некоторым запасом. Можно найти в интернете фотки комнаты подсвеченной kinect в ик диапазоне — там видна плотность точек, она не очень высокая. Но с другой стороны сблизи от камеры она может быть достаточно большой, если поставить правильную оптику. Было бы очень удобно — провести kinect близко перед объектом и получить более детальную модель.
С движением не просто, тут надо строить модель и отслеживать ее параметры. Собственно Kinect SDK это умеет, но он это делает более хитрым и дешевым способом, не прибегая к построению и совмещению 3D поверхности. Возможно, что при наличии подобного нового алгоритма и отслеживание движения вывести на новый уровень.
В этом видео показан трекинг пальцев руки и вероятно, что он делается новым методом.
В играх наверняка постараются использовать. В прошлом году они показывали возможности взаимодействия с предметами из реального мира, но там было что-то простое — типа показываем фотку и листок с изображением забирает себе виртуальный персонаж. Здесь же можно передавать небольшие 3D предметы и использовать их в игре. Загрузка больших пространств — это уже задача посложнее, но думаю и этому найдут применение.
Насчет DXVA я вас понял, здесь рассматривается Windows платформа.
MPC-HC — это можно сказать MPC с предустановленным набором кодеков. Для H264 там используется модификация ffdshow с поддержкой DXVA (но есть и простой вариант). В отличии от кодек паков все эти кодеки в системе не видны, они видны только внутри MPC-HC.
Не буду утверждать, что кодек паки это однозначное зло, есть конечно масса положительных примеров использования, но есть и обратное, причем в изобилии. Я бы предпочел без необходимости кодеки в систему не внедрять.
Herb Sutter: Heterogeneous Computing and C++ AMP
C++ Accelerated Massive Parallelism
Microsoft brings GPU computing to C++ with C++ AMP (есть слайды)
На channel9 можно еще видео по С++ AMP найти.
PPL (Parallel Patterns Library)
Это аналог OpenMP от Microsoft, реализован в виде библиотеки средствами языка C++11 (lambda-выражения передаются параметрами функций). Весьма вероятно, что спецификации открыты, но учитывая недостаточную распространенность C++11 и существование OpenMP это дело возможно есть только в vs2010.
Намного более интересна другая вещь — C++ Accelerated Massive Parallelism (C++ AMP). Это замена OpenCL, но с использованием C++, как и PPL — это просто библиотека, которая работает в рамках языка C++11. Это дело недавно демонстрировали в работе, синтаксис немного показали, будет доступно в следующей версии Visual Studio. Важно, что спецификация будет точно открытой.
Некоторые ссылки:
C++ Accelerated Massive Parallelism
Человек с Kinect-ом не может мгновенно переместится в другое место, за счет этого они так быстро совмещают (регистрируют в терминологии реверса) облако точек с существующей сеткой. Для совмещения используется алгоритм ICP, это по сути специальный тип минимизации для которой самое важное — хорошее начальное приближение. При локальном движении им удалось достаточно эффективно находить это начальное приближение.
Вот и получается, что обновление сетки носит локальный характер, а для работы с большими моделями типа целых зданий нужно реализовать эффективный механизм подгрузки геометрии, ну и конечно LOD нужен, чтобы видеть то что вдали находится.
Не знаю уж насколько критична проблема выбора начального приближения у них, но например за счет добавления акселерометров можно точность выбора начального приближения повысить, тем самым сократив число итераций ICP и ускорив алгоритм. Но повторю — может это и не является узким местом.
По детализации мне кажется они упираются в число сканирующих точек в датчике глубины. Еще конечно влияет зашумленность данных и необходимость аппроксимации нормали к поверхности по окрестности точки, т.е. получается, что разрешение по точкам должно быть с некоторым запасом. Можно найти в интернете фотки комнаты подсвеченной kinect в ик диапазоне — там видна плотность точек, она не очень высокая. Но с другой стороны сблизи от камеры она может быть достаточно большой, если поставить правильную оптику. Было бы очень удобно — провести kinect близко перед объектом и получить более детальную модель.
В этом видео показан трекинг пальцев руки и вероятно, что он делается новым методом.