Я пытаюсь создать сервер потоковой передачи звука в java. Существует несколько протоколов для потоковой передачи мультимедиа, таких как RTP, и я немного запутался со всеми протоколами.
В чем разница между RTP и Shoutcast? Используют ли они TCP, UDP или HTTP? У кого-нибудь есть четкое объяснение по этому поводу?
SHOUTcast и Icecast используют клиентский протокол, очень похожий на HTTP. (На самом деле, Icecast совместим с HTTP, как указано в RFC2616, и большинство HTTP-клиентов работают с SHOUTcast без изменений.) Приходит запрос для потока, и они возвращают аудиоданные потока так же, как ответ HTTP. вместе с некоторыми дополнительными метаданными.
GET /radioreddit/main_mp3_128k HTTP/1.1
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: X-Requested-With
Server: AudioPump Server/0.8.1 (http://audiopump.co)
Content-Type: audio/mpeg
Cache-Control: no-cache
Pragma: no-cache
Expires: Sat, 15 Aug 2009 22:00:00 GMT
Connection: close
icy-genre: Indie,Rock,Talk
icy-name: Radio Reddit - Main
icy-pub: 1
icy-url: http://radioreddit.com
Date: Tue, 05 Aug 2014 13:40:55 GMT
В этом примере ответ является чисто HTTP. Если бы это был сервер SHOUTcast, вместо HTTP/1.1 200 OK в строке состояния вы бы увидели ICY 200 OK. Заголовки, начинающиеся с icy-, описывают станцию. Иногда их больше, иногда их нет вообще. Клиент сможет воспроизводить данные MP3 с этой станции как есть.
Теперь иногда клиент будет запрашивать отправку метаданных в потоке. Это позволяет игроку сказать вам, что играет. Клиент делает это, отправляя заголовок icy-metadata: 1. Сервер ответит icy-metaint: 8192, что означает, что каждые 8192 байта будет фрагмент метаданных. Вы можете узнать больше о формате этих метаданных в предыдущем ответе.
Я также должен отметить, что эту форму потоковой передачи часто называют HTTP Progressive Streaming. Для клиента это ничем не отличается от воспроизведения медиафайла во время его загрузки... за исключением того, что файл имеет бесконечный размер.
Теперь RTP — это протокол, используемый вместе с RTSP. RTP — это фактические мультимедийные данные, где для управления используется RTSP. Эти протоколы намного сложнее, так как предназначены для настоящей потоковой передачи. То есть, если клиент не может справиться с пропускной способностью, он может перейти на более низкий битрейт. Если клиенту нужно управлять удаленным, это тоже можно сделать. Эта сложность имеет свою цену. Серверы сложны в реализации. Нет большой совместимости клиентов.
Пару лет назад, когда я начал создавать свой собственный потоковый сервер, я задал себе тот же вопрос. Должен ли я реализовывать настоящий протокол потоковой передачи, который имеет не очень хорошую клиентскую поддержку и на выяснение которого потребуется много времени, или я реализую протокол, который может воспроизводить все, и для которого легко построить. Я пошел по HTTP-маршруту.
В наши дни вам также следует подумать о HLS, который представляет собой не что иное, как разбиение исходного потока на части по нескольким битрейт и обслуживать его по HTTP. Если клиент хочет изменить битрейт из-за нехватки полосы пропускания, он может просто начать запрашивать фрагменты с низким битрейтом. У HLS тоже не очень хорошая поддержка клиентов, но она становится лучше. Я подозреваю, что со временем он превзойдет все остальные по доставке мультимедиа на веб-сайты.
Сравнение между RTP (протокол) и Shoutcast (приложение) неприменимо.
RTP — это интернет-стандарт для передачи мультимедиа через IP.
Это протокол прикладного уровня, поэтому RTP может передаваться через TCP или UDP, в зависимости от характера связи. Кроме того, он должен быть реализован приложением, прежде чем он сможет быть использован, так же, как HTTP должен быть реализован браузером, чтобы пользователь мог получить доступ к веб-страницам. При реализации приложением он используется для указания формата мультимедиа, множества других характеристик и базовой управляющей информации (через RTSP).
Shoutcast – это потоковое приложение, созданное Nullsoft (авторы Winamp). Он использует собственные протоколы для передачи мультимедиа и может работать как по TCP, так и по UDP.
Существует множество других протоколов потоковой передачи, поэтому поиск в Google по этому вопросу, как обычно хорошая идея. Википедия также содержит сравнение систем потокового мультимедиа.
