Comments 50
А что на счет кодеков vp8/vp9 и h265? Они поддерживается аппаратно?
Насколько мне известно, поддерживается h265 (HEVC)
Уточнил, аппаратной поддержки нет, SDK поддерживает h265 только софтварно
Жаль, просто h264 кодируется очень быстро(даже на cpu) по сравнению с h265 и тем более с vp9. Даже на вашем примере 12 мин видео закодировалось за 8 мин. Недавно, я кодировал vp9 с помощью последнего ffmpeg и скорость была ужасной, около 0.01fps, т.е. чтобы закодировать 12 мин видео мне нужно было кодировать 25 суток(600 часов или 36000 мин). Это было двухпроходное кодирование FullHD видео с максимальным качеством.
Когда много стримов (100 и больше) этот выигрыш ~10 раз может играть определенную роль. Скажем, один сервер с ускорителем на борту кодирует так же как и 5 — 6 таких серверов.
Мы так же двух проходное кодирование ffmpeg сравнивали с LookAhead от Intel. Разница в 10 раз, при том, что на глаз не сразу и увидишь разницу (считали метрики)
Мы так же двух проходное кодирование ffmpeg сравнивали с LookAhead от Intel. Разница в 10 раз, при том, что на глаз не сразу и увидишь разницу (считали метрики)
Ну как-то технических подробностей маловато. Каким получился выходной размер файла во всех случаях, или средний битрейт? Одинаковые ли были настройки, хотя бы, motion estimator, b/p-frames?
А что с качеством результата? Обычно, проблема аппаратного кодирования в том, что он хоть и быстрее, но дает существенный проигрыш в качестве, особенно, на низком битрейте (если сравнивать кодирование на nvidia tesla/видеокартах и ffmpeg). В этом и состоит основная проблема его использования.
Качество для live вполне приемлемое и это видно по метрикам. Можете сами глянуть результат — inventos.ru/video/v1.mp4 — это фрагмент, закодированный при помощи ffmpeg, а это inventos.ru/video/v2.mp4 при помощи Quick Sync, при одинаковых параметрах. Если сравнивать с 2-pass кодированием ffmpeg, то разница видна конечно, но надо сильно присматриваться.
Ну такое, у первого видео мало того, что битрейт 13 Мбит, так еще и в полтора раза больше второго. Конечно первое будет круче, а если второе сделать с таким-же битрейтом, то разница будет не заметной.
Вы не могли бы сделать примеры с одинаковым битрейтом, мегабита по 4? А то матери с таким чипсетом нету, ради теста покупать не охота, а аппаратное кодирование с достаточно хорошим качеством это очень актуально!
Вы не могли бы сделать примеры с одинаковым битрейтом, мегабита по 4? А то матери с таким чипсетом нету, ради теста покупать не охота, а аппаратное кодирование с достаточно хорошим качеством это очень актуально!
Так это фрагмент же большого видео (700 Мб), у которого _средний_ битрейт 8 Мб/с. На разных участках эти кодеры по-разному жали. Просто все видео тяжелое довольно.
Ниже выложил фрагменты по 1 минуте из тестового ролика, там битрейт примерно одинаковый. Как вариант, можете выслать ваш контент с рекомендациями по настройкам сжатия и я его попробую транскодировать
так выложили бы и исходный файл? :) чтобы было с чем сравнивать
Перекодировал фрагмент 1 мин. Исходник — inventos.ru/video/v.mp4
Это результат ffmpeg inventos.ru/video/test1.mp4
Это результат Quick Sync — inventos.ru/video/test2.mp4
(На длинных роликах ffmpeg лучше соблюдает средний битрейт и здесь он получился немного больше)
Это результат ffmpeg inventos.ru/video/test1.mp4
Это результат Quick Sync — inventos.ru/video/test2.mp4
(На длинных роликах ffmpeg лучше соблюдает средний битрейт и здесь он получился немного больше)
А почему у закодированного фрагмента размер почти в 2 раза больше чем у исходника? В чем физический смысл кодирования с таким задранным битрейтом? :)
Это тест синтетический, просто попался файл нужного мне размера. На других файлах и битрейтах ситуация похожая.
В таком случае теряется смысл объективных тестов :) «исходник» сам по себе замыленный и с кучей артефактов. Т.е. суть статьи сводится ко фразе «на глаз вроде бы ничего так» :)
А для настоящих тестов лучше было бы воспользоваться уже ставшим стандартным 22-х секундным отрывком брызги-дерево-туман из Автара. Там бы сразу стало ясно по скриншотам что из себя представляет какой-либо из типов кодирования.
Если интересно, то вот этот отрывок на яндекс диске (40Мб)
yadi.sk/i/lcSv-PTMWGeTf
А для настоящих тестов лучше было бы воспользоваться уже ставшим стандартным 22-х секундным отрывком брызги-дерево-туман из Автара. Там бы сразу стало ясно по скриншотам что из себя представляет какой-либо из типов кодирования.
Если интересно, то вот этот отрывок на яндекс диске (40Мб)
yadi.sk/i/lcSv-PTMWGeTf
Пожал Ваш файл, вот здесь результат ffmpeg inventos.ru/video/avatar1.mp4, вот здесь Quick Sync inventos.ru/video/avatar2.mp4 Битрейт сделал 20 Мб/с, чуть ниже, чем у исходника
Спасибо и теперь можно посравнивать :) В принципе все как я и думал — качество Quick Sync сравнимо с самым быстрым пресетом софтверного x264 и еще не факт кто из них окажется быстрее :)
Для иллюстрации сравнение скриншотов — Quick Sync 20 Мб/c с медленным x264 битрейтом в 2 раза ниже. Вот с этим
yadi.sk/i/SDQIG2dXWHhrC
Очевидно что у x264 в 2 раза меньшего размера качество заметно выше
screenshotcomparison.com/comparison/82845
И до кучи сравнение с исходником
screenshotcomparison.com/comparison/82846
Для иллюстрации сравнение скриншотов — Quick Sync 20 Мб/c с медленным x264 битрейтом в 2 раза ниже. Вот с этим
yadi.sk/i/SDQIG2dXWHhrC
Очевидно что у x264 в 2 раза меньшего размера качество заметно выше
screenshotcomparison.com/comparison/82845
И до кучи сравнение с исходником
screenshotcomparison.com/comparison/82846
качество Quick Sync сравнимо с самым быстрым пресетом софтверного x264 и еще не факт кто из них окажется быстрее
Очень спорно. Я так и не смог найти пресет, когда ffmpeg обогнал бы Quick Synck
Для иллюстрации сравнение скриншотов — Quick Sync 20 Мб/c с медленным x264 битрейтом в 2 раза ниже
С каким пресетом Вы сжимали? Я просто хочу обратить внимание на метрики PSNR и SSIM. Среднее значение метрики для ffmpeg и Quick Sync не сильно отличается, но я видел флуктуации как в ffmpeg, так и в Quick Sync на некоторых кадрах. Про «заметно выше» тоже очень спорно. В ffmpeg скрине хорошо заметны шумы, которые в Quick Sync слегка замылены. кроме этого в Quick Sync использовался «пресет» balanced и это не совсем корректно сравнивать с медленными пресетами ffmpeg.
А сколько времени заняло кодирование отрывка из Аватара в Quick Sync? Попытаюсь набросать командную строчку для x264 со сравнимым качеством за сравнимое время.
И дался вам этот ffmpeg :) Он в 264 кодировал всегда по принципу побыстрее-посмешнее. И в замыленности как раз все и дело — в результате пропадает большая часть мелких деталей.
И дался вам этот ffmpeg :) Он в 264 кодировал всегда по принципу побыстрее-посмешнее. И в замыленности как раз все и дело — в результате пропадает большая часть мелких деталей.
Кодировал 3,3 секунды
Хм… 3.3 сек не получилось, но у меня и процессор попроще. Быстрее 7.3 сек не смог, но так думаю что x264 на Ксеноне с параметрами
Вот мой семисекундный лог
screenshotcomparison.com/comparison/82905
И даже если сжать битрейт в 2 раза x264 все еще выглядит сравнимо
screenshotcomparison.com/comparison/82908
Так что в результате можно сказать что Quick Sync с битрейтом на 70% выше обеспечивает качество сравнимое с x264 при выигрыше во времени кодирования от 70 до 150%
PS. Файлы с результатами быстрого кодирования с помощью x264 вот тут
yadi.sk/i/YKJY-0c_WKh5B
yadi.sk/d/Cgmin8rNWKh9o
--ref 2 --me dia --subme 2 --analyse none --bframes 1 --no-b-adapt --no-chroma-me
Вот мой семисекундный лог
x264 [info]: profile High, level 4.1
x264 [info]: frame I:8 Avg QP:18.30 size:202347
x264 [info]: frame P:264 Avg QP:20.06 size:130896
x264 [info]: frame B:260 Avg QP:21.64 size: 65315
x264 [info]: consecutive B-frames: 2.3% 97.7%
x264 [info]: mb I I16..4: 5.5% 55.4% 39.1%
x264 [info]: mb P I16..4: 35.8% 0.0% 0.0% P16..4: 63.3% 0.0% 0.0% 0.0% 0.0% skip: 0.9%
x264 [info]: mb B I16..4: 14.6% 0.0% 0.0% B16..8: 41.0% 0.0% 0.0% direct:
30.0% skip:14.4% L0:28.9% L1:31.1% BI:39.9%
x264 [info]: 8x8 transform intra:3.2% inter:64.3%
x264 [info]: coded y,uvDC,uvAC intra: 84.6% 79.8% 30.4% inter: 69.2% 52.3% 6.3%
x264 [info]: i16 v,h,dc,p: 13% 43% 29% 15%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 30% 27% 3% 5% 3% 5% 4% 13%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 20% 12% 9% 10% 8% 9% 7% 10%
x264 [info]: i8c dc,h,v,p: 48% 32% 16% 4%
x264 [info]: Weighted P-Frames: Y:0.4% UV:0.0%
x264 [info]: kb/s:19165.41
encoded 532 frames, 73.38 fps, 19165.69 kb/s
screenshotcomparison.com/comparison/82905
И даже если сжать битрейт в 2 раза x264 все еще выглядит сравнимо
screenshotcomparison.com/comparison/82908
Так что в результате можно сказать что Quick Sync с битрейтом на 70% выше обеспечивает качество сравнимое с x264 при выигрыше во времени кодирования от 70 до 150%
PS. Файлы с результатами быстрого кодирования с помощью x264 вот тут
yadi.sk/i/YKJY-0c_WKh5B
yadi.sk/d/Cgmin8rNWKh9o
ffmpeg -i Avatar.Remux.1080p.enc.stress-test-sample4.mkv -an -vcodec libx264 -x264-params ref=2:me=dia:subme=2:analyse=none:bframes=1:no-b-adapt=1:no-chroma-me=1 -b:v 20000000 -f mp4 avatar3.mp4
У меня 12 секунд получилось
Можете всю командную строку показать?
По качеству, повторюсь вопрос дискуссионный, особенно когда речь про live идет )
Качество можно повысить, использую preset quality, тогда время кодирования будет примерно 4-5 сек
У меня 12 секунд получилось
Можете всю командную строку показать?
По качеству, повторюсь вопрос дискуссионный, особенно когда речь про live идет )
Качество можно повысить, использую preset quality, тогда время кодирования будет примерно 4-5 сек
а я через AviSynth и x264 :) Поэтому 2 файла.
Первый — mkv-source.avs:
и второй — x264-fast.cmd:
Первый — mkv-source.avs:
FFVideoSource("D:\Video\test4\Avatar.Remux.1080p.enc.stress-test-sample4.mkv")
и второй — x264-fast.cmd:
"D:\x264\x264.exe" "D:\Video\test4\mkv-source.avs" --force-cfr --crf 19 --crf-max 24 --level 4.1 --ref 1 --me dia --subme 2 --analyse none --bframes 1 --no-b-adapt --no-chroma-me --output "D:\Video\test4\video_fast.mkv"
pause
Это вообще на испорченный кадр похоже, посмотрю в чем дело. Следующий кадр буквально уже нормальный
Там минимум 4 таких испорченных «кадра» за 20 секунд видео — при каждой смене сцены, начиная с самых первых кадров. Даже для потокового видео это издевательство.
Честно говоря, первый раз с таким столкнулся, доберусь до железа, попробую еще раз. Перед этим, наверное, 2 десятка роликов сжал, просматривая при этом по кадрам.
Да, похоже штатный парсер h264 фреймов затупил. Я пережал сначала ffmpeg-ом в валидный формат, а потом средствами SDK и артефактов не было. Кстати, при сжатии ffmpeg ругался. В общем это не глюк кодека, похоже. Спасибо за внимательный анализ
Для чистоты эксперимента сначала распаковал в raw yuv, а затем пожал средствами SDK — inventos.ru/video/avatar3.mp4
А можно параллельно несколько потоков кодировать?
Да, у нас в софте именно так
Вероятно, имелось в виду параллельное кодирование с использованием аппаратного ускорителя. Когда два разных потока используют ускоритель одновременно.
В rtgraph обычно использовались однопоточные Tee фильтры, и вся программа работала в один поток, а головы проца напрягал сторонний кодировщик кадров. Из-за этого нельзя было одновременно кодить много потоков, потому что они кодились поочередно и могли теряться кадры. При использовании TeeThreaded картина кардинально менялась.
Так что вопрос — если второй экземпляр программы запустить, какова будет производительность?
В rtgraph обычно использовались однопоточные Tee фильтры, и вся программа работала в один поток, а головы проца напрягал сторонний кодировщик кадров. Из-за этого нельзя было одновременно кодить много потоков, потому что они кодились поочередно и могли теряться кадры. При использовании TeeThreaded картина кардинально менялась.
Так что вопрос — если второй экземпляр программы запустить, какова будет производительность?
Только вот вопрос увидел. Сейчас мы почти прекратили поддержку rtgraph, вместо этого — новый продукт — streambuilder. Там все кодировщики в графе в отдельном потоке и нет разницы — два экземпляра запущены или один с множеством потоков. А производительность почти линейно зависит только от количества видеостримов, которые идут на GPU.
Baseline и main тоже поддерживаются? (в статье только high упоминается)
Вы ребята, конечно даёте.
Пока туда-сюда, 1226 уже больше не поддерживаются.
Пока туда-сюда, 1226 уже больше не поддерживаются.
Упс, а можно ссылку на это?
в референсе на Intel Media SDK написано, что нужно 128x процессоры. Т.е. не по $150, а по $700
Пока что свежий SDK запустить не получилось. Честно говоря у меня руки опускаются от того, что я вижу =(
Пока что свежий SDK запустить не получилось. Честно говоря у меня руки опускаются от того, что я вижу =(
Вообще мне говорили что ВСЕ хасвелы будут поддерживаться. Если нет, то это плохо чуть более, чем полностью. Завтра проверим в связке CentOS + 1225 работоспособность 2015R3.
показания расходятся.
Я написал Нине, поскольку больше писать попросту некому. Сотрудникам интела на intel.com веры нет =)
Напишите потом, какие будут результаты. Будет очень обидно, если нам прийдется деградировать до центоса для того, что бы заработал долбаный квиксинк =(
Я написал Нине, поскольку больше писать попросту некому. Сотрудникам интела на intel.com веры нет =)
Напишите потом, какие будут результаты. Будет очень обидно, если нам прийдется деградировать до центоса для того, что бы заработал долбаный квиксинк =(
Пока сервер решили не трогать в плане установки Centos. Написал вопрос сотрудникам Intel в московском офисе, жду ответ. Но, насколько мне известно 2015 R3 точно только на Centos работает. Вроде как следующую версию можно будет на другие OS портировать.
Запустили наш софт на centos с 1225. Релиз СДК 2015 R4.
А без центоса не?
Пока нет. Там нетривиальная процедура портирования на убунту, но вроде как возможно. Еще один момент — на десктопных материнках с Xeon не работает вообще никак, что странно, ибо ядро процессора одно и тоже по идее. А i7 вроде как работает.
ядро, да?
Это очень грустно и смешно. Надо ехать в датацентр и опоганивать сервера проклятым центосом. Спасибо соотечественникам, блин.
Это очень грустно и смешно. Надо ехать в датацентр и опоганивать сервера проклятым центосом. Спасибо соотечественникам, блин.
Как вариант — попробовать процедуру портирования на убунту (ядро 3.14.5, если не ошибаюсь). Можно у сотрудников Интел уточнить про это.
Кстати, хотел спросить. У вас на серверах загрузка какая? Были случаи GPU hang, или полного зависания системы на ubuntu?
Кстати, хотел спросить. У вас на серверах загрузка какая? Были случаи GPU hang, или полного зависания системы на ubuntu?
мы не запустили ещё квиксинк в продакшн под нормальные нагрузки. Я вообще не готов никому из клиентов рекомендовать квиксинк как продакшн решение, потому что это всё пока что большая веселая бета.
Когда кому-то из Нижнего в очередной раз зачешется левая нога и прийдет в голову решение отказаться от поддержки очередной ОС и клиенту надо будет объяснять, что надо всё пересетапливать… Не, парни, это всё не более чем веселое поделие.
Когда кому-то из Нижнего в очередной раз зачешется левая нога и прийдет в голову решение отказаться от поддержки очередной ОС и клиенту надо будет объяснять, что надо всё пересетапливать… Не, парни, это всё не более чем веселое поделие.
software.intel.com/sites/default/files/managed/12/a9/media_server_studio_getting_started_guide_linux.pdf
For Xeon processors only the
E3-128Xv3 family with C226 chipset is supported.
У меня нет цензурных слов на этот счёт. На форуме мне опять говорят, что я не так понял и всё поддерживается: software.intel.com/en-us/forums/topic/543042 но учитывая что в интеле этому media sdk не уделяют внимания, возможно действительно втихаря «забыли» включить media sdk для «дешевых нищебродских» процессоров.
Не исключено, что надо будет удалять всю систему, возвращаться обратно на Media SDK 2014 и больше никогда не обновляться =(
For Xeon processors only the
E3-128Xv3 family with C226 chipset is supported.
У меня нет цензурных слов на этот счёт. На форуме мне опять говорят, что я не так понял и всё поддерживается: software.intel.com/en-us/forums/topic/543042 но учитывая что в интеле этому media sdk не уделяют внимания, возможно действительно втихаря «забыли» включить media sdk для «дешевых нищебродских» процессоров.
Не исключено, что надо будет удалять всю систему, возвращаться обратно на Media SDK 2014 и больше никогда не обновляться =(
Sign up to leave a comment.
Серверное решение для кодирования видео с использованием встроенного видео Intel HD Graphics