Трансляции Служб мультимедиа

  • Статья

Логотип Служб мультимедиа версии 3

Предупреждение

Поддержка Служб мультимедиа Azure будет прекращена 30 июня 2024 г. Дополнительные сведения см. в руководстве по прекращению поддержки AMS.

Службы мультимедиа Azure позволяют вам предоставлять клиентам события потоковой трансляции в облаке Azure.

Совет

При миграции из API Служб мультимедиа версии 2 сущность трансляции заменяет Channel в версии 2, а динамические выходные данные заменяют программу.

Трансляции

Трансляции приема и обработки потоков видеотрансляции. При создании трансляции создается конечная точка приема. Конечная точка приема принимает динамический сигнал от удаленного кодировщика. Удаленный динамический кодировщик отправляет веб-канал во входную конечную точку с помощью входного протокола RTMP или Smooth Streaming (фрагментированный MP4). Для протокола приема RTMP содержимое может быть отправлено в виде открытого (rtmp://) или безопасно зашифрованного канала передачи (rtmps://). Для протокола приема Smooth Streaming поддерживаются следующие схемы URL-адресов: http:// или https://.

По умолчанию выделяется 5 трансляций на учетную запись Служб мультимедиа. Если вы хотите увеличить это ограничение, отправьте запрос в службу поддержки на портале Azure.

Типы событий, связанных с прямой трансляцией

Для трансляции можно задать базовое или стандартное сквозное или динамическое кодирование. Типы задаются во время создания с помощью типа кодирования динамических событий.

  • Базовый сквозной режим. Локальный динамический кодировщик отправляет поток с несколькими скоростями. Базовая сквозная передача ограничена максимальным входящим трафиком 5 Мбит/с, окно DVR составляет 8 часов, а динамическое транскрибирование не поддерживается.
  • Стандарт сквозной передачи. Локальный динамический кодировщик отправляет поток с несколькими скоростями. Стандартная сквозная передача имеет более высокие ограничения для входящего трафика, 25-часовое окно DVR и поддержку динамического транскрибирования.
  • Стандартный. Локальный динамический кодировщик отправляет поток с одной скоростью в трансляцию, а Службы мультимедиа создают несколько потоков скорости. Если веб-канал передачи имеет разрешение 720p или более, предустановка Default720p закодирует поток из 6 пар "разрешение и скорость".
  • Premium 1080p: локальный динамический кодировщик отправляет поток с одной скоростью в трансляцию, а Службы мультимедиа создают несколько потоков скорости. Предустановка Default1080p задает выходной набор пар "разрешение и скорость".

Примечание

Максимальная частота кадров составляет 30 кадров/с для кодирования уровня "Стандартный" и "Премиум".

Трансляция сквозной передачи

При использовании базового или стандартного сквозного трансляции локальный динамический кодировщик используется для создания видеопотока с несколькими скоростями и отправки его в трансляцию (по протоколу RTMP или fragmented-MP4). Затем трансляция передается во входящие видеопотоки без какой-либо дальнейшей обработки. Трансляция со сквозной передачей оптимизирована для длительных трансляций или непрерывной ежедневной круглосуточной линейной потоковой трансляции. Создавая трансляцию такого типа, укажите базовую ("basic") или стандартную ("standard") сквозную передачу.

Вы можете отправлять канал в разрешениях до 4K и с частотой кадров 60 кадров в секунду с помощью видеокодеков H.264/AVC или H.265/HEVC (только для приема Smooth) и аудиокодека AAC (AAC-LC, HE-AACv1 или HE-AACv2). Дополнительные сведения см. в статье Сравнение типов трансляции.

Примечание

Использование сквозного метода — это самый экономичный способ выполнения потоковой трансляции при передаче нескольких трансляций в течение длительного периода времени, когда вами уже были вложены средства в локальные кодировщики. См. сведения о расценках.

Трансляция кодирования в реальном времени

При использовании динамического кодирования вы настраиваете локальный динамический кодировщик для отправки видео с одной скоростью в трансляцию (по протоколу RTMP или Fragmented-Mp4). Затем вы настраиваете трансляцию таким образом, чтобы оно закодировали входящий односкоростной поток в видеопоток с несколькими скоростями. Это делает выходные данные доступными для доставки устройств воспроизведения с помощью таких протоколов, как MPEG-DASH, HLS и Smooth Streaming.

В этом случае вы можете отправлять канал вкладов только в разрешениях до 1080p с частотой кадров 30 кадров в секунду с помощью видеокодека H.264/AVC и аудиокодека AAC (AAC-LC, HE-AACv1 или HE-AACv2). Дополнительные сведения см. в статье Сравнение типов трансляции.

Параметры потоковой передачи HLS и DASH с низкой задержкой

Дополнительные сведения о том, как достичь низкой задержки с помощью кодирования трансляций, см. в разделе Параметры потоковой передачи с низкой задержкой HLS (LL-HLS) и DASH и рекомендации по потоковой трансляции.

Разрешение и скорость вывода кодирования в реальном времени

Разрешения и скорости в выходных данных динамического кодировщика определяются предустановкой:

  • При использовании динамического кодировщика Standard предустановка Default720p задает набор из шести пар разрешения и скорости, начиная с 720p на 3,5 Мбит/с до 192p при 200 Кбит/с.
  • При использовании динамического кодировщика Premium1080p предустановка Default1080p задает набор из шести пар разрешения и скорости передачи, начиная с 1080p на 3,5 Мбит/с до 180p при 200 Кбит/с.

Дополнительные сведения см. в разделе о системных предустановках.

Примечание

Если вам нужно настроить предустановки для динамического кодирования, отправьте запрос в службу поддержки через портал Azure. Следует указать нужную таблицу с разрешениями видеоданных и скоростями видео- и аудиоданных. Убедитесь, что для видео имеется только один слой 720p и не более 6 слоев. Для звука можно настроить следующие дискретные скорости AAC (96k, 112k, 128k, 160k, 192k, 224k, 256k, 320k, 384k, 448k, 512k). Можно использовать несколько звуковых дорожек с разными скоростями, которые можно включить в настраиваемую предустановку. Кроме того, укажите, что вы запрашиваете пользовательскую предустановку в запросе в службу поддержки.

Ознакомьтесь с REST API для LiveEventEncodingType или пакетами SDK для .Net, Node.JS или Python . Кроме того, можно попробовать пример кода трансляции.

Параметры трансляции

При создании трансляции можно указать следующие варианты.

  • Имя и описание.
  • Для кодировки "Стандартный" и "Премиум" можно выбрать режим растяжения закодированного видео:
    • Нет. Строго учитывает разрешение выходных данных, указанное в предустановке кодирования, без учета пропорций пикселей или пропорций отображения входного видео.
    • AutoSize: переопределяет разрешение выходных данных и изменяет его в соответствии с пропорциями входных данных без заполнения. Например, если разрешение исходного видео составляет 1920×1080, а в предустановках кодирования задано 1280×1280, предустановленное значение будет изменено, а разрешение выходного видео составит 1280×720, что соответствует пропорциям входного видео, равным 16:9.
    • Автоподбор: заполняет выходные данные (с помощью поля "Буквы" или "Столбик") для учета разрешения выходных данных, гарантируя, что активная область видео в выходных данных имеет то же соотношение сторон, что и входные данные. Например, если входные данные составляют 1920×1080, а предустановка требует 1280×1280, тогда выходные данные будут иметь разрешение 1280×1280, при котором внутренний прямоугольник будет иметь разрешение 1280×720 с отношением сторон экрана в 16:9 и вертикальными неактивными областями экрана шириной в 280 пикселей слева и справа.
  • Протокол потоковой передачи RTMP или Smooth Streaming. Примечание. Вы не можете изменить параметр протокола во время трансляции или связанных с ним выходных данных. Если требуются другие протоколы, создайте отдельную трансляцию для каждого протокола потоковой передачи.
  • Входной идентификатор , который является глобально уникальным идентификатором для потока входных данных трансляции.
  • Статический префикс имени узла , который не содержит ни одного (в этом случае используется случайная шестнадцатеричная строка 128 бит), use live event name или Use custom name. Если решено использовать имя клиента, это значение является префиксом пользовательского имени узла.
  • Интервал входного ключевого кадра, который представляет собой длительность (в секундах) каждого сегмента мультимедиа в выходных данных HLS. Значение должно быть ненулевым целым числом в диапазоне от 0,5 до 20 секунд. Значение по умолчанию равно 2 секундам, если не задан ни один из интервалов входного или выходного ключевого кадра. Интервал ключевых кадров допустим только при сквозной передаче событий.
  • Автозапуск. Если для автозапуска задано значение true, трансляция будет запущена после создания. Оплата начисляется сразу же после запуска трансляции. Чтобы остановить дальнейшее выставление счетов, необходимо явно остановить трансляцию. Кроме того, событие можно запустить, когда все готово для начала потоковой передачи.
  • Ограничения IP-адресов для приема и предварительного просмотра. Можно задать IP-адреса, с которых разрешено принимать видео в поток трансляции. Можно указать отдельный допустимый IP-адрес (например, 10.0.0.1), или диапазон IP-адресов, используя IP-адрес и маску подсети CIDR (например, 10.0.0.1/22), или IP-адрес и маску подсети с точками (например, 10.0.0.1(255.255.252.0)).
  • Динамическое транскрибирование , которое по умолчанию отключено. Дополнительные сведения о расшифровке трансляции см. в статье Расшифровка трансляции.

Режим ожидания

При создании трансляции его можно перевести в режим ожидания. Пока событие находится в режиме StandBy, вы можете изменить описание и префикс статического имени узла, а также ограничить параметры входного и предварительного просмотра. Режим ожидания все равно подлежит оплате, но тарификация отличается от той, которая используется при запуске прямой трансляции.

Дополнительные сведения см. в статье Состояния трансляции и выставление счетов.

Выходные данные трансляции

После настройки потока из локального кодировщика в трансляцию можно начать потоковое событие, создав ресурс, выходные данные и указатель потоковой передачи. Выходные данные потоковой трансляции запустят архивирование потока и предложат его зрителям через Конечную точку потоковой передачи.

Вопросы о выходных данных трансляции

См. вопросы, заданные во время трансляции в разделе «Часто задаваемые вопросы». Сведения о квотах на трансляции см. в разделе о квотах и ограничениях.

Дополнительные сведения о настройке трансляций

Правила именования

  • Максимальная длина имени трансляции — 32 символа.
  • Имя должно задаваться в соответствии с данным регулярным выражением по шаблону ^[a-zA-Z0-9]+(-*[a-zA-Z0-9])*$.

См. также Соглашения об именовании конечных точек потоковой передачи.

Совет

Чтобы гарантировать уникальность имени трансляции, можно создать идентификатор GUID, а затем удалить все дефисы и фигурные скобки (если они есть). Строка будет уникальной для всех трансляций, а ее длина гарантированно будет составлять 32 символа.

URL-адреса приема трансляции

После создания события трансляции можно получить URL-адреса приема, которые необходимо передать локальному динамическому кодировщику. Он использует эти адреса для передачи потоковой трансляции. Дополнительные сведения см. в статье о рекомендуемых локальных динамических кодировщиках.

Примечание

Начиная с версии API 2020-05-01, "запоминающиеся" URL-адреса известны как статические имена узлов (useStaticHostname: true).

Примечание

Чтобы URL-адрес приема был статическим и прогнозируемым для использования в настройках аппаратного кодировщика, присвойте свойству useStaticHostname значение true и задавайте каждому свойству accessToken одинаковый идентификатор GUID при каждом создании.

  • Нестатическое имя узла

    По умолчанию в Службах мультимедиа версии 3 при создании LiveEventиспользуется нестатическое имя узла. Можно немного быстрее выделять адрес для трансляции, но URL-адрес приема, который требуется для аппаратного или программного кодирования в реальном времени, будет случайным. URL-адрес изменится, если остановить и вновь запустить трансляцию. Нестатические имена узлов полезны только в сценариях, где конечному пользователю требуется выполнить потоковую передачу с помощью приложения, которое должно очень быстро получить ресурс для трансляции, когда получение динамического URL-адреса приема не является проблемой.

    Если клиентскому приложению не требуется предварительно создавать URL-адрес приема перед созданием трансляции, Служба мультимедиа самостоятельно автоматически создаст маркер доступа для трансляции.

  • Статические имена узлов

    Режим статического имени узла предпочтительнее для большинства операторов, которым требуется предварительная настройка аппаратного или программного обеспечения для кодирования в реальном времени с помощью URL-адреса приема по протоколу RTMP, который никогда не изменяется при создании или отключении и повторном запуске конкретной трансляции. Этим операторам нужен прогнозируемый URL-адрес приема по протоколу RTMP, который не изменяется со временем. Это также весьма разумно, если необходимо отправить статический URL-адрес приема по RTMP в параметры конфигурации аппаратного устройства кодирования, такого как BlackMagic Atem Mini Pro или аналогичного аппаратного устройства кодирования и производственных средств.

    Примечание

    На портале Azure статический URL-адрес имени узла называется "Статический префикс имени узла".

    Чтобы установить этот режим в API, задайте значение useStaticHostName равным true во время создания, (по умолчанию его значение false). Если значение параметра useStaticHostname равно true, тогда hostnamePrefix задает первую часть имени узла, назначенную предварительному просмотру трансляции и принимающим конечным точкам. Последняя часть имени узла представляет собой сочетание этого префикса, имя учетной записи службы мультимедиа и короткий код для центра обработки данных Службы мультимедиа Azure.

    Чтобы избежать случайного токена в URL-адресе, необходимо также передать собственный токен доступа (LiveEventInput.accessToken) во время создания. Токен доступа должен являться допустимой строкой GUID (с дефисами или без них). После задания режима его нельзя обновить.

    Маркер доступа должен быть уникальным для региона Azure и учетной записи Служб мультимедиа. Если приложению требуется URL-адрес, принимающий статическое имя узла, рекомендуется всегда создавать новый экземпляр GUID для использования с определенной комбинацией региона, учетной записи Служб мультимедиа и трансляции.

    Используйте следующие API-интерфейсы, чтобы включить статическое имя узла для URL-адреса и задать токен доступа для допустимого идентификатора GUID (например, "accessToken": "1fce2e4b-fb15-4718-8adc-68c6eb4c26a7").

    Язык Включить URL-адрес статического имени узла Задание маркера доступа.
    REST properties.useStaticHostname LiveEventInput.useStaticHostname
    CLI --use-static-hostname --access-token
    .NET LiveEvent.useStaticHostname LiveEventInput.AccessToken

Правила именования URL-адресов динамического приема

  • Случайная строка ниже представляет собой 128-разрядное шестнадцатеричное число (состоящее из 32 знаков: 0–9 и a–f).
  • маркер доступа: допустимая строка GUID, задаваемая при использовании статического параметра имени узла. Например, "1fce2e4b-fb15-4718-8adc-68c6eb4c26a7".
  • имя потока: указывает имя потока для конкретного соединения. Значение имени потока обычно добавляется используемым динамическим кодировщиком. Можно настроить динамический кодировщик для использования любого имени, описывающее соединение, например: "video1_audio1", "video2_audio1", "stream".

Предупреждение

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

URL-адрес приема нестатического имени узла

RTMP

rtmp://<random 128bit hex string>.channel.media.azure.net:1935/live/<auto-generated access token>/<stream name>
rtmp://<random 128bit hex string>.channel.media.azure.net:1936/live/<auto-generated access token>/<stream name>
rtmps://<random 128bit hex string>.channel.media.azure.net:2935/live/<auto-generated access token>/<stream name>
rtmps://<random 128bit hex string>.channel.media.azure.net:2936/live/<auto-generated access token>/<stream name>

Потоковая передача Smooth Streaming

http://<random 128bit hex string>.channel.media.azure.net/<auto-generated access token>/ingest.isml/streams(<stream name>)
https://<random 128bit hex string>.channel.media.azure.net/<auto-generated access token>/ingest.isml/streams(<stream name>)

URL-адрес приема статического имени узла

В следующих действиях <live-event-name> означает либо имя, присвоенное событию, либо пользовательское имя, используемое при создании трансляции.

RTMP

rtmp://<live event name>-<ams account name>-<region abbrev name>.channel.media.azure.net:1935/live/<your access token>/<stream name>
rtmp://<live event name>-<ams account name>-<region abbrev name>.channel.media.azure.net:1936/live/<your access token>/<stream name>
rtmps://<live event name>-<ams account name>-<region abbrev name>.channel.media.azure.net:2935/live/<your access token>/<stream name>
rtmps://<live event name>-<ams account name>-<region abbrev name>.channel.media.azure.net:2936/live/<your access token>/<stream name>

Потоковая передача Smooth Streaming

http://<live event name>-<ams account name>-<region abbrev name>.channel.media.azure.net/<your access token>/ingest.isml/streams(<stream name>)
https://<live event name>-<ams account name>-<region abbrev name>.channel.media.azure.net/<your access token>/ingest.isml/streams(<stream name>)

URL-адрес предварительной версии трансляции

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

Важно!

Прежде чем продолжить, убедитесь, что видео правильно передается на URL-адрес предварительного просмотра.

Долгосрочные операции с трансляцией

Дополнительные сведения см. в разделе долгосрочные операции.

Справка и поддержка

Вы можете обратиться к Службам мультимедиа с вопросами или следить за нашими обновлениями одним из следующих способов: