Comments 11
UFO just landed and posted this here
Здравствуйте stepik777б
Спасибо за комментарий. Здесь, похоже, еще играет роль удаленность кадра от ключевого (указанный Вами кадр где-то около второй сотни).
Для кадров недалеко от ключевого скорректированный профиль дает более четкую картинку:
dl.dropboxusercontent.com/u/102689788/original-ultrafast-8MBit-frame3.png
dl.dropboxusercontent.com/u/102689788/corrected-ultrafast-8MBit-frame3.png
Относительно SSIM, мы придерживались методики, указанной в открытом отчете, а там все опирается на вычисление этой метрики.
Спасибо за комментарий. Здесь, похоже, еще играет роль удаленность кадра от ключевого (указанный Вами кадр где-то около второй сотни).
Для кадров недалеко от ключевого скорректированный профиль дает более четкую картинку:
dl.dropboxusercontent.com/u/102689788/original-ultrafast-8MBit-frame3.png
dl.dropboxusercontent.com/u/102689788/corrected-ultrafast-8MBit-frame3.png
Относительно SSIM, мы придерживались методики, указанной в открытом отчете, а там все опирается на вычисление этой метрики.
Когда-то давно — больше 10 лет назад — было очень модно показывать пары кадров в качестве аргумента, что один кодек лучше другого. При этом в подавляющем большинстве кодеков по целому ряду причин в смысле качества идут колебательные процессы и найти пары кадров, где кодек А лучше кодека Б (и наоборот, особенно если они примерно равны) обычно не очень сложно даже вручную.
В итоге мы просто включили в качестве стандартной опции в наш MSU Video Quality Measurement Tool сравнительный анализ двух файлов с оригиналом, который позволял автоматически выдавать на двух сжатых последовательностях 10 кадров, на которых кодек А, сильнее всего выигрывает у кодека Б (и наоборот).
Народ тогда вволю повеселился, помнится )))
При этом субъективные тесты (когда, например, люди вслепую голосуют какая последовательность лучше) MSU (как и многие) также уже много лет проводит. Просто они сложнее, дороже и меньше последовательность аккуратно сравнить позволяют.
В итоге мы просто включили в качестве стандартной опции в наш MSU Video Quality Measurement Tool сравнительный анализ двух файлов с оригиналом, который позволял автоматически выдавать на двух сжатых последовательностях 10 кадров, на которых кодек А, сильнее всего выигрывает у кодека Б (и наоборот).
Народ тогда вволю повеселился, помнится )))
При этом субъективные тесты (когда, например, люди вслепую голосуют какая последовательность лучше) MSU (как и многие) также уже много лет проводит. Просто они сложнее, дороже и меньше последовательность аккуратно сравнить позволяют.
Коллеги!
Наверное все-таки не очень корректно так сравнивать.
У MSU:
У вас одна последовательность, на которой вы руками подобрали лучшие параметры.
Для тех, кто не в курсе, может и интересно, но те, кто в теме знают, что возможное улучшение на одной последовательности в два раза — совершенно реальный результат (тем более на рендеринге). На то она и заточка.
А теперь внимание, вопрос: А можете продемонстрировать авторам кодеков, что вы на разнородном наборе 20 разных последовательностей найдете параметры лучшие, чем знают авторы кодека?
Ибо вот это реально будет интересно и полезно! ) И авторы спасибо скажут. Даже если 3-5% будет — это будет круто.
Привет Элекарду и Томску! )
Наверное все-таки не очень корректно так сравнивать.
У MSU:
- Все пресеты предоставляют авторы кодеков, все кодеки выравниваются по скорости на заранее заявленном железе.
- Всего используется 21 последовательность.
- Сравнение проводится больше 10 лет и основная интрига в том, что часть последовательностей меняется с прошлого года, причем новые последовательности неизвестны авторам кодеков, т.е. принимаются меры, чтобы авторы не затачивали пресеты под конкретные последовательности
У вас одна последовательность, на которой вы руками подобрали лучшие параметры.
Для тех, кто не в курсе, может и интересно, но те, кто в теме знают, что возможное улучшение на одной последовательности в два раза — совершенно реальный результат (тем более на рендеринге). На то она и заточка.
А теперь внимание, вопрос: А можете продемонстрировать авторам кодеков, что вы на разнородном наборе 20 разных последовательностей найдете параметры лучшие, чем знают авторы кодека?
Ибо вот это реально будет интересно и полезно! ) И авторы спасибо скажут. Даже если 3-5% будет — это будет круто.
Привет Элекарду и Томску! )
Здравствуйте 3Dvideo,
Прошу прощения за медленный ответ.
Выравнивание по скорости мы учли. Относительно того, что использовали одну последовательность, исходной точкой к исследованию было то, что мы заметили разницу в профилях для AVC и HEVC — для AVC использовался немодифицированный быстрый профиль с одним GOP, а для HEVC использовался модифицированный и с двумя GOP.
Сразу же возник вопрос: может, эти опции или еще какие-то другие очевидные способны изменить картину, указанную в открытом отчете для исследуемого файла (несколько удивило, что при быстром перекодировании x264 оказался лучше x265 — на графике в открытом отчете для зависимости SSIM от битрейта без учета времени). Выбранный нами фрагмент похож (как нам кажется) на описание файла открытого отчета, и графики для него получаются похожими на те, что указаны, поэтому можно считать аналогом.
Результат для совокупности файлов может оказаться другим, но, как минимум, для этого файла указание нескольких упомянутых опций (типа «keyint» и «tunessim») способно реабилитировать x265.
К сожалению у нас не было доступа к последовательностям из тестов
Прошу прощения за медленный ответ.
Выравнивание по скорости мы учли. Относительно того, что использовали одну последовательность, исходной точкой к исследованию было то, что мы заметили разницу в профилях для AVC и HEVC — для AVC использовался немодифицированный быстрый профиль с одним GOP, а для HEVC использовался модифицированный и с двумя GOP.
Сразу же возник вопрос: может, эти опции или еще какие-то другие очевидные способны изменить картину, указанную в открытом отчете для исследуемого файла (несколько удивило, что при быстром перекодировании x264 оказался лучше x265 — на графике в открытом отчете для зависимости SSIM от битрейта без учета времени). Выбранный нами фрагмент похож (как нам кажется) на описание файла открытого отчета, и графики для него получаются похожими на те, что указаны, поэтому можно считать аналогом.
Результат для совокупности файлов может оказаться другим, но, как минимум, для этого файла указание нескольких упомянутых опций (типа «keyint» и «tunessim») способно реабилитировать x265.
К сожалению у нас не было доступа к последовательностям из тестов
Похоже я плохо пояснил.
Представьте себя автором кодека. В принципе можно заточиться под последовательности этого года, но в следующем они сменятся, причем неизвестным образом. Может слабо, как в прошлом году, а может сильно как в поза-позапрошлом. И вам нужно выдать пресет не зная, какие последовательности будут в тесте.
А идут авторы кодеков на это, поскольку такой тест очень близок к тестам, которые все равно (пусть часто менее масштабно, чем мы) делают те, кто кодеки покупает (оптом и дорого ;). И в реальной работе критично, чтобы кодек (в отведенных рамках) быстро и эффективно адаптировался под неизвестные последовательности. Т.е. слепой тест ближе к реальности и реально стимулирует улучшение кодека. Тем более, что оно реально всегда возможно.
А заточиться под известную последовательность, да еще одну, да еще специфическую… Именно поэтому безмерно актуален заданный выше вопрос: можете продемонстрировать авторам кодеков, что вы на разнородном наборе 20 разных последовательностей найдете параметры лучшие, чем знают авторы кодека?
И это будет интересно всем, именно если последовательности будут достаточно разнородны, настолько, что результат будет воспроизведется на другом (неизвестном вам) наборе последовательностей. И в такой постановке даже 3-5% стабильного улучшения — это очень круто. И это путь, по которому ежегодно улучшают работу кодеков (ускоряя куски кода, улучшая адаптивность rate control и т.д.).
P.S. И к слову о последовательности. Почему вы ссылаетесь на А.1 «Apple Tree», вам последовательность A.2 “Bunny” ничего не напоминает? :))) compression.ru/video/codec_comparison/hevc_2015/MSU_HEVC_comparison_2015_free.pdf#subsection.a.A.2 Из каких соображений вы взяли как аналог самую короткую последовательность отчета, при том, что следующая за ней — фактически та самая?
Представьте себя автором кодека. В принципе можно заточиться под последовательности этого года, но в следующем они сменятся, причем неизвестным образом. Может слабо, как в прошлом году, а может сильно как в поза-позапрошлом. И вам нужно выдать пресет не зная, какие последовательности будут в тесте.
А идут авторы кодеков на это, поскольку такой тест очень близок к тестам, которые все равно (пусть часто менее масштабно, чем мы) делают те, кто кодеки покупает (оптом и дорого ;). И в реальной работе критично, чтобы кодек (в отведенных рамках) быстро и эффективно адаптировался под неизвестные последовательности. Т.е. слепой тест ближе к реальности и реально стимулирует улучшение кодека. Тем более, что оно реально всегда возможно.
А заточиться под известную последовательность, да еще одну, да еще специфическую… Именно поэтому безмерно актуален заданный выше вопрос: можете продемонстрировать авторам кодеков, что вы на разнородном наборе 20 разных последовательностей найдете параметры лучшие, чем знают авторы кодека?
И это будет интересно всем, именно если последовательности будут достаточно разнородны, настолько, что результат будет воспроизведется на другом (неизвестном вам) наборе последовательностей. И в такой постановке даже 3-5% стабильного улучшения — это очень круто. И это путь, по которому ежегодно улучшают работу кодеков (ускоряя куски кода, улучшая адаптивность rate control и т.д.).
P.S. И к слову о последовательности. Почему вы ссылаетесь на А.1 «Apple Tree», вам последовательность A.2 “Bunny” ничего не напоминает? :))) compression.ru/video/codec_comparison/hevc_2015/MSU_HEVC_comparison_2015_free.pdf#subsection.a.A.2 Из каких соображений вы взяли как аналог самую короткую последовательность отчета, при том, что следующая за ней — фактически та самая?
спасибо за критику. видоизменили вступление
Исходной точкой к исследованию стало то, что мы заметили разницу в пресетах в тестах для AVC и HEVC — для AVC использовался немодифицированный быстрый профиль с одним GOP, а для HEVC использовался модифицированный с несколькими GOP. При этом для единственного описанного в открытом отчете файла “Apple Tree” кодер x264 оказался лучше x265 при быстром перекодированим на графиках зависимости SSIM от битрейта без учета скорости кодирования. Сразу же возник вопрос: может, эти опции или еще какие-то другие очевидные способны изменить указанную картину.
В отчете сравниваются пресеты, но не даются рекомендации по их исправлению. В данной статье мы провели аналогичное сравнение и привели рекомендации по модификации пресетов кодера х265. Для видеопоследовательности, аналогичной исследуемой в бесплатной версии отчета, предлагаемые изменения параметров кодирования позволяют повысить эффективность сжатия, при этом они реабилитируют кодер x265 при построении графиков отчета.
Измененные пресеты не претендуют на универсальность, тестирование на большом количестве видеопоследовательностей выходит за рамки данного исследования. Однако их можно рекомендовать как отправную точку при поиске возможностей увеличения эффективности кодирования x265.
Исходной точкой к исследованию стало то, что мы заметили разницу в пресетах в тестах для AVC и HEVC — для AVC использовался немодифицированный быстрый профиль с одним GOP, а для HEVC использовался модифицированный с несколькими GOP. При этом для единственного описанного в открытом отчете файла “Apple Tree” кодер x264 оказался лучше x265 при быстром перекодированим на графиках зависимости SSIM от битрейта без учета скорости кодирования. Сразу же возник вопрос: может, эти опции или еще какие-то другие очевидные способны изменить указанную картину.
В отчете сравниваются пресеты, но не даются рекомендации по их исправлению. В данной статье мы провели аналогичное сравнение и привели рекомендации по модификации пресетов кодера х265. Для видеопоследовательности, аналогичной исследуемой в бесплатной версии отчета, предлагаемые изменения параметров кодирования позволяют повысить эффективность сжатия, при этом они реабилитируют кодер x265 при построении графиков отчета.
Измененные пресеты не претендуют на универсальность, тестирование на большом количестве видеопоследовательностей выходит за рамки данного исследования. Однако их можно рекомендовать как отправную точку при поиске возможностей увеличения эффективности кодирования x265.
Измененные пресеты не претендуют на универсальность, тестирование на большом количестве видеопоследовательностей выходит за рамки данного исследования.В таком случае, надеюсь, вы понимаете, что минимально грамотный человек при желании может взять ваш «улучшающий» пресет и показать, как на «аналогичных» последовательностях он будет, например, в полтора-два раза просаживать показатели. Найти такие последовательности будет реально не так сложно. Тем более вы все скрипты выложили. ;-)))
И дальше вы все равно вернетесь к основному вопросу, над которым плотно годами работают авторы кодеков: Как улучшить показатели без заточки на широком наборе последовательностей, т.ч. вслепую.
И по поводу «реабилитации х265», как вашей основной цели. Надо сказать, что в принципе ситуация, когда кодек старого стандарта оказывается лучше нового — это нормально. В истории много раз бывало, что на отдельных примерах MPEG-1 был лучше MPEG-2, MPEG-2 был лучше MPEG-4, MPEG-4 лучше H.264. Тем более на относительно молодых реализациях, которые только-только падать перестали. Десять лет назад мы рапортовали пачками баги в сырых реализациях Н.264 разных авторов, сейчас та же самая картина у HECV. Это скоро пройдет, за счет реального улучшения кодеков (х264, например, очень хорошо подрос за 10 лет).
так мы же не против, для этого все и выложили в открытый доступ )
Случаи бывали разные, согласен. но это не тот случай, как мы считаем.
Вот, кстати соответствующая статья, на нужном количестве стримов. Жаль не наша :)
www.bbc.co.uk/rd/blog/2016/01/h-dot-265-slash-hevc-vs-h-dot-264-slash-avc-50-percent-bit-rate-savings-verified
Случаи бывали разные, согласен. но это не тот случай, как мы считаем.
Вот, кстати соответствующая статья, на нужном количестве стримов. Жаль не наша :)
www.bbc.co.uk/rd/blog/2016/01/h-dot-265-slash-hevc-vs-h-dot-264-slash-avc-50-percent-bit-rate-savings-verified
но это не тот случай, как мы считаемА зря. Обратите внимание, что по нашим замерам x265 пока в среднем заметно хуже, чем х264 на 20 последовательностях. Там работа явно только начата.
И имейте ввиду, что пока они сильно рихтуют кодек ваши советы по «улучшенным пресетам» будут очень быстро устаревать. Т.е. буквально на следующей ревизии люди будут пробовать и у них не будет воспроизводиться ваш результат. Стоит дать авторам время довести кодек.
Вот, кстати соответствующая статья, на нужном количестве стримов. Жаль не наша :)Читал. Там «папа» HEVC в авторах, они лучше, чем то-либо знали на чем и как гонять. И у них, обратите внимание, вообще не учитывается время, т.е. в этом плане довольно академический результат. При этом они получили 44% улучшения по PSNR (и 59% — MOS).
Впрочем приоткрывая тайну ) скажу, что у мы скоро опубликуем сравнение HEVC кодеков на 4K последовательностях (на которых HEVC конкурировать заметно легче). На них по нашим замерам у лучшего HEVC кодека 45% улучшения (почти как у процитированных вами товарищей), при том, что он БЫСТРЕЕ х264. А вот это уже для индустрии реально очень интересно и мега-круто.
PS Имейте ввиду, что если просто отвечаете, а не в ответ мне, мне ваш ответ не приходит (тут надо приноровиться к интерфейсу). Случайно увидел.
Случаи бывали разные, согласен. но это не тот случай, как мы считаем.Из свежего, что назвывается ). Вчера общался с коллегаим из Рутьюба. Они протестировали х265 (сами независимо), увидели, что он значительно хуже х264, пришли в ужас насколько и решили тему HEVC вообще закрыть на какое-то время. В общем-то я им сказал ровно то же самое, что и вам — дайте авторам время. Но не в этом дело — там было конкретное разочарование вообще в HEVC (особенно учитывая его проблемы с отчислениями), на фоне завышенных ожиданий от прочитанных фонфарных откликов.
Т.е. чем сильнее у людей отличается в худшую сторону результат собственных тестов от того, что они читали, тем сильнее отторжение к технологии. Мне совершенно понятна ваша мотивация, но в этом плане тексты с примерами заточки кодека под одну последовательность с демонстрацией мега-результатов, которые нельзя воспроизвести массово (просто потому, что вы не будете несколько раз одну последовательность сжимать) скорее способствуют у людей (в т.ч. принимающих решения) разочарованию в новом стандарте.
Вот такие свежие впечатления.
Sign up to leave a comment.
Сравнение HEVC кодеков от МГУ. Как улучшить результаты