HTML5 INSIGHT


* Это третья статья из серии погружения в HTML5 — их можно рассматривать как заметки к более объемному труду, который также постепенно готовится, но вместе с тем, они могут служить и просто кратким в введением в тематику HTML5*

Потребность воспроизводить аудио и видео информацию в браузере без использования плагинов и расширений сегодня кажется все более и более естественной. (Ок, это фраза из ближайшего будущего.)

На практике, большинство пользователей не отдает себе отчета в том, что большинство аудио и видео информации в интернете сегодня воспроизводится через Flash или Silverlight. Если оглянуться назад в историю, мы еще можем вспомнить воспроизведение видео через Media Player в браузере (мы к этой истории еще вернемся).

Мастодонты веб-разработки, наверняка, должны помнить про элемент bgsound (Пожалуйста, никогда… Слышите? Никогда его больше не используйте.)

И все-таки…

Зачем в браузере нужна нативная поддержка аудио и видео

Хотя я уже касался этого вопроса в первой статье (см. раздел “Почему HTML5 — это мега-мега-круто”) и, в основном, остается только повторить доводы из нее, я начну с другого.

Если посмотреть на эволюционный контекст развития HTML5, то на заднем фоне сильно начнет мелькать не только заметно обострившаяся конкуренция браузеров, но и целый форпост нового поколения мобильных устройств: от непосредственно телефонов и сматрфонов до энергоэффективных нетбуков и планшетных устройств на всяких армах (ARM) и атомах (Intel Atom).

И вот эта, вторая, буря доставляет ничуть не меньше потребности в изменениях, чем первая. В этом контексте абсолютно прав Стив Джобс, отсылающий возникновение новых веб-стандартов именно к мобильной эре.

Если говорить простым словами, то ситуация следующая. Мобильные устройства должны быть эффективными и кушать мало энергии в ходе своей работы, чтобы долго-долго радовать своих владельцев. Простая мысль сделать более энергоёмкой батарею, в тех же размерах или даже более компактную, сталкивается с непреодолимыми на сегодня физико-химическими барьерами, которые еще только предстоит решить (и на решение которых по всему миру тратятся миллиарды долларов ежегодно).

С другой стороны, на мобильных устройствах хочется все большего и большего – и кино посмотреть, и музыку в фоне послушать, и в гонки поиграть, и документы в Word/Excel поправить.

Решение этих задач, с одной стороны, приводит к потребности делать менее прожорливые и более эффективные процессоры, позволяющие более эффективно проводить вычисления (кстати, именно поэтому в современных мобильных устройствах есть не только видео-чипы, но и появляются многоядерные процессоры). А с другой, к повышених энергоэффективности программного обеспечения – и вот тут ребром встает вопрос эффективного воспроизведения аудио и видео.

Суть в том, что эффективно воспроизводить аудио и видео можно только нативно, то есть при максимальной интеграции браузера с ОС, ну и далее с железом. Любое промежуточное решение будет заведомо менее удачным.

На фоне эффективности прекрасные возможности Flash и Silverlight по работе с мультимедиа (к чему мы еще вернемся) оказываются не у дел в простых сценариях, когда нужно просто проиграть аудио- или видеопоток.

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

(И, как известно, не на всех мобильных устройства поддерживаются Flash или Silverlight в браузере.)

И, возвращаясь к тому, о чем я уже писал: реализация поддержки аудио и видео через стандарт, а не плагин, позволяет легко интегрировать мультимедийные компоненты в общую экосистему клиентских технологий, основанных на веб-стандартах (html, css, javascript и др.). Тут вам и доступ и управление через DOM и JavaScript, и наложение стилей через CSS, и прозрачная по реализации вставка “куда хочу” без перекрытия слоев.

Теперь давайте ближе к делу!

Как это выглядит на практике

Как ни странно, работа с аудио и видео выглядит не сильно отлично от того, как выглядит работа с обычными картинками.

Например, чтобы вставить аудио-файл, достаточно написать что-то в таком виде :

<audio id="myAudio" controls loop>
   <source src="elvis.mp3" />
   <source src="elvis.ogg" />
</audio>

Обратите внимание на две вещи:

  1. Наличие атрибутов без значений – это так называемые бинарные атрибуты, наличие которых эквивалентно значению true или тому, которое определяется стандартом. То есть controls равносильно тому, что вы бы написали controls =
    “controls”
    .
  2. В данном случае указано два источника для воспоизведения, чтобы браузер мог выбрать, какой из них он может проиграть в зависимости от того, какие кодеки он поддерживает (к этому вопросу мы вернемся в следующем разделе). Если источник только один, то достаточно указать ссылку на файл в родительском теге audio через атрибут src.

Вставка видео производится абсолютно аналогично, но с некоторыми дополнительными возможностями (размер и постер):

<video id="myVideo" width="640" height="480"   
       poster="images/elvis.jpg" />
<script>
function loadVideo() {
 var player = document.getElementById("myVideo");
 player.src = "media/elvis.mp4";
 player.setAttribute("autoload", "autoload");
 
 player.play();
}
</script>

Постер – это картинка, которая показывается до начала воспроизведения. В этом примере мы инициализируем проигрывание видео через код на JavaScript, начиная с установки ссылки на файл и заканчивая непосредственно запуском на проигрывание.

Когда вы вставите аудио или видео на страницу, браузер предложит вам готовые средства для управления воспроизведением:

Важный нюанс, который в отдельных сценариях может иметь значение – эти элементы воспроизведения видео или аудио – разные в разных браузерах и не подлежат стилизации через CSS или какие-либо другие механизмы.

В большинстве случаев это не критично, но если вы хотите, чтобы контролы выглядели одинаково или выглядели совсем по-другому, все в ваших силах. Через JavaScript можно управлять воспроизведением, громкостью, узнавать текущую отсечку во времени проигрывания и длительность всего произведения, а также ряд других параметров.

Используя все это, можно скрыть дефолтные элементы управления и сделать свои собственные, повесив на них соответствующие события. Мы рассмотрим такой пример в одной из следующих статей.

Что там с кодеками?

Кодеки – это один из самых острых вопросов применительных к аудио и видео в HTML5. Если коротко, но все не просто и простой жизни в ближайшем будущем не предвидится.

Стандарт HTML5 не говорит, какие кодеки должны поддерживаться браузером, оставляя это на усмотрение разработчиков последнего. Поддержка того или иного кодека – вопрос сложный, причем не только в техническом отношении, но и в финансово-юридическом.

Если в первом случае это вопрос не просто того, чтобы что-то добавить, но и того, чтобы сделать это эффективно, причем, в оптимальном случае, с аппаратной поддержкой, то во втором – это большой вопрос лицензирования, лицензионных отчислений и патентной защиты тех или иных технологий.

Для дополенительных деталей рекомендую вот эти статьи в блоге Internet Explorer, довольно доступно и подробно освещающие суть проблемы:

На практике оказывается, что единственный кодек с широкой индустриальной поддержкой, включая аппаратное кодирование и декодирования, для видео – это .h264 (и mp3 для аудио), лицензируемый MPEG LA.

Бесплатная альтернатива, продвигаемая Google – VP8 (WebM), к сожалению, на сегодня не имеет ни широкой аппаратной поддержки, ни гарантий патентной защиты со стороны Google.

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

Аудио-кодеки

Видео-кодеки

Для Chrome и Firefox существуют специальные плагины, подменяющие воспроизведение HTML5 видео в неподдерживаемом .h264 на проигрывание через Windows Media Player. Да, Chrome все еще поддерживает .h264, хотя Google и обещал отключить поддержку уже более полугода назад.

IE9 воспроизводит нативно видео в .h264 и в WebM, если в системе установлен соответствующий кодек.

(К слову, популярные мобильные платформы на iOS, Android и WP7 аппаратно поддерживают .h264 и mp3.)

Такая сложная ситуация с кодеками приводит к тому, что на практике, если вы хотите обеспечить полностью кросс-браузерную поддержку, необходимо дублировать работу по кодированию и выкладывать несколько альтернатив как для аудио, так и для видео.

Фолбэк! Я хочу это в IE6!

Важный вопрос заключается в том, что делать с новыми мультимедийными возможностями HTML5 применительно к старым браузерам, в которых остается уповать только на Flash или Silverlight.

Ответ, как ни странно, просто – надо использовать Flash или Silverlight. Такой подход называется обеспечением обратной совместимости или fallback.

Реализация fallback для аудио или видео становится возможным благодаря тому, что браузер должен просто игнорировать не известные ему теги, поэтому вот этот код

<video width="854" height="480" controls preload> 
    <source src="video/trailer_480p.mp4" type="video/mp4;" /> 
    <source src="video/trailer_480p.webm" type='video/webm; codecs="vorbis,vp8"'/> 
     <object width="854" height="480" type="application/x-shockwave-flash" data="video/player.swf"> 
         <param name="movie" value="video/player.swf" /> 
         <param name="allowfullscreen" value="true" /> 
         <param name="flashvars" value='file=trailer_480p.mp4' /> 

         <p>Download video as <a href="video/trailer_480p.mp4">mp4</a>.</p> 
     </object>
</video>

будет предлагать пользователю именно ту альтернативу, которую его браузер способен воспроизвести, начиная с HTML5 Video, продолжая Flash и заканчивая просто ссылой на видео-файл, которую можно скачать штатным загрузчиком.

И да – это будет работать даже в IE6.

Что я не могу сделать с аудио и видео, но, возможно, смогу в будущем?

Мягко говоря, сегодня в мультимедийных возможностях HMTL5 есть множество белых пятен или пробелов, и к упомянутым проблемам со стандартизацией дефолтных контролов и кодеками добавляются ряд других:

Это и защита контента (DRM), и возможности адаптации качества видео-потока под текущие ограничения канала или устройства (наподобии Smooth Streaming в Silverlight или Live Streaming во Flash), и даже возможность воспроизведения видео в полноэкранном режиме.

Последнее, кстати, вы можете почувствовать на себе, если включите поддержку HTML5 Video на Youtube и попробуйте раскрыть какое-нибудь видео на полный экран – это будет видео на полную страницу внутри браузера.

Ключевая причина, по которой сегодня в стандарте HTML5 нет полноэкранного проигрывания видео – это вопрос безопасности, то есть исключения того, что любой скрипт на странице может перевести браузер в полноэкранный режим (это как раз обратная стороная интеграции в экосистему).

Другая задача, которую разработчикам стандартов еще только предстоит решить – это доступ к внутреннему содержанию аудио и видео-файлов для их анализа на стороне клиента (например, для создания визуализации на основании аудио-ряда, или генерации аудио-потока на лету).

Работа над этими и другими возможностями сегодня активно ведется внутри W3C, так, относительно недавно (весной этого года) была создана новая группа, занимающаяся именно вопросами работы с аудио.

Так что самое интересное еще впереди.

p.s. Совсем забыл самое важное: чтобы сделать видео со скругленными уголками, достаточно просто применить к видео CSS-правило border-raduis.