Какие браузеры поддерживают html5 видео
Стандарт HTML5 поддерживает всевозможные странные методы. В то же самое время он возрождает (и стандартизует) некоторые старые либеральные правила HTML и вводит передовые возможности, которые работают только в новейших браузерах.
Что касается браузерной совместимости, функциональные возможности HTML5 можно разбить на три категории:
Возможности, которые уже работают . К этой категории принадлежат возможности, которые имеют высокий уровень поддержки, но официально не были частью стандарта HTML в прошлом (например, метод drag and drop). В нее так же входят возможности, которые можно реализовать для старых браузеров, приложив очень небольшие дополнительные усилия, наподобие семантических элементов.
Возможности с поэтапной деградацией . Например, если у старого браузера имеются проблемы с использованием нового элемента , этот элемент позволит вам предоставить браузеру какое-либо другое средство проигрывания например плеер, использующий подключаемый модуль Flash.
Возможности, требующие обходных решений JavaScript . Мотивацией для многих новых возможностей HTML5 послужили разработки, которые веб-программисты уже делали другим, более трудоемким, способом. Поэтому не стоит удивляться, что много из возможностей HTML5 можно дублировать с помощью хорошей библиотеки JavaScript (или, в худшем случае, написав энное количество строк кода собственного специализированного сценария JavaScript).
Создание обходного решения JavaScript может быть очень трудоемкой задачей, поэтому, если вы посчитаете, что определенная возможность является необходимой и требует обходного решения JavaScript, вы можете просто решить использовать это обходное решение для всех страниц и отложить использование методов HTML5 на будущее.
Поддерживает ли браузер вашу разметку?
Последнее слово в вопросе, в каком объеме использовать HTML5, принадлежит разработчикам браузеров. Если браузер не поддерживает какую-либо возможность, нет никакого смысла использовать ее, несмотря на все, что говорится в стандарте. В настоящее время существуют четыре или пять основных браузеров (не считая браузеров для мобильных устройств с возможностью подключения к Интернету, таких как смартфоны и планшеты iPad).
У разработчика-одиночки нет никаких шансов протестировать каждую потенциальную возможность на каждом браузере, не говоря уже о возможности оценить поддержку ее в старых версиях браузеров, которые широко используются до сих пор.
Сначала выберите вкладку Tables, а потом вкладку Compatibility tables и выберите на ней требуемую вам возможность (или группу возможностей), установив соответствующие флажки:
Можно выполнить поиск конкретной возможности, введя ее название в поле Search, расположенное по центру вверху страницы. Или же можно просмотреть целую категорию возможностей, установив соответствующий флажок в разделе Caterogy слева на странице. (В таком случае будет выведена таблица совместимости для каждой вложенной возможности.)
Например, чтобы проверить только возможности, которые считаются частью стандарта HTML5, сбросьте все флажки и установите только флажок HTML5. Чтобы проверить совместимость возможностей на основе JavaScript, которые сначала входили в HTML5, но потом были выделены в отдельную категорию, установите флажок JS API и т.д.
При желании, выберите другие опции, установив соответствующие флажки. Можно уточнить результаты поиска, удалив некоторые подробности. Например возможно, вас не интересует информация о совместимости с браузерами для мобильных устройств или с браузерами, которые находятся в стадии разработки и не были официально выпущены. Но обычно не стоит отказываться от этих подробностей, т.к. таблицы легко понимать даже с ними.
Прокрутите страницу вниз, чтобы просмотреть все результаты:
Для большого количества возможностей одновременно выводится только 20 таблиц результатов. Для просмотра следующих 20 таблиц результатов следует щелкнуть по ссылке Show next 20 внизу страницы.
В таблице для каждой возможности в заголовках столбцов указаны браузеры, в заголовках строк — их характеристики версий. Определенная версия браузера находится на пересечении соответствующего столбца и строки. Если возможность поддерживается данной версией браузера, соответствующая ячейка закрашена светло-зеленым цветом; частичная поддержка обозначается темно-зеленым, а отсутствие поддержки — розовым. Если неизвестно, поддерживается ли данная возможность, в ячейке не указывается номер версии браузера, а сама ячейка окрашена коричневым цветом.
Также приводится примерное количество браузеров, поддерживающих данную возможность, в процентах.
Статистика популярности браузеров
Последним важным пунктом проблемы поддержки возможностей браузерами является статистика популярности конкретных браузеров. Иными словами, информация о том, сколько посетителей Паутины пользуется браузером, поддерживающим возможности, которые вы намереваетесь использовать в своей разметке.
Одним из хороших источников этой информации является популярный сайт GlobalStats. На странице сайта в раскрывающемся списке Statistic выберите вариант Browser. А вариант Browser Version позволит просмотреть популярность не только конкретного браузера, но и каждой из его версий. Результаты можно сузить, выбрав конкретный регион или страну в раскрывающемся списке Country/Region:
Сайт GlobalStats собирает статистические данные ежедневно с помощью кода слежения, который установлен на миллионах веб-сайтов. Однако для вашего сайта цифры могут быть совершенно другими. Например вот статистика для этого сайта, полученная через Google Analytics за тот же период:
Как видите пользователей современных браузеров Google Chrome, Opera и Firefox гораздо больше чем в статистике от GlobalStats. При этом пользователей Internet Explorer всего 6%, что в три раза меньше чем в общемировой статистике. Эта статистика очень сильно зависит от тематики сайта. Данный сайт создан в основном для IT-специалистов, которые редко используют устаревшие браузеры. Если посмотреть статистику какой-нибудь популярной социальной сети, то количество счастливых обладателей браузеров IE
Определение возможностей с помощью Modernizr
В течение нескольких следующих лет абсолютно реальным будет то обстоятельство, что некоторые посетители вашего веб-сайта будут пользоваться браузерами, не поддерживающими HTML5. Но это не должно остановить вас от использования возможностей этого стандарта при условии, что вы согласны вложить немного усилий в разработку обходных решений или возможности поэтапной деградации. В любом случае вам, скорее всего, потребуется некоторая помощь JavaScript. Обычно это делается таким образом: после загрузки вашей страницы браузером запускается специальный сценарий, который проверяет, поддерживает ли браузер определенную возможность.
К сожалению, т.к. в своей основе HTML5 является набором связанных стандартов, одного общего теста на поддержку возможностей не существует. Вместо этого требуется выполнить несколько десятков разных тестов, чтобы проверить наличие поддержки различных возможностей, при этом иногда даже требуется проверять, поддерживается ли определенная часть возможности, что очень быстро делает задачу тестирования весьма неприятной.
При проверке поддержки некоторой функциональности браузером обычно требуется найти возможность в программном объекте или создать объект и использовать его определенным образом. Но подумайте хорошенько, прежде чем приступать к написанию кода тестирования такого типа, т.к. с этой задачей очень легко наломать дров.
Например, код для проверки поддержки возможности браузерами может не работать на некоторых браузерах по той или иной непонятной причине или быстро устареть. Вместо этого подумайте о применении компактного, постоянно обновляемого инструмента Modernizr, который проверяет поддержку браузерами широкого диапазона возможностей HTML5 и связанных возможностей. Он также предоставляет классный метод для реализации поддержки резервных решений при использовании новых возможностей CSS3.
Проверка веб-страниц с помощью Modernizr выполняется так:
Загрузите JavaScript-файл для Modernizr. Для этого в области Download Modernizr в верхней центральной части страницы нажмите кнопку Development.
Обычно, имя этого файла будет похоже на modernizr-2.0.6.js. Точное имя зависит от используемой версии. Некоторые разработчики переименовывают этот файл, убирая номер версии, например modernizr.js. Это позволяет обновить файл Modernizr в будущем, не требуя поиска и корректировки ссылок на него в веб-страницах, в которых он используется.
Код полной версии Modernizr несколько объемистый. Эта версия сценария предназначена для выполнения тестирования на стадии разработки веб-сайта. По окончании разработки, когда сайт можно публиковать для использования, можно создать облегченную версию сценария Modernizr, которая тестирует только требуемые возможности.
Для этого загрузите версию Production, нажав одноименную кнопку в области Download Modernizr. Откроется страница, предлагающая выбрать возможности, поддержку которых вы хотите проверять (установив соответствующие флажки), а потом создать свою специальную версию сценария Modernizr, нажав кнопку Generate слева внизу страницы.
Скопируйте файл сценария в папку, в которой находится веб-страница, требующая тестирования. Либо файл сценария можно поместить в подкаталог и подкорректировать должным образом путь к ней в ссылке JavaScript.
В блоке тестируемой веб-страницы вставьте ссылку на файл сценария Modernizr. В следующем листинге показан пример вставки этой ссылки:
Теперь, всякий раз при загрузке этой страницы будет исполняться сценарий Modernizr. В считанные миллисекунды сценарий тестирует поддержку пары десятков новых возможностей, а потом создает объект JavaScript, называющийся, опять же, Modernizr и содержащий результаты тестирования. Чтобы проверить поддержку браузером определенной возможности, тестируются свойства этого объекта.
Полный список тестируемых с помощью Modernizr возможностей, а также код JavaScript для тестирования каждой из этих возможностей, смотрите в документации Modernizr.
Напишите сценарий, который тестирует требуемую возможность, а потом выполняет соответствующее действие. Пример возможного сценария для проверки поддерживается ли HTML5-возможность drag and drop, и вывода результатов в окне браузера показан в следующем листинге:
Хотя в этом примере показан правильный способ проверки поддержки возможности, применяемый в нем подход к обработке неподдерживаемой возможности не идеален. Вместо того чтобы просто проинформировать (пусть даже и самым вежливым образом) посетителя вашего веб-сайта о том, что его браузер не поддерживает определенную функциональность вашего сайта, намного лучше будет реализовать какое-либо обходное решение, даже если это решение и не будет таким изящным или обладать всеми способностями заменяемой возможности HTML5. Например, если неподдерживаемая возможность — всего лишь какая-то несущественная примочка, которая бесполезна для посетителя сайта, то эту проблему можно вообще игнорировать.
Свершилось то, чего многие ожидали — крупнейшие видеосервисы (YouTube, Vimeo) предоставили в режиме бета-тестирования возможность воспроизводить ролики средствами HTML5. Казалось бы, всё прекрасно, и Flash-у пора уйти на заслуженный покой. Ан нет — оказалось всё не так гладко.
А разгадка одна — кодеки. Разработчики браузеров и поставщики контента не сошлись во мнении, какой кодек для видео использовать. На самом деле, эта проблема обсуждалась и ранее, и консенсуса по ней так и нет. В итоге из черновой спецификации HTML5 были удалены упоминания о конкретном кодеке.
Кодеки
На звание кодека для HTML5 video в данный момент претендуют два кодека — Ogg Theora и H.264.
Ogg Theora
Использовать Ogg Theora можно везде, всегда, без лицензионных или патентных отчислений.
H.264 — это лицензируемый стандарт сжатия видео. Его использование требует платы в странах, где действует патенты на него (в первую очередь, это США). Однако, на сегодняшний день, это один из самых лучших способов сжимать видео. Именно H.264 является стандартом де-факто сжатия HD-видео, к примеру. H.264 заметно эффективнее Ogg Theora по соотношению качество/битрейт.
Если кратко, H.264 — лучше, но даже его open-source реализации не могут быть использованы свободно в странах, где действуют патенты на него.
Реализации в современных браузерах
Здесь я упоминаю только те браузеры, в которых HTML5 video работает уже сейчас.
Mozilla Firefox
Реализация использует библиотеку liboggplay, а это означает, что могут использоваться только Ogg Theora для видео и Ogg Vorbis для аудио. Т.е. кодек фиксирован, и чтобы сделать поддержку чего-то ещё, нужно по сути переписать реализацию.
Google Chrome
Реализация использует статически привязанный ffmpeg. ffmpeg поддерживает кучу разных кодеков, включая и Ogg Theora, и H.264, и вообще практически всё, что сейчас реально используется.
К слову, ffmpeg в данный момент используется почти повсеместно — например, в CCCP и K-Lite Codec Pack, а также в mplayer и VLC используется именно ffmpeg.
Казалось бы, всё замечательно. Но! ffmpeg, хоть и open source, не может быть свободным в США. Для распространения программы, использующей ffmpeg, нужно платить отчисления. Google себе это может позволить, и имеет право выпускать билды со встроенным ffmpeg. Но совсем не такая ситуация с дистрибутивами Linux. Те из них, что выпускаются в США, не смогут включить в свои репозитории Chrome с поддержкой ffmpeg, так как это потребует платы отчислений. В первую очередь это касается такого небезызвестного дистрибутива, как Fedora.
Safari
Использует фреймворк QuickTime, что позволяет воспроизводить что угодно, если установлен соответствующий QuickTime-кодек.
Наверное, из современных реализаций эта наиболее правильная, т.к. имеет модульную архитектуру изначально. Но это всё сильно завязано на Mac OS, поэтому к остальным системам и браузерам неприменимо.
Суровая реальность
Теперь поговорим о поставщиках контента. Свобода, равенство, братство — это всё хорошо в теории, но на практике вопрос решается небольшими зеленоватыми бумажками с портретами американских президентов. Google-у как-то проще заплатить за лицензию на более эффективный кодек, чем платить больше за трафик, и место на серверах. Мало того, учитывая то, что у них и так всё видео хранится в H.264, было бы особенно глупо (с точки зрения бизнеса, естественно), перекодировать это всё в Ogg Theora. Так что решение использовать H.264 — это абсолютная, экономически оправданная, жизненная необходимость. YouTube не станет использовать Ogg Theora. Не выгодно. Точка.
А мало того, использование H.264 выгоднее и нам, конечным пользователям. Мы же не платим лицензионные отчисления, а, тем не менее, получаем лучшее качество видео при меньшем количестве загруженных данных (привет жителям не-столиц с хилыми каналами в интернеты).
Всё плохо?
Сейчас — да. Но! Есть выход. Для декодирования видео в браузере нужно использовать модульный подход, не привязываясь к определённому кодеку. Мало того, в каждой операционной системе уже и так есть модульная инфраструктура кодеков. В Windows — это DirectShow, в Mac OS X — это QuickTime, в Linux — это gstreamer. А gstreamer ещё и кроссплатформенный, между прочим, и уже используется в кроссплатформенных программах, к примеру, Songbird для воспроизведения музыки использует именно gstreamer на всех платформах.
Использование gstreamer решит все проблемы с кодеками в браузерах один раз и навсегда. В частности, не будет никаких проблем с патентами, так как браузер будет распространятся без защищённых патентами кодеков, но на системе пользователя он сможет найти установленный плагин для этого кодека, и использовать его.
А мало того, в gstreamer предусмотрена возможность использовать кодеки, установленные в родном для данной системы фреймворке (для Windows — DirectShow, для Mac OS — QuickTime).
Светлое будущее, наступит ли оно?
Mozilla Firefox
Собственно, вот. Но, судя по комментариям там, сейчас такая интеграция планируется только для Fennec. Честно говоря, я искренее недоумеваю по этому поводу. Поддержка H.264 для Firefox нужна, и быстро, иначе есть большой риск остаться за бортом.
Google Chrome
Беда. Я пытался вникнуть в причину отказа, но она мне показалось не слишком веской. В принципе, тут нечего добавить. Можно почитать обсуждение, оно довольно жаркое. Ещё можно проголосовать за этот баг (отметить звёздочкой). Мало ли…
Opera
Внезапно, маленькая, но очень упорная, норвежская компания показывает себя с очень хорошей стороны. Читаем, радуемся.
Другие браузеры
Неповоротливые гиганты легко могут оказаться позади маленьких, почти не используемых в широких массах браузеров, таких как Epiphany, Midori, Aurora. Все они используют WebKit. Epiphany и Midori используют GtkWebKit, в нём планируется (или уже сделана) поддержка HTML5 video через gstreamer. Aurora использует QtWebKit, в нём для HTML5 планируется (или уже частично сделано) использование Phonon, который, с свою очередь, может использовать разные бэкэнды, в том числе и gstreamer.
Однако, на текущий момент, ни в одном из них работающей поддержки HTML5 нет. Остаётся верить в их скорое светлое будущее, ведь оно вполне реально.
Нередко клиенты спрашивают, умеет ли наш сервер «mp4-стриминг в HTML5». В 99% случаев спрашивающий не понимает о чём говорит. В этом сложно винить клиентов: из-за путаницы с терминами, технической сложности и большого разнообразия вариантов стриминга запутаться очень легко.
В этой статье мы расскажем, какой бывает HTML5-стриминг, какие варианты хорошие, и почему, чёрт побери, нельзя говорить «mp4-стриминг».
▍Термины
HTML5-видео — это когда вы вставляете в веб-страницу тег и указываете ему какой-то src. HTML5-стриминг — это то же HTML5-видео, но когда в src не готовый файл, а постоянно обновляющийся видеопоток. Ролик на Ютубе — это HTML5-видео, трансляция в Твитче — HTML5-стриминг.
Тегу неважно, как видеопоток формируется и передаётся, и сможет ли браузер его проиграть. Главное, чтобы в src была ссылка на какой-то видеопоток. Говоря техническим языком, спецификация ничего не говорит о том, какие протоколы, транспорты и кодеки поддерживаются в HTML5-видео.
Протокол — это то, как два участника видеосвязи (почти всегда это клиент и сервер) обмениваются данными с целью получения данных. Клиентом называют того, кто приходит к серверу и инициирует сессию связи. Видеопоток может течь от сервера к клиенту (тогда это обычное проигрывание) или от клиента к серверу (тогда это публикация). Даже когда гигантский шкаф, жрущий электричество как многоквартирный дом приходит к маленькой IP-камере, то она будет сервером, а этот шкаф клиентом.
Протокол обычно подразумевает хотя бы команду Play (начать проигрывание), но иногда есть и расширенные варианты: пауза, продолжение, публикация, перемотка и т. п.
Транспорт, или транспортный контейнер, или контейнер — это то, как сжатое видео упаковывается в байты для передачи от одного участника к другому (по какому-то протоколу).
Примеры контейнеров: MPEG-TS, RTMP, RTP.
Обратите внимание, что RTMP оказался и в протоколах, и в транспортах. Это потому, что в описании RTMP есть спецификация и того, что должны слать друг другу стороны, чтобы видео потекло (т. е. протокол), и того, как упаковывать видео (т. е. транспорт). Так бывает не всегда. Например в протоколе RTSP видео упаковывается в транспорт RTP. |
Кодек — многозначный термин. Здесь он означает способ сжать сырое видео. Разница между кодеком и транспортом в том, что кодек — это про подготовку видео, а транспорт — про передачу видео по протоколу. Видео, сжатое одним кодеком, можно пересылать по разными протоколам и разными транспортами. Большинство видеостриминговых серверов не залезают глубже кодированного видео и оперируют только протоколами и транспортами.
Примеры кодеков: h264, aac, mp3.
Из-за того, что термин многозначный, возникает путаница с названиями. Например, H.264 — это стандарт того, как упаковать поток огромных сырых видеокадров в очень мало байтов, libx264 — это библиотека для сжатия по этому стандарту, а ещё есть одноимённый софт под Винду, который умеет декодировать h264 и проигрывать его на экране. |
Итак, в спецификации HTML5 не описаны протоколы, транспорты и кодеки. Поэтому авторы браузеров сами выбирают, что поддерживать, а под «HTML5-стримингом» подразумевают разные вещи.
При этом есть комбинации, которые поддерживаются значительной частью браузеров. Рассмотрим самые перспективные.
Разработали HLS в Эппле, поэтому изначально он работал только в Сафари на iOS и MacOS. Даже Сафари на Windows не умел играть HLS (когда еще была версия под Win).
Тем не менее, сейчас HLS умеют проигрывать все телевизионные приставки и даже почти все устройства на Андроиде.
Но не всё гладко. Производители сторонних плееров плюнули на стандарт Эппла в части донесения разных аудиодорожек и добавили проигрывание всего что есть в обычном MPEG-TS: mpeg2 video, mpeg2 audio и т. п. Из-за этого приходится отдавать разные форматы плейлистов для разных плееров.
▍MPEG-DASH
MPEG-DASH — обычно это h264/h265-видео и aac-аудио, упакованное в транспорт mp4, или vp8/vp9, упакованное в WebM, хотя стандарт и не привязан к конкретным кодекам, протоколам и транспортам. Как и в HLS, поток может разбиваться на сегменты, но это необязательно. Вместо плейлистов — MPD-манифест в XML.
MPEG-DASH во многом похож на HLS. Возможно, он даже популярнее, ведь такие гиганты как Ютуб и Нетфликс уже несколько лет используют его как основной способ раздачи контента.
MPEG-DASH хорош тем, что в большинстве браузеров работает нативно, через MSE (о том, что это такое, — чуть ниже). Для него даже нет реализации на Флеше — это честный, бескомпромиссный HTML5.
Определенно, MPEG-DASH — самый настоящий HTML5-стриминг, за ним будущее.
Когда стало ясно, что Флеш всё-таки умрёт (после сотни ложных похорон), ребром встал вопрос о том, что придёт ему на смену. Хорошо было бы получить в браузерах возможность проигрывать видео по качеству и удобству близко к тому, что умеет Флеш (а он это делает всё-таки хорошо).
Во Флеше давно появился очень удобный механизм для универсального проигрывания разных вариантов — appendBytes. Суть в том, что пользовательский код сам как хочет скачивает кадры сжатого видео, упаковывает в оговоренный контейнер (с Флешем это flv) и засовывает в видеопроигрыватель. Т. е. протокол и транспорт реализуются в пользовательском коде, запускаемом в браузере.
MSE (Media Sources Extensions) — это расширение спецификации HTML5, которое позволяет делать то же, что делает appendBytes во Флеше. К сожалению, MSE намного сложнее как в понимании, так и в реализации.
MPEG-DASH, созданный на его базе, ещё хитрее, поэтому работать с ними то ещё удовольствие: тонны XML, парсинг бинарных контейнеров в Яваскрипте, непродуманные на этапе дизайна вопросы нарезки на сегменты — всё как мы любим, всё что нужно для единой безглючной реализации во всех браузерах.
Интересно, что MSE работает не только с MPEG-DASH, но и с HLS. Существует реализация hls.js, которая скачивает HLS-плейлисты, скачивает MPEG-TS-сегменты, перепаковывает их в нужный для MSE формат и играет через MSE. Эппл даже сделала шаг в сторону совместимости с MPEG-DASH — использование mp4-контейнеров в HLS.
К концу 2017 года Флеш скорее всего умрёт окончательно, и уже сегодня можно смело начинать проект с MPEG-DASH.
▍WebRTC
Во Флеше была сделана годная попытка в одной технологии реализовать и риалтайм-общение, и массовый броадкастинг. К сожалению, в HTML5 так не вышло. Для просмотра трансляций у нас есть MSE, а для видеозвонков — WebRTC.
WebRTC — это SIP в браузере: способ организовать аудио- и видеоканал и канал данных между двумя браузерами при посредничестве сервера.
Технология не предназначена для стриминга, но в принципе может и его, так что было бы неправильно забыть про него. WebRTC тоже считается HTML5, потому что вроде как ничего кроме Яваскрипта в браузере не требует. Зато требует наличия последних версий обоих популярных браузеров, а с Эджем пока вообще не совместимо.
Путаницу в понимании WebRTC вносит его использование в торрент-доставке телевидения. Суть в том, что браузеры через WebRTC организуют сеть каналов данных, а дальше по этой сети раздаются HLS- или MSE-сегменты видео, а проигрывание происходит через Флеш или MSE. Т. е. WebRTC — для доставки, MSE — для проигрывания. Важно не путать это с использованием WebRTC для проигрывания видео.
▍Так что там с mp4-стримингом?
Вокруг h264 сложилось немало шумихи по поводу его «закрытости» и «несвободности». Так что есть «открытая» альтернатива, которую форсит Гугл — видеокодеки vp8 и vp9, упакованные в транспорт WebM. WebM — это подмножество транспорта mkv (a. k. a. Матрёшка), который очень похож на mp4 по сути, но отличается от него своей «бинарностью».
Именно отсюда растут ноги у такого явления как «mp4-стриминг», который устроен как WebM. Дело в том что в обычном mp4 в самом начале указывается размер всего контейнера. Поэтому, если мы хотим отдать по обычному mp4 прямой эфир, у нас ничего не получится. А чтобы всё-таки получилось и можно было создавать mp4 без фиксированного конца, придуман следующий ход: сначала пишется mp4 без кадров, а потом в конце подписываются блоками по несколько секунд фрагменты с кадрами. Это называется mp4 fragmented, или mp4 streaming.
По сути это никакой не стриминг, а костыль, позволяющий создать его видимость. Mp4 — отличный формат для скачивания видео, но негодный для стриминга, так что про него можно просто забыть и никогда не использовать термин «mp4-стриминг».
Давно не видел статей по поводу сравнение браузеров, в связи с полетевшим диском, подумал, а может перейти с фф на что-то другое (все привыкли искать лучшее).
Стало интересно, кто же сейчас лидирует на рынке. Самый простой способ взять и сравнить, что же еще сделать.
Сравнение не всегда может быть адекватным в связи и использованием различных сервисов и тестов. Для теста использовались следующие сервисы:
Html5
FF 18.0.2
Maze Solver — CSS3 Layout Performance Test
CSS3 Selectors Test
From the 41 selectors 41 have passed, 0 are buggy and 0 are unsupported (Passed 574 out of 574 tests)
Acid3
html5test
Test2
Peacekeeper
Итоговая таблица по результатам FF
Css3 | |
---|---|
ie.microsoft.com | 136 seconds |
css3test.com | 56% (500/ 937) |
tools.css3.info | 41/41 574/574 |
acid3 | 100/100 |
Html5 | |
html5test | 393/500 (+10) |
wapsbttest2 | 129/160 |
peacekeeper1 | 798 (5/7) |
peacekeeper2 | 1514 (5/7) |
Opera 12.14
Чтобы не засорять пост массой картинок, выложу только итоговую таблицу.
Css3 | |
---|---|
ie.microsoft.com | 16 seconds |
css3test.com | 58% (451/937) |
tools.css3.info | 41/41 574/574 |
acid3 | 100/100 |
Html5 | |
html5test | 404/500 (+9) |
wapsbttest2 | 146/160 |
peacekeeper1 | 2441 (2/7) |
peacekeeper2 | 2522 (4/7) |
Chrome 24.0.1312.57
Css3 | |
---|---|
ie.microsoft.com | 6.9 seconds |
css3test.com | 63% (562/937) |
tools.css3.info | 41/41 574/574 |
acid3 | 100/100 |
Html5 | |
html5test | 448/500 (+13) |
wapsbttest2 | 148/160 |
peacekeeper1 | 1734 (6/7) |
peacekeeper2 | 3127 (6/7) |
IE 9.0.8112.16421 64-bit
Css3 | |
---|---|
ie.microsoft.com | 22 seconds |
css3test.com | 33% (274/937) |
tools.css3.info | 41/41 574/574 |
acid3 | 100/100 |
Html5 | |
html5test | 138/500 (+5) |
wapsbttest2 | 91/160 |
peacekeeper1 | 998 (3/7) |
peacekeeper2 | 1001 (3/7) |
IE 10.0.9200.16438 64-bit
Css3 | |
---|---|
ie.microsoft.com | 24 seconds |
css3test.com | 54% (444/937) |
tools.css3.info | 41/41 574/574 |
acid3 | 100/100 |
Html5 | |
html5test | 320/500 (+6) |
wapsbttest2 | 127/160 |
peacekeeper1 | 1882 (3/7) |
peacekeeper2 | 1882 (3/7) |
Safary Версия 6.0.2 (8536.26.17), max osx 10.8
Спасибо btd за результаты Safari
Css3 | |
---|---|
ie.microsoft.com | 6.9 seconds |
css3test.com | 55% (500/937) |
tools.css3.info | 41/41 574/574 |
acid3 | 100/100 |
Html5 | |
html5test | 378/500 (+8) |
wapsbttest2 | 139/160 |
peacekeeper1 | 3117 (3/6) |
peacekeeper2 | 3117 (3/6) |
Выводы и итого по всем
Удивил тест на peacekeepers, ребята постарались. Интересный факт, что 1-й запуск тест сильно отличается от 2-ого, может быть кэш так влияет, но вопрос очень спорный.
Так же очень странно было видеть алгоритм поиска выхода из лабиринта у FF, Opera, Chrome один и тот же алгоритм выхода был, но IE не ищет легких путей и пошел не так как все (хотя запускал тест раза 3-4 один и тот же лабиринт). Итоговая таблица лучший пожалуй хром, а дальше черт ногу сломит, в общем, смотрите сами:
Browser | FF | Opera | Chrome | IE | IE10 | Safari |
Css3 | ||||||
---|---|---|---|---|---|---|
ie.microsoft.com | 136 seconds | 16 seconds | 6.9 seconds | 22 seconds | 24 seconds | 6.9 seconds |
css3test.com | 56% (500/937) | 58% (451/937) | 63% (562/937) | 33% (274/937) | 54% (444/937) | 55% (500/937) |
tools.css3.info | 41/41 574/574 | 41/41 574/574 | 41/41 574/574 | 41/41 574/574 | 41/41 574/574 | 41/41 574/574 |
acid3 | 100/100 | 100/100 | 100/100 | 100/100 | 100/100 | 100/100 |
Html5 | ||||||
html5test | 393/500 (+10) | 404/500 (+9) | 448/500 (+13) | 138/500 (+5) | 320/500 (+6) | 378/500 (+8) |
wapsbttest2 | 129/160 | 146/160 | 148/160 | 91/160 | 127/160 | 139/160 |
peacekeeper1 | 798 (3/7) | 2441 (2/7) | 1734 (6/7) | 998 (3/7) | 1820 (3/7) | 3117 (3/7) |
peacekeeper | 1514 (5/7) | 2522 (4/7) | 3127 (6/7) | 1001 (3/7) | 1882 (3/7) | 3117 (3/7) |
P.S. Никто не безупречен, орфография и ошибки прошу милости в личку.
P.P.S. Если у кого есть желание протестите Safari.
P.P.P.S. Добавил IE10 удивил отчасти, но лишь отчасти…
Спасибо btd за результаты Safari
В рассмотренных ранее примерах использовались два популярных стандарта: MP3 для аудио и H.264 для видео. Этого достаточно для Chrome и Safari, но не для других браузеров.
Небольшие разработчики, такие как Mozilla, создатели браузера Firefox и разработчики Opera, не желают платить непомерно высокую для них цену за лицензию на использование таких популярных стандартов, как MP3 для аудио или H.264 для видео (хотя поддержка этих стандартов включена в версии Firefox 24 и выше, после солидного спонсирования от Google ;). И их трудно винить за это, ведь они предоставляют свои продукты бесплатно.
У компаний покрупнее (таких как Microsoft, Google или Apple) имеются свои оправдания почему надо избегать нелицензированных стандартов. Они жалуются, что качество работы этих стандартов будет ниже (в настоящее время они не поддерживают аппаратное ускорение) и что они не так широко используются, как запатентованные стандарты, такие как, например, H.264, который используется в камкордерах, проигрывателях Blu-Ray и во многих других разных устройствах.
Но самая большая проблема может состоять в том, что никто по-настоящему не уверен, что эти нелицензированные стандарты не связаны с чьей-либо интеллектуальной собственностью. Если такие связи имеются, используя эти стандарты, крупные компании наподобие Microsoft или Apple, делают себя уязвимыми к дорогостоящим искам за нарушение патентных прав, которые могут тянуться годами.
Знакомимся с форматами
Официальный стандарт HTML5 не требует, чтобы браузеры поддерживали какой-либо конкретный аудио- или видеоформат. (Ранние версии стандарта содержали такую рекомендацию, но в результате интенсивного лоббирования она была отменена.) Вследствие этого разработчики браузеров могут выбирать форматы, какие они хотят поддерживать, несмотря на то обстоятельство, что разные форматы органически несовместимы друг с другом. Список и краткое описание основных форматов, используемых в настоящее время, приведен в таблице:
Формат | Описание | Расширение файла | MIME тип |
---|---|---|---|
MP3 | Самый популярный аудиоформат в мире. Но стоимость лицензии делает его непрактичным для небольших разработчиков, наподобие Opera | mp3 | audio/mp3 |
Ogg Vorbis | Открытый, бесплатный стандарт, предоставляющий высококачественное сжатое аудио, сравнимое с MP3 | ogg | audio/ogg |
WAV | Первоначальный формат для сырого цифрового аудио. Не использует сжатие, поэтому файлы невероятно большого объема и непригодны для большинства интернет-приложений | wav | audio/wav |
H.264 | Промышленный стандарт для кодирования видео, особенно при работе с видео высокой четкости. Применяется в бытовых устройствах (таких как проигрыватели и камкордеры Blu-Ray), на видеообменных сайтах (таких как YouTube и Vimeo) и в браузерных модулях расширения (таких как Flash и Silverlight) | mp4 | video/mp4 |
Ogg Theora | Открытый, бесплатный стандарт для видео, созданный разработчиками аудиостандарта Vorbis. Качество и производительность ниже стандарта H.264, но достаточно высокие, чтобы удовлетворить потребности большинства пользователей | ogv | video/ogg |
WebM | Новейший бесплатный видеоформат, созданный Google на основе приобретенного ими VP8. Критики доказывают, что его качество еще не на уровне видео H.264 и он может содержать скрытые связи с другими патентами, что может вызвать лавину судебных исков в будущем. Тем не менее, WebM является наилучшим выбором для будущего открытого видео | webm | video/webm |
В этой таблице также указаны рекомендуемые расширения файлов для мультимедиа. Чтобы осознать, почему это важно, нужно понимать, что для создания видеофайла в действительности применяются три разных стандарта. Первым, наиболее очевидным, стандартом является видеокодек, применяемый для сжатия видео в поток данных. В качестве примера можно назвать такие кодеки, как H.264, Theora и WebM.
Вторым является аудиокодек, который применяется для сжатия одной или нескольких аудиодорожек. Например, для видео в формате H.264 обычно используется звук в формате MP3, а для видео Theora - звук Vorbis. Наконец, формат контейнера применяется для упаковки видео и аудио вместе с описательной информацией и, необязательно, другими безделушками типа изображений и субтитров. Часто расширение файла обозначает формат контейнера, т.е. расширение mp4 означает контейнер типа MPEG-4, расширение ogv — контейнер Ogg и т.п.
Но не все так просто, т.к. формат контейнера поддерживает несколько разных аудио- и видеостандартов. Например, популярный контейнер Matroska (mkv) может содержать видео в формате H.264 или Theora. Чтобы не усложнять этот вопрос излишними подробностями, в приведенной таблице каждый видеоформат соотнесен с наиболее употребляемым для его упаковки контейнером, для которого также обеспечивается наиболее высокий уровень поддержки для Интернета.
В приведенной таблице также указан требуемый тип MIME, который нужно установить в настройках вашего веб-сервера. Если не указать правильный тип MIME, браузеры могут заупрямиться с воспроизведением вполне качественного мультимедийного файла.
Поддержка браузерами форматов мультимедиа
Все аудио- и видеоформаты в мире будут вам бесполезны, если вы не знаете, как они поддерживаются разными браузерами. Разобраться в этом вопросе вам поможет следующие таблицы, в которых показаны поддержки основными браузерами аудио- и видеоформатов:
IE | Firefox | Chrome | Safari | Opera | Safari iOS | Android | |
MP3 | 9 | 24 | 5 | 3.1 | - | 3 | - |
Ogg Vorbis | - | 3.6 | 5 | - | 10.5 | - | - |
WAV | - | 3.6 | 8 | 3.1 | 10.5 | - | - |
IE | Firefox | Chrome | Safari | Opera | Safari iOS | Android | |
H.264 | 9 | 24 | 5 | 3.1 | - | 4 | 2.3 |
Ogg Theora | - | 3.5 | 5 | - | 10.5 | - | - |
WebM | 9 (при установке кодеков) | 4 | 6 | - | 10.6 | - | 2.3 |
Поддержка этих форматов мобильными браузерами представляет особый вид проблем. Прежде всего, это нерегулярность работы. Некоторые функции, такие как автоматическое воспроизведение и повтор, могут не поддерживаться, а некоторые устройства могут воспроизводить видео только в специализированном проигрывателе, а не прямо в окне на веб-странице. А еще видео для мобильных устройств обычно нужно кодировать с кадром меньшего размера и худшего качества.
Если вы хотите, чтобы видео проигрывалось на мобильных устройствах, примите за правило кодировать его в формате H.264 Baseline Profile (а не в формате High Profile). Для телефонов iPhone и под управлением операционной системы Android следует использовать размер 640x480, а для BlackBerry — 480x360. Многие программы кодирования имеют предварительные настройки, с помощью которых можно создать видео, оптимизированное для мобильных устройств.
Множество форматов: как понравиться всем браузерам
Что делать бедному веб-разработчику со всеми этими форматами? Горькая правда состоит в том, что ни один аудио- или видеоформат не будет работать на всех браузерах. Если вы хотите поддерживать все браузеры, а поддерживать их все вы должны, вам нужно запастись мультимедийными файлами в нескольких форматах. Кроме этого, вам, скорее всего, нужно будет организовать резервное решение Flash для посетителей, которые пользуются браузерами, не признающими HTML5, такими как, например, IE8.
К счастью, элементы и поддерживают достаточно хорошую систему предоставления резервных решений, которая была хорошо отлажена новаторами веб-технологий. Но, к сожалению, война форматов означает, что содержимое нужно будет кодировать, по крайней мере, дважды, что является затратным процессом по времени, процессорным ресурсам и дисковому пространству.
Но прежде чем приступать к работе, нужно определиться со стратегией поддержки браузеров, которые не признают HTML5. По большому счету, веб-разработчики имеют на выбор два хороших пути:
Использовать Flash в качестве основного решения, а HTML5-решение в качестве резервного
Таким образом, все посетители вашего сайта смогут использовать Flash, за исключением тех, на чьих браузерах этот модуль не установлен. Эта стратегия имеет смысл, если вы уже предоставляете на своем сайте видеосодержимое посредством Flash, но хотите еще привлечь пользователей iPad и iPhone.
Использовать HTML5 в качестве основного решения, а Flash-решение — в качестве резервного
Таким образом, все посетители получают HTML5-видео и/или аудио, за исключением тех, кто использует старые браузеры, которые получают Flash-содержимое. Если вы пойдете этим путем, можно также поддерживать меньшее число форматов HTML5. В таком случае посетители, чьи браузеры хотя и поддерживают HTML5-мультимедиа, но не поддерживают предоставляемые вами форматы, также получат Flash-содержимое. Так как будущее за этим подходом, то он является предпочтительным при условии, что текущие ограничения HTML5 видео и аудио — вам не помеха.
В следующих разделах мы будем воплощать второй подход в жизнь. Таким образом, мы обеспечим для браузеров чисто HTML5-решение во всех случаях, когда это возможно.
ЭлементПервым шагом в обеспечении поддержки нескольких форматов будет удаление атрибута src из элемента или и замена его вложенным списком элементов . Например:
В данном случае элемент содержит два элемента , каждый из которых указывает на отдельный аудиофайл. Из указанных файлов браузер выбирает первый, формат которого он поддерживает. В частности, Opera возьмет файл mysong.ogg, a Firefox, Safari и Chrome - файл mysong.mp3.
Теоретически, браузер может определить, поддерживает он или нет конкретный файл, загрузив и исследовав небольшую его часть. Но лучшим подходом будет использовать атрибут type, чтобы предоставить правильный MIME-тип. Таким образом, браузер попытается загрузить только тот файл, который он, как считает, может воспроизвести.
Этот же метод применяется и для элемента . В следующем листинге показан пример указания видеосодержимого в двух разных форматах — H.264 и Theora:
В этом примере следует отметить одну новую особенность. При использовании разных видеоформатов файл в формате H.264 всегда должен быть в списке первым. В противном случае он не будет проигрываться на старых устройствах iPad под управлением iOS 3x. (Эта проблема была решена в операционной системе iOS 4, но размещение файла H.264 вверху списка ничем ничему не вредит.)
Так сколько же видеоформатов следует использовать? Чтобы прикрыть все тылы необходимо использовать форматы H.264 и Theora для основного решения HTML5 и Flash для резервного. Для лучшего качества видео формат Theora можно заменить форматом WebM. Или же можно совсем разойтись и включить все версии своего видео — H.264, Theora и WebM в указанном порядке. Версия WebM идет перед версией Theora для того, чтобы браузеры, которые поддерживают эти формата, выбрали видео лучшего качества.
Ну а если гулять по полной программе, то можно создать одну веб-страницу с видео как для настольных компьютеров, так и для мобильных устройств. В таком случае нужно не только предоставить файлы в формате H.264 и Theora, но также создать версии видеофайлов меньшего объема, более подходящие для менее мощных мобильных устройств и интернет-подключений с меньшей пропускной способностью.
Резервное решение Flash
Испокон веков все браузеры обрабатывают нераспознаваемые теги одинаково - игнорируют их. Например, если Internet Explorer 8 встречается открывающий тег элемента , он с ветерком проносится мимо него, не затрудняясь ознакомиться с атрибутом src и другими параметрами этого элемента. Но при всем этом, браузеры не игнорируют содержимое внутри неизвестного им элемента, что является важной особенностью. Это означает, что в случае следующей разметки:
браузеры, которые не понимают HTML5, ведут себя, как будто бы они видели вот эту разметку:
Эта особенность и лежит в основе бесшовного предоставления резервного решения для старых браузеров.
Правильный подход — это включить в качестве резервного содержимого другое работоспособное видеоокно, иными словами, любое содержимое, которое бы пользовалось на обычной видеостранице, т.е. странице без поддержки HTML5. Можно использовать видеопроигрыватель Flash (или аудиопроигрыватель Flash для аудио). К счастью, в Интернете существует масса видеопроигрывателей Flash, многие из которых бесплатные, по крайней мере, для некоммерческого использования. И большинство из них поддерживает формат H.264, который вы уже, наверное, используете для HTML5-видео.
В следующем листинге приведен пример использования в качестве резервной решения в элементе проигрывателя Flowplayer:
Если же требуется, наоборот, реализовать основное решение в виде Flash, а резервное — в виде HTML, нужно просто переставить строки из предыдущего примера. Начинаем с элемента :
Обычно этот подход следует применять только в том случае, если нужно расширить существующий веб-сайт на основе Flash для поддержки устройств Apple, таких как iPad. Кстати, существует по крайней мере один проигрыватель на JavaScript со встроенной возможностью резервного решения HTML5. Называется он JW Player.
Читайте также: