(Написано в мае 2012 специалистом по фронтенду и особенно, по медиаформатам, разработчиком нескольких опенсорсных проектов и happyworm.com и отражает современное состояние дел с поддержкой браузерами новых медиатегов и форматов. --прим. перев.)
Это продолжение моей (автора, Марка Боаса) статьи 2009 года "Native Audio in the browser" (англ., и дополненной в октябре 2010 --прим. перев.), которая объясняет основы работы аудио в HTML5. Возможно, стоит почитать сначала её, если вы хотите почувствовать работу тега <audio> и связанного с ним API. (Есть русский перевод, но в варианте от 2009 года.)
Теперь, через 2.5 года, пришло время посмотреть, как идут дела. При том, что многие продвинутые аудио API активно разрабатываются, улучшается воодушевляющая нас нативная браузерная поддержка звука — самое время вернуться в увлекательный мир тега <audio>.
Хороший способ понять, как идут дела — посмотреть несколько примеров использования, что мы увидим далее.
Как же нам начать? Есть несколько понятий, которые надо освоить для подготовки. Давайте сначала разберёмся в типах MIME.
Их называют ещё интернет медиа-типами — это один из способов сделать так, чтобы ваша система знала, как работать с медиаданными.
Прежде всего, сервер должен быть настроен для правильной поддержки MIME-типов. В случае Apache это означает, что в .htaccess имеются строки:
При описании источников данных в коде или разметке можно указать MIME-тип, который позволит браузеру определить данные правильно.
Самый надежный способ описать аудио HTML5 — примерно такой:
Здесь определяется тег и используемые источники данных. Браузер выберет только один — он не будет проигрывать их два или больше. В этом же коде размещаются резервные варианты обработки.
Вместе с адресом данных в атрибуте src указан атрибут type. Он не обязателен, но помогает браузеру узнать MIME-тип и кодеки для отдаваемого файла до того как он его загрузит. Если его нет, браузер пытается узнать тип из файла возможными способами.
Отлично. Теперь мы знаем, как определить адрес файла, и браузер преспокойно выберет первый поддерживаемый им формат. А можем ли мы подать файл динамически?
К счастью, API показывает, поддерживается ли данный формат файла в браузере. Но вначале — краткое описание того, как мы управляем тегом <audio>.
Если есть объект Audio, то есть доступ к его методам и свойствам. Для проверки поддержки форматов используют метод canPlayType с параметром — текстовым значением MIME-типа.
Можно даже явно указать кодек:
canPlayType возвращает одно из 3 значений:
1) probably,
2) maybe, или
3) "" (пустая строка).
Смысл получения этих странных типов истекает из общей странности ситуации, в которой находятся кодеки, пока мы судим о них по типу. Без реальной попытки воспроизведения браузер может только догадываться о применимости кодека.
Итого, для проверки поддержки делаем:
Здесь проверяется что canPlayType поддерживается ("!!" просто превращает объект строки в логический тип) и затем проверяется, что canPlayType нашего формата — не пустая строка. (Как-то нелогично с первой частью. Наверное, автор забыл упомянуть, что может вернуть undefined? --прим. перев.)
Посмотрим, как поддерживаются кодеки в современных браузерах.
Кодеки десктопных браузеров:
Кодеки мобильных:
Хорошая новость — в том, что на момент написания статьи около 80% браузеров поддерживают HTML5 Audio.
Плохая новость — до сих пор нет договорённости об универсальной поддержке какого-либо кодека, поэтому сервер должен поддерживать и MP3, и Ogg Vorbis, чтобы максимально полно поддержать HTML5 Audio в браузерах.
Выше я упоминал об известных аудиоформатах, но технически мы должны работать с их форматом контейнера. (Контейнер может содержать более одного формата — например, MP4 может содержать AAC и AAC+.)
Ладно, мы кое-как запустили аудио-теги — и это работает. Что ещё хотелось бы сделать? Сейчас в каждом браузере элементы работают немного по-разному из-за настроек по умолчанию. Хочется немного подогнать их к единому виду. Для этого есть несколько свойств элемента <audio>.
Несколько самых используемых атрибутов:
Использовать их крайне просто. Например:
Переменной duration присвоено значение длительности (в секундах) аудиоклипа.
Ситуация на этом фронте улучшается, разработчики браузеров начинают делать основную часть спецификации.
API даёт нам атрибуты buffered и seekable, когда хотим узнать, какая часть медиафайла была буферизована или предзагружена для воспроизведения без задержек. Они оба возвращают объект TimeRanges, который есть список интервалов — числа начала и конца.
Возвращает интервалы полностью загруженных участков файла. Небольшой пример:
The TimeRanges object contains data on the parts on buffered media in the form of one or more — you guessed it — time ranges. A TimeRanges object consists of these properties:
Содержит данные о частях буферизованных участков медиафайла (один или более — сколько успело буферизоваться) и имеет свойства:
length — число интервалов,
start(index) — начальное время указанного интервала,
end(index) — конечное время указанного интервала
(отсчитывается от начала воспроизведения).
Таким образом, в этом примере:
В каких случаях может быть больше одного буферизованного интервала? Пользователь кликает впереди, на небуферизованном участке шкалы на блоке проигрывателя. Объект начинает новую буферизацию от точки клика, и возникают 2 интервала буферизации.
Заметим, что если пользователь активно переключает точку воспроизведения, буферизация имеет мало смысла. Некоторые браузеры могут прочитать конец файла, чтобы установить длительность записи, почти сразу создавая 2 интервала буфера. Поэтому прогресс-бар в проигрывателе несколько сложнее обычного контрола прогресс-бара с 1 интервалом.
Вы можете проверить TimeRanges вашего браузера с помощью этого удобного HTML5 Media Event Inspector.
Поиск в контексте медиафайла — это заглядывание вперёд или назад в медиафайл. Обычно это происходит, когда ещё не закончена полная буферизация файла. Атрибут seeking используется для указания на то, что призошло событие "seeked". true означает, что часть файла ещё не загружена.
Продолжение следует...
Примечание на сайте оригинала, html5doctor.com :
Эта статья написана Марком Боасом. Марк разрабатывает / преподает / описывает и продвигает новые и открытые веб-технологии. Сооснователь Happyworm — небольшой вебстудии, разрабатывающей, в частности, jPlayer Media Framework, он раздвигает возможности браузера с помощью HTML5 и JavaScript. Будучи универсалом в сердце, Марк большую часть времени занимается веб-медиа и протоколами реального времени. Любитель всего, относящегося к аудио, он сейчас страстно работает над задачей «сделать что-то новое» в его экспериментах в проекте Hyperaudio. Вы можете следить за твиттером Марка.
Содержание следующей части:
 ● Замечание о предзагрузке
 ● Успешно воспроизведённое
■ Медиа-события
■ Потоковое воспроизведение
■ Эволюция спецификаций (или «Вау, это дело движется!»)
● Метод load
● Когда браузеры вернутся к официальной документации?
 ● Автовоспроизведение и громкость
 ● Одновременное воспроизведение нескольких аудиотегов
 ● Зависимость от ОС
■ Что нового?
 ● Изменение шага
 ● Медиа-фрагменты
■ Расширенное аудио API: будущий звук в браузерах
■ Заключение
■ Литература
Местные статьи и переводы по теме аудиотегов HTML5:
* Визуализация аудио в HTML5, 7 августа 2011
* Создаем кассетный магнитофон при помощи HTML5 Audio, 13 июля 2012
* Обработка звука через Audio Data API, 30 августа 2010
* HTML5 Audio и Game Development: баги браузеров, проблемы и их решения, идеи, 6 августа 2010
* Освоение HTML5 тега audio, 21 июля 2012
* Проблемы с HTML5 <Audio>, 16 мая 2011
* Using HTML5 audio and video, last mod. 13 Jun 2012
Спасибо ShpuntiK за то, что он обратил внимание на полезность перевода этой статьи.
UPD: Перевод 2-й части.
Это продолжение моей (автора, Марка Боаса) статьи 2009 года "Native Audio in the browser" (англ., и дополненной в октябре 2010 --прим. перев.), которая объясняет основы работы аудио в HTML5. Возможно, стоит почитать сначала её, если вы хотите почувствовать работу тега <audio> и связанного с ним API. (Есть русский перевод, но в варианте от 2009 года.)
Теперь, через 2.5 года, пришло время посмотреть, как идут дела. При том, что многие продвинутые аудио API активно разрабатываются, улучшается воодушевляющая нас нативная браузерная поддержка звука — самое время вернуться в увлекательный мир тега <audio>.
Хороший способ понять, как идут дела — посмотреть несколько примеров использования, что мы увидим далее.
Как же нам начать? Есть несколько понятий, которые надо освоить для подготовки. Давайте сначала разберёмся в типах MIME.
■ Типы MIME
● Серверная часть
Их называют ещё интернет медиа-типами — это один из способов сделать так, чтобы ваша система знала, как работать с медиаданными.
Прежде всего, сервер должен быть настроен для правильной поддержки MIME-типов. В случае Apache это означает, что в .htaccess имеются строки:
# AddType TYPE/SUBTYPE EXTENSION
AddType audio/mpeg mp3
AddType audio/mp4 m4a
AddType audio/ogg ogg
AddType audio/ogg oga
AddType audio/webm webma
AddType audio/wav wav
Совет: Не делайте gzip-сжатие медиафайлов на сервере. Большинство форматов уже сжаты, и есть некоторая поддержка для остальных. Кроме того, в запасном решении с флешем, он не поддерживает сжатия медиаданных. |
● Клиентская часть
При описании источников данных в коде или разметке можно указать MIME-тип, который позволит браузеру определить данные правильно.
Самый надежный способ описать аудио HTML5 — примерно такой:
<audio>
<source src="elvis.mp3" type='audio/mpeg; codecs="mp3"'>
<source src="elvis.oga" type='audio/ogg; codecs="vorbis"'>
<!-- здесь - добавить запасные варианты тегов -->
</audio>
Здесь определяется тег и используемые источники данных. Браузер выберет только один — он не будет проигрывать их два или больше. В этом же коде размещаются резервные варианты обработки.
Вместе с адресом данных в атрибуте src указан атрибут type. Он не обязателен, но помогает браузеру узнать MIME-тип и кодеки для отдаваемого файла до того как он его загрузит. Если его нет, браузер пытается узнать тип из файла возможными способами.
Замечание: можно пропустить в атрибуте название кодека, но для надежности и эффективности я рекомендую помогать браузеру, давая максимум возможной информации. |
● Заранее узнать тип аудио поможет .canPlayType (наверное)
К счастью, API показывает, поддерживается ли данный формат файла в браузере. Но вначале — краткое описание того, как мы управляем тегом <audio>.
Если объект Audio описывается в HTML, доступ к объекту можно получить через DOM:
var audio = document.getElementsByTagName('audio')[index];
или, если определён id,
var audio = document.getElementById('my-audio-id');
Как вариант, объект создаётся полностью на Javascript.
var audio = new Audio();
Если есть объект Audio, то есть доступ к его методам и свойствам. Для проверки поддержки форматов используют метод canPlayType с параметром — текстовым значением MIME-типа.
audio.canPlayType('audio/ogg');
Можно даже явно указать кодек:
audio.canPlayType('audio/ogg; codecs="vorbis"');
canPlayType возвращает одно из 3 значений:
1) probably,
2) maybe, или
3) "" (пустая строка).
Смысл получения этих странных типов истекает из общей странности ситуации, в которой находятся кодеки, пока мы судим о них по типу. Без реальной попытки воспроизведения браузер может только догадываться о применимости кодека.
Итого, для проверки поддержки делаем:
var audio = new Audio();
var canPlayOgg = !!audio.canPlayType
&& audio.canPlayType('audio/ogg; codecs="vorbis"') != "";
Здесь проверяется что canPlayType поддерживается ("!!" просто превращает объект строки в логический тип) и затем проверяется, что canPlayType нашего формата — не пустая строка. (Как-то нелогично с первой частью. Наверное, автор забыл упомянуть, что может вернуть undefined? --прим. перев.)
■ Поддержка различных кодеков в браузере
Посмотрим, как поддерживаются кодеки в современных браузерах.
Кодеки десктопных браузеров:
Десктопные версии | Номер | Поддержка кодеков |
---|---|---|
Internet Explorer | 9.0+ | MP3, AAC |
Chrome | 6.0+ | Ogg Vorbis, MP3, WAV (начиная с Chrome 9) |
Firefox | 3.6+ | Ogg Vorbis, WAV |
Safari | 5.0+ | MP3, AAC, WAV |
Opera | 10.0+ | Ogg Vorbis, WAV |
Мобильные браузеры | Версия | Поддержка кодеков |
---|---|---|
Opera Mobile | 11.0+ | Device-dependent |
Android | 2.3+ | Device-dependent |
Mobile Safari | (iPhone, iPad, iPod Touch) iOS 3.0+ | MP3, AAC |
Blackberry | 6.0+ | MP3, AAC |
Плохая новость — до сих пор нет договорённости об универсальной поддержке какого-либо кодека, поэтому сервер должен поддерживать и MP3, и Ogg Vorbis, чтобы максимально полно поддержать HTML5 Audio в браузерах.
Забавно: Android 2.2 поддерживает <video>, но не <audio>. Чтобы воспроизводить аудио, нужно использовать тег <video>. |
● Контейнеры, форматы и расширения файлов (и снова эти MIME-типы)
Выше я упоминал об известных аудиоформатах, но технически мы должны работать с их форматом контейнера. (Контейнер может содержать более одного формата — например, MP4 может содержать AAC и AAC+.)
Container | Format(s) | File Extensions | MIME Type | Codec String |
---|---|---|---|---|
MP3 | MP3 | .mp3 | audio/mpeg | mp3 |
MP4 | AAC, AAC+ | .mp4, .m4a, .aac | audio/mp4 | mp4a.40.5 |
OGA/OGG | Ogg Vorbis | .oga, .ogg | audio/ogg | vorbis |
WAV | PCM | .wav | audio/wav | 1 |
● Мы имеем <audio> и не боимся его использовать!
Ладно, мы кое-как запустили аудио-теги — и это работает. Что ещё хотелось бы сделать? Сейчас в каждом браузере элементы работают немного по-разному из-за настроек по умолчанию. Хочется немного подогнать их к единому виду. Для этого есть несколько свойств элемента <audio>.
Несколько самых используемых атрибутов:
Свойство | Описание | Возвращаемое значение |
---|---|---|
currentTime | позиция курсора проигрывателя | double (секунды) |
duration | длительность воспроизведения | double (секунды); только чтение |
muted | заглушен ли звук | boolean |
paused | остановлено ли воспроизведение | boolean |
volume | уровень громкости | double (от 0 до 1) |
var audio = new Audio();
var duration = audio.duration;
Переменной duration присвоено значение длительности (в секундах) аудиоклипа.
■ Буферизация, поиск и временны́е диапазоны
Ситуация на этом фронте улучшается, разработчики браузеров начинают делать основную часть спецификации.
API даёт нам атрибуты buffered и seekable, когда хотим узнать, какая часть медиафайла была буферизована или предзагружена для воспроизведения без задержек. Они оба возвращают объект TimeRanges, который есть список интервалов — числа начала и конца.
● Атрибут buffered
Возвращает интервалы полностью загруженных участков файла. Небольшой пример:
// возвращает объект TimeRanges буферизованного файла
var buffered = audio.buffered;
// выделяет время в секундах из сохранённого объекта TimeRange
var bufferedEnd = audio.buffered.end();
● Объект TimeRanges
The TimeRanges object contains data on the parts on buffered media in the form of one or more — you guessed it — time ranges. A TimeRanges object consists of these properties:
Содержит данные о частях буферизованных участков медиафайла (один или более — сколько успело буферизоваться) и имеет свойства:
length — число интервалов,
start(index) — начальное время указанного интервала,
end(index) — конечное время указанного интервала
(отсчитывается от начала воспроизведения).
Забавно: По умолчанию размерность времени в JS Audio API — секунды, хотя традиционные функции в JS используют миллисекунды. |
------------------------------------------------------ //пример
|=============| |===========| |
------------------------------------------------------
0 5 15 19 21
Таким образом, в этом примере:
audio.buffered.length //returns 2
audio.buffered.start(0) //returns 0
audio.buffered.end(0) //returns 5
audio.buffered.start(1) //returns 15
audio.buffered.end(1) //returns 19
audio.buffered.end() //returns 19
В каких случаях может быть больше одного буферизованного интервала? Пользователь кликает впереди, на небуферизованном участке шкалы на блоке проигрывателя. Объект начинает новую буферизацию от точки клика, и возникают 2 интервала буферизации.
Совет: Большинство аудио-проигрывателей позволяет перемещаться на новые позиции файла во время загрузки, выполняя ряд запросов на сервер. В Apache множественный доступ к файлу разрешён по умолчанию, но надо убедиться в этом для сервера с неизвестными настройками. |
Вы можете проверить TimeRanges вашего браузера с помощью этого удобного HTML5 Media Event Inspector.
● Атрибуты seeking и seekable
Поиск в контексте медиафайла — это заглядывание вперёд или назад в медиафайл. Обычно это происходит, когда ещё не закончена полная буферизация файла. Атрибут seeking используется для указания на то, что призошло событие "seeked". true означает, что часть файла ещё не загружена.
Продолжение следует...
Примечание на сайте оригинала, html5doctor.com :
Эта статья написана Марком Боасом. Марк разрабатывает / преподает / описывает и продвигает новые и открытые веб-технологии. Сооснователь Happyworm — небольшой вебстудии, разрабатывающей, в частности, jPlayer Media Framework, он раздвигает возможности браузера с помощью HTML5 и JavaScript. Будучи универсалом в сердце, Марк большую часть времени занимается веб-медиа и протоколами реального времени. Любитель всего, относящегося к аудио, он сейчас страстно работает над задачей «сделать что-то новое» в его экспериментах в проекте Hyperaudio. Вы можете следить за твиттером Марка.
Содержание следующей части:
 ● Замечание о предзагрузке
 ● Успешно воспроизведённое
■ Медиа-события
■ Потоковое воспроизведение
■ Эволюция спецификаций (или «Вау, это дело движется!»)
● Метод load
● Когда браузеры вернутся к официальной документации?
 ● Автовоспроизведение и громкость
 ● Одновременное воспроизведение нескольких аудиотегов
 ● Зависимость от ОС
■ Что нового?
 ● Изменение шага
 ● Медиа-фрагменты
■ Расширенное аудио API: будущий звук в браузерах
■ Заключение
■ Литература
Местные статьи и переводы по теме аудиотегов HTML5:
* Визуализация аудио в HTML5, 7 августа 2011
* Создаем кассетный магнитофон при помощи HTML5 Audio, 13 июля 2012
* Обработка звука через Audio Data API, 30 августа 2010
* HTML5 Audio и Game Development: баги браузеров, проблемы и их решения, идеи, 6 августа 2010
* Освоение HTML5 тега audio, 21 июля 2012
* Проблемы с HTML5 <Audio>, 16 мая 2011
* Using HTML5 audio and video, last mod. 13 Jun 2012
Спасибо ShpuntiK за то, что он обратил внимание на полезность перевода этой статьи.
UPD: Перевод 2-й части.