Прошу помощи в оптимизации видеокодека H.264. Имеются готовые исходники кодека (JM 12.2). Но они работают очень медленно. Может кто подскажет, как его ускорить, с чего начать, что можно оптимизировать. Любая информация будет очень полезна. Заранее благодарна любой помощи в данном вопросе.

А никак. Полная переписка вам грозит. Ибо референсы пишутся не для скорости, а для наглядности.

Вот сюда посмотрите за енкодером
http://www.videolan.org/developers/x264.html

вот сюда за кодеком.
http://ffmpeg.mplayerhq.hu/

Если первый энкодер еще более менее хвалят - в том смысле что у него получается (но при этом скорость работы для него не есть приоритет), то второй это ужас на крыльях ночи - но работает.

Вы бы лучше рассказали немного что за оптимизацию подразумеваете и немного раскрыли цели.
Сам по себе 264 немного скособочен в сторону посчитать без толку. Другими словами ему ростят альтернативы которые скажем на 25% меньше тратят "посчитать" при примерно том же качестве.

Как я уже говорила, у меня имеются исходники видеокодека (http://iphome.hhi.de/suehring/tml/). Мне достаточно использовать только базовый профиль (в дальнейшем нужно будет перенести на Code Composer, ибо кодек пишется для TMS320C55x). Нужно, чтобы битрейт составлял 300-500 kbit/s при разрешении 720x576. Кодек имеет гибкие настройки. Но скорость его работы оставляет желать лучшего. Использую AQtime. В пятерку самый "быстрых" попали BlockMotionSearch, PartitionMotionSearch, computeSAD, getSubImagesChroma (сreates the 16 (YUV444), 32 (YUV422), or 64 (YUV420) sub-images that contain quarter-pel samples sub-sampled at different spatial orientationss), _calloc_dpb (Get a block of memory from the debug heap, init to 0).
Проект очень большой, очень сложно разобраться. Понимаю, что скорее всего придется переписывать кодек заново. Но все-таки питаю надежды ускорить его с меньшими затратами сил и времени, так как опыта у меня маловато.
Очень буду рада любым замечанием, советом в это вопросе.

Хмм, попробуйте отключить в профиле "навороты" (Inter Prediction & Motion Compensation) и все, что не нужно.
Затем можно пооптимизировать "узкие" участки вручную, т.е. переписать. Однако, не факт, что ускорение окажется достаточным.

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



Насчет переписки, питаться полезно, но думаю что для х86 коды, под дсп переписать придеться.
может вам проще купить кодек на 642 ? ну вот например у этих ребят http://www.mainconcept.com/

обратитесь в саппорт у них есть иксдайсный однобашковый базелайн диван, с неплохим качеством.

Удачи!!

Купить не проще... А переписывать придется. Думаю, может сначала начать с Motion Estimation. Может подскажете, есть ли оптимальные алгоритмы, кто-нить реализовывал? У меня еспользуется алгоритм Simplified UMHexagonS.

насчет купить ну тут вам виднее, оплачивать месяца 4-6 труд разработчика в 1500 - 2500 баков в месяц или купить где нибудь за 5000 баков (цену взял от балды, точнее узнавайте в саппорте). Причем эти ребята вплотную сидят на видео. И если не ошибаюсь "вылизывали" однобашковый энкодер порядка 2 - 3 лет.

Насчет фрейм рейта и типа изображения вы не сказали ничего. Если фрейм рейт большой, и изображение хотя бы со средним движением, снятое подвижной видеокамерой то без P, B фреймов и купельного поиска вам не обойтись. Иначе на 200 килобитах у вас будет сплошное мыло. из-за большого квантайзера.

А если пошел МЕ то и без деблока не обойтись. (можно убрать деблок при определенных квантайзерах но это вам нужно к тем, кто занимается оценкой качества изображения)

Насчет jm референса, если мне память не изменяет там реализован оптимальный для процессорных систем алгоритм. PMVFAST + Diamond Search. Нужно только его правильно реализовать. Статей в сети море, ищите.

ЗЫ. В этой фирме не работаю, так проходил мимо. Могу и ошибаться.

Удачи!

PPS. Посмотрите на результаты реализаций на нексперии http://elecard.com/products/embedded/nexperia/codec-pack.php
что бы сделать прогноз .....

Я как раз не просто мимо проходил и хорошо знаю ситуацию изнутри. Нормальная реализация Baseline H.264 енкодера из jvt'шных исходников на TMS займет труд двух хороших специалистов в течении примерно двух лет. При этом специалисты должны иметь подготовку в области цифрового видео и в области оптимизации на ембеддед платформы. Если этой подготовки нет, то нужно добавить еще год на такую подготовку, при этом еще нужно чтобы были те, кто будет готовить.
720х576 25 fps BaseLine в 500 кбит будет выглядеть не слишком хорошо. Кстати, если вы хотите использовать BaseLine, то там нет интерлейса, поэтому лучше использовать Main Profile. Или кодировать одно поле - 720х288. Если кодировать интерлейсное видео 720х576, в BaseLine как прогрессив, то будет уже совсем не слишком хорошо. Возьмите лучший на сегодня енкодер - http://elecard.com/products/products-pc/co...nverter-studio/
закодируйте свои файлы в Baseline 500 kbit и посмотрите, что получится. Писано это было теми же людьми, кто писал енкодеры для MainConcept, Moonlight, Sonic Solutions, Roxio, Harris, Harmonic, Tandberg и др. Тесты движков, сделанные независимой лабораторией, можно посмотреть здесь http://compression.ru/video/codec_comparis...64_2006_en.html

5000 - Мало реальная цена
50000 - гораздо больше похоже на правду.

Может, не в тему, но ведь на H264 свет клином не сошелся. Разве другие кодеки так уж плохи ?

Не плохи, но этот один из лучших. Посему была задача реализовать свой именно по данному стандарту

Помогите понять по теме: у меня сделан JPEG сжиматель - 800x600
цветное делает 15 кадров (Spartan3-4000 - 1 штука) - передаю по хорошей линии - горя не знаю. Зачем мне нужен видео-кодек?
В чем я проигрываю?

В деньгах:
1. Стоимость Spartan3-4000 - 1 штука.
2. Стоимость траффика.
3. Стоимость электроэнергии.

Сообщение отредактировал blackfin - Oct 18 2007, 08:22