Не работает кодек h 264
Сначала Mozilla отказывалась поддерживать проприетарный и защищённый патентами формат h264, продвигая использование открытых кодеков, потом, когда стало понятно, что без поддержки h264 в современном вебе никуда, реализовала её при при помощи компонента Windows Media Foundation, отсутствующего в Windows XP. Когда Cisco предоставила открытые и лицензионно чистые кодеки OpenH264, было слишком поздно — никто не хотел переписывать рабочий код, использующий WMF, ради ОС, поддержка производителем которой была окончена, и внедрение OpenH264 ограничили видео по WebRTC.
Но многие (в том числе и я) всё ещё используют эту ОС по разным причинам, и не стоит им отказывать в просмотре видео в h264 в самом лучшем (по моему скромному мнению) браузере Firefox.
Помощь, откуда не ждали
После обновления на Firefox 48 я внезапно для себя обнаружил, что видео в h264 прекрасно работает.
Небольшое расследование привело меня к тому, что это стало возможно благодаря плагину Adobe Primetime, ориентированному на воспроизведение DRM видео.
На скриншоте ниже, полученном при помощи Process Explorer, видно, что процесс plugin-container, появившийся после загрузки страницы с видео, использует файл eme-adobe.dll из профиля текущего пользователя.
Зайдя в настройку плагинов Firefox, я нашёл там Adobe Primetime, отключение которого приводило к тому, что FF переставал воспроизводить h264, что доказывало, что именно он виновник этого торжества.
Но радость моя была не долгой.
Последовательность foreman, кадр 282
Выводы
- При одинаковом значении метрики PSNR кодеки стандарта H.264 показывают заметно лучшее визуальное качество.
- Большинство кодеков явно оптимизированы для достижения максимальной скорости кодирования на сегодняшних конфигурациях и не используют всех возможностей, предоставляемых форматом H.264.
При сравнении кодеков всегда хочется узнать, кто же в итоге лучший. Часто при ответе на подобные вопросы возникают заключения вроде «H.264 лучше DivX на 45%!». Однако кодеки можно сравнивать по многим параметрам – качеству сжатых последовательностей, способности держать заданный битрейт, быстродействию, удобству использованию, размеру инсталлятора, красоте логотипа и т.д. Причём для разных задач отдельные параметры могут быть неодинаково важны. Например, если вы хотите сжимать телевизионный сигнал, для вас важна скорость работы кодека, если записывать сжатые фильмы на CD – то немаловажна точность соблюдения битрейта, а если решили сделать архив оцифрованного видео – то, скорее всего, определяющим фактором является качество сжатых последовательностей.
Как было сказано выше, данный текст является сильно сокращенным и откомментированным вариантом сравнения видеокодеков, предназначенного в первую очередь для профессиональных пользователей и производителей кодеков. Полный вариант этого тестирования имеет объем 70 pdf-страниц, содержит сравнения всех указанных в начале статьи видеокодеков, множество графиков и рисунков, не приведенных в данной статье.
Мы выражаем благодарность компаниям Moonlight Cordless LTD, Fraunhofer Institute for Integrated Circuits IIS и Ateme за любезно предоставленные для данного тестирования кодеки, недоступные публично.
Распространённый в «нулевых» формат DVD, основанный на кодеке MPEG2, по мере появления телевизоров и мониторов с высоким разрешением уже не мог удовлетворять возросшим требованиям к качеству видео. Поэтому появление в 2003 году формата кодирования H.264 было воспринято в основном доброжелательно. Но со временем и этот стандарт перестал отвечать современным нуждам – требовался такой кодек, который бы обеспечивал меньший размер файла при том же битрейте (или увеличенный битрейт при неизменном объёме видеофайла). Так появился усовершенствованный формат H.265, именуемый также HEVC, позволивший уменьшить размеры файлов на 30-50% при сравнимом качестве. В нём реализована поддержка разрешения уровня 8К (8192×4320 пикселей). Насколько успешно продвигается этот стандарт? Давайте разбираться.
Результат
Хотя мы и предполагали, что на некоторых устройствах при работе с H.264 будут возникать проблемы, Android опять смог нас удивить. Как мы видим из статистики пользователей Badoo, на руках у пользователей ещё достаточно много устройств 2014–2016 года выпуска, которые они не хотят или не могут обновлять. И хотя ситуация с выходом обновлений Android для новых устройств уже гораздо лучше, чем несколько лет назад, доля гаджетов предыдущего поколения сокращается довольно медленно и поддерживать их придётся ещё достаточно долго.
Сейчас WebRTC активно развивается Google из-за его использования в проекте Stadia (вот видео с подробностями на эту тему), поэтому он будет становиться всё лучше и лучше и, скорее всего, станет стандартом для реализации видеосвязи. Надеюсь, что эта статья поможет вам понять особенности работы с H.264 в WebRTC и использовать это в своих проектах.
Выводы
- На низких битрейтах DivX сильно уступает кодекам VSS_main, Fraunhofer, Ateme.
- На средних и высоких битрейтах кодек от Ateme опережает все остальные кодеки.
В полной версии сравнения представлены другие типы графиков для различных последовательностей и видеокодеков: V-PSNR, U-PSNR , Y-difference и bitrate-handling.
Часть 3: Покадровое сравнение видеокодеков
На этих графиках хорошо видно, как изменяется качество сжатия отдельных кадров кодеками. По оси X отложены номера соответствующих кадров, а по оси Y – PSNR кодеков при сравнении с оригиналом.
Регулировка битрейта
Стандартный код WebRTC содержит следующее:
Как видно из этого кода, для всех чипсетов, кроме Exynos, регулировка битрейта выключена. Но это относится только к Qualcomm, так как в стандартном коде поддерживаются только Exynos и Qualcomm. Поэкспериментировав с различными значениями этой настройки, а также поискав в Интернете, мы выяснили, что для кодеков с префиксами «OMX.MTK.» её тоже нужно включить. Также необходимо сделать это для кодеков HUAWEI, начинающихся с префикса «OMX.IMG.TOPAZ.», «OMX.hisi.» или «OMX.k3.». Это связано с тем, что эти кодеки не используют временные метки кадров для регулировки битрейта, считая, что все кадры приходят с одинаковой частотой, установленной при конфигурации кодека.
В завершение приведу список кодеков, которые мы получили для устройств на Android 5.0 и 5.1. Они были нам интересны в первую очередь потому, что на более новых версиях Android ситуация улучшается и нестандартных кодеков становится всё меньше.
Это видно на графике ниже. Шкала логарифмическая, чтобы лучше показать редкие случаи.
Как мы видим, у большинства устройств были чипсеты Spreadtrum, MediaTek, HUAWEI и MARVELL — поэтому наши изменения помогли включить аппаратное кодирование на этих гаджетах.
Поддержка H.264 в WebRTC
Тут есть метод с говорящим названием isHardwareSupportedInCurrentSdkH264:
Как мы видим, поддержка аппаратного кодирования на Android реализована только для чипсетов Qualcomm и Exynos. Почему же в стандартной реализации WebRTC нет поддержки других чипсетов? Вероятнее всего, это связано с особенностями реализации аппаратных кодеков производителей. И выявить эти особенности часто можно только на продакшене, поскольку найти те или иные устройства не всегда представляется возможным.
Все описания кодеков на устройстве хранятся в файле media_codecs.xml. Вот, например, этот файл для Pixel XL и для HUAWEI P8 lite. При получении списка кодеков с помощью метода getCodecInfos() объекта MediaCodecList этот файл парсится — и возвращаются кодеки, хранящиеся в нём. Эта операция и правильность заполнения этого файла производителем покрываются в CTS тестом MediaCodecListTest, который также увеличился со 160 строк кода в Android 4.3 до 740 строк в Android 10.
В Badoo мы поменяли код метода isHardwareSupportedInCurrentSdkH264, отказавшись от «белого» списка кодеков и заменив его «чёрным» списком префиксов программных кодеков, которые перечислены в WebRTC:
Но нельзя просто так взять и реализовать поддержку всех кодеков, не обращая внимания на особенности производителей. Из названий топиков, посвящённых аппаратному кодированию на Android в группе discuss-webrtc, можно понять, что в этом случае у нас точно возникнут ошибки. В основном они появляются на этапе конфигурации кодека.
Поддержка H.264 на Android
Если верить описанию поддержки форматов мультимедиа, декодирование H.264 Baseline Profile должно работать на всех Android-устройствах, а кодирование — начиная с Android 3.0. В Badoo мы поддерживаем устройства начиная с Android 5.0, так что у нас не должно было возникнуть проблем. Но всё оказалось не так просто: даже в гаджетах с пятой версией мы обнаружили большое количество особенностей.
С чем это может быть связано?
Нас в этом наборе тестов интересуют мультимедиа-тесты, а конкретнее — тесты на кодирование и декодирование видео. Я решил остановиться на тестах EncodeDecodeTest, MediaCodecTest, DecoderTest и EncoderTest, так как они присутствуют на всех версиях Android начиная с 4.3. График количества строк кода в этих тестах выглядит так:
До версии 4.3 большинства из этих тестов просто не существовало, и значительный их прирост пришёлся на версии 5 и 7. Поэтому можно говорить о том, что до версии Android 4.3 Google никак не проверяла соответствие устройств своей спецификации по кодированию и декодированию видео, а в версии 5.0 значительно улучшила эту проверку.
Казалось бы, это указывает на то, что начиная с версии 5.0 с кодированием всё должно быть в порядке. Но, учитывая предыдущий мой опыт работы с декодированием потокового видео на Android, я был уверен, что это не так. Достаточно было посмотреть на количество топиков про кодирование в Google-группе discuss-webrtc.
Искать подводные камни нам помогали исходные файлы WebRTC, которые находятся в свободном доступе. Рассмотрим их подробнее.
Sequence bankomatdi. Bitrate 2340 kb/sec
- Битрейт 700 Кбит/с.
- Последовательности для сравнения: bbc3di и foreman.
Метрика PSNR
Описание метрики
В рамках данного тестирования критерием качества сжатия служит метрика PSNR (peak signal to noise ratio/пиковое отношение сигнала к шуму, измеряется в дБ). Использование именно этой метрики обусловлено ее популярностью. Ее используют в большинстве научных статей и сравнений в качестве меры потерь качества. Как и все существующие метрики, она не идеальна и имеет свои достоинства и недостатки. Для понимания приведенных ниже цифр, необходимо знать лишь то, что значение метрики тем больше, чем больше разница между сравниваемыми изображениями.
Примечание: PSNR – это наиболее общепринятая метрика для оценки различий между двумя последовательностями. Несомненно, у неё есть множество недостатков. Можно придумать огромное количество последовательностей, на которых эта метрика не совсем адекватно себя ведёт. Например, два кадра, яркость одного из которых подняли на одну единицу (из, скажем, 255). Или два кадра, отличающихся одним пикселем – на первом пиксель белый, а на втором – чёрный. В обоих примерах вы с трудом сможете уловить различия в кадрах на глаз, но с точки зрения PSNR кадры будут значительно отличаться! Однако, несмотря на все недостатки, именно метрикой PSNR до сих пор пользуется большинство разработчиков кодеков для анализа своих результатов. Эта метрика понимается и признаётся всеми профессионалами в области кодирования видео. Именно по этой причине мы выбрали PSNR в качестве основной метрики.
Смысл графиков PSNR/Frame size
На графике изображена зависимость показателя метрики от среднего размера кадра. Каждая ветвь соответствует определенному кодеку. Ветви построены на опорных точках, каждая из которых соответствует конкретному битрейту. Хорошо видно, что на каждой ветви находится по десять точек (каждая последовательность сжимается на 10 настройках битрейта). Бывает, что кодек не удерживает битрейт и с разными настройками битрейта сжимает одинаково. В таких случаях, очевидно, на ветви кодека расположено менее десяти опорных точек. Для сравнения кодеков на этих графиках следует обращать внимание на то, как высоко расположены ветви кодеков. Чем выше находится ветвь – тем выше в среднем качество последовательности, сжатой данным кодеком. На вышеприведенном в качестве примера рисунке видно, что на высоком битрейте Videosoft сжал последовательность с меньшими потерями качества по сравнению с другими кодеками.
Почему именно H.264?
При соединении по WebRTC все устройства, участвующие в сеансе, передают различные параметры связи, в том числе видео- и аудиокодеки. Если устройства поддерживают несколько кодеков (например, VP8 и H.264), приоритетные для платформы кодеки указываются первыми. Эти данные используются на этапе согласования в WebRTC, после которого остаются только кодеки, поддерживаемые всеми устройствами. Пример таких данных с расшифровкой можно увидеть в этом документе.
В случае с видеозвонками при отсутствии на одном из устройств поддержки кодека H.264 оба устройства могут перейти, например, на кодек VP8, который не зависит от аппаратной реализации на устройстве. Но наше приложение доступно на самых разных гаджетах, в том числе на смартфонах предыдущих поколений. Поэтому для видеосвязи мы хотели по возможности использовать аппаратное кодирование: оно снижает нагрузку на процессор и не так сильно ест батарею, что критично для устаревших гаджетов. Поддержка аппаратного кодирования H.264 реализована на большом количестве устройств, в отличие от того же VP8.
P.S. Обновление
На Bugzilla подсказали более простой и корректный способ активации плагина. Достаточно создать в about:config настройку:
И выставить её в true. Так же необходимо выставить в true уже существующий параметр media.gmp.decoder.enabled, и проверить на всякий случай параметры media.gmp-eme-adobe.visible и media.gmp-eme-adobe.enabled, они активированы по умолчанию, но мало ли. Это позволяет активировать плагин без бинарных патчей файла, поэтому новые версии выкладывать не буду.
Основная задача настоящего тестирования - сравнить результаты работы нового поколения MPEG4-кодеков (называемых MPEG-4 AVC или H.264) при записи домашнего видео простыми пользователями. Такие пользователи, как правило, используют простые известные программы для того, чтобы считывать DVD или оцифровывать сигнал с тюнера и редко изменяют настройки кодеков. Мы прекрасно понимаем, что писать кодеки так, чтобы они хорошо работали в разных ситуациях без специальной настройки (автоматически подстраиваясь под тип видео) сложнее, но тем больше чести авторам, если их кодеки хорошо справляются с такой задачей. DivX Pro 5 использовался для сравнения, как один из лучших кодеков предыдущего поколения, стандарта MPEG-4 ASP. Подробнее о разновидностях MPEG-4 можно прочитать здесь.
Использованные кодеки
Main Concept H.264
Ateme MPEG-4 AVC / H.264
Videosoft H.264 codec main
Учитывая специфику H.264 (очень большое время работы при включении "по максимуму" всех опций и возможностей), мы в дальнейшем введем два набора настроек, получаемых от производителей кодеков (и только от них). Первый набор - "tuned" - настройки, дающие максимальное качество, но долгую работу и "fast" - настройки, обеспечивающие быструю работу, но с меньшим качеством. Причем и время, и качество будут измеряться в обоих случаях. Это позволит кодекам продемонстрировать, на что они способны по качеству и даст возможность более корректно сравнивать скорость, чем в варианте сравнения настроек по умолчанию. Часть 1: Методика тестирования
Цветовой формат
При использовании кодека в режиме байт-буферов необходимо выбрать правильный формат. Обычно это делается с помощью функции следующего вида:
Грубо говоря, всегда выбирается первый из поддерживаемых цветовых форматов.
Однако в случае с кодеками HUAWEI, начинающимися с префиксов «OMX.IMG.TOPAZ.», «OMX.hisi.» и «OMX.k3.», это не работало, и после долгих поисков мы нашли решение: вне зависимости от того, какой формат возвращают эти кодеки, необходимо использовать формат COLOR_FormatYUV420SemiPlanar. Разобраться в этом нам помог тред на одном китайском форуме.
Послесловие
Для тех, кому лень возиться с HEX- редакторами и архиватором, прикладываю ссылку на каталог на Яндекс.диске, куда я буду сбрасывать свои исправленные файлы omni.ja после обновлений. Пока там лежит один файл из актуальной версии.
Плагины в Firefox запускаются в изолированном процессе, не имеющим доступ к странице, поэтому ничего страшного в использовании плагина с закрытым кодом нет. Хоть я и предлагаю скачать исправленный файл, я также даю инструкции по его самостоятельному исправлению выше.
Получившийся у вас файл omni.ja при бинарном сравнении может отличатся от моего даже на одной версии FF, так как используются разные архиваторы, его версии и параметры сжатия по умолчанию.
Спасибо за внимание!
Разрешение потока
После получения для кодека объекта MediaCodecInfo можно изучить кодек подробнее, получив его возможности в классе CodecCapabilities. Из них можно узнать, поддерживает ли кодек выбранные разрешение и частоту кадров. Если он поддерживает эти параметры, их можно устанавливать безопасно.
Однако иногда это правило не работает. Мы столкнулись с тем, что кодеки с префиксом “OMX.MARVELL.” кодировали неправильно, показывая зелёные полосы по краям экрана, если разрешение потока отличалось от 4:3. При этом сам кодек утверждал, что выбранные разрешение и частота кадров поддерживаются.
Что такое формат H.265 (HEVC)
High Efficiency Video Coding на сегодняшний день является самым современным и продвинутым видеокодеком. Если H.264 (AVC), основанный на кодеке MPEG, был ориентирован на воспроизведение FullHD видео, то его сменщик способен сжимать видеоряд до разрешения UHDTV, или 8К.
Что интересно, к разработке более совершенного стандарта приступили в 2004 году, то есть всего через год после начала внедрения AVC. Первоначально проект назывался H.NGVC, что расшифровывается как Next-generation Video Coding, а затем за стандартом закрепилось нынешнее эволюционное название. Перед экспертной группой VCEG стояла нелёгкая задача: повысить разрешение видео, добившись снижения битрейта, при этом не увеличивая вычислительные мощности оборудования. Требования, прямо скажем, противоречивые, поэтому в полной мере их реализовать не удалось.
И всё-таки разработчикам удалось добиться главного: увеличения максимального размера блока, основной единицы кодека, в 16 раз по сравнению с H.264, у которого он равен 16х16 пикселей. При этом была задействована технология блоков динамического размера, когда кодек во время сжатия видео сам выбирает оптимальное количество пикселей в блоке. Это и позволило новому формату легко поддерживать разрешение 8К, хотя и 4К на сегодня внедряется не такими быстрыми темпами, как хотелось бы. Добавьте сюда технологию параллельного кодирования, и вы получите кодек, способный сжимать видео до размера, на 25-50% меньше, чем у предшественника, при том же качестве.
Новый стандарт был утверждён только в 2012 году и поначалу имел ограниченное применение – в телевидении и IP камерах. Но когда в 2017 году поддержку HEVC реализовали в iOS 11, ситуация начала быстро меняться.
Параметры конфигурации кодека
Инициализация кодека для кодирования выглядит так:
В некоторых из этих параметров легко допустить ошибку, что вызовет исключение при конфигурации кодека и нарушит работу приложения. Также при работе с кодеком может понадобиться регулировать его битрейт в зависимости от различных факторов, так как сам кодек делает это неправильно. За это в WebRTC отвечает класс BaseBitrateAdjuster, у которого есть два наследника:
-
— регулирует битрейт в зависимости от объёма данных, — регулирует битрейт в зависимости от частоты кадров.
Sequence bankomatdi. Bitrate 100 kb/sec
Какие кодеки выбрать?
В интернете можно найти множество различных программ с кодеками. Я пытался работать с различными установщиками, но всегда возвращался к одному сборнику кодеков.
Называется этот сборник K-Lite Codec Pack. Это наиболее оптимальный вариант для обычных пользователей, да и для профессионалов в аудио и видео обработке данный сборник будет очень полезен. В нем нет ничего лишнего, а установка очень проста.
У меня были ситуации, когда после установки кодеков половина форматов воспроизводилась, а другая половина ни в какую не хотела. Но с K-Lite Codec Pack такого ни разу не было. Кодеки здесь подобраны очень грамотно и всегда есть все необходимое для удовлетворения нужд рядового пользователя.
В K-Lite Codec Pack есть собственный плеер – « Media Player Classic ». Он привлекает своей простотой и огромным количеством настроек. Попробуйте и вы уже никогда не сможете работать в каком-то другом.
Всё опять сломали
При очередном обновлении до Firefox 49 я с грустью обнаружил, что h264 опять не играется. Я не нашёл Adobe Primetime в списке плагинов, я не нашёл его файлов в профиле, а попытка их подсунуть ни к чему не привела.
В поисках по интернету я наткнулся на обсуждение предложения по скрытию Adobe Primetime на ОС ниже Vista. Оттуда я узнал, что этот плагин официально не поддерживает Windows XP, и на некоторых конфигурациях наблюдались проблемы со стабильностью. Но у меня же проблем не было!
В багтрекере была ссылка на «исправление» проблемы отображения плагина Primetime на XP. Опираясь на код из него, я сделал исправление, которое откатывает вредный эффект данных изменений.
Методика тестирования
Последовательность действий
В тестировании участвует девять фильмов (см. ниже). Каждый фильм сжимается десять раз с разными битрейтами (кбит/с): 100, 225, 340, 460, 700, 938, 1140, 1340, 1840, 2340. Таким образом, для каждого кодека генерируется 50 фильмов. Затем для каждого фильма вычисляется метрика PSNR. Причем указанная метрика вычисляется для каждого кадра. Далее для построения графика используются соответствующие числа, в зависимости от типа графика.
Задачи и правила тестирования
Самый распространённый вопрос по поводу этого тестирования – «А с какими настройками тестировались кодеки?». В полном тексте документа, в разных местах мы ответили на него 8 раз – с настройками по умолчанию! Это означает следующее. Мы брали чистую операционную систему и инсталлировали на неё кодек. Настройки, которые он выставил при этом, мы считали настройками по умолчанию. В процессе тестирования мы меняли только один параметр – битрейт. Таким образом, чтобы посмотреть все параметры, вам надо всего лишь заново проинсталлировать интересующий вас кодек.
Последовательности
На разных последовательностях кодеки показывают разные результаты. Например, эффективно сжать последовательность из одинаковых кадров намного легче, чем последовательность, состоящую из существенно различающихся картинок. Есть и другие характеристики последовательностей – размер кадров, зашумлённость, длина последовательности, тип движения камеры и т.д. Для нашего тестирования мы выбрали стандартные последовательности. Многими из них пользуются производители кодеков для тестирования своих продуктов. Конечно, эти последовательности не покрывают всего множества фильмов – тут нет ни мультфильмов, ни видео с тюнера. В дальнейшем мы планируем расширить число последовательностей.Часть 2: Графики по PSNR для всех кодеков
Преимущества HEVC по отношению к старым форматам
С выходом iOS 11 и macOS High Sierra Apple начала усиленно продвигать новые форматы для изображений (HEIF) и видео (HEVC). Задача упростилась в том плане, что новый кодек обеспечивал либо видео лучшего разрешения, либо меньшего размера, что в эпоху глобального обмена контентом имеет немаловажное значение – попробуйте передать по сети файл размером с 10-20 ГБ.
Использование блоков большего размера позволило также сократить время, затрачиваемое на кодирование и, что не менее важно, на декодирование, предотвращая фризы при просмотре видео.
Частично улучшения характеристик нового формата удалось добиться за счёт использования новых технологий, о которых мы уже упоминали. Но за всё нужно платить. В данном случае речь идёт о возрастании нагрузки на аппаратную часть, из чего следует вывод, что для обеспечения декодирования видео в формате HEVC потребуется более мощное оборудование. Второй негативный момент связан с тем, что соответствующие кодеки, по крайней мере, на начальном этапе распространения формата, встроены в популярные проигрыватели в ограниченном количестве. Ещё хуже обстоят дела с «железом» – только передовые модели телевизоров, медиаплееров, телевизионной техники и IP-камер умеют «переваривать» этот формат. Но это, разумеется, дело поправимое в среднесрочной перспективе. Во всяком случае, уже сейчас количество доступных аппаратных и софтверных декодеров стремительно растёт.
Что касается ПК, то поначалу H.265 поддерживали только видеокарты 970/980 от GeForce, а для кодирования среднего видео этого формата на более слабом оборудовании требовалось порядка 10 часов. Сегодня ситуация в этом плане гораздо более благоприятная, а дивиденды от использования HEVC очень даже ощутимы. Главное, что выгода будет тем больше, чем выше качество видео: для разрешения 720p, которое ещё совсем недавно было «золотым стандартом», размер файла будет примерно на 25% меньше, чем в формате H.264. Но для 4К выигрыш составит уже 50%, а если говорить о рипах Blue-ray, то здесь экономия достигается десятикратная, то есть видео такого качества вполне можно упаковать в каких-то 3-4 ГБ.
Рассмотрим основные особенности кодека HEVC с технической точки зрения:
Разумеется, это не все технологические новшества, характеризующие новый кодек. Но и перечисленного вполне достаточно, чтобы специалист смог понять, на что способен новый формат.
Как использовать кодек HEVC
Разумеется, обычного пользователя больше интересует вопрос, чем смотреть видео в формате HEVC/H.265, нежели технические подробности реализации улучшенного стандарта.
Если не привязываться к видеоадаптеру, то самый простой вариант – это использование программных плееров. В частности, всем хорошо известного VLC. Его последняя версия гарантированно поддерживает новый формат.
Но по умолчанию поддержка HEVC здесь выключена, и чтобы смотреть видео, закодированное H.265, необходимо выполнить следующие действия:
В результате вы получите возможность просматривать на компьютере видео, сжатое новым кодеком, вне зависимости от используемой операционной системы.
Примерно таким же способом можно установить HEVC/H.265 на Windows, используя последние версии других популярных медиаплееров – Media Player Classic, KMPlayer, GOM Player и других.
Поддержка H.265 реализована и в некоторых браузерах – Microsoft Edge (начиная с 16-й версии) и Safari (от одиннадцатой версии и выше).
Что касается MacOS High Sierra, то там с новым кодеком справляется стандартное приложение «Видео», хотя если вам нравятся сторонние плееры, то все вышесказанное остаётся справедливым. Аналогичная ситуация и с мобильными девайсами, работающими под iOS 11 – здесь главное, чтобы для воспроизведения нового формата хватило производительности устройства.
Что касается смартфонов и планшетов под Android, то на сегодня получить работающий кодек HEVC/H.265 можно только в приложении MX Player с тем же условием – производительности девайса должно хватать для воспроизведения видео нового формата.
Другое дело, что видео, записанного с использованием кодека HEVC, в сети пока не так много. Остаётся надеяться, что ситуация будет постепенно улучшаться, как это было с предшественником и разрешением 4К – сегодня количество каналов, вещающих в этом формате, растёт в арифметической прогрессии.
В немалой степени проблема касается и оборудования, способного поддерживать сверхвысокие разрешения – среди компьютерных мониторов таковых практически нет, да и телевизоры с разрешением 8192×4320 пикселей – пока не столь распространённое явление. Но технический прогресс не остановить…
Очень часто пользователи сталкиваются с проблемой, когда на компьютере не воспроизводится видео. Могут воспроизводиться только определенные форматы или вовсе никакое видео не воспроизводится. Все дело в отсутствии кодеков. В данной статье я расскажу, почему не показывает видео и как решить данную проблему с помощью кодеков для Windows.
Последовательность bbc3di, кадр 280
Что такое кодеки?
С английского языка слово « кодек » переводится как « кодировщик/декодировщик ». Кодек используется для кодирования аудио и видео файлов, а при воспроизведении файлы декодируются этим же кодеком.
Кодеки устанавливаются на компьютеры как обычные программы. У них есть установочный файл, который выполняет автоматическую установку и интегрирование кодеков в систему. При воспроизведении файлов операционная система сама подбирает нужный кодек для расшифровки. Пользователю ничего не нужно делать самостоятельно. Думаю, теперь вы сами сможете ответить на вопрос, почему не показывает видео.
Как скачать K-Lite Codec Pack?
Теперь перейдем к практической части нашей статьи. Я расскажу, где и как скачать K-Lite Codec Pack. Файлы установки подходят как для 32-х битных систем, так и для 64-х битных. Придерживайтесь данного алгоритма:
Для видеозвонков в Badoo мы используем стандарт WebRTC и кодек H.264. Если верить документации, этот кодек должен без проблем работать на любых устройствах Android начиная с Android 5.0. Но на практике всё оказалось не совсем так. В этой статье я расскажу про особенности реализации аппаратного кодирования для кодека H.264 в WebRTC и о том, как заставить его работать на большем количестве устройств.
Режим битрейта
Стандартный режим для всех видеокодеков — постоянный битрейт. Однако однажды нам пришлось использовать переменный битрейт:
Произошло это на устройстве Lenovo A1000 с чипсетом компании Spreadtrum (теперь Unisoc), начинающимся с префикса “OMX.sprd.”. Поиск в Интернете привёл нас к посту шестилетней давности о Firefox OS, описывающему эту проблему и способ её решения.
Исправление
Тем самым мы включим работу плагина на ядре NT 5.0 и выше, вместо NT 6.0. После исправления необходимо упаковать файлы обратно в omni.ja. Архивация с обычными параметрами тут не подойдёт, нужно использовать консоль:
После замены им оригинала всё опять заработало.
Замечу, что необходимо так же активировать поддержку воспроизведения видео при помощи плагинов, в about:config необходимо выставить в true:
У меня эта настройка была давно включена, в надежде на работу h264 через OpenH264. После этого можно наслаждаться видео в h264 на любых сайтах, в том числе YouTube, Vimeo, сервисах онлайн-трансляций и т.д.
(тест на чистой ОС в виртуальной машине)
Я создал запрос в Bugzilla на возврат поддержки плагина Primetime на Windows XP, но что-то мне подсказывает, что это закончится ничем.
Предлагаю помочь в исправлении описания запроса, так как я косноязычен даже на русском языке (если вы не заметили), а уж на английском понятность моих пояснений полностью теряется, что ещё более снижает шансы на официальное исправление этой проблемы в будущих версиях Firefox.
Графики Y-PSNR - Frame Size
На этих графиках хорошо видна динамика зависимости качества сжатого фильма от его размера. Координатами опорных точек диаграммы являются средние по фильму значения метрики и размера кадра. Таким образом, каждая ветвь имеет по десять точек, соответствующих разным битрейтам.
Delta Y-PSNR – это графики относительного PSNR. В качестве референсного кодека выбран DivX 5.1.1. Для каждого замера на графике конкретного кодека бралась разница этого замера и значения PSNR для референсного кодека с тем же битрейтом. При отсутствии значения, PSNR референсного кодека получался линейной интерполяцией.
Читайте также: