Microsoft добавила поддержку H.264 в Firefox

    Ни для кого не секрет что Firefox не умеет воспроизводить видео закодированное H.264 кодером и в будущем такой функционал не планируется. Причина довольно проста — Mozilla в войне кодеков для HTML5 video сделала ставку на свободный VP8(в контейнерах WebM) от Google. Но в сети много видео закодированного в H.264(формат flv5, mp4) и для его перекодировки под новый стандарт нужны не малые вычислительные мощности. Для таких гигантов как google это конечно не такая большая проблема, а вот для небольших компаний переход на новый стандарт может влететь в копеечку. Вот для таких товарищей и постарался Microsoft(конечно не без профита для себя) — был выпущен аддон для плагина WindowsMediaPlayer, который позволит пользователям Windows 7 смотреть H.264-видео в Firefox.

    Итак встречайте — HTML5 Extension for Windows Media Player Firefox Plug-in

    [Перевод]
    HTML5 Extension для Windows Media Player Firefox Plug-in это аддон, позволяющий пользователям Firefox просматривать H.264-видео на HTML5 страницах, используя встроенные возможности Windows 7. Это расширение позволяет очень популярному ранее плагину Windows Media Player Plug-in for Firefox функционировать на страницах которые используют стандарт HTML5.

    Поддерживаемые платформы
    Требует Firefox 3.6 или последний Firefox 4.0 beta
    Windows 7

    Ссылки
    Установить аддон
    Windows Media Player Firefox Plug-in Release Notes

    Лицензия
    Копия лицензионного соглашения доступна здесь (Также копия будет установлена вместе с аддоном)

    Заметки для разработчиков
    Расширение основано на аддоне для Firefox который парсит HTML5 страницы и заменяет теги Video на вызов Windows Media Player plug-in, таким образом позволяя просматривать видео в браузере. Аддон заменяет видео теги только если в теге указан формат видео, который поддерживается в
    Windows Media Player. Теги с другими видео форматами остаются не тронутыми.

    В некоторых случаях Firefox не сможет воспроизвести видео, даже если аддон установлен корректно. Это происходит если на странице используется вызов canPlayType для определения поддержки H.264-видео браузером. Обычно проверку делают используя createElement('video') или getElementsByTagName('video') и вызовом canPlayType('video'mp4'). В обоих случаях вызов вернет пустую строку даже если аддон установлен и браузер может проиграть H.264-видео.

    Текущая версия аддона все еще использует Windows Media Player Plugin API для управления проигрывателем, потому есть некоторые различия между методами/свойствами определенными в стандарте HTML5 и теми, что доступны в Windows Media Player plug-in.
    Мы стараемся найти решение этих проблем, если это возможно.
    [/Перевод]
    Поделиться публикацией

    Комментарии 49

      –4
      Mozzila могли бы уже давно научить браузер использовать кодек который поставляется с ОС, ибо все современные и успешные ОС (Мак ОС, Винда) имеют кодек h.264 out-the-box, а у нище^W линупсоидов есть какой-то свой контейнер кодеков и x264.
        –2
        могли бы, никто не спорит. но зачем им добавлять поддержку h264, если они продвигают его конкурента? А вот для мелкомягких это плюс в карму для вин7 и дополнительные юзеры для wmp.
          +10
          Только работать этот плагин не будет практически нигде. Да и не плагин это, а какое-то недоразумение. Во-первых, список поддерживаемых форматов для HTML5 video проверяют практически все (и тег формируют динамически — тоже). Во-вторых, и в основных — главное достоинство в HTML5 video теге — это его дикая интеграция в страничку. Захотел — повернул на 30 градусов. Захотел — дёрнул из javascript'а и как-то им поманипулировал — запустил, остановил, перемотал, зациклил. Видеотэг — легкий, не тяжелее, чем <img/> — его хорошо использовать для любых анимаций, в том числе за замена анимированным gif'ам и т.п.

          А здесь — получается штуковина, которая тупо ищет все <video/>-вхождения и заменяет их на свой собственной вызов со своим собственным API. Работать это будет ровно в одном-единственном случае — когда видеотэг прописан явно и со включенными controls. Ни повернуть, ни даже остановить или перемотать это программно не получится. Не говоря уже о том, что ActiveX-подобная подгрузка будет, как это бывает обычно, тормозить и жить своей жизнью, ни разу не вписываясь в страничку.
          +1
          Согласен с Вами. Тем не менее, на сколько я помню, когда начиналась вся эта затея с видео/аудио тегами, идея была именно в том, чтобы видео работало в браузере независимо от установленных в системе кодеков. Происходила эта идея одной ногой из тренда по превращению браузера в изолированную, унифицированную и максимально функциональную операцтонную среду для web-приложений, а другой из наивных надежд и здорового стремления народа устранить зоопарк путём прописывания одного единственного кодека (тогда на это претендовала OGG Theora) в стандарт HTML by W3C и «железной» («чтоб наверняка») реализации его в браузерах но, увы, опять «хотели как лучше, а получилось как всегда».

          Ход MS видится довольно грамотным — без этого с выходом Firefox 4 формат WebM-VP8 вполне мог стать количественно наиболее широко поддержанным браузерами стандартом (на сколько я понимаю, получается Firefox, Chrome и Opera — сразу тремя из основных браузеров (Chrome видится мне весомее Safari, хотя может я и не прав)) и благодаря этому вкупе со свободностью начать завоёвывать популярность. А теперь количественно наиболее широко поддержанным браузерами стандартом (Safari, Chrome, IE, теперь и Firefox (большинство установок которого всё равно вроде приходится на винду), на счёт Оперы не знаю) получится, на сколько я понимаю, в любом случае H.264.
            +1
            Еще один плюс H.264 — аппаратное декодирование, что очень полезно и необходимо для портативных и мобильных устройств.
              +4
              Нет никакого «аппаратного декодирования H.264», забудьте. Есть motion compensation, есть iDCT, есть аппаратное декодирование variable-length — подчеркиваю, что всё это есть и полезно не только для H.264, но и для большинства других кодеков, будь то VP8 или Theora — и есть кое-где аппаратный деблокинг для того, что уже декодировалось каким-то образом, в том числе есть деблокинг, учитывающий особенности и артефакты, характерные именно для H.264.
                –1
                Аппаратное декодирование есть. полное. Только пока в HTML5 ни один браузер не задействует его. Но флэш и стационарные плееры уже его юзают.
                  –1
                  А вообще я наверное неправильно понял комментарий выше.
                  Действительно аппаратно декодировать можно любой из современных видео-форматов. Все зависит от желания разработчиков железа реализовать поддержку формата в драйвере/железе. А желании зависит от важности и популярности формата. Войдет вебМ в массы — будет и он декодироваться на железе.
                    0
                    Думаетя мне на энтузиазм разработчиков железа логично было бы повлиять ещё и тому факту, что за реализацию VP8 не надо платить роялти всяким MPEG LA.
                    +1
                    Покажите мне, пожалуйста, хоть одну распространенный чип, который на вход получает каким-то образом MPEG4 контейнер с H.264/AAC (побайтово или поблочно, например), а на выходе каким-то магическим образом отдает изображение.

                    Такого нет и не нужно это никому. «Аппаратно» разбирать контейнерные форматы и даже декодировать H.264 блоки никакого смысла нет — железячники вполне умеют считать деньги и ускоряют именно то, что имеет смысл ускорять — то что обычные процессоры делают медленно — а именно iDCT, moco, VLD и деблокинг. Причем без деблокинга даже в теории можно жить (хотя H.264 стандарт и обязывает его делать при воспроизведении — за счёт чего, собственно, и получается львиная доля криков о том, что, мол, H.264 — это очень круто, а все более старые кодеки — отстой и куда сильнее портят картинку; о том, что такой же деблокинг в постпроцессинге вполне можно сделать хоть на DivX, хоть на MPEG2 — почему-то стараются не думать).
                      –1
                      Любой современный видеочип.
                      Это и называется Bitstream Acceleration. В видеокарту заливается видеострим, где происходит аппаратное декодирование потока, постпроцессинг и вывод на экран. И это очень нужно, потому что только благодаря этому на платформе Nvidia ION с процессором Atom можно смотреть H264 1080p.
                      Что я могу наблюдать лично на своем десктопе, что при задействовании DXVA ядра процессора снижают частоту до 800MHz загрузка при этом не превышает 10%. Что позволяет говорить о полностью аппаратном декодировании.
                      en.wikipedia.org/wiki/Nvidia_PureVideo
                      en.wikipedia.org/wiki/Unified_Video_Decoder
                        +5
                        Почитайте, пожалуйста, еще раз всё, что я написал и интенсивнее смахните с ушей маркетинговую лапшу, которую усиленно навешивают местами даже в википедии. Почитайте, как устроен любой современный кодек — DivX, H264 / AVC, VP8, даже та же самая Theora.

                        Никакой магии нет. Никакой «современный видеочип» не разбирает видеопоток — это дорого и бессмысленно. Файл читается на уровне приложения, приложение передает видеопоток даже не драйверу, а некоему API (DXVA в Windows, XvBA/VPDAU в Linux), API трансформирует это в серию вызовов драйвера, где те операции, которые можно распараллелить, делаются через конвейерную логику GPU (я их уже несколько раз назвал выше, могу объяснить, что это за операции, в чем их смысл и почему именно их имеет смысл ускорять), а те операции, которые делать на GPU смысла нет — вполне себе делаются на CPU.

                        Если совсем на пальцах — вы согласны с тем, что если бы декодирование было бы совсем полное на видеокарте, то вы бы наблюдали загрузку процессора, равную 0, а не 10%?
                          –3
                          Вы придираетесь к словам. По-вашему выражение «полное ускорение» вообще недопустимо. В OpenGL и Direct3D тоже куча операций выполняется программно, а те, которые нет, что странно, кидаются не напрямую в железо, а через API. На каждый пост где будет употреблено выражение Full hardware acceleration будете коммент писать?

                          Надо еще распарсить контейнер, подготовить данные для апи, декодировать звук. Я не буду спорить с тем что какая-то часть выполняется на CPU. Это совершенно не играет роли, т.к. для пользователя это полное аппаратное ускорение. Ибо загрузка процессора падает до пренебрежимо малого уровня. И пример ION говорит нам о том, что для CPU остается очень мало работы.
                            +3
                            GreyCat полностью прав. И да, это никакое не полное аппаратное ускорение. H264 поддерживается аппаратно почти не более, чем любой другой кодек.
                            +2
                            я их уже несколько раз назвал выше, могу объяснить, что это за операции, в чем их смысл и почему именно их имеет смысл ускорять

                            Если не трудно — пожалуйста.
                              0
                              На самом деле каждое из них — предмет отдельной статьи или даже цикла статей про то, как работают кодеки, как работают алгоритмы сжатия вообще и т.п.

                              Но есть коротко и на пальцах:

                              Motion compensation

                              Иногда еще называется MoCo, moco, mo co и т.п.

                              Представим себе процесс сжатия видео: первый кадр сжимается, как статическая картинка (JPEG), а для каждого последующего n-го кадра вычисляется разница между (n) и (n-1), и записывается только разница. Это работает хорошо, когда камера статична (т.е., например, фон всегда на одном и том же месте в кадре, двигается только какой-то один объект поверх этого фона), но совершенно безобразно портит нам всю картину сжатия, когда камера начинает двигаться и формально фон кадра (n) отличается от фона кадра (n-1) на 100%. Для этого придуман mo co — вместе с каждым кадром, где происходит фон сдвигается, вычисляется хитрая матрица преобразований фона, которая позволяет сдвигать, масштабировать и вращать его. Вместо записи 100% новой картинки фона — достаточно записать матрицу из 9 значений и только кусочки нового фона, которых не было видно в прошлом кадре. Есть 2D и 3D mo co — в 3D варианте, соответственно, фон умеет уже не только вращаться и масштабироваться в 2D, но и проделывать практически произвольные 3D репроекции.

                              Эта задачка репроецирования безумно похожа на то, что делают графические процессоры при выводе какого-нибудь трехмерного треугольника с текстурой — с той только разницей, что, в отличие от 3D-игрушек, где алгоритм такой:

                              1. Закачать в память видеокарты текстуры
                              2. Инициировать процесс вывода полигона с такими-то 3D-координатами в буфер экрана
                              3. Показать экран пользователю
                              тут будет такой:

                              1. Закачать кадр в текстурную память
                              2. Отрендерить полигон в буфер
                              3. Буфер перенести обратно в текстурную память


                              … Комментарии тут ограничены немножко, поэтому я в нескольких комментариях…
                                0
                                Требую полноценной статьи.
                          0
                          Если вы не знаете о таких чипах, то это не значит что их нет.
                          В любом устройстве типа set-top-box и часто в мобильных устройствах стоят чипы с полным аппаратным декодированием H.264. Например такие чипы выпускает ST.
                            0
                            То, что вы показываете — не совсем «чип» в традиционном понимании этого слова, это скорее SoC — system-on-a-chip — готовая система, включающая в себя основной процессор, сопроцессоры, память, IO, периферия и т.д. По сути, здоровый компьютер, просто сверхвысокой интеграции и посему упакованный в корпус с 708 + 84 ножками. Они, кстати, от традиционных процессоров даже визуально отличаются — видно, что они состоят из нескольких изолированных частей, с отдельными генераторами, частотами, организованными шинами между ними и т.п.

                            С точки зрения градиции «полностью аппаратный — полностью программный» — этот пример гораздо более «программный», чем большинство других (с теми же NVIDIA/ATI-чипами). В этом system-on-a-chip есть прошивка, в ней стоит скорее всего обычный Linux для процессора ST40, на котором базируется этот SoC, или, в крайнем случае — какая-нибудь другая embedded OS, типа uC/OS. Под нее портирован фреймворк какого-нибудь mplayer или ffmpeg. Да, там есть графический сопроцессор (Gamma 2D/3D, как там написано), который ускоряет в большинстве своем базовые штуки, которые на x86 делаются за счёт SSE-инструкций — всякие преобразования цветовых пространств, матричные 2D/3D преобразования, фильтрации изображений после них, интерлейсер-деинтерлейсер — но, субъективно, роль NVIDIA/ATI в этом процессе на PC куда больше и ускоряют они куда эффективнее. Тут же ускорять-то сильно не нужно — центральный процессор аж на 266 мегагерц, причем RISC, все они по сути отданы под одну задачу — декодировать видео.

                            Каких-то принципиальных проблем декодировать на этой системе кодеки, отличные от H.264, я не вижу — нужно просто портировать под эту ОС, которая там стоит, сам кодек и предусмотреть перекладывание в нем потоковых параллелизуемых операций на имеющийся сопроцессор.
                    0
                    >А теперь количественно наиболее широко поддержанным браузерами стандартом (Safari, Chrome, IE, теперь и Firefox (большинство установок которого всё равно вроде приходится на винду), на счёт Оперы не знаю) получится, на сколько я понимаю, в любом случае H.264.

                    Чтобы получилось, нужно чтобы в большинство установок файерфокса был этот плагин установлен. Полуавтоматически, как в случае скажем с флэш или пдф, он, кажется, не встанет без движений со стороны Mozilla, а таких движений от них ждать сложно. Да и учитывая, что среди пользователей Fx довольно много тех, для кого слово «Microsoft» как тряпка для красного быка сознательных установок может быть немного.
                      0
                      Я думаю Mozilla могла бы добавить его как «default», но для этого Microsoft нужно было сделать действительно подарок невиданной щедрости и реализовать работу плагина на всех системах, будь это Windows XP, Linux или Mac Os.
                        +2
                        Полуавтоматически, как в случае скажем с флэш или пдф, он, кажется, не встанет без движений со стороны Mozilla

                        Зато при желании Microsoft встанет полностью автоматически как, к примеру,«Microsoft .NET Framework Assistant», «Search Helper Extension», и т.п. «движениями» со стороны Mozilla при этом, увы, будет только недовольное ёрзание — совсем недавно, помню, кто-то (вроде из Мозиллы) выражал опасения той ситуацией, что такая практика (внедрение кем попало экстеншнов в Firefox) в последнее время популярна — сделать они ничего с этим, как видимо, не могут — такая архитектура — «defective by design» :-(
                          0
                          Ошибся :( Как-то не замечал экстешенов от MS в своей лисе —
                            +1
                            Ну, у Mozilla есть способы бороться. Blacklisting, например. Тот же MS .Net Framework Assistant свое уже раз получал.
                              0
                              Это таки лечение гойловной боли гильотиной (ведь чего лукавить, это плохо если Mozilla в принципе лишит пользователей возможности использовать определённый плагин — кому-то он может быть практически полезен, особенно в данном конкретном случае — иметь возможность смотреть H.264 видео, да не выходя из Firefox — это хорошо), плохо что более человеческих способов нет.

                              Можно понять что посторонний софт при должных правах на запись в соответствующие места может внедрить плагин.

                              Абсурдно что его можно внедрить так, что кнопки Disable и Uninstall в списке плагинов в Firefox будут недоступны (хотя казалось бы, чем сам Firefox хуже внедрителей если он мог бы, соответственно, не запускать этот плагин в случае такого распряжения пользователя и удалить его если есть те же права на запись), и ещё интересней что даже если я запускаю вроде как самостоятельный портабельный Firefox (с portableapps.com) — он всё равно находит в системе и подцепляет эти плагины (что свидетельствует о том, что они хранятся не в рабочей/профильной директории фаерфокса и что нахождением и запуском их он занимается лично сам).
                                0
                                Ну, если я правильно помню историю, то под угрозой blacklisting кнопка uninstall появилась.

                                А начиная с Fx 4.0, когда он в первый раз видит установленный таким образом плагин, он спрашивает, юзать его или нет.
                                  0
                                  Ну, если я правильно помню историю, то под угрозой blacklisting кнопка uninstall появилась.

                                  Что, собственно, только демонстрирует — что ввиду каких-то архитектурных особенностей Firefox сам себе не хозяин и доступность кнопок в нём может управляться внешними силами, на которые приходится воздействовать силой убеждения.
                                  А начиная с Fx 4.0, когда он в первый раз видит установленный таким образом плагин, он спрашивает, юзать его или нет.

                                  Отрадно.
                          0
                          >OGG Theora

                          Не претендовала. Просто парочка (сотен) задротов наивно полагали, что:
                          1) Опенсурс освобождает от патентов
                          2) Стандарт без поддержки производителей взлетит
                          3) Реализация которая встасывает у реализации другого стандарта взлетит

                          > Происходила эта идея одной ногой из тренда по превращению браузера в изолированную, унифицированную и максимально функциональную операцтонную среду для web-приложений,

                          Этой идей были заражены только Mozzila и Opera.

                          >WebM-VP8 вполне мог стать количественно наиболее широко поддержанным браузерами стандартом (на сколько я понимаю, получается Firefox, Chrome и Opera — сразу тремя из основных браузеров (Chrome видится мне весомее Safari, хотя может я и не прав))

                          Нет, не мог. FF,Opera,Chrome < IE, Safari. А проблема с кодеком только у *nix like (а их на десктопе меньше той о которой можно заботиться). А теперь вспомним про мобильные девайсы, а там у нас iPad, iPhone, iPod + тысячи китайский недоделок на андроиде 1.6 и доставщики пиццы ждущие когда же на их телефон выйдет 2.2 ( а кто-то все еще ждет 2.1). Так или иначе h.264 победит.

                          Напомню, что еще до покупки гуглом разработчики говорили, что VP8 БЫСТРЕ ЛУЧШЕ НЯШНЕЕ ЕЩЕ И КОФЕ ГОТОВИТ!!!!!, а вышло хуже, медленнее и затратнее.
                            +1
                            >Нет, не мог. FF,Opera,Chrome < IE, Safari.

                            Угу, Сафари со своими ~5% рынка по многим оценкам (кроме российских :) у нас Опера сильна как нигде, наверное) перетягивает чашу на сторону IE
                            +1
                            Из того, что видно мне — в среднем по рунету ~65..68% браузеров поддерживают video-тэг — т.е., грубо говоря всё, кроме IE. Chrome занимает 8.2% и уверенно растёт по ~0.7-0.8% в месяц. Доля Safari (включая и мобильный вариант Safari) — 2%.

                            Время полураспада IE7 после выхода IE8 (т.е. чтобы IE8 стало больше, чем IE7) — с марта по ноябрь 2009, т.е. ~8-9 месяцев — причём точка переключения на уровне доли 8-9%.

                            Когда придёт великий-и-ужасный IE9 со своей поддержкой video-без-VP8 — пройдет еще минимум эти же 8-9 месяц — и только после этого доля браузеров-с-video-без-VP8 будет достигать 2% (Safari) + 9% (IE9) = 11%. Думаете, если так дела будут идти, они не прогнутся?
                          0
                          Недавно случайно обнаружил что youtube хорошо просматривается в Firefox в html5 режиме и большую часть роликов уже сконвертировали в WebM.
                            0
                            youtube в html5 просматривается только в фф4+, в 3.6 все еще флеш. ну а на счет того сколько сконвертировали, недавно инфа пролетала что 80%+ всех видео ютуба уже в WebM
                            0
                            Что-то у меня автоопределение не сработало нигде. После установки стало отдавать флеш.
                              0
                              а сам Windows Media Player Firefox Plug-in у вас стоит?
                              +2
                              отлично, но хотелось бы больший список поддерживаемых платформ…
                                –2
                                /оффтопик

                                Три раза перечитывал название топика, сначала думал глюки, потом что автор опечатался :)
                                  0
                                  Microsoft продемонстрировала, что иногда умеет играть на рынке достаточно умно, лихо, но с подковыркой.
                                    –1
                                    Мне кажется им нужно было это сделать на год раньше, а сейчас уже гугл большую часть видео перекодировал в собственный формат.
                                    +3
                                    «Полный набор ваших любимых уязвимостей в вашем любимом браузере.»
                                      0
                                      Как на меня это костыль по сути.
                                        +1
                                        HTML5 и снова костыли, костыли, костыли… Почти все видео на одном из сайтов в H264 и не буду я его ради FireFox переделывать в WebM.
                                          –2
                                          А мы не будем заходить на «один из сайтов».
                                            0
                                            Обойдемся теми у кого таки установлен Flash в бразуере.
                                          +3
                                          А смысл?
                                          Зачем ставить плагин WM, если есть flash с H264, который имеется во всех браузерах?
                                            +1
                                            Хорошо, но лучше бы они VP8 и Vorbis в Internet Explorer 9 добавили.
                                              0
                                              А разве IE не все равно, какой кодек? В системе стоит — будет проигрываться.
                                                +1
                                                Но поддержку VP8 и Vorbis нужно будет доустанавливать, хотя она могла бы быть из коробки.
                                              0
                                              И чем оно лучше System Video?
                                                0
                                                Ещё уточните, что плагин есть только для 32-битной сборки. Для Win64 его (пока?) нет.

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                Самое читаемое