Android media player - как отключить запрос диапазона? (сломанная потоковая передача звука на Nexus 7)

Ответ 1

Мы наконец решили это чистым способом. В нашем случае у нас есть полный контроль над потоковым сервером, но я думаю, вы могли бы сделать это и с локальным прокси. Поскольку Build.VERSION_CODES.ICE_CREAM_SANDWICH можно установить заголовки для объекта MediaPlayer. Поскольку наше приложение позволяет пользователю искать внутри аудиопотока, мы реализовали этот заголовок Range на клиенте. Если сервер отвечает соответствующими заголовками, MediaPlayer не будет запрашивать многопрофильное время для запроса потока.

То, что наши заголовки серверов выглядят сейчас для клиента android:

Content-Type: audio/mpeg
Accept-Ranges: bytes
Content-Length: XXXX
Content-Range: bytes XXX-XXX/XXX
Status: 206

Важной частью является код состояния 206 (частичный контент). Если вы не отправляете этот заголовок, клиент android попытается повторно запросить источник, независимо от того, что.

Если ваш проигрыватель не разрешает поиск в потоке, вы всегда можете установить заголовок Range на 0-some arbitrary large number.

Ответ 2

Я работаю над широкомасштабным приложением для потоковой передачи звука (которое использует прокси-сервер локального хоста для потоковой передачи звука в MediaPlayer), и я столкнулся с этой проблемой, как только я получил устройство JellyBean в моих руках в Google I/O 2012.

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

Не вдаваясь в подробности, это то, что я видел: некоторые реализации будут делать несколько запросов (несколько раз 5+) для одного и того же URL-адреса. Эти запросы были немного отличны друг от друга, поскольку каждый из них был для другого байтового диапазона (обычно для первого или последнего 128 байтов). Вывод состоял в том, что MediaPlayer пытался найти встроенные метаданные, после чего через некоторое время он сдался и просто сделал бы обычный запрос без диапазона.

Это не то, что делает реализация JellyBean MediaPlayer, это всего лишь пример безумной и общей фрагментации медиакарты на Android. Однако решение вышеуказанной ситуации также было решением проблемы JellyBean, и это:

Попросите вашего локального прокси ответить закодированное кодирование

Это заменяет заголовок Content-Length заголовком Tranfer-Encoding: chunked. Это означает, что запрашивающий клиент не будет знать общую длину ресурса и, следовательно, не сможет выполнить запрос диапазона, он просто должен иметь дело с кусками по мере их получения.

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

Ответ 3

Когда вы ищете или пропускаете или соединение потеряно, и MediaPlayer продолжает переподключение к прокси-серверу, вы должны отправить этот ответ с Статус 206 после того, как вы получите запрос и диапазон (int) от клиента,

String headers += "HTTP/1.0 206 OK\r\n";
headers += "Content-Type: audio/mpeg\r\n";
headers += "Accept-Ranges: bytes\r\n";
headers += "Content-Length: " + (fileSize-range) + "\r\n";
headers += "Content-Range: bytes "+range + "-" + fileSize + "/*\r\n";
headers += "\r\n";