Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 49
Mozzila могли бы уже давно научить браузер использовать кодек который поставляется с ОС, ибо все современные и успешные ОС (Мак ОС, Винда) имеют кодек h.264 out-the-box, а у нище^W линупсоидов есть какой-то свой контейнер кодеков и x264.
могли бы, никто не спорит. но зачем им добавлять поддержку h264, если они продвигают его конкурента? А вот для мелкомягких это плюс в карму для вин7 и дополнительные юзеры для wmp.
Только работать этот плагин не будет практически нигде. Да и не плагин это, а какое-то недоразумение. Во-первых, список поддерживаемых форматов для HTML5 video проверяют практически все (и тег формируют динамически — тоже). Во-вторых, и в основных — главное достоинство в HTML5 video теге — это его дикая интеграция в страничку. Захотел — повернул на 30 градусов. Захотел — дёрнул из javascript'а и как-то им поманипулировал — запустил, остановил, перемотал, зациклил. Видеотэг — легкий, не тяжелее, чем <img/> — его хорошо использовать для любых анимаций, в том числе за замена анимированным gif'ам и т.п.
А здесь — получается штуковина, которая тупо ищет все <video/>-вхождения и заменяет их на свой собственной вызов со своим собственным API. Работать это будет ровно в одном-единственном случае — когда видеотэг прописан явно и со включенными controls. Ни повернуть, ни даже остановить или перемотать это программно не получится. Не говоря уже о том, что ActiveX-подобная подгрузка будет, как это бывает обычно, тормозить и жить своей жизнью, ни разу не вписываясь в страничку.
А здесь — получается штуковина, которая тупо ищет все <video/>-вхождения и заменяет их на свой собственной вызов со своим собственным API. Работать это будет ровно в одном-единственном случае — когда видеотэг прописан явно и со включенными controls. Ни повернуть, ни даже остановить или перемотать это программно не получится. Не говоря уже о том, что ActiveX-подобная подгрузка будет, как это бывает обычно, тормозить и жить своей жизнью, ни разу не вписываясь в страничку.
Согласен с Вами. Тем не менее, на сколько я помню, когда начиналась вся эта затея с видео/аудио тегами, идея была именно в том, чтобы видео работало в браузере независимо от установленных в системе кодеков. Происходила эта идея одной ногой из тренда по превращению браузера в изолированную, унифицированную и максимально функциональную операцтонную среду для web-приложений, а другой из наивных надежд и здорового стремления народа устранить зоопарк путём прописывания одного единственного кодека (тогда на это претендовала OGG Theora) в стандарт HTML by W3C и «железной» («чтоб наверняка») реализации его в браузерах но, увы, опять «хотели как лучше, а получилось как всегда».
Ход MS видится довольно грамотным — без этого с выходом Firefox 4 формат WebM-VP8 вполне мог стать количественно наиболее широко поддержанным браузерами стандартом (на сколько я понимаю, получается Firefox, Chrome и Opera — сразу тремя из основных браузеров (Chrome видится мне весомее Safari, хотя может я и не прав)) и благодаря этому вкупе со свободностью начать завоёвывать популярность. А теперь количественно наиболее широко поддержанным браузерами стандартом (Safari, Chrome, IE, теперь и Firefox (большинство установок которого всё равно вроде приходится на винду), на счёт Оперы не знаю) получится, на сколько я понимаю, в любом случае H.264.
Ход MS видится довольно грамотным — без этого с выходом Firefox 4 формат WebM-VP8 вполне мог стать количественно наиболее широко поддержанным браузерами стандартом (на сколько я понимаю, получается Firefox, Chrome и Opera — сразу тремя из основных браузеров (Chrome видится мне весомее Safari, хотя может я и не прав)) и благодаря этому вкупе со свободностью начать завоёвывать популярность. А теперь количественно наиболее широко поддержанным браузерами стандартом (Safari, Chrome, IE, теперь и Firefox (большинство установок которого всё равно вроде приходится на винду), на счёт Оперы не знаю) получится, на сколько я понимаю, в любом случае H.264.
Еще один плюс H.264 — аппаратное декодирование, что очень полезно и необходимо для портативных и мобильных устройств.
Нет никакого «аппаратного декодирования H.264», забудьте. Есть motion compensation, есть iDCT, есть аппаратное декодирование variable-length — подчеркиваю, что всё это есть и полезно не только для H.264, но и для большинства других кодеков, будь то VP8 или Theora — и есть кое-где аппаратный деблокинг для того, что уже декодировалось каким-то образом, в том числе есть деблокинг, учитывающий особенности и артефакты, характерные именно для H.264.
Аппаратное декодирование есть. полное. Только пока в HTML5 ни один браузер не задействует его. Но флэш и стационарные плееры уже его юзают.
А вообще я наверное неправильно понял комментарий выше.
Действительно аппаратно декодировать можно любой из современных видео-форматов. Все зависит от желания разработчиков железа реализовать поддержку формата в драйвере/железе. А желании зависит от важности и популярности формата. Войдет вебМ в массы — будет и он декодироваться на железе.
Действительно аппаратно декодировать можно любой из современных видео-форматов. Все зависит от желания разработчиков железа реализовать поддержку формата в драйвере/железе. А желании зависит от важности и популярности формата. Войдет вебМ в массы — будет и он декодироваться на железе.
Покажите мне, пожалуйста, хоть одну распространенный чип, который на вход получает каким-то образом MPEG4 контейнер с H.264/AAC (побайтово или поблочно, например), а на выходе каким-то магическим образом отдает изображение.
Такого нет и не нужно это никому. «Аппаратно» разбирать контейнерные форматы и даже декодировать H.264 блоки никакого смысла нет — железячники вполне умеют считать деньги и ускоряют именно то, что имеет смысл ускорять — то что обычные процессоры делают медленно — а именно iDCT, moco, VLD и деблокинг. Причем без деблокинга даже в теории можно жить (хотя H.264 стандарт и обязывает его делать при воспроизведении — за счёт чего, собственно, и получается львиная доля криков о том, что, мол, H.264 — это очень круто, а все более старые кодеки — отстой и куда сильнее портят картинку; о том, что такой же деблокинг в постпроцессинге вполне можно сделать хоть на DivX, хоть на MPEG2 — почему-то стараются не думать).
Такого нет и не нужно это никому. «Аппаратно» разбирать контейнерные форматы и даже декодировать H.264 блоки никакого смысла нет — железячники вполне умеют считать деньги и ускоряют именно то, что имеет смысл ускорять — то что обычные процессоры делают медленно — а именно iDCT, moco, VLD и деблокинг. Причем без деблокинга даже в теории можно жить (хотя H.264 стандарт и обязывает его делать при воспроизведении — за счёт чего, собственно, и получается львиная доля криков о том, что, мол, H.264 — это очень круто, а все более старые кодеки — отстой и куда сильнее портят картинку; о том, что такой же деблокинг в постпроцессинге вполне можно сделать хоть на DivX, хоть на MPEG2 — почему-то стараются не думать).
Любой современный видеочип.
Это и называется Bitstream Acceleration. В видеокарту заливается видеострим, где происходит аппаратное декодирование потока, постпроцессинг и вывод на экран. И это очень нужно, потому что только благодаря этому на платформе Nvidia ION с процессором Atom можно смотреть H264 1080p.
Что я могу наблюдать лично на своем десктопе, что при задействовании DXVA ядра процессора снижают частоту до 800MHz загрузка при этом не превышает 10%. Что позволяет говорить о полностью аппаратном декодировании.
en.wikipedia.org/wiki/Nvidia_PureVideo
en.wikipedia.org/wiki/Unified_Video_Decoder
Это и называется Bitstream Acceleration. В видеокарту заливается видеострим, где происходит аппаратное декодирование потока, постпроцессинг и вывод на экран. И это очень нужно, потому что только благодаря этому на платформе Nvidia ION с процессором Atom можно смотреть H264 1080p.
Что я могу наблюдать лично на своем десктопе, что при задействовании DXVA ядра процессора снижают частоту до 800MHz загрузка при этом не превышает 10%. Что позволяет говорить о полностью аппаратном декодировании.
en.wikipedia.org/wiki/Nvidia_PureVideo
en.wikipedia.org/wiki/Unified_Video_Decoder
Почитайте, пожалуйста, еще раз всё, что я написал и интенсивнее смахните с ушей маркетинговую лапшу, которую усиленно навешивают местами даже в википедии. Почитайте, как устроен любой современный кодек — DivX, H264 / AVC, VP8, даже та же самая Theora.
Никакой магии нет. Никакой «современный видеочип» не разбирает видеопоток — это дорого и бессмысленно. Файл читается на уровне приложения, приложение передает видеопоток даже не драйверу, а некоему API (DXVA в Windows, XvBA/VPDAU в Linux), API трансформирует это в серию вызовов драйвера, где те операции, которые можно распараллелить, делаются через конвейерную логику GPU (я их уже несколько раз назвал выше, могу объяснить, что это за операции, в чем их смысл и почему именно их имеет смысл ускорять), а те операции, которые делать на GPU смысла нет — вполне себе делаются на CPU.
Если совсем на пальцах — вы согласны с тем, что если бы декодирование было бы совсем полное на видеокарте, то вы бы наблюдали загрузку процессора, равную 0, а не 10%?
Никакой магии нет. Никакой «современный видеочип» не разбирает видеопоток — это дорого и бессмысленно. Файл читается на уровне приложения, приложение передает видеопоток даже не драйверу, а некоему API (DXVA в Windows, XvBA/VPDAU в Linux), API трансформирует это в серию вызовов драйвера, где те операции, которые можно распараллелить, делаются через конвейерную логику GPU (я их уже несколько раз назвал выше, могу объяснить, что это за операции, в чем их смысл и почему именно их имеет смысл ускорять), а те операции, которые делать на GPU смысла нет — вполне себе делаются на CPU.
Если совсем на пальцах — вы согласны с тем, что если бы декодирование было бы совсем полное на видеокарте, то вы бы наблюдали загрузку процессора, равную 0, а не 10%?
Вы придираетесь к словам. По-вашему выражение «полное ускорение» вообще недопустимо. В OpenGL и Direct3D тоже куча операций выполняется программно, а те, которые нет, что странно, кидаются не напрямую в железо, а через API. На каждый пост где будет употреблено выражение Full hardware acceleration будете коммент писать?
Надо еще распарсить контейнер, подготовить данные для апи, декодировать звук. Я не буду спорить с тем что какая-то часть выполняется на CPU. Это совершенно не играет роли, т.к. для пользователя это полное аппаратное ускорение. Ибо загрузка процессора падает до пренебрежимо малого уровня. И пример ION говорит нам о том, что для CPU остается очень мало работы.
Надо еще распарсить контейнер, подготовить данные для апи, декодировать звук. Я не буду спорить с тем что какая-то часть выполняется на CPU. Это совершенно не играет роли, т.к. для пользователя это полное аппаратное ускорение. Ибо загрузка процессора падает до пренебрежимо малого уровня. И пример ION говорит нам о том, что для CPU остается очень мало работы.
GreyCat полностью прав. И да, это никакое не полное аппаратное ускорение. H264 поддерживается аппаратно почти не более, чем любой другой кодек.
я их уже несколько раз назвал выше, могу объяснить, что это за операции, в чем их смысл и почему именно их имеет смысл ускорять
Если не трудно — пожалуйста.
На самом деле каждое из них — предмет отдельной статьи или даже цикла статей про то, как работают кодеки, как работают алгоритмы сжатия вообще и т.п.
Но есть коротко и на пальцах:
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-игрушек, где алгоритм такой:
… Комментарии тут ограничены немножко, поэтому я в нескольких комментариях…
Но есть коротко и на пальцах:
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-игрушек, где алгоритм такой:
- Закачать в память видеокарты текстуры
- Инициировать процесс вывода полигона с такими-то 3D-координатами в буфер экрана
- Показать экран пользователю
- Закачать кадр в текстурную память
- Отрендерить полигон в буфер
- Буфер перенести обратно в текстурную память
… Комментарии тут ограничены немножко, поэтому я в нескольких комментариях…
Если вы не знаете о таких чипах, то это не значит что их нет.
В любом устройстве типа set-top-box и часто в мобильных устройствах стоят чипы с полным аппаратным декодированием H.264. Например такие чипы выпускает ST.
В любом устройстве типа set-top-box и часто в мобильных устройствах стоят чипы с полным аппаратным декодированием H.264. Например такие чипы выпускает ST.
То, что вы показываете — не совсем «чип» в традиционном понимании этого слова, это скорее 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, я не вижу — нужно просто портировать под эту ОС, которая там стоит, сам кодек и предусмотреть перекладывание в нем потоковых параллелизуемых операций на имеющийся сопроцессор.
С точки зрения градиции «полностью аппаратный — полностью программный» — этот пример гораздо более «программный», чем большинство других (с теми же 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, я не вижу — нужно просто портировать под эту ОС, которая там стоит, сам кодек и предусмотреть перекладывание в нем потоковых параллелизуемых операций на имеющийся сопроцессор.
>А теперь количественно наиболее широко поддержанным браузерами стандартом (Safari, Chrome, IE, теперь и Firefox (большинство установок которого всё равно вроде приходится на винду), на счёт Оперы не знаю) получится, на сколько я понимаю, в любом случае H.264.
Чтобы получилось, нужно чтобы в большинство установок файерфокса был этот плагин установлен. Полуавтоматически, как в случае скажем с флэш или пдф, он, кажется, не встанет без движений со стороны Mozilla, а таких движений от них ждать сложно. Да и учитывая, что среди пользователей Fx довольно много тех, для кого слово «Microsoft» как тряпка для красного быка сознательных установок может быть немного.
Чтобы получилось, нужно чтобы в большинство установок файерфокса был этот плагин установлен. Полуавтоматически, как в случае скажем с флэш или пдф, он, кажется, не встанет без движений со стороны Mozilla, а таких движений от них ждать сложно. Да и учитывая, что среди пользователей Fx довольно много тех, для кого слово «Microsoft» как тряпка для красного быка сознательных установок может быть немного.
Я думаю Mozilla могла бы добавить его как «default», но для этого Microsoft нужно было сделать действительно подарок невиданной щедрости и реализовать работу плагина на всех системах, будь это Windows XP, Linux или Mac Os.
Полуавтоматически, как в случае скажем с флэш или пдф, он, кажется, не встанет без движений со стороны Mozilla
Зато при желании Microsoft встанет полностью автоматически как, к примеру,«Microsoft .NET Framework Assistant», «Search Helper Extension», и т.п. «движениями» со стороны Mozilla при этом, увы, будет только недовольное ёрзание — совсем недавно, помню, кто-то (вроде из Мозиллы) выражал опасения той ситуацией, что такая практика (внедрение кем попало экстеншнов в Firefox) в последнее время популярна — сделать они ничего с этим, как видимо, не могут — такая архитектура — «defective by design» :-(
Ошибся :( Как-то не замечал экстешенов от MS в своей лисе —
Ну, у Mozilla есть способы бороться. Blacklisting, например. Тот же MS .Net Framework Assistant свое уже раз получал.
Это таки лечение гойловной боли гильотиной (ведь чего лукавить, это плохо если Mozilla в принципе лишит пользователей возможности использовать определённый плагин — кому-то он может быть практически полезен, особенно в данном конкретном случае — иметь возможность смотреть H.264 видео, да не выходя из Firefox — это хорошо), плохо что более человеческих способов нет.
Можно понять что посторонний софт при должных правах на запись в соответствующие места может внедрить плагин.
Абсурдно что его можно внедрить так, что кнопки Disable и Uninstall в списке плагинов в Firefox будут недоступны (хотя казалось бы, чем сам Firefox хуже внедрителей если он мог бы, соответственно, не запускать этот плагин в случае такого распряжения пользователя и удалить его если есть те же права на запись), и ещё интересней что даже если я запускаю вроде как самостоятельный портабельный Firefox (с portableapps.com) — он всё равно находит в системе и подцепляет эти плагины (что свидетельствует о том, что они хранятся не в рабочей/профильной директории фаерфокса и что нахождением и запуском их он занимается лично сам).
Можно понять что посторонний софт при должных правах на запись в соответствующие места может внедрить плагин.
Абсурдно что его можно внедрить так, что кнопки Disable и Uninstall в списке плагинов в Firefox будут недоступны (хотя казалось бы, чем сам Firefox хуже внедрителей если он мог бы, соответственно, не запускать этот плагин в случае такого распряжения пользователя и удалить его если есть те же права на запись), и ещё интересней что даже если я запускаю вроде как самостоятельный портабельный Firefox (с portableapps.com) — он всё равно находит в системе и подцепляет эти плагины (что свидетельствует о том, что они хранятся не в рабочей/профильной директории фаерфокса и что нахождением и запуском их он занимается лично сам).
Ну, если я правильно помню историю, то под угрозой blacklisting кнопка uninstall появилась.
А начиная с Fx 4.0, когда он в первый раз видит установленный таким образом плагин, он спрашивает, юзать его или нет.
А начиная с Fx 4.0, когда он в первый раз видит установленный таким образом плагин, он спрашивает, юзать его или нет.
Ну, если я правильно помню историю, то под угрозой blacklisting кнопка uninstall появилась.
Что, собственно, только демонстрирует — что ввиду каких-то архитектурных особенностей Firefox сам себе не хозяин и доступность кнопок в нём может управляться внешними силами, на которые приходится воздействовать силой убеждения.
А начиная с Fx 4.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) Опенсурс освобождает от патентов
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 БЫСТРЕ ЛУЧШЕ НЯШНЕЕ ЕЩЕ И КОФЕ ГОТОВИТ!!!!!, а вышло хуже, медленнее и затратнее.
Из того, что видно мне — в среднем по рунету ~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%. Думаете, если так дела будут идти, они не прогнутся?
Время полураспада IE7 после выхода IE8 (т.е. чтобы IE8 стало больше, чем IE7) — с марта по ноябрь 2009, т.е. ~8-9 месяцев — причём точка переключения на уровне доли 8-9%.
Когда придёт великий-и-ужасный IE9 со своей поддержкой video-без-VP8 — пройдет еще минимум эти же 8-9 месяц — и только после этого доля браузеров-с-video-без-VP8 будет достигать 2% (Safari) + 9% (IE9) = 11%. Думаете, если так дела будут идти, они не прогнутся?
Недавно случайно обнаружил что youtube хорошо просматривается в Firefox в html5 режиме и большую часть роликов уже сконвертировали в WebM.
Что-то у меня автоопределение не сработало нигде. После установки стало отдавать флеш.
отлично, но хотелось бы больший список поддерживаемых платформ…
/оффтопик
Три раза перечитывал название топика, сначала думал глюки, потом что автор опечатался :)
Три раза перечитывал название топика, сначала думал глюки, потом что автор опечатался :)
Microsoft продемонстрировала, что иногда умеет играть на рынке достаточно умно, лихо, но с подковыркой.
«Полный набор ваших любимых уязвимостей в вашем любимом браузере.»
Как на меня это костыль по сути.
HTML5 и снова костыли, костыли, костыли… Почти все видео на одном из сайтов в H264 и не буду я его ради FireFox переделывать в WebM.
А смысл?
Зачем ставить плагин WM, если есть flash с H264, который имеется во всех браузерах?
Зачем ставить плагин WM, если есть flash с H264, который имеется во всех браузерах?
Хорошо, но лучше бы они VP8 и Vorbis в Internet Explorer 9 добавили.
И чем оно лучше System Video?
Ещё уточните, что плагин есть только для 32-битной сборки. Для Win64 его (пока?) нет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Microsoft добавила поддержку H.264 в Firefox