HTML5 Local Storage источника аудиоэлемента - возможно ли это?

Question

В последнее время я экспериментировал с функциями аудио и локального хранилища в html5 и столкнулся с тем, что поставило меня в тупик.

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

Я попробовал следующее с помощью WebKit:

<Ол>

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

Я также пытался использовать javascript для помещения аудиообъекта в локальное хранилище, но размер mp3 делает это невозможным из-за проблем с памятью (я думаю).

Я пытался использовать данные uri и base64, чтобы использовать html в качестве аудиопередачи, которая может быть кэширована, но опять же размер файла делает это запретительным. Также кажется, что аудиоэлементу не нравится это в WebKit (отлично работает в Mozilla)

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

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

Answer 1

Прошло много времени с тех пор, как я задал этот вопрос, и я подумал, что дам некоторую информацию о том, как мы решили его. По сути, мы закодировали данные в PNG, используя похожую технику:

http://audioscene.org/scene-files/yury /pngencoding/sample.html

Затем кэшировал изображение на мобильном устройстве с помощью локального хранилища html5 и получал к нему доступ по мере необходимости. PNG были довольно большими, но у нас это получилось.

Answer 2

Я пытался сделать это сам, на iOS (для iPhone / iPad), но он отказывается кэшировать аудиофайлы в автономном режиме, даже если в Cache Manifest.

Это не ошибка, а просто притворяется, что он проигрывал аудио элемент, если вызывается через JavaScript без элемента управления. Если он встроен в элемент управления, он отображает альтернативный элемент управления с надписью & Quot; Невозможно воспроизвести аудиофайл. & Quot ;. Работает нормально, если приложение может выходить в интернет.

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

Я экспериментировал с base64, кодирующим аудио как URI данных. Это работает в Safari на настольном компьютере (по крайней мере, для довольно коротких образцов размером около 20-30 Кб, которые я использовал), но, похоже, вообще не поддерживается на iOS - он ничего не делает, что очень раздражает.

Я не знаю о других поставщиках - Google Chrome раньше не поддерживал URI данных для аудио, но, возможно, они исправили это ... - похоже, сейчас это невозможно.

Обновление: незначительное расхождение с iPhone OS 3.x (протестировано с 3.1.2): если в автономном веб-приложении указан аудиоэлемент, но у него нет элемента управления, он отображает неинтерактивный элемент управления с не анимированный спиннер на нем (что он определенно не должен делать). Я предполагаю, что это исправлено в iOS 4.x (которая должна выйти на следующей неделе).

Answer 3

Я потратил некоторое время, пытаясь сделать это для игры, которую я делаю, и, насколько я могу судить, браузеры (Firefox и Chrome) все еще не поддерживают кэширование аудиоэлементов, я думал, что выложу решение Я нашел.

Обходной путь описан здесь: http://dougx.net/plunder/index.php # кодовой

Я могу подтвердить, что он работает довольно хорошо, но, вероятно, лучше подходит для небольших файлов. Как он описывает здесь ( http://dougx.net/plunder/GameSounds.txt ), вы закодируйте аудио как строки base64 и передайте им данные: audio / ogg; base64 (или любой другой совместимый аудиоформат) заголовок, который затем может прочитать аудио HTML5. Поскольку это всего лишь строка, браузер будет ее кэшировать.

Answer 4

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

Что произойдет, если вы измените заголовки HTTP аудиофайла, например, Content-Type и Expires? Браузер делает что-то другое, если расширение файла меняется?

Answer 5

Я вижу, вам пока не повезло.

Возможно, вы захотите взглянуть на JAI (аудиоинтерфейс JavaScript) (" первый в мире интерфейс javascript для веб-сайтов <audio> "). Или свяжитесь с Аластером Макдональдом , который его написал.

В противном случае HTML5 Doctor может оказать помощь.

Answer 6

Добавление видео и аудио файлов в локальное хранилище работает с iOS 4.3.

Я только что добавил видео и аудиофайл в манифест, и они оба были загружены в автономное хранилище на iPad.