Онлайн-трансляция радиостанции

Происхождение и история термина

Английское stream означает поток. В рассматриваемой технологии данные поступают последовательно, пока программа продолжается. Отдельную дату появления выражения radio stream нельзя надёжно вывести из истории одной программы или протокола: у сетевой доставки звука несколько технических реализаций. Полезнее проследить документированное развитие одной из них, не назначая её началом всего интернет-вещания.

В RFC 8216 указано, что первый проект спецификации HLS опубликован в 2009 году. Сам RFC вышел в августе 2017 года и описывает седьмую версию протокола. Его статус — Informational, то есть информационный документ, а не стандарт ветви Internet Standards Track. ^[3] Эти даты относятся к HLS, а не к первой радиостанции в интернете.

Развитие продолжается: на дату проверки в IETF Datatracker второе издание HLS обозначено как проект draft-pantos-hls-rfc8216bis-22, переданный редактору RFC. Проект предусматривает замену RFC 8216 после утверждения; опубликованной заменой его считать преждевременно. ^[11] Поэтому приведённая ниже схема опирается на конкретные положения RFC 8216 и не обещает охватить все последующие расширения HLS.

Суть и механизм

Представим учебную станцию с ведущим, музыкальным расписанием и местными новостями. Для разбора разделим её сетевой путь на пять участков: подготовленный звук, кодирование, подачу на сервер, доставку и воспроизведение. Это редакционная схема проверки, основанная на разделении источника и сервера в Icecast, а не обязательный список отдельных компьютеров. ^{[1, 2]}

Кодирование превращает звук в данные выбранного аудиоформата. Source client, или клиент-источник, — программа, которая отправляет эти данные серверу трансляции. Например, официальный FAQ описывает IceS: он может читать звук с диска либо получать его со звуковой карты и кодировать по мере поступления. ^[2] Поэтому текущая трансляция не обязательно состоит из выступлений вживую. Заранее записанные песни и передачи тоже могут идти в общей последовательности станции.

Потоковый сервер принимает эту последовательность и обслуживает подключения плееров. В Icecast конкретный поток обозначается адресом, называемым mountpoint, или точкой подключения. Он может выглядеть как /stream.ogg, но похожее на файл имя само по себе не означает наличие законченной записи. На одном сервере могут быть несколько точек: с разными программами или разными вариантами одной программы. ^[1]

На последнем участке плеер получает данные и воспроизводит звук. Между созданием звука и его прослушиванием есть промежуточная обработка и получение данных. При HLS плеер читает плейлист — текстовый перечень адресов и параметров медиасегментов, то есть последовательных частей программы. Затем получает эти части и обновляет плейлист, чтобы обнаружить продолжение. ^[3] Название протокола не означает, что программа слышна без задержки.

Для учебной станции важно ещё одно разделение: звук в студии, сигнал, принятый эфирным радиоприёмником, и интернет-поток — разные точки наблюдения. Допустим, местное объявление добавляют после точки, из которой берётся звук для интернета. Тогда оно прозвучит в эфирном тракте, но не попадёт в сетевой поток. Проверка интернет-соединения это не исправит: сначала нужно найти точку подачи программы. Это условная схема, а не утверждение об устройстве конкретной станции.

Поток, файл и подкаст

Различие касается прежде всего того, что выбирает пользователь. В линейном потоке он подключается к общей последовательности станции. В архиве он выбирает конкретный выпуск. Если запись интервью запущена в программе в полдень, слушатель, подключившийся позже, не обязательно получит её с начала; отдельная ссылка на запись решает другую задачу. ^[2]

Подкаст тоже может воспроизводиться потоково. Например, Apple Podcasts требует для эпизодов в RSS — ленте со сведениями о выпусках — отдельные адреса файлов и поддерживает их потоковое воспроизведение. ^[6] Следовательно, противопоставление «поток или подкаст» только по способу загрузки неверно. В радиопотоке важна общая текущая программа, а в этом примере подкаста — выбранный эпизод с собственным адресом. Файл, в свою очередь, может быть источником материала для обеих схем. ^{[2, 6]}

Виды и классификации

Для работы редакции удобно различать потоки по содержанию. Это предложенная здесь классификация задач, а не отраслевой стандарт.

Техническую классификацию следует держать отдельно. Документация Icecast описывает подключение источника и слушателей к точке потока; RFC 8216 — доставку сегментов по плейлистам. ^{[1, 3]} Содержание и способ доставки не определяют друг друга: отдельная сетевая программа не обязана использовать особый протокол. При проектировании полезно сначала описать программу для слушателя, а затем выбрать совместимую цепочку доставки.

Как применяется на практике

В мировой технической практике описанные подходы представлены документацией открытого проекта Icecast и протоколом HLS. ^{[1, 2, 3]} Для российского проекта можно разобрать такую же цепочку, отдельно учитывая применимое право. ^{[7, 8]} Ниже приведён учебный пример региональной станции, а не сведения о распространённости технологий на российском рынке.

Задание инженеру формулируют через ожидаемый результат: в плеере должны звучать городской выпуск новостей и местные рекламные вставки. Слова «подключить радио» слишком неопределённы: по ним нельзя понять, подходит ли федеральная версия программы. Для приёмки команда выбирает узнаваемую фразу из собственного выпуска и отмечает её в студийном выходе, эфирном приёмнике и сетевом плеере.

Если эфирный приёмник и сайт передают разные объявления, команда сравнивает источники программы. Если объявления совпали, но в плеере одно пришло позже, исследуется задержка. Если сайт открылся, а звука нет, проверяется запуск воспроизведения. Эти три результата описывают разные неисправности; одно сообщение «трансляция не работает» скрывает нужную для исправления информацию.

Для браузерного плеера предусмотрен ручной запуск. Chrome описывает условия, при которых автозапуск со звуком разрешается, и рекомендует проверять результат вызова play(), запускающего медиа, прежде чем показывать состояние воспроизведения. ^[4] MDN дополнительно объясняет, что детали ограничений различаются между браузерами. ^[5] Поэтому проверка на компьютере редактора, который часто посещает сайт, не заменяет проверку первого посещения.

В учебной приёмке один участник открывает страницу впервые и нажимает «Слушать», второй повторяет проверку на другом устройстве. Они записывают время нажатия, появления звука и название услышанного выпуска. При отказе сохраняют показанное сообщение и условия подключения. Такой протокол полезнее обещания «проверено в браузере»: по нему другой специалист сможет повторить тот же маршрут и увидеть, где результаты расходятся.

Как измерить или проверить

Нужно различать время запуска и задержку программы. Первое — интервал от нажатия кнопки до начала звука. Второе — разница между появлением одного события в выбранной исходной точке и в проверяемом плеере. Это операционные определения для предлагаемой редакцией проверки: в отчёте их фиксируют до измерения, чтобы не сравнивать разные величины.

Учебный пример: наблюдатели используют согласованные часы и отмечают начало одной и той же тестовой фразы. Отдельно они записывают нажатие кнопки и первый слышимый звук после него. Получился такой журнал:

Задержка тестовой фразы равна 12 − 0 = 12 секундам. Время запуска равно 10 − 9 = 1 секунде: отсчёт заканчивается при первом звуке, а не при тестовой фразе. Интервал 12 − 9 = 3 секунды показывает ожидание именно этой фразы после нажатия. Если отметку первого звука потерять, время запуска по оставшимся трём событиям определить нельзя. Оно совпало бы с тремя секундами лишь при дополнительном условии: тестовая фраза была первым звуком после нажатия.

Замер повторяют в указанных условиях, сохраняя все четыре отметки и точку исходного наблюдения. Для измерения запуска выбирают участок с непрерывно слышимым звуком: иначе пауза в самой программе попадёт во время ожидания первого звука. Если часы устройств расходятся на две секунды, результат тоже содержит эту неопределённость. Для учебного контроля удобнее общий источник времени или запись двух сигналов в одной системе. В HLS тег EXT-X-PROGRAM-DATE-TIME связывает первый отсчёт сегмента с абсолютным временем, но сам по себе не является отметкой момента прослушивания. ^[3]

Битрейт и нагрузка

Битрейт — количество передаваемых битов в секунду; в статистике Icecast для аудио предусмотрены значения в битах и килобитах в секунду. ^[12] Для учебной оценки примем постоянный битрейт одного подключения и прямую раздачу каждому слушательскому подключению с одного сервера. Тогда скорость передачи полезных аудиоданных равна сумме скоростей этих подключений:

R = b × N.

Здесь b — битрейт одного подключения, N — число одновременно обслуживаемых подключений, R — их суммарная скорость. В примере используются десятичные единицы: килобит равен тысяче битов, мегабит — миллиону битов. При 128 кбит/с и 100 подключениях получаем 12 800 кбит/с, или 12,8 Мбит/с. Это расчёт по заданным условиям, без служебных данных протокола и повторных передач.

Если все сто подключений работают ровно час с тем же постоянным битрейтом, объём полезных данных составляет 5,76 ГБ. Получаем его умножением 12,8 миллиона битов в секунду на 3600 секунд и делением на восемь битов в байте, затем на миллиард байтов в десятичном гигабайте. Это не 5,76 гигабит и не оценка дискового архива станции.

Расчёт отвечает на вопрос о передаваемом объёме в заданной модели. Он не доказывает, что канал с указанной номинальной скоростью выдержит нагрузку, что звук устроит слушателя или что сто подключений принадлежат ста разным людям. При изменяющемся числе подключений нельзя умножать пиковое значение на весь месяц и выдавать результат за измеренный трафик. Сначала нужен журнал нагрузки либо фактический счётчик байтов.

Icecast различает число активных слушательских подключений listeners и накопленное число подключений listener_connections. Общий счётчик client_connections включает также другие обращения, например к административным функциям. Статистика отдельного источника имеет собственную границу отсчёта и сбрасывается при его переподключении. ^[12] Поэтому до сравнения отчётов нужно выяснить, какой счётчик прочитан и за какой интервал он накоплен.

Ошибки, ограничения и спорные вопросы

Одна ошибка — считать работающую серверную страницу доказательством слышимого звука. В учебном примере источник может передавать тишину, а плеер успешно получать данные. Проверка доступности должна дополняться прослушиванием ожидаемой программы. И наоборот, отказ автозапуска не означает, что источник оборван: браузер может ждать действия пользователя. ^{[4, 5]}

Другая ошибка — обещать одинаковую задержку всем слушателям. Даже в одном учебном испытании два плеера могут показать разные результаты; в отчёте требуется сохранить различие, а не выбрать более красивое число. Важны конкретный маршрут, время и условия измерения. Результат приёмки «три проверенных запуска успешны» уже, но точнее, чем утверждение об исправности у всей аудитории.

Наконец, текущая доставка и сохранение передач решают разные задачи. У HLS плейлист текущей программы может обновляться с удалением старых сегментов из списка. ^[3] Наличие сегментов во время трансляции не следует принимать за обещание доступности выпуска через месяц. Отдельно задают, где хранится запись, как её найти и какой срок хранения требуется. Для российских редакций соответствующая обязанность предусмотрена статьёй 34 закона о СМИ. ^[8]

Правовой аспект

Статья 1270 ГК РФ в действующей редакции части IV от 23.07.2025, с изменениями, вступившими в силу 04.01.2026, различает способы использования произведения: в частности, воспроизведение, сообщение в эфир, сообщение по кабелю и доступ из любого места в любое время по выбору лица. ^[7] Последнее описание нельзя автоматически приравнивать к любой линейной интернет-трансляции: для правовой квалификации нужны фактическая схема использования и условия договоров.

Разрешение для одного способа нельзя без анализа считать разрешением для всех остальных. Работающий сервер не отвечает на эти вопросы. Эта статья объясняет техническую схему и не даёт заключения о правах конкретной станции. ^[7]

Статья 34 закона о СМИ в редакции от 26.06.2026 требует сохранять материалы собственных передач, вышедших в эфир в записи, и вести регистрационный журнал передач. Поэтому плеер текущего потока не заменяет процесс хранения. ^[8] Применимость норм и договоров к конкретной станции требует проверки юристом.

Частые вопросы

Связанные термины