Конвертация видео с помощью GPU - возможно ли ?

Присоединяюсь к вопросу. В ксакепе гдето полгода назад про это была статья, но там они только хэши считали и показали одну коммерческую кодировалку видео.

Если коротко — нет, нельзя.

Если же данная «проблема» кого-нибудь интересует лишь с теоретической точки зрения, то при кодировании видео технически можно использовать видеокарту несколькими способами:

1. Декодинг исходника с помощью ASIC'а на видеокарте.

   Довольно легко реализуется через VDPAU и функцию VdpVideoSurfaceGetBitsYCbCr(). Основное неудобство — зависимость видеоэнкодера от X11, ибо единственный способ инициализировать VDPAU — VdpDeviceCreateX11(). В аналогичном API для Windows (nvcuvid) хотя бы есть недокументированная возможность использовать cuCtxCreate() вместо рекомендованных cuD3D9CtxCreate()/cuGLCtxCreate() и таким образом избавить себя от проблем с вещами, которые абсолютно не понадобятся в процессе работы программы.

2. Энкодер специально спроектированный и написанный для работы с видеокартой.

   Именно такой проприетарный энкодер H.264/VC1 от NVIDIA включен в CUDA SDK для Windows в форме nvcuvenc.lib и соответствующих хедеров NVEncoderAPI.h и NVEncodeDataTypes.h. Ничего подобно в составе CUDA SDK для Linux не замечено.

   В любом случае, качество и эффективность у этого энкодера мягко говоря оставляют желать много лучшего.

3. Offloading на видеокарту некоторых функций в существующих энкодерах, например в x264.

   Теоретически это возможно, но ни одна из множества попыток работы в этом направлении успехом не увенчалась. Причин множество и разработчики x264 уже озвучивали их на различных публичных форумах, найти труда не составит. В общем, все причины сводятся к тому, что архитектура GPU плохо подходит для алгоритмов, которые реально имеет смысл применять при энкодинге.

Так что, лучше забудьте про идею магического ускорения кодирования с помощью видеокарты и либо используйте более быстрые опции кодирования, компенсируя повешением битрейта, либо обновите процессор на что-то более резвое, либо ждите Sandy Bridge, там вроде обещают программируемый ASIC для видеокодирования: http://doom10.org/index.php?topic=717.msg4897#msg4897, возможно в итоге он окажется полезнее, чем видеокарта, но чуда в любом случае ждать не стоит.

>Конвертация видео с помощью GPU - возможно ли ?

Теоретически сегодня - легко. Практически - пока не реализовано. С нетерпением ждём, пока реализуют. Хоть на том же OpenCL.

> Если коротко — нет, нельзя. ..........

убил .

Майкрософт это запатентовали, поэтому нельзя)

>Если коротко — нет, нельзя.
лжец!
а нах куда и опенцл?
и да - под виндой есть - http://www.badaboomit.com/
а вообще давно можно было бы слабать либу для того же опенцл чтоб можно было заставить считать произвольную софтину на гпу-шке
наиболее вкусно на мультимедии-архиваторах-шифровании
если такая либа будет - можно будет забить на ограниченный вдпау и иже с ним

>Майкрософт это запатентовали, поэтому нельзя)
пруф?
как они умудрились запатентовать вычисления на гпу?
скорее уж теже железнячники запатентуют

http://www.theinquirer.net/inquirer/news/1742037/microsoft-granted-gpu-video-...

ох лол - пиндосы - дегенераты )
впрочем всем пох как обычно

>лжец!

Насколько я понял вопрос был практический, а не теоретический.

и да - под виндой есть - http://www.badaboomit.com/

Это относится ко второму пункту, да и по качеству примерно ему же и соответствует.

а вообще давно можно было бы слабать либу для того же опенцл чтоб можно было заставить считать произвольную софтину на гпу-шке

Расчеты на GPU пригодны лишь для очень узкого круга задач, конкретно для алгоритмов где можно легко применять очень большое количество потоков (сотни и более), выполняющих одинаковые инструкции и работающих с похожими данными. Для всего остального GPU намного медленнее любых современных general-purpose процессоров.

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

наиболее вкусно на мультимедии-архиваторах-шифровании

По архиваторам и шифрованию ничего не скажу, ибо как-то не было возможности рассмотреть это в деталях, но для видеокодирования GPU подходит очень плохо, так как процесс в основе своей требует последовательного исполнения. Единственная часть этого процесса, которая на первый взгляд подходит для реализации на GPU — motion estimation, но это лишь на первый взгляд, ибо из качественных алгоритмов этого процесса на GPU легко реализуется лишь exhaustive search, но аналогичных результатов за намного меньшее количество операций достигает successive elimination algorithm (SEA), который уже плохо подходит для GPU. Да и плюс к этому при выполнении motion estimation важно принимать во внимание и начинать поиск отталкиваясь от предиктора вектора, который основывается на векторах соседних блоков в растровом порядке, а это, по очевидным причинам, сводит на нет возможности параллелизации поиска.

можно будет забить на ограниченный вдпау и иже с ним

И можно узнать, каким образом?

На данный момент, VDPAU — единственный способ добраться до декодера на видеокарте. Обойти его ограничения можно только переписав драйвер и реализовав новый, несовместимый с VDPAU, API для доступа к PureVideo-чипу, ни OpenCL, ни CUDA в этом ну совершенно никак не помогут.

пруф?

Они получили патент именно на метод выполнения motion estimation на GPU: http://www.google.com/patents?id=u9HHAAAAEBAJ&zoom=4&pg=PA4#v=onepage&q&f=false.

вывод - в обозримой перспективе сабж невыполним , я правильно понял ?

>вывод - в обозримой перспективе сабж невыполним

Не так уж чтобы совсем невыполним, но ни один из наверное десятка независимых разработчиков, пытавшихся реализовать поддержку GPU для x264 в той или иной форме, так и не представил что-либо стоящее и работоспособное. Так что в ближайшей перспективе вероятность действительно очень сомнительная.

С кодированием видео все понятно, но если нужно перекодировать видео из одного формата в другой, нельзя ли использовать аппаратное декодирование, а кодировать уже через CPU?

Странно, почему до сих пор в тот же ffmpeg не добавили CUDA: ведь технически ничего сложного в переносе алгоритмов параллельного кодирования mpeg4 с CPU на GPU нет.

что-то ты явно гонишь
надо будет погонять как-нибудь этот бадабум - благо винда под боком есть

>нельзя ли использовать аппаратное декодирование, а кодировать уже через CPU?

Можно и очень легко, было бы желание у кого-нибудь это написать. Если бы мне оно было нужно, то однозначно бы сделал, но так как на Linux-машинах я использую wine, Avisynth и avs2yuv для фильтрации и соответственно декодирования, то такая функция для меня будет ну совершенно бесполезной.

ведь технически ничего сложного в переносе алгоритмов параллельного кодирования mpeg4 с CPU на GPU нет

Эмм, и какой способ threading'а использует ffmpeg для кодирования mpeg4?

Правильный ответ — slice-based, а, как известно, каждый новый слайс сбрасывает все предикторы и соответственно значительно снижает эффективность кодирования, примерные цифры для x264: http://git.videolan.org/?p=x264.git;a=blob;f=doc/threads.txt.

И это даже не говоря о том, что реализовать весь процесс кодирования даже слайса на видеокарте просто невозможно.

Ну, не знаю, как про x264, а вот для «MPEG-1/2 and H.264 only» в mplayer повышение количества потоков сильно увеличивает скорость кодирования (я на своем четырехъядернике обычно кодирую в 4 потока).

Для кодирования H.264 в ffmpeg и mencoder'е как раз используется libx264, для MPEG-1/2 используется собственный энкодер в ffmpeg/libavcodec.

Я и не отрицал повышение скорости, под эффективностью я подразумевал эффективность «сжатия» aka quality per bit.

Кстати, x264 ведь вроде бы основан на вейвлетах? В этом случае вполне реально распараллелить процесс сжатия.

Какие вейвлеты? Откуда им там вообще взяться?

H.264 — стандартный DCT-based кодек, а x264 всего лишь кодирует в него, так что уж что-что, а вейвлеты к x264 совершенно не имеют отношения.

sorry, вейвлетами из самых распространенных кодеков сжимает dirac. И этот кодек имеет реализацию через CUDA, если википедия не врет.