Браузерное потоковое видео/аудио (не прогрессивная загрузка)

Question

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

Edit:

В исследовании я обнаружил, что есть несколько протоколов: RTSP, HTTP Streaming, RTMP и RTP.

HTTP-потоковая передача несколько неприемлема, если вы поторопите какое-то живое исполнение/сообщение, потому что оно зависит от TCP (как его основано на HTTP), и вы не теряете пакеты. В ситуации с низкой пропускной способностью клиент может значительно отстать в воспроизведении. ref

RTMP - это проприетарная технология, требующая использования флэш-медиа-сервера. Дерьмо на этом. Причина, по которой я смотрел флеш, - это то, что они чрезвычайно гибкие, насколько это касается пользователей. SoundManager2 обеспечивает превосходный интерфейс javascript для воспроизведения со вспышкой. Это то, что я хотел бы найти в клиентском приложении.

RTSP/RTP - это то, что Microsoft переключилось на использование, отказавшись от своего протокола MMS. RTSP - это протокол управления. Его похож на HTTP с несколькими отличительными отличиями - сервер также может разговаривать с клиентом, и есть дополнительные команды, такие как PAUSE. Его также протокол состояния, который поддерживается с идентификатором сеанса. RTP - это протокол для доставки полезной нагрузки (закодированный звук или видео). Существует несколько проектов с открытым исходным кодом, один из которых поддерживается яблоком here. Похоже, что это может сделать то, что я хочу, и это выглядит как quite a few players support it. Похоже, он был бы подходящим для «живой» трансляции с этой страницы here.

Спасибо, Джош

Answer 1

Во-первых, позвольте мне сбить две неправильные точки быстро. Детали нижеследуют:

• RTMP может быть сделан по сравнению с другими серверами, чем Flash Media Server,
• TCP отлично подходит для живых. Слишком много F.U.D. от любящих UDP людей. Apple has just released a draft specification делает простой, прямой эфир через HTTP (и, следовательно, TCP) для iPhone. Я ожидаю, что это тоже закончится в браузерах. Кроме того, TCP имеет гораздо более частый и легкий доступ к корпоративным брандмауэрам.

Полагаю, что сложная и потоковая передача на основе UDP сужается. Я не прогнозирую смерть, а меньшую и меньшую долю рынка. Потоковые серверы на основе UDP потребляют огромные ресурсы по сравнению с решениями на базе TCP (например, 10x или более), а преимущества просто не осязаемы.

Вы говорите, что не хотите проприетарную технологию, и «дерьмо на [Flash]»,, но вы все еще хотите сделать настоящую передачу? Ненавижу, чтобы разорвать его на вас, но оба RealAudio и RealVideo являются проприетарными.

Если вы собираетесь использовать Open Source, это важно для вас, что я могу понять, тогда вам нужно будет игнорировать подавляющее большинство рынка потоковых медиа.Посмотри на

• Theora: безвозмездный, открытый стандарт, с потерями видеотехнологию сжатия
• Vorbis: бесплатное программное обеспечение/открытый проект, который производит аудио спецификации и программное обеспечение реализацию в формате для сжатие с потерями звука.
• Ogg: свободный, открытый стандартный контейнер формата

Если прагматизм получает лучшее из вас, то пересмотрите свое отвращение к Adobe продуктов. Помните, что Flash более широко распространен, чем любой другой браузер на базе браузера (а именно Windows Media Player, Quick Time и Real Players).

Вы все еще можете использовать RTMP с открытым исходным кодом: Red5, вероятно, представляет наибольший интерес - он может поток в реальном времени для браузеров с поддержкой Flash.

Я бы рекомендовал подумать о ваших приоритетах. Запишите их нам в вопросе.

Answer 2

Я бы добавил к ответу Стью, что протоколы потоковой передачи на основе UDP часто имеют дополнительную сложность для работы, когда они находятся за брандмауэрами или NAT. Например, если вы планируете использовать точки доступа WIFI вне дома, многие из них не будут поддерживать RTP с использованием доставки UDP. У многих клиентов есть механизм отката, где, если пакеты не принимаются до истечения таймаута, клиент будет пытаться выполнить доставку TCP.