|
Первое сравнение
| |
| Oleggg10 | Дата: Понедельник, 25.11.2013, 11:06 | Сообщение # 1 |
|
Полковник
Группа: Администраторы
Сообщений: 162
Репутация: 0
Статус: Offline
| 
За короткое время мне удалось протестировать новый, слегка сыроватый hevc видеокодек и узнать все его плюсы и минусы. Начну по порядку:
1. Новый кодек прибавил планку необходимых системных требований. С каждым днём продолжает развиваться сеть программного обеспечения и стандарт hevc-кодирования постепенно улучшается, становиться менее требовательным к вычислениям процессора, подключается поддержка со стороны GPU (DXVA, CUDA, OpenCL), так что можно не сомневаться в дальнейшем улучшении скорости кодирования и раскодирования видеопотока. Кроме того, уже продемонстрировано воспроизведение видео в формате h.265 на современном двухъядерном смартфоне. Лично я на своём двухъядерном Core 2 Duo E6850 3,4 Ghz спокойно смотрю 720p и даже 1080p с битрейтом до 3000 kbps, а также конвертирую 720p со скоростью 1 к 18 (10 минутный ролик кодируется 3 часа; примерно 1 FPS в секунду). Это кажется не подъёмно долго, но почти все современные процессоры 4-х ядерные, а значит скорость увеличиться минимум в двое. Ещё пару месяцев назад Core i5-3750K с трудом воспроизводил 4К hevc ролик, а теперь грузит лишь 25%.
2. Смазанность. Новый кодек значительно лучше справляется с видео высокого качества, существовавших ранее "квадратов" уже практически нет, что будет продемонстрировано на этом сайте, но ещё есть куда расти. Если проанализировать стоп кадры старого (h.264) и нового (h.265) видеообразца, созданного с помощью DivX конвертера, то заметим следующее: при уменьшенном размере ролика от 30 до 50% детали картинки слегка смазаны, но контуры остаются ровными и чёткими; цвет изображения менее выраженный, чёрный становиться сероватым. Всё это может отпугнуть от hevc формата, но всё не так просто. Потеря цвета наблюдается пока только в DivX (причём в новой бета версии уже не наблюдается), кроме того в новом кодеке есть разные профили кодирования 8-bit и 10-bit, которые наоборот должны в дальнейшем прибавить палитру цветов; если битрейт сильно не уменьшать, например от 1 до 30% в сравнении с h.264, то качество неотличимо от оригинала.
3. Коварство. Увеличенная мощность кодирования создала увеличенную сложность выявления ошибок такого кодирования, поэтому качество выходного потока при конвертировании нужно проверять с особой осторожностью. Каждый участок видеокартинки теперь анализируется по своему, каждый пиксель может остаться в исходном виде, а может и перекодироваться. Такой сложный алгоритм, автоматизированный новым стандартом, существенно улучшает качество выходной картинки, но может добавить ряд "артефактов" (особенно при сильном сжатии). Таким образом, в одном и том же видеоролике могут быть участки ничем не уступающие исходнику и в то же время некоторые сцены будут сильно искажены.
Примеры будут добавлены ниже.
|
| |
| |
| Oleggg10 | Дата: Понедельник, 25.11.2013, 19:06 | Сообщение # 2 |
|
Полковник
Группа: Администраторы
Сообщений: 162
Репутация: 0
Статус: Offline
| Пример перекодированного мультфильма. На изображении видно, что в одном кадре качество hevc лучше за h.264, в то же время на другом кадре (этой же сессии кодирования) h.264 значительно лучше hevc. Такая особенность связана с плохой работой автоматического поиска детализации картинки, когда новый кодек не правильно воспринимает картинку и беспощадно сжимает её для экономии места.
|
| |
| |
| Oleggg10 | Дата: Понедельник, 25.11.2013, 19:36 | Сообщение # 3 |
|
Полковник
Группа: Администраторы
Сообщений: 162
Репутация: 0
Статус: Offline
| Вот пример обещанного двукратного сжатия. Качественный оригинальный ролик в формате h.264 был пережат на 50% исходного размера. В принципе такой способ нельзя назвать правильным, ведь кодирование было не из единого исходника в формат h264/h265, а из старого h264 в новый h265, но именно такая операция наиболее привлекательна для тех, кто собирается ужать свою видеоколлекцию на половину.
Тут стоит отметить, что падение детализации (незначительная смазанность) является одновременно и гордостью нового кодека, ведь визуально трансляция видеопотока через интернет с плохим качеством значительно лучше выглядит вот в таком смазанном виде, нежели в квадратной пикселизации. Пример:
h264. Блоки пикселей
|
| |
| |
| Oleggg10 | Дата: Понедельник, 25.11.2013, 19:51 | Сообщение # 4 |
|
Полковник
Группа: Администраторы
Сообщений: 162
Репутация: 0
Статус: Offline
| Здесь попытался максимально сжать видеоклип. Получилось 77% сжатия или 23% от исходного файла. Результат также двоякий (советую открыть прикреплённый файл, чтобы увидеть картинку во весь экран):
Заметьте, как DivX изменяет цветовую палитру (уменьшает контрастность и не только). Баг признан, обещают исправить.
|
| |
| |
| Oleggg10 | Дата: Понедельник, 25.11.2013, 20:01 | Сообщение # 5 |
|
Полковник
Группа: Администраторы
Сообщений: 162
Репутация: 0
Статус: Offline
| Тут представлены 2 видеофайла h264/265, максимально приближённых по разрешению и размеру:
Стоит сказать, что выигрыш нового HEVC (h265) пока совсем незначительный, но не будем забывать, что h.264 за 10 лет существования неоднократно допиливался, программное обеспечение для работы с кодеком также совершенствовалось на ошибках и сегодня выжимает с него максимум, в то время как HEVC только-только принят за стандарт и ещё не поддерживается даже многими популярными приложениями.
|
| |
| |
| Oleggg10 | Дата: Воскресенье, 12.01.2014, 20:45 | Сообщение # 6 |
|
Полковник
Группа: Администраторы
Сообщений: 162
Репутация: 0
Статус: Offline
| Появился в интернете тест сравнения x264/x265, который отображает текущее положение дел у этих кодеков.
График PSNR (больше лучше)
График времени кодирования (в секундах)
Сравнение показывает, что x265 только догоняет x264 по качеству кодирования (причём на высоких битрейтах немного обгоняет, а на низких наоборот отстаёт) и сильно уступает по времени. Но стоит учесть 2 значительные вещи:
1. Программное сравнение по метрике PSNR может не показать реальной картины. Ведь глаз лучше понимает что красивее, а что некрасиво. А эти программные сравнения показывают скорее чёткость выходного кадра, нежели гладкость. Именно с чёткостью в x264 есть проблемы, ведь картинка при кодировании получается очень резкая, пикселизованная и т.д., а в x265 наоборот наблюдаются проблемы с размытостью. Короче, тут лучше 1 раз увидеть, чем 100 раз услышать.
2. x265 пока не имеет возможности кодирования в 2 прохода, а в тесте использовали именно 2 прохода x264 и 1 проход x265.
Но одно ясно, x265 ещё очень далёк от совершенства, и это видно по времени кодирования, которое пока никак не перекрывается качеством. Стоит сказать, что h265 пока выглядит немного лучше за x265, но как и с x264, думаю, в дальнейшем x265 обгонит вначале h265, затем x264 и станет весьма перспективной заменой существующих кодеков.
|
| |
| |
| Oleggg10 | Дата: Четверг, 16.01.2014, 10:03 | Сообщение # 7 |
|
Полковник
Группа: Администраторы
Сообщений: 162
Репутация: 0
Статус: Offline
| Сегодня расскажу о первом сравнении DivX 10.1 Final с использованием режимов кодирования: very fast (fastest), fast, standart (balanced), slow (better quality), very slow (best quality).
Приведу сразу время кодирования 1 минуты видео каждого режима в 720p на двухъядерном ПК и сравнение с предыдущим DivX 10.1 beta (примерное):
Fastest - 2 минуты
Fast - 6 минут
Balanced - 19 минут
Better quality - 28 минут
Best quality - не дождался (где-то 6 часов)
DivX 10.1 Beta (режимы кодирования отсутствуют) - 16 минут
Режим Fastest порадовал временем, но огорчил результатами. Они не то, чтобы плохие, но x264 переплюнет его и по времени кодирования и по качеству.
Аналогичная ситуация и с режимом Fast. По сравнению с Fastest результат наглядно получился действительно лучше и больше похож на остальные, более качественные режимы. Но и тут есть проблемы с конкурентами в лице кодеков предыдущего поколения: x264 лучше.
Интересным является режим Balanced. Он практически повторяет качество и время кодирования DivX 10.1 Beta. А значит будет немного лучше за x264 по качеству, но времени потребуется гораздо больше. К сожалению, на первый взгляд, DivX 10.1 Beta немного лучше DivX 10.1 Final - Balanced.
Теперь перейдём к Better quality и Best quality. Именно на них были возложены все надежды, ведь HEVC пока берёт именно своим выходным качеством, которое в некоторых ситуациях значительно превосходит x264 с любыми параметрами, несмотря на возросшее время кодирования. Так вот, если стандартный HEVC превосходит x264 very slow 2-pass по качеству, то что же будет с HEVC very slow 2-pass? К сожалению 2 прохода пока недоступно, но уже есть инструменты скорости кодирования.
Результат Better quality наглядно большого улучшения не принёс. Но это только на первый взгляд. В течении нескольких дней проведу несколько тестов и предоставлю более точные результаты.
Результат Best quality огорчил ещё больше, ведь дождаться окончания кодирования минутного ролика так и не удалось. Шкала застряла на 7% и висела минут 20. Правда процессор по прежнему был загружен и надеюсь на днях всё таки проверю этот режим. Но уже сейчас можно сказать, что он будет непомерно долгим и рекомендовать его можно только счастливчикам с 6-8 и более ядрами.
Отдельно стоит сказать про WPP. Как я понял это настройка использования распараллеливания процесса кодирования на все ядра процессоров. Т.е. кадр делиться на несколько блоков, каждый из которых кодируется отдельным потоком. Такое деление кадра на блоки происходит и в обычном режиме, но все они кодируются обычным способом, без чёткого разделения на потоки. P.S. Если информация неточная, большая просьба меня поправить.
Так вот, ощутимой разницы при включении/выключении WPP на двухъядерные я не заметил ни с качеством, ни со временем кодирования. И даже процессор загружался одинаково. Быть может преимущество станет заметным на 4 ядрах.
Ещё мне не понравилась загрузка процессора на всех режимах. Если 2 ядра в DivX 10.1 Beta стабильно загружались на 98%, то DivX 10.1 Final на любом режиме загружает их на 90-97%, а в некоторых случаях на секунды падает до 70%. Почему так, сложно сказать. Одно могу сказать точно: DivX 10.1 Beta и DivX 10.1 Final отличаются весьма сильно. А в какую сторону - судить вам.
|
| |
| |
| Oleggg10 | Дата: Четверг, 16.01.2014, 21:46 | Сообщение # 8 |
|
Полковник
Группа: Администраторы
Сообщений: 162
Репутация: 0
Статус: Offline
| Обнаружил печальный факт. DivX 10.1 Final в режиме Fast и Fastest обрезает выходное разрешение видео: было 1920х1080, стало 1920х1072.
К счастью на более высоких режимах всё нормально. Как то они действительно с улучшениями намудрили.
Сообщите если вас тоже замечена такая проблема.
И ещё одно. Удалось протестировать режим Best Quality. Качество неплохое, но 30 минут кодировать 5 секунд видео!? Это маразм. Кроме того, результат не сильно отличается от Balanced.
Что это всё значит. А значит это то, что остались работоспособны к повседневному использованию только 2 режима: Balanced и Better Quality.
Фактически внедрение этих режимов пока бессмысленно, поэтому нет смысла переходить из Beta на Final (ну разве чтобы кодировать файлы ранее закодированные HEVC. P.S. Да, раньше этого нельзя было сделать).
А у меня пока всё, ждём дальнейшего развития и улучшения формата.
|
| |
| | |
|
