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