Comments 35
А что с качеством получаемого видео? Вроде как разница есть и она достаточно заметная.
Профайл high, битрейт 3000 кб/с., HD — картинка полученная софтовым энкодером и GPU энкодером на глаз идентична. На более низких качествах разница есть, но она не существенна.
Ну уж не знаю, пробовал жать GPU, решениями от Intel и Nvidia, получается мыло. На FullHD с ходу конечно не заметно, но мелкие детали изрядно замыливаются. На HD заметно уже лучше, если на мониторе смотреть, еще куда ни шло, а вот на ТВ было жуткое мыло. От Intel правда качество было получше. Единственный вариант, это задирать битрейт очень высоко. Для стриминга еще терпимо, если не через WiFi глядеть в домах, где всё загажено множеством сетей. А для хранения уже нет смысла.
>> Например, более точно выдерживался битрейт
Ну битрейт может быть плавающим, в зависимости от динамичности сцены и к сожалению современные решения на GPU с этим никак не справляются, вот и выдерживают.
>> Например, более точно выдерживался битрейт
Ну битрейт может быть плавающим, в зависимости от динамичности сцены и к сожалению современные решения на GPU с этим никак не справляются, вот и выдерживают.
А что насчет размеров файла? Насколько я знаю, решение от Intel выдает приблизительно такой файл, какой выдает x264 с пресетом veryfast, а решения с использованием CUDA так вообще ultrafast, т.е. результат получается почти никакой.
В основном, именно по этой причине решения на базе GPU так непопулярны.
В основном, именно по этой причине решения на базе 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 и какой-нибудь более крутой звуковой кодек.
Когда кодируешь с коэффициентом квантования 38 (если мне память не изменяет), любые мелочи заметно влияют на результат. В результате имеем видеофайл, в котором звуковой поток HE-AACv2 в 32кб/с составляет более половины размера файла, и при этом артефакты компрессии картинки заметны очень редко и никак не мешают.
Жду h.265 и какой-нибудь более крутой звуковой кодек.
Так это, есть же www.opus-codec.org/
У того же ffmpeg или mplayer есть возможность померить качество кодирования «в попугаях». Метрика называется PSNR, нужно полистать man-ы, и можно будет качественно оценить, насколько просело качество картинки.
Ну битрейт может быть плавающим, в зависимости от динамичности сцены и к сожалению современные решения на GPU с этим никак не справляются, вот и выдерживают.
Здесь, наверное, соглашусь. Но иногда бывает критично выдерживать постоянный битрейт. С ffmpeg подобрать такой профайл кранйе тяжело для каждого качества.
Надо бы добавить к минусам — требуется поддержка в самих процах. Более того, когда появятся мощные Xeon'ы с поддержкой Intel® Quick Sync Video — неизвестно.
IMHO, топовый E3-1285L v3 не отвечает требованиям по мощности CPU, а только для транскодирования его покупать как-то не выгодно, не находите?
IMHO, топовый E3-1285L v3 не отвечает требованиям по мощности CPU, а только для транскодирования его покупать как-то не выгодно, не находите?
Ждем тесты со сравнением haswell/ivy bridge
Скажите, как ведут себя в этом плане новые видеокарты 5000 и 5100? Пробовали ли на них проводить кодирование?
UFO just landed and posted this here
Сколько в итоге у вас лайв стримов реально обрабатывается на одном сервере (и на каком?)
На сервере пока не тестировали, только недавно собрали само железо. Тесты были на обычном десктопе. При этом удалось кодировать 12-14 full HD или примерно 60 потоков SD (640x320)
Я рекомендую обратиться к Ясону (рассылка libx264-devel) и попросить его помочь с настройками x264, которые выдадут такое же качество при таком же количестве потоков.
Возможно он что-то предоставит?
Ещё вопрос: чем вы mpeg2 декодировали?
Возможно он что-то предоставит?
Ещё вопрос: чем вы mpeg2 декодировали?
Спасибо за идею, надо попробовать
Я декодировал udp поток, сжатый h264 кодеком, а так же сигнал SDI (там «сырые» данные)
Что касается libx264 и ffmpeg, то я просто не смог столько потоков физически транскодировать — банально закончилась память (причем до 60 потоков так и не дошло) Intel SDK, как выяснилось, кушает гораздо меньше памяти
Я декодировал udp поток, сжатый h264 кодеком, а так же сигнал SDI (там «сырые» данные)
Что касается libx264 и ffmpeg, то я просто не смог столько потоков физически транскодировать — банально закончилась память (причем до 60 потоков так и не дошло) Intel SDK, как выяснилось, кушает гораздо меньше памяти
*h264 декодировал так же Intel SDK
Думаю, что вы натолкнулись на какие-то проблемы именно libav.
У libx264 потребление памяти очень небольшое.
Ваш код в каком-то виде доступен? Исходники, платная программа? Или только всё закрытое?
У libx264 потребление памяти очень небольшое.
Ваш код в каком-то виде доступен? Исходники, платная программа? Или только всё закрытое?
ПО у нас закрытое. Кодировал я и при помощи ffmpeg и при помощи нашего софта, написанного с использованием этой библиотеки — результат одинаковый. При большом количестве потоков наблюдается значительное потребление памяти. Версии ffmpeg и libav мы пробовали разные. Intel SDK потребляет примерно в два раза меньше памяти для разных параметров кодирования, разных качеств и т.д.
UFO just landed and posted this here
Добавил в статью два ролика, сжатых ffmpeg и Intel Mеdia SDK для примера.
Sign up to leave a comment.
Кодирование видео с использованием встроенного видео Intel HD