Прогрессивная потоковая передача HTTP работает, просто отправляя данные одним непрерывным потоком, в то время как принимающая сторона воспроизводит данные по мере их поступления. Природа сетей такова, что данные поступают порциями, а не непрерывно, поэтому клиент, воспроизводящий звук, имеет буфер на пару секунд, чтобы выдержать периодические всплески данных.
Чтобы пережить выпадение в минуту, клиенту в будущем придется получать более минуты данных. Это достигается путем буферизации минутных данных на сервере, а затем сбрасывания этого буфера как можно быстрее клиенту при подключении. Хотя он не будет добираться до клиента одновременно, он должен добраться туда достаточно быстро, и тогда у вас будет этот буфер, который может пережить разъединение. То есть, если ваш сервер на минуту опережает клиента, а клиент с полным 1-минутным буфером теряет соединение, он может продолжать воспроизведение около минуты, прежде чем ему придется отключиться.
Хотя это только половина проблемы. Что вы делаете, когда снова подключаетесь? Как клиент синхронизируется с сервером? К сожалению, нет общедоступных серверов, выполняющих прогрессивный HTTP в реальном времени, которые поддерживают способ синхронизации. Я сам экспериментировал с заголовками Range и с тем, что не работает, но требует специального клиента. (Однако VLC работает...)
Вы также должны учитывать причину, по которой ваш звук немедленно останавливается. Если вы пытаетесь имитировать пропадание сети или медленное место, включив режим полета, это не подходящий тест. ОС отключает сетевой интерфейс, который немедленно разрывает любые TCP-соединения, немедленно убивая канал к приложению. Большинство приложений перестанут воспроизводиться в этот момент, если у них нет дополнительного буфера независимо от сетевого подключения. В ситуации, когда качество вашего сетевого соединения страдает, TCP-соединение редко действительно разрывается ... пакеты просто задерживаются, что приводит к тому, что звук в конечном итоге останавливается, когда заканчивается буфер.
При всем при этом есть два решения в зависимости от ваших потребностей:
Выжить в случаях, когда качество сети меняется, TCP-соединение сохраняется
Это просто. Увеличьте буфер на стороне сервера, который сбрасывается клиентам. Я обычно использую 20 секунд.
Обратите внимание, что не все клиенты примут такой большой буфер. Некоторые уменьшают размер окна TCP, не позволяя серверу отправлять слишком много аудиоданных.
(Примечание. Если вы не можете понять, как это сделать с существующим сервером потоковой передачи, конфигурация буфера доступна на CDN AudioPump., который я создал. Он пока недоступен, но вы можете написать мне по электронной почте [email protected], чтобы попробовать его.)
Пережить изменение IP-адреса, TCP-соединение гарантированно будет потеряно
Для этого сценария вам нужен совершенно новый протокол потоковой передачи. HLS — это то, что вам нужно.
HLS работает, сегментируя ваш поток, который в любом случае должен быть запрошен несколькими HTTP-запросами. Из-за этого клиент может менять адреса (например, переходить из мобильной сети в WiFi) и поток все равно будет работать.
HLS, к сожалению, не так хорошо поддерживается клиентами, но на стороне сервера все просто. В большинстве случаев подойдет любой HTTP-сервер. Кодер — это то, что нужно изменить, чтобы закодировать и загрузить сегменты.
person
Brad
schedule
12.02.2015
