Google Cast работает медленно для некоторых потоков - PullRequest
Новая
       37

Google Cast работает медленно для некоторых потоков

0 голосов
/ 25 сентября 2018

У меня есть приложение для Android, которое воспроизводит прямые трансляции из Интернета (в основном, с Icecast) через Google Cast.Все работало нормально и быстро, но теперь для запуска некоторых потоков требуется гораздо больше времени (издает звук).Это может быть как-то связано с обновлением прошивки Chromecast, так как мое устройство Chromecast недавно обновилось до последней версии (1.32.124602).

Вот как я воспроизводлю поток через Cast: 

MediaMetadata metadata = new MediaMetadata(MediaMetadata.MEDIA_TYPE_GENERIC);
metadata.putString(MediaMetadata.KEY_TITLE, "My title");
metadata.putString(MediaMetadata.KEY_SUBTITLE, "My subtitle");
metadata.addImage(new WebImage(myImageUri);
MediaInfo mediaInfo = new MediaInfo.Builder(streamUrl)
        .setStreamType(MediaInfo.STREAM_TYPE_LIVE)
        .setContentType("audio/mpeg")
        .setMetadata(metadata)
        .build();
MediaLoadOptions options = new MediaLoadOptions.Builder()
       .setAutoplay(true)
       .setPlayPosition(0)
       .build();
sessionManager.getCurrentCastSession().getRemoteMediaClient().load(mediaInfo, options);

Странно то, что некоторые потоки довольно быстрые, а другие нет:

  1. http://stream.funradio.sk:8000/dance128.mp3 - Звук воспроизводится через 20 секунд
  2. http://stream.expres.sk:8000/128.mp3 - Звук воспроизводится за 1 секунду

Я также заметил, что ResultCallback функции load () запускается почти мгновенно для второго потока, тогда как первый занимает около 3 секунд.

Я ценю любую помощь или идею, как это исправить.

1 Ответ

0 голосов
/ 26 сентября 2018

Вторая ссылка имеет больший буфер для очистки.

Throughput Analysis

Этот график показывает пропускную способность.Первый косяк - когда я тестировал первый URL на stream.funradio.sk:8000.Вторая ошибка - когда я тестировал второй URL-адрес на stream.expres.sk:8000.

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

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

Я ценю любую помощь или идею, как это исправить.

Если не считать прокси потоков, с этим мало что можно поделать.Устройства Android и Chromecast особенно требовательны к потокам MP3 и требуют для синхронизации большого количества данных.

Кроме того, алгоритм, который использует Chrome, чтобы определить, достаточно ли заполнен буфер для воспроизведения без остановки, не знает.вы даете ему радиопоток, видите снижение скорости и еще больше буферизируете перед началом.Эту проблему можно обойти, если полностью закодировать собственный проигрыватель, который буферизует данные и затем передает их в декодер, а не просто дает URL-адрес базовой системе.В Интернете это можно сделать с помощью расширений Media Source Extensions.Для Android у меня нет большого опыта там.

...