Как стать автором
Обновить

Комментарии 35

А что с качеством получаемого видео? Вроде как разница есть и она достаточно заметная.
Профайл high, битрейт 3000 кб/с., HD — картинка полученная софтовым энкодером и GPU энкодером на глаз идентична. На более низких качествах разница есть, но она не существенна.
Ну уж не знаю, пробовал жать GPU, решениями от Intel и Nvidia, получается мыло. На FullHD с ходу конечно не заметно, но мелкие детали изрядно замыливаются. На HD заметно уже лучше, если на мониторе смотреть, еще куда ни шло, а вот на ТВ было жуткое мыло. От Intel правда качество было получше. Единственный вариант, это задирать битрейт очень высоко. Для стриминга еще терпимо, если не через WiFi глядеть в домах, где всё загажено множеством сетей. А для хранения уже нет смысла.

>> Например, более точно выдерживался битрейт
Ну битрейт может быть плавающим, в зависимости от динамичности сцены и к сожалению современные решения на GPU с этим никак не справляются, вот и выдерживают.
А что насчет размеров файла? Насколько я знаю, решение от Intel выдает приблизительно такой файл, какой выдает x264 с пресетом veryfast, а решения с использованием CUDA так вообще ultrafast, т.е. результат получается почти никакой.

В основном, именно по этой причине решения на базе GPU так непопулярны.
А что насчет размеров файла?

Так битрейт одинаковый => размеры файлов одинаковые. А вот качество — уже нет. Программный енкодер ВСЕГДА качественнее (возможны очень плохо работающие на GPU оптимизации), но нередко разница в качестве несущественна, а вот в скорости — другой разговор.

Я для себя кодирую в x264 high/5.1 с пресетом placebo. Ну а что, спешить мне некуда. Для моих видео скорость кодирования составляет 4х, за ночь пачка файлов на пару месяцев просмотра нормально обрабатывается.
Да, как-то не подумал, что автор использует исключительно vbr (или подобие abr). Было бы интересно сравнить размер файла с одинаковым коэффициентом квантования в x264 и quicksync.

с пресетом placebo

Это вы зря.
Было бы интересно сравнить размер файла с одинаковым коэффициентом квантования в x264 и quicksync.

Пожалуй, да. Хотя разница в качестве все равно будет.
Это вы зря.

Почему? Медленно — да (хотя 4х не так уж плохо). Самый точный motion estimation, что неплохо для весьма статичного видео. Ага, я понимаю, что по сравнению с тем же fastest выигрываю доли процента по качеству, но как я уже говорил — спешить некуда :)
Разница между veryslow и placebo минимальна, разница в скорости кодирования значительная.
Да и плевать. Ну закончит кодироваться не в 10 утра, а в 2 часа ночи. Кому-то от этого будет лучше?

Когда кодируешь с коэффициентом квантования 38 (если мне память не изменяет), любые мелочи заметно влияют на результат. В результате имеем видеофайл, в котором звуковой поток HE-AACv2 в 32кб/с составляет более половины размера файла, и при этом артефакты компрессии картинки заметны очень редко и никак не мешают.

Жду h.265 и какой-нибудь более крутой звуковой кодек.
Я изучал.
1) Он не лучше, чем HE-AACv2.
2) На всей моей электронике нет его аппаратного декодирования. Это очень плохо — время жизни планшета от зарядки сокращается с недели (удобно) до 3-4 дней (неудобно).
время жизни планшета от зарядки

Ооо. Подскажите, плиз, что за планшет, который неделю живёт (я серьёзно, мне бы пригодился).
Nexus 7 (2012). Без модификаций программных или аппаратных. Полтора-два часа видео в день, ни под какие другие задачи он не используется.
Ага, спасибо.
У того же ffmpeg или mplayer есть возможность померить качество кодирования «в попугаях». Метрика называется PSNR, нужно полистать man-ы, и можно будет качественно оценить, насколько просело качество картинки.
В ближайшее время планируем это сделать.
Ну битрейт может быть плавающим, в зависимости от динамичности сцены и к сожалению современные решения на GPU с этим никак не справляются, вот и выдерживают.

Здесь, наверное, соглашусь. Но иногда бывает критично выдерживать постоянный битрейт. С ffmpeg подобрать такой профайл кранйе тяжело для каждого качества.
Надо бы добавить к минусам — требуется поддержка в самих процах. Более того, когда появятся мощные Xeon'ы с поддержкой Intel® Quick Sync Video — неизвестно.

IMHO, топовый E3-1285L v3 не отвечает требованиям по мощности CPU, а только для транскодирования его покупать как-то не выгодно, не находите?
Мы планируем использовать выделенный сервер именно для транскодирования. Собрали недавно сервер с xeon, погоняем тесты на нем и обязательно выложим результаты в ближайшее время.
Ждем тесты со сравнением haswell/ivy bridge
Скажите, как ведут себя в этом плане новые видеокарты 5000 и 5100? Пробовали ли на них проводить кодирование?
Пока не пробовали
НЛО прилетело и опубликовало эту надпись здесь
Intel Media SDK работает только на процессорах, поддерживающих Quick Sync и использует аппаратные ресурсы встроенного видео, насколько мне известно.
НЛО прилетело и опубликовало эту надпись здесь
Сколько в итоге у вас лайв стримов реально обрабатывается на одном сервере (и на каком?)
На сервере пока не тестировали, только недавно собрали само железо. Тесты были на обычном десктопе. При этом удалось кодировать 12-14 full HD или примерно 60 потоков SD (640x320)
Я рекомендую обратиться к Ясону (рассылка libx264-devel) и попросить его помочь с настройками x264, которые выдадут такое же качество при таком же количестве потоков.

Возможно он что-то предоставит?

Ещё вопрос: чем вы mpeg2 декодировали?
Спасибо за идею, надо попробовать
Я декодировал udp поток, сжатый h264 кодеком, а так же сигнал SDI (там «сырые» данные)
Что касается libx264 и ffmpeg, то я просто не смог столько потоков физически транскодировать — банально закончилась память (причем до 60 потоков так и не дошло) Intel SDK, как выяснилось, кушает гораздо меньше памяти
*h264 декодировал так же Intel SDK
Думаю, что вы натолкнулись на какие-то проблемы именно libav.

У libx264 потребление памяти очень небольшое.

Ваш код в каком-то виде доступен? Исходники, платная программа? Или только всё закрытое?
ПО у нас закрытое. Кодировал я и при помощи ffmpeg и при помощи нашего софта, написанного с использованием этой библиотеки — результат одинаковый. При большом количестве потоков наблюдается значительное потребление памяти. Версии ffmpeg и libav мы пробовали разные. Intel SDK потребляет примерно в два раза меньше памяти для разных параметров кодирования, разных качеств и т.д.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Добавил в статью два ролика, сжатых ffmpeg и Intel Mеdia SDK для примера.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий