Сжатие данных перед сохранением в Google App Engine

Question

Я пытаюсь сохранить 30-секундные пользовательские записи mp3 в виде Blobs в моем хранилище данных движка приложения. Однако, чтобы включить эту функцию (App Engine имеет ограничение в 1 МБ на загрузку) и снизить затраты, я хотел бы сжать файл перед загрузкой и распаковывать файл каждый раз, когда он запрашивается. Как бы вы предложили мне это сделать (это может произойти в фоновом режиме, кстати, через очередь задач, но эффективное решение всегда хорошо)

Основываясь на моих собственных тестах и ​​исследованиях - я вижу два возможных подхода для достижения этой цели

• Злиб

Для этого мне нужно сжимать определенное количество блоков одновременно, используя цикл While. Однако App Engine не позволяет записывать в файловую систему. Я думал об использовании временного файла для достижения этой цели, но мне не повезло с таким подходом при попытке распаковать содержимое из временного файла

• Gzip

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

Дайте мне знать, как бы вы предложили использовать zlib или gzip или другое решение для этого. Спасибо

Answer 1

Вы можете попробовать новый API Blobstore, позволяющий хранить и обслуживать файлы размером до 50 МБ

http://www.cloudave.com/link/the-new-google-app-engine-blobstore-api-first-thoughts

http://code.google.com/appengine/docs/python/blobstore/

http://code.google.com/appengine/docs/java/blobstore/

Answer 2

«Сжатие перед загрузкой» подразумевает выполнение этого в браузере пользователя - но ни один текст в вашем вопросе не решает эту проблему! Это похоже на сжатие в вашем приложении GAE , где, конечно, данные будут только после загрузки. Вы можете сделать это с расширением Firefox (или эквивалентами других браузеров), если вы можете разработать их и убедить своих пользователей установить их, но это не имеет ничего общего с GAE! -) Не говоря уже о том, как комментирует @ RageZ упоминает, что MP3, по сути, уже сжат, так что выиграть практически нечего (хотя, возможно, вы могли бы, опять же с расширением браузера для пользователя, уменьшить скорость передачи MP3 и, следовательно, размер файла, что может повлиять на качество звука, в зависимости от предполагаемого использования этих аудиофайлов).

Итак, в общем, я должен повторить предложение @ jldupont (также в комментарии) - использовать другой сервер для хранения больших файлов (S3, предложение Amazon, безусловно, возможно, но не единственное).

Answer 3

Хотя технические ограничения (упомянутые в других ответах) на сжатие файлов MP3 с помощью стандартного сжатия или перекодирования с более низкой скоростью передачи битов верны, ваша цель состоит в том, чтобы хранить 30 секунд данных в формате MP3. Предполагая, что вы можете применить это к своим пользователям, у вас должно быть все в порядке, не применяя дополнительные методы сжатия, если битрейт MP3 равен 256 Кбит / с с постоянной битрейтом (CBR) или ниже. На 256 кбит CBR 30 секунд аудио потребует:

(((256 * 1000) / 8) * 30) / 1048576 = 0.91MB

Максимальный стандартный битрейт составляет 320 Кбит, что соответствует 1,14 МБ, поэтому вам придется использовать 256 или меньше. Наиболее часто используемый битрейт в дикой природе составляет 128 кбит.

Существуют дополнительные накладные расходы, которые увеличивают конечный размер файла, такие как теги ID3 и кадрирование, но вы должны быть в порядке. Если нет, уменьшите до 224 кбит как максимум (30 секунд = 0,80 МБ). Существуют и другие сложности, такие как кодирование с переменным битрейтом, размер файла которого не так предсказуем, и я их игнорирую.

Таким образом, ваша проблема больше не в том, как сжимать файлы MP3, а в том, чтобы гарантировать, что ваши пользователи знают, что они не могут загружать более 30 секунд, закодированных при 256 Кбит / с, и как применять эту политику.

Answer 4

Вы можете хранить до 10 Мб со списком BLOB-объектов. Искать google file service. На мой взгляд, он гораздо более универсален, чем BlobStore, поскольку я только вчера начал использовать BlobStore Api, и я все еще выясняю, возможно ли получить доступ к данным в байтовом режиме ... как при изменении doc на pdf, jpeg на gif ..

Вы можете хранить BLOB-объекты размером 1 МБ * 10 = 10 МБ (я думаю, что это максимальный размер объекта), или вы можете использовать API BlobStore и получить те же 10 МБ или 50 МБ, если вы включите биллинг (вы можете включить его, но если вы не не сдать бесплатную квоту, которую вы не платите).

Answer 5

Как отмечает Aneto в комментарии, вы не сможете сжимать данные MP3 с помощью стандартной библиотеки сжатия, такой как gzip или zlib. Тем не менее, вы можете перекодировать MP3 с более низкой скоростью MUCH , возможно с LAME .