Часто задаваемые вопросы о Службах мультимедиа Azure

См. руководство по прекращению поддержки Служб мультимедиа Azure.

Они представлены ниже:

• Спецификация OpenAPI (Swagger)
• Azure CLI
• .NET
• Java
• Python
• Node.js
• GO

Мы не рекомендуем вам переносить REST API для Служб мультимедиа непосредственно в собственный код библиотеки. Чтобы правильно реализовать такой подход в производственных целях, вам потребуется реализовать полную логику повторных попыток в Azure Resource Manager и понять, как управлять длительными операциями в API Resource Manager. Клиентские пакеты SDK для различных языков, например .NET, Java, TypeScript, Python и Ruby, автоматически обрабатывали такие операции, чтобы снизить вероятность проблем с логикой повторных попыток или неудачными вызовами API.

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

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

Изучите учебник Шифрование данных в Службах мультимедиа с использованием ключа Key Vault, чтобы узнать, как с помощью CLI связать Службы мультимедиа с Key Vault для шифрования данных.

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

См. Перемещение учетной записи Служб мультимедиа между подписками.

Ознакомьтесь с разделом Управление доступом на основе ролей Azure (Azure RBAC) для учетных записей Служб мультимедиа.

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

• Администратор учетной записи Служб мультимедиа
• Оператор мультимедиа Служб мультимедиа
• Администратор политик Служб мультимедиа
• Администратор конечных точек потоковой передачи Служб мультимедиа
• Администратор служб мультимедиа Live Events

Эти роли подробно описаны в статье Управление доступом на основе ролей Azure (Azure RBAC) для учетных записей Служб мультимедиа.

Эти роли можно использовать для предоставления детализированного доступа к учетной записи Служб мультимедиа. Чтобы разрешить полный доступ ко учетной записи Служб мультимедиа, можно использовать роль "Владелец" или "Участник". В Службах мультимедиа есть старый API, который будет объявлен нерекомендуемым. Он не поддерживает детализированное управление доступом. Клиенты, которым требуется детализированное управление доступом, не должны выбирать параметр "Включить классические API" при создании учетной записи Служб мультимедиа на портале (или использовать версию API 2020-05-01, если они используют API для создания учетных записей).

Для блокировки создания учетных записей, поддерживающих старый API, можно использовать следующую встроенную политику Azure: Учетные записи служб мультимедиа Azure, предоставляющие доступ к устаревшей API версии 2, должны блокироваться — Microsoft Azure.

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

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

Кодировщик ценовой категории "Стандартный" Служб мультимедиа поддерживает все популярные форматы кодирования. Полный список форматов см. в статье Форматы и кодеки кодировщика Standard Encoder.

Задание можно создать на портале Azure, используя Azure CLI, REST или любой пакет SDK. Также см. примеры для Служб мультимедиа на предпочтительном для вас языке.

Да. См. Кодирование с помощью автоматически созданной схемы скоростей.

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

Да. Ссылки на пример приложения, в котором показано, как отправить предварительно закодированный файл MP4 с одной скоростью и создать манифест сервера (ISM) и манифест клиента (ISMC) см. в разделе ответов на вопрос о потоковой передаче в разделе "Можно ли выполнить потоковую передачу имеющихся MP4-файлов, закодированных или предварительно закодированных в другом решении?", в подразделе об упаковке и доставке. В этом ответе также описывается влияние на производительность версии origin.

Это не рекомендуемый вариант. Очень краткое содержимое (продолжительностью менее одной-двух минут) не является оптимальным вариантом для потоковой передачи с переменной скоростью. Если планируется потоковая передача файлов в очень короткой форме, мы рекомендуем предварительно кодировать содержимое в формате, который легко передается потоком с одной скоростью.

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

Кроме того, некоторые проигрыватели по умолчанию используют буферизацию до трех сегментов видео. Каждый сегмент может иметь длину от двух до шести секунд. Для очень коротких видео проигрыватель, скорее всего, поместит в буфер и начнет воспроизводить видео с первой скоростью, выбранной в наборе с адаптивной скоростью. По этой причине мы рекомендуем использовать MP4-файл с одной скоростью и отправить его в ресурс, если требуется создать манифест HLS или DASH. Дополнительные сведения о том, как это сделать, см. в разделе ответа на вопрос "Можно ли выполнить потоковую передачу имеющихся MP4-файлов, закодированных или предварительно закодированных в другом решении?", в подразделе об упаковке и доставке.

Если вы хотите воспользоваться преимуществами протоколов HLS или DASH, достаточно передать файлы в этом формате. Для потоков с одной скоростью они по-прежнему способны предложить намного больше, например более быстрый поиск, поддержку управления цифровыми правами (DRM) и повышение сложности загрузки по URL (при этом не устраняется возможность загрузки!), чем поэтапная загрузка MP4 в хранилище BLOB-объектов. Еще одно преимущество — поддержка субтитров для VTT и IMSC1. Кроме того, возможность позднее связать дополнительные звуковые дорожки или дубляж на других языках делает этот вариант очень полезным в некоторых ситуациях.

Если вы хотите использовать кодировщик Служб мультимедиа, чтобы поворачивать видео, создавать подклипы, сшивать видеофрагменты, создавать эскизы и спрайты и т.д., то здесь вы найдете массу примеров кода. Доступны примеры на языках Node.JS, Python, .NET и Java.

Трансляция Служб мультимедиа — это процесс приема видеопотоков и их трансляция по протоколу RTMPS или Smooth Streaming. Дополнительные сведения см. в статье События и записи трансляции в Службах мультимедиа

Первый шаг — выбрать локальный кодировщик. Мы предоставили примеры по созданию трансляции с помощью Wirecast и OBS. Если вы хотите начать с обзора трансляций Служб мультимедиа, см. раздел Типы трансляций.

Службы мультимедиа Azure предоставляют видео, аудио и текст в разных протоколах. Когда вы публикуете трансляцию с помощью MPEG-DASH или HLS/CMAF, вместе с видео и аудио служба отправляет транскрибированный текст на совместимом с IMSC1.1 языке разметки TTML. Дополнительные сведения см. в статье о транскрибировании в реальном времени.

Вы можете отслеживать события в реальном времени, подписавшись на события Сетки событий Azure. Дополнительные сведения см. в статье о схеме событий службы "Сетка событий Azure". Вы можете сделать одно из двух:

• Подпишитесь на события Microsoft.Media.LiveEventEncoderDisconnected на уровне потока и следите за тем, чтобы в течение длительного времени не поступали повторные подключения для остановки и удаления трансляции.
• Подпишитесь на события пульса уровня дорожки. Если входящая скорость всех дорожек упала до 0 или последняя метка времени больше не увеличивается, то можно безопасно завершить трансляцию. События пульса поступают каждые 20 секунд для каждой дорожки, поэтому эти сведения могут быть несколько избыточными.

Нет, если вы останавливаете и возобновляете трансляцию использовать один и тот же URL-адрес потоковой передачи нельзя. При каждых создании и публикации новой записи трансляции (и ресурса) для нового указателя будет использоваться новый URL-адрес потоковой передачи (GUID). Это позволяет гарантировать отсутствие конфликта кэша в конечной точке потоковой передачи и сети доставки содержимого (CDN). Вы можете заранее подготовить (и узнать) URL-адреса потоковой передачи, поскольку имеете возможность принудительно применить конкретный GUID для указателя потоковой передачи, а затем выбрать имя манифеста, который будет использоваться для записи трансляции.

Предположим, вы решили использовать GUID 1a7ed69e-a361-433d-8a56-29c61872744f для записи трансляции, которую вы создадите завтра. Когда приходит соответствующий день, вы запускаете трансляцию и создаете ее запись. Вы можете использовать для манифеста название conference1 и принудительно задать GUID для указателя.

URL-адрес потоковой передачи является прогнозируемым и имеет значение http://<youraccountname>-<azureregion>.streaming.media.azure.net/1a7ed69e-a361-433d-8a56-29c61872744f/conference1.ism/manifest.

Многократно использовать одну и ту же запись трансляции или ресурс нельзя. Воспринимайте сочетание записи трансляции и ресурсов как запись на ленту. После того как запись трансляции будет передана в ресурс, ее нельзя будет повторно использовать для другой записи. При повторном выполнении этого действия произойдет конфликт больших двоичных объектов или перезапись. Это полезно, только если вы планируете полностью очищать большие двоичные объекты в учетной записи хранения и CDN. В ином случае возникнут проблемы. Скорее всего, проблемы все равно возникнут, поскольку фрагменты уже кэшированы в нисходящем направлении в CDN или в кэшах клиентских устройств (например, в кэше браузера).

Чаще всего это вызвано отсутствием конечной точки потоковой передачи, из которой выполняется попытка воспроизведения в состоянии "Выполняется".

В Службах мультимедиа конечная точка потоковой передачи — это служба динамической упаковки (JIT) и исходная служба, которая может доставить содержимое в реальном времени и по запросу непосредственно в клиентское приложение проигрывателя с помощью одного из распространенных протоколов потоковой передачи мультимедиа (HLS или DASH). Кроме того, конечная точка потоковой передачи обеспечивает динамическое (JIT) шифрование для ведущих систем DRM в отрасли. Дополнительные сведения см. в статье Конечные точки потоковой передачи (источник) в Службах мультимедиа Azure.

Чтобы видео стали доступны для воспроизведения в клиентах, необходимо создать указатель потоковой передачи, а затем сформировать URL-адреса потоковой передачи. Указатели потоковой передачи также используются для применений политик потоковой передачи, которые содержат правила по потреблению файлов мультимедиа.

Чтобы создать URL-адрес потоковой передачи, сначала создайте указатель потоковой передачи. Затем вы объединяете имя хоста конечной точки потоковой передачи и путь указателя потоковой передачи.

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

Список предварительно определенных политик для начала работы см. в статье Политики потоковой передачи.

Убедитесь, что в конце пути (после раздела /manifest URL-адреса) добавлена строка (format=m3u8-cmaf), чтобы сообщить серверу-источнику потоковой передачи, чтобы требуется вернуть содержимое HLS на устройствах с Apple iOS. Дополнительные сведения см. в разделе Доставка содержимого.

Да, сервер-источник Служб мультимедиа (конечная точка потоковой передачи) поддерживает динамическую упаковку файлов MP4 в формат потоковой передачи HLS или DASH. Однако содержимое должно быть закодировано в формате закрытой группы GOP с короткими группами GOP в диапазоне длительности от двух до шести секунд. Мы рекомендуем использовать следующие параметры: 2-секундные группы GOP, максимальное и минимальное расстояние между опорными кадрами две секунды, кодирование с постоянной скоростью (режим CBR). Поддерживается большая часть содержимого в этом формате, закодированная с помощью видеокодека H.264 или HEVC со звуком в формате AAC. Кроме того, могут поддерживаться дополнительные предварительно закодированные форматы звука, например Dolby DD+.

Чтобы обеспечить такую поддержку нужно создать ресурс, передать предварительно закодированные ресурсы в контейнер ресурса с помощью клиентских пакетов SDK Хранилища BLOB-объектов Azure, а затем создать требуемый манифест сервера (ISM) и файлы манифеста клиента. Сведения о потоковой передаче имеющихся MP4-файлов см. в примере проекта .NET.

Следует помнить, что при использовании этого подхода возникают проблемы с производительностью, поскольку встроенный кодировщик в Cлужбах мультимедиа также создает двоичные индексы (MPI-файлы), которые улучшают время доступа в файлах MP4. Без этих файлов сервер может использовать немного больше ресурсов ЦП при высокой нагрузке. Дополнительные сведения см. в разделе Потоковая передача существующего MP4-файла с одной скоростью с помощью HLS или Dash.

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

Указатели потоковой передачи, созданные с помощью API версии 2, продолжат работать и после отключения этого программного интерфейса. Если данные указателя потоковой передачи созданы в серверной базе данных Cлужб мультимедиа, потоковая передача не будет зависима от REST API версии 2. Мы не будем удалять записи, относящиеся к версии 2, из базы данных, когда версия 2 перестанет поддерживаться в феврале 2024 г.

Однако есть некоторые свойства ресурсов и указателей, созданные с помощью версии 2, которые не удастся обновить (или к которым не удастся получить доступ) с использованием нового API версии 3. Например, версия 2 предоставляет API-интерфейс для файлов ресурсов, когда в API версии 3 эквивалентной функции нет. Для большинства наших клиентов это не представляет проблемы, поскольку эта возможность не является широко используемой, кроме того, вы все еще сможете передавать старые указатели и удалять их, когда они станут не нужны.

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

Динамическое шифрование позволяет защищать данные мультимедиа, покидающие ваш компьютер, на всех этапах хранения, обработки и доставки. Службы мультимедиа позволяют доставлять в режиме реального времени и по требованию содержимое, зашифрованное динамически с помощью Advanced Encryption Standard (AES-128) или трех основных систем DRM: Microsoft PlayReady, Google Widevine и Apple FairPlay. Дополнительные сведения см. в статье Защита содержимого с помощью динамического шифрования Служб мультимедиа.

Клиенты часто интересуются, следует ли им использовать шифрование AES или систему DRM. Основное различие между этими двумя системами заключается в том, что при шифровании AES ключ содержимого передается клиенту по протоколу TLS. Ключ шифруется при передаче без дополнительного шифрования ("открытым текстом"). В результате ключ, используемый для шифрования содержимого, доступен проигрывателю клиента, и его можно просмотреть в сетевой трассировке на стороне клиента в виде открытого текста. Шифрование незащищенного ключа AES-128 подходит для использования в случаях, когда зритель является доверенным лицом (например, шифрование корпоративного видео, распространяемого внутри компании, для просмотра сотрудниками).

Системы DRM, такие как PlayReady, Widevine и FairPlay, обеспечивают дополнительный уровень шифрования ключа, который используется для расшифровки содержимого, по сравнению с незашифрованным ключом AES-128. Помимо шифрования на транспортном уровне, обеспечиваемом протоколом TLS, ключ содержимого шифруется и защищается средой выполнения DRM. Расшифровка выполняется в защищенной среде на уровне операционной системы, где злоумышленнику труднее атаковать. Мы рекомендуем использовать DRM в случаях, когда зритель может не быть доверенной стороной и вам нужен самый высокий уровень безопасности.

Вам не нужно использовать какой-либо конкретный поставщик маркеров, например Azure Active Directory (Azure AD). Вы можете создать собственный поставщик JWT (так называемая служба токенов безопасности или STS) с использованием шифрования с асимметричным ключом. В своей настраиваемой службе STS вы можете добавлять утверждения на основе бизнес-логики.

Убедитесь, что издатель, аудитория и утверждения полностью совпадают с содержимым JWT и ContentKeyPolicyRestriction значением, используемым в ContentKeyPolicy.

Дополнительные сведения см. в статье Защита содержимого с помощью динамического шифрования Служб мультимедиа.

Для рабочей среды необходимо использовать службу токенов безопасности (веб-службу), которая выдает токен JWT по HTTPS-запросу. Для тестирования можно использовать код, показанный в методе GetTokenAsync, определенном в Program.cs.

После выполнения проверки подлинности пользователя проигрыватель отправляет к службе токенов безопасности запрос на получение такого токена и присваивает его как значение токена. Можно использовать API решения "Проигрыватель мультимедиа Azure".

Пример запуска STS с симметричным или асимметричным ключом приведен в описании инструмента JWT. Пример проигрывателя на основе Проигрывателя мультимедиа Azure, использующего токен JWT, см. в описании инструмента тестирования мультимедиа Azure. (Чтобы увидеть входные данные токена, разверните ссылку player_settings.)

Правильный подход заключается в использовании службы токенов безопасности. В службе токенов безопасности, в зависимости от профиля пользователя, добавьте разные утверждения (например, "Пользователь (ценовая категория "Премиум")", "Пользователь (ценовая категория "Базовый")" или "Пользователь бесплатной пробной версии"). С различными утверждениями в JWT пользователь может видеть разное содержимое. Для другого содержимого или ресурсов ContentKeyPolicyRestriction будет иметь соответствующее значение RequiredClaims.

Используйте API Служб мультимедиа Azure для настройки доставки лицензий и ключей и шифрования ресурсов (как показано в этом примере).

Такое поведение, по-видимому, связано с дизайном примера приложения. При наличии альтернативной звуковой дорожки (как, например, для HLS) в автономном режиме операционные системы iOS 10 и iOS 11 по умолчанию используют альтернативную звуковую дорожку. Чтобы исправить проблемы, вызванные таким поведением в автономном режиме, удалите из потока альтернативную звуковую дорожку. Чтобы сделать это для Служб мультимедиа, добавьте фильтр динамического манифеста audio-only=false. Другими словами, URL-адрес HLS оканчивается на .ism/manifest(format=m3u8-aapl,audio-only=false) .

Содержимое может быть кэшировано в зависимости от структуры ключа кэша сети доставки содержимого (CDN). Очистите кэш.

Структура скачанного файла на устройстве iOS выглядит как на следующем снимке экрана. В папке _keys хранятся скачанные лицензии FPS, один файл хранилища для каждого узла службы лицензий. В папке .movpkg хранится аудио- и видеосодержимое.

Первая папка, имя которой заканчивается дефисом с числами, содержит видеосодержимое. Числовое значение равно значению пиковой пропускной способности для представлений видео. Вторая папка с именем, заканчивающимся тире, за которым следует 0, содержит аудио. Третья папка с именем Данные содержит главный список воспроизведения содержимого FPS. Наконец, boot.xml предоставляет полное описание содержимого папки .movpkg.

Воот пример файла boot.xml:

<?xml version="1.0" encoding="UTF-8"?>
<HLSMoviePackage xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns="http://apple.com/IMG/Schemas/HLSMoviePackage" xsi:schemaLocation="http://apple.com/IMG/Schemas/HLSMoviePackage /System/Library/Schemas/HLSMoviePackage.xsd">
  <Version>1.0</Version>
  <HLSMoviePackageType>PersistedStore</HLSMoviePackageType>
  <Streams>
    <Stream ID="1-4DTFY3A3VDRCNZ53YZ3RJ2NPG2AJHNBD-0" Path="1-4DTFY3A3VDRCNZ53YZ3RJ2NPG2AJHNBD-0" NetworkURL="https://example.streaming.mediaservices.windows.net/e7c76dbb-8e38-44b3-be8c-5c78890c4bb4/MicrosoftElite01.ism/QualityLevels(127000)/Manifest(aac_eng_2_127,format=m3u8-aapl)">
      <Complete>YES</Complete>
    </Stream>
    <Stream ID="0-HC6H5GWC5IU62P4VHE7NWNGO2SZGPKUJ-310656" Path="0-HC6H5GWC5IU62P4VHE7NWNGO2SZGPKUJ-310656" NetworkURL="https://example.streaming.mediaservices.windows.net/e7c76dbb-8e38-44b3-be8c-5c78890c4bb4/MicrosoftElite01.ism/QualityLevels(161000)/Manifest(video,format=m3u8-aapl)">
      <Complete>YES</Complete>
    </Stream>
  </Streams>
  <MasterPlaylist>
    <NetworkURL>https://example.streaming.mediaservices.windows.net/e7c76dbb-8e38-44b3-be8c-5c78890c4bb4/MicrosoftElite01.ism/manifest(format=m3u8-aapl,audio-only=false)</NetworkURL>
  </MasterPlaylist>
  <DataItems Directory="Data">
    <DataItem>
      <ID>CB50F631-8227-477A-BCEC-365BBF12BCC0</ID>
      <Category>Playlist</Category>
      <Name>master.m3u8</Name>
      <DataPath>Playlist-master.m3u8-CB50F631-8227-477A-BCEC-365BBF12BCC0.data</DataPath>
      <Role>Master</Role>
    </DataItem>
  </DataItems>
</HLSMoviePackage>

Так как Службы мультимедиа версии 3 позволяют ресурсу иметь несколько экземпляров StreamingLocator, можно использовать:

• один экземпляр ContentKeyPolicy с license_type = "persistent", ContentKeyPolicyRestriction с утверждением "persistent", а также его экземпляр StreamingLocator;
• другой экземпляр ContentKeyPolicy с license_type="nonpersistent", ContentKeyPolicyRestriction с утверждением "nonpersistent", а также его экземпляр StreamingLocator;
• два экземпляра StreamingLocator с разными значениями ContentKey.

В зависимости от бизнес-логики пользовательской службы маркеров безопасности публикуются разные заявки в маркере JWT. С маркером возможно получить только соответствующие лицензии и воспроизводить только соответствующие URL-адреса.

В документе Google Widevine DRM Architecture Overview (Общие сведения об архитектуре DRM Widevine) определены три уровня безопасности. Однако в документации Служб мультимедиа Azure по шаблону лицензии Widevine описываются пять уровней безопасности (требования к надежности клиента для воспроизведения).

Google Widevine определяет оба набора уровней безопасности. Разница заключается в уровнях использования — это уровень архитектуры или уровень API. В API Widevine используется пять уровней безопасности. Служба лицензий Widevine Служб мультимедиа Azure дессериализует объект content_key_specs, который содержит свойство security_level, и передает его службе глобальной доставки Widevine. В следующей таблице показано соответствие между двумя наборами уровней безопасности.

Отслеживать ресурсы Служб мультимедиа можно с помощью Azure Monitor. Дополнительные сведения см. в статье Мониторинг Служб мультимедиа. Практические руководства указаны в конце страницы.

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

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

Дополнительные сведения о Службах мультимедиа и высоком уровне доступности см. в статье Обеспечение высокого уровня доступности с использованием Служб мультимедиа и видео по запросу (VOD).

Мы создали комплексное руководство по миграции с версии 2 на версию 3. Мы хотим знать, какие у вас потребности и опыт миграции, поэтому просим вас оставить свой отзыв на GitHub или с помощью запроса в службу поддержки.

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

Вы можете сбросить данные для входа учетной записи с помощью Azure CLI.

См. страницу Цены на Службы мультимедиа.

См. статью Квоты и ограничения Служб мультимедиа.

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

Дополнительные данные, связанные с учетной записью Служб мультимедиа (включая ключи шифрования содержимого, ключи проверки маркеров, URL-адреса JobInputHttp и другие метаданные сущностей), хранятся в хранилище корпорации Майкрософт в регионе, выбранном для учетной записи Служб мультимедиа.

В связи с требованиями к месту расположения данных в Южной Бразилии и Юго-Восточной Азии дополнительные данные в учетной записи хранения хранятся с обеспечением избыточности между зонами и остаются в одном регионе. Для Юго-Восточной Азии все дополнительные данные учетных записей хранятся в Сингапуре. А для Южной Бразилии все данные хранятся в Бразилии. В регионах, отличных от Южной Бразилии и Юго-Восточной Азии, дополнительные данные учетной записи также могут храниться в хранилище корпорации Майкрософт, размещенном в парном регионе.

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