Существует куча способов конвертации видео в Linux , но все они используют ресурс центрального процессора , к примеру :
ffmpeg -i video.avi -target dvd -aspect 16:9 -sameq tempo.mpg
dvdauthor --title -f tempo.mpg -o dvd
dvdauthor -T -o dvd
или как здесь
к примеру , а возможно ли использовать для этой задачи ресурсы видеокарты ?
Нашёл у Nvidia фичу CUDA , вроде бы как для подобных целей пригодную может кто знает как это можно использовать на практике ...
Присоединяюсь к вопросу. В ксакепе гдето полгода назад про это была статья, но там они только хэши считали и показали одну коммерческую кодировалку видео.
Если же данная «проблема» кого-нибудь интересует лишь с теоретической точки зрения, то при кодировании видео технически можно использовать видеокарту несколькими способами:
Декодинг исходника с помощью ASIC'а на видеокарте.
Довольно легко реализуется через VDPAU и функцию VdpVideoSurfaceGetBitsYCbCr(). Основное неудобство — зависимость видеоэнкодера от X11, ибо единственный способ инициализировать VDPAU — VdpDeviceCreateX11(). В аналогичном API для Windows (nvcuvid) хотя бы есть недокументированная возможность использовать cuCtxCreate() вместо рекомендованных cuD3D9CtxCreate()/cuGLCtxCreate() и таким образом избавить себя от проблем с вещами, которые абсолютно не понадобятся в процессе работы программы.
Энкодер специально спроектированный и написанный для работы с видеокартой.
Именно такой проприетарный энкодер H.264/VC1 от NVIDIA включен в CUDA SDK для Windows в форме nvcuvenc.lib и соответствующих хедеров NVEncoderAPI.h и NVEncodeDataTypes.h. Ничего подобно в составе CUDA SDK для Linux не замечено.
В любом случае, качество и эффективность у этого энкодера мягко говоря оставляют желать много лучшего.
Offloading на видеокарту некоторых функций в существующих энкодерах, например в x264.
Теоретически это возможно, но ни одна из множества попыток работы в этом направлении успехом не увенчалась. Причин множество и разработчики x264 уже озвучивали их на различных публичных форумах, найти труда не составит. В общем, все причины сводятся к тому, что архитектура GPU плохо подходит для алгоритмов, которые реально имеет смысл применять при энкодинге.
Так что, лучше забудьте про идею магического ускорения кодирования с помощью видеокарты и либо используйте более быстрые опции кодирования, компенсируя повешением битрейта, либо обновите процессор на что-то более резвое, либо ждите Sandy Bridge, там вроде обещают программируемый ASIC для видеокодирования: http://doom10.org/index.php?topic=717.msg4897#msg4897, возможно в итоге он окажется полезнее, чем видеокарта, но чуда в любом случае ждать не стоит.
>Если коротко — нет, нельзя.
лжец!
а нах куда и опенцл?
и да - под виндой есть - 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 в этом ну совершенно никак не помогут.
Не так уж чтобы совсем невыполним, но ни один из наверное десятка независимых разработчиков, пытавшихся реализовать поддержку 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 потока).
