Domande comuni su Servizi multimediali di Azure

Vedere la guida al ritiro di Servizi multimediali di Azure

Ecco un elenco:

• Specifica OpenAPI (Swagger)
• Interfaccia della riga di comando di Azure
• .NET
• Java
• Python
• Node.js
• Go

Non è consigliabile provare a eseguire il wrapping dell'API REST per Servizi multimediali direttamente nel codice della libreria. In questo modo, a scopo di produzione, è necessario implementare la logica di ripetizione dei tentativi completa di Azure Resource Manager e comprendere come gestire le operazioni a esecuzione prolungata nelle API Resource Manager. Gli SDK client per diversi linguaggi, ad esempio .NET, Java, TypeScript, Python e Ruby, gestiscono automaticamente questa funzionalità per ridurre le probabilità di problemi con la logica di ripetizione dei tentativi o le chiamate API non riuscite.

Vedere le pagine degli esempi. Sono disponibili esempi per account, asset, streaming live, streaming VOD, protezione contenuto, codifica, analisi e utilizzo dei giocatori.

Quando si usa la paginazione, è consigliabile usare sempre il collegamento successivo per enumerare la raccolta e non dipendere da una determinata dimensione di pagina. Per informazioni dettagliate ed esempi, vedere Filtro, ordinamento e entità di paging.

Per informazioni sull'uso dell'interfaccia della riga di comando di Azure per associare Servizi multimediali ad Azure Key Vault per crittografare i dati, vedere l'esercitazione Usare una chiave Key Vault per crittografare i dati in un account di Servizi multimediali.

Se si vuole che Servizi multimediali accesi un account di archiviazione quando l'account di archiviazione è configurato per bloccare le richieste da indirizzi IP sconosciuti, seguire la procedura descritta in Accedere all'archiviazione con un'identità gestita di Servizi multimediali.

Vedere Spostamento di un account di Servizi multimediali tra sottoscrizioni.

Vedere Controllo degli accessi in base al ruolo di Azure per gli account di Servizi multimediali.

Servizi multimediali definisce i ruoli predefiniti seguenti:

• Amministratore account di Servizi multimediali
• Operatore multimediale di Servizi multimediali
• Amministratore dei criteri di Servizi multimediali
• Amministratore degli endpoint di streaming di Servizi multimediali
• Amministratore eventi live di Servizi multimediali

Questi ruoli sono dettagliati nel controllo degli accessi in base al ruolo di Azure per gli account di Servizi multimediali.

Questi ruoli possono essere usati per concedere l'accesso con granularità fine a un account di Servizi multimediali. Per consentire l'accesso a un account di Servizi multimediali, è possibile usare il ruolo "Proprietario" o "Collaboratore". Servizi multimediali ha un'API precedente nel percorso di deprecazione che non supporta il controllo di accesso con granularità fine. I clienti che richiedono un controllo di accesso con granularità fine non devono selezionare "Abilitare le API classiche" quando si crea un account di Servizi multimediali usando il portale (o usare la versione API 2020-05-01 se usano l'API per creare account).

È possibile usare le Criteri di Azure predefinite seguenti per bloccare la creazione di account che supportano l'API precedente: gli account di Servizi multimediali di Azure che consentono l'accesso all'API v2 legacy devono essere bloccati - Microsoft Azure

Un asset di Servizi multimediali è un contenitore di account di archiviazione di Azure usato per ogni file video caricato. Ha un identificatore univoco usato con trasformazioni e altre operazioni. Vedere Asset in Servizi multimediali di Azure v3.

Ogni volta che si vuole caricare un file multimediale e fare qualcosa con esso, ad esempio codifica o streaming, si crea un asset per archiviare il file multimediale e i file associati. Gli asset vengono creati automaticamente se si usa il portale di Azure. Se non si usa il portale per caricare i file, è necessario creare prima un asset.

I formati di codifica comuni sono disponibili con Media Services Standard Encoder. Per un elenco di tutti i formati, vedere Formati e codec standard del codificatore.

È possibile creare un processo nella portale di Azure usando l'interfaccia della riga di comando di Azure, REST o uno degli SDK. Vedere gli esempi di Servizi multimediali per la lingua preferita.

Sì. Vedere Codifica con una scala a bitrate generata automaticamente.

Sì. Servizi multimediali può eseguire un'analisi bidirezionale su un video. Può quindi consigliare i migliori set di bitrate adattivi, risoluzioni e impostazioni di codifica in base al contenuto del video.

Sì. Per informazioni dettagliate e collegamenti a un'applicazione di esempio che illustra come caricare un file MP4 a bit singolo con codifica predefinita e generare il manifesto del server (.ism) e il manifesto client (.ismc), vedere la risposta alla domanda "È possibile trasmettere file MP4 esistenti pre-codificati o codificati in un'altra soluzione?" nella sezione relativa alla creazione e al recapito. Tale risposta descrive anche l'impatto sulle prestazioni sull'origine.

Non lo consigliamo. Il contenuto molto breve che è minore di un minuto o due in durata non è ideale per lo streaming di bitrate adattivo. Se si intende trasmettere file molto brevi, è consigliabile pre-codificare il contenuto in un formato facilmente trasmesso usando una singola velocità in bit.

Poiché la maggior parte dei giocatori di bitrate adattivo richiede tempo per bufferare più segmenti di video, nonché tempo per analizzare la larghezza di banda di rete prima di "spostarsi" verso l'alto o verso il basso, è spesso inutile fornire un sacco di bitrate per il contenuto inferiore a 30 secondi. Al momento in cui il lettore blocca l'algoritmo euristico sulla velocità a bit destra per riprodurre in base alle condizioni di rete, il file verrà eseguito in streaming.

Inoltre, alcuni giocatori predefinito per buffering fino a tre segmenti di video. Ogni segmento può essere di due-sei secondi di lunghezza. Per i video in formato molto breve, il lettore è probabile che buffer e inizi la riproduzione del primo bitrate selezionato del set di bitrate adattivo. Per questo motivo, è consigliabile usare un file MP4 a bit singolo e caricarlo in un asset se è necessaria la generazione di manifesti HLS o DASH. Per informazioni dettagliate su come ottenere questo risultato, vedere la risposta alla domanda "È possibile trasmettere i file MP4 esistenti pre-codificati o codificati in un'altra soluzione?" nella sezione relativa alla creazione e al recapito.

È necessario distribuire i file in formato HLS o DASH solo se si desidera trarre vantaggio dalle funzionalità di tali protocolli. Per i flussi a bitrate singolo, possono comunque offrire molto, ad esempio il supporto di digital rights management (DRM) e una maggiore difficoltà a scaricare tramite URL (ma ancora possibile!) rispetto a un download progressivo MP4 nell'archiviazione BLOB. Il supporto della didascalia per VTT e IMSC1 è un altro vantaggio. Inoltre, la possibilità di associare in ritardo ulteriori rendering audio o doppiatori in lingue alternative, rende questa scelta preziosa per alcune situazioni.

Se si sta cercando modi per usare un codificatore di Servizi multimediali per eseguire operazioni come ruotare un video, creare video, creare anteprime e sprite, è disponibile un ton di esempi di codice nella pagina Esempi di codice. I linguaggi di esempio disponibili includono Node.JS, Python, .NET e Java.

Un evento live di Servizi multimediali è il processo di inserimento di feed video live e di trasmissione tramite un protocollo RTMPS o Smooth Streaming. Per altre informazioni, vedere Eventi live e output live in Servizi multimediali.

Il primo passaggio consiste nel scegliere un codificatore locale. Sono stati forniti esempi per la creazione di un evento live con Wirecast e OBS. Se si preferisce iniziare con una panoramica degli eventi live di Servizi multimediali, vedere Tipi di eventi live.

Il servizio multimediale di Azure offre video, audio e testo in vari protocolli. Quando si pubblica il live stream usando MPEG-DASH o HLS/CMAF, quindi insieme al video e all'audio, il servizio fornisce il testo trascritto in IMSC1.1 compatibile con TTML. Per altre informazioni, vedere Trascrizione dinamica.

È possibile monitorare gli eventi live sottoscrivendo gli eventi Griglia di eventi di Azure. Per altre informazioni, vedere lo schema degli eventi griglia di eventi. È possibile:

• Sottoscrivere gli eventi Microsoft.Media.LiveEventEncoderDisconnected a livello di flusso e monitorare che nessuna riconnessione viene eseguita per un po' per arrestare ed eliminare l'evento live.
• Sottoscrivere gli eventi heartbeat a livello di traccia. Se tutte le tracce hanno un bitrate in ingresso che scende a 0 o l'ultimo timestamp non aumenta più, è possibile arrestare in modo sicuro l'evento live. Gli eventi heartbeat vengono inclusi ogni 20 secondi per ogni traccia, quindi potrebbe essere un po' dettagliato.

No, non è possibile usare facilmente lo stesso URL di streaming se si arresta e si avvia un evento live. Ogni volta che si crea e si pubblica un nuovo output live (e asset), verrà usato un nuovo URL di streaming (GUID) per il nuovo localizzatore. In questo modo, si è certi che non ci sarà alcun conflitto di cache nell'endpoint di streaming e nella rete di distribuzione del contenuto (CDN). È possibile preparare (e conoscere) gli URL di streaming in anticipo perché è possibile forzare un GUID specifico per il localizzatore di streaming e quindi decidere il nome del manifesto da usare per l'output live.

Si supponga di decidere di usare GUID 1a7ed69e-a361-433d-8a56-29c61872744f per l'output live che verrà creato domani. Quando viene il giorno, si avvia l'evento live e si crea un output live. È possibile decidere di usare "conference1" per il manifesto e forzare il GUID per il localizzatore.

L'URL di streaming è prevedibile ed è http://<youraccountname>-<azureregion>.streaming.media.azure.net/1a7ed69e-a361-433d-8a56-29c61872744f/conference1.ism/manifest.

Non è possibile riutilizzare lo stesso output live o asset più volte. Si consideri la combinazione dell'output live e dell'asset come registrazione nastro. Dopo aver registrato l'output live nell'asset, non è possibile riutilizzarlo per un'altra registrazione. Se si esegue di nuovo questa operazione, si verifica un conflitto BLOB o sovrascrive. A meno che non si prevede di eliminare completamente i BLOB nell'account di archiviazione e di eliminare completamente la rete CDN, ci saranno problemi. Probabilmente ci saranno problemi perché i frammenti sono già memorizzati nella cache downstream nella rete CDN o nella cache dei dispositivi client (ad esempio, la cache del browser).

Uno dei motivi più comuni è che non si ha l'endpoint di streaming da cui si sta tentando di riprodurre nello stato in esecuzione.

In Servizi multimediali un endpoint di streaming rappresenta un servizio di creazione di pacchetti e origine dinamico (just-in-time) che consente di distribuire il contenuto live e su richiesta direttamente a un'app lettore client usando uno dei protocolli di streaming multimediali comuni (HLS o DASH). Inoltre, l'endpoint di streaming fornisce la crittografia dinamica (just-in-time) ai sistemi DRM leader del settore. Per altre informazioni, vedere Endpoint di streaming (origine) in Servizi multimediali di Azure.

Per rendere disponibili i video ai client per la riproduzione, creare un localizzatore di streaming e quindi creare URL di streaming. I localizzatori di streaming vengono usati anche per applicare i criteri di streaming che contengono regole per la modalità di utilizzo dei file multimediali.

Per compilare un URL di streaming, è prima di tutto necessario creare un localizzatore di streaming. Si concatena quindi il nome host dell'endpoint di streaming e il percorso del localizzatore di streaming.

I criteri di streaming consentono di definire protocolli di streaming e opzioni di crittografia per i localizzatori di streaming. Servizi multimediali v3 fornisce alcuni criteri di streaming predefiniti. Per altre informazioni, vedere Criteri di streaming.

Per un elenco di criteri predefiniti che è possibile usare per iniziare, vedere Criteri di streaming.

Assicurarsi di avere (format=m3u8-cmaf) alla fine del percorso (dopo la parte /manifesto dell'URL) per indicare al server di origine di streaming di restituire il contenuto HLS per l'utilizzo nei dispositivi nativi di Apple iOS. Per informazioni dettagliate, vedere Distribuzione di contenuto.

Sì, il server di origine di Servizi multimediali (endpoint di streaming) supporta la creazione dinamica di pacchetti di file MP4 in formato di streaming HLS o DASH. Tuttavia, il contenuto deve essere codificato in formato CLOSED-GOP, con GOP brevi nell'intervallo di durata di due-sei secondi. È consigliabile usare le impostazioni seguenti: goP a due secondi, massima fotogramma chiave e distanza minima di due secondi, codifica a bitrate costante (modalità CBR). La maggior parte del contenuto in questo formato codificato tramite codec video H.264 o HEVC, insieme al formato audio AAC, può essere supportato. Altri formati audio pre-codificati potrebbero essere supportati, ad esempio Dolby DD+.

La chiave per renderla funzionante consiste nel creare un asset, caricare gli asset pre-codificati nel contenitore dell'asset usando sdk client Archiviazione BLOB di Azure e quindi generare il manifesto del server richiesto (con estensione ism) e i file manifesto client. Per informazioni dettagliate, vedere il progetto di esempio .NET nei file MP4 esistenti.

Tenere presente che si verificano implicazioni sulle prestazioni quando si usa questo approccio, poiché il codificatore predefinito in Servizi multimediali genera anche indici binari (file con estensione mpi) che migliorano il tempo di accesso nei file MP4. Senza questi file, il server può usare leggermente più CPU a carico elevato. Per altre informazioni, vedere Streaming di un file MP4 a bitrate singolo esistente con HLS o Dash.

Quando si esegue il ridimensionamento con questo approccio, è necessario monitorare il carico della CPU dell'endpoint di streaming. Se si prevede di passare alla produzione con una grande libreria di file MP4 pre-codificati all'esterno di Servizi multimediali, inviare un ticket di supporto per avere esaminato l'architettura e chiedere modi per migliorare le prestazioni del server di origine del contenuto MP4 pre-codificato.

I localizzatori di streaming creati con l'API v2 continueranno a funzionare dopo la disattivazione dell'API v2. Dopo aver creato i dati del localizzatore di streaming nel database back-end di Servizi multimediali, non esiste alcuna dipendenza dall'API REST v2 per lo streaming. Non verranno rimossi record specifici dal database quando la versione 2 viene disattivata nel febbraio 2024.

Esistono alcune proprietà di asset e localizzatori creati con v2 che non possono essere accessibili o aggiornati usando la nuova API v3. Ad esempio, v2 espone un'API File di asset che non ha una funzionalità equivalente nell'API v3. Spesso questo non è un problema per la maggior parte dei nostri clienti, poiché non è una funzionalità ampiamente usata e puoi comunque trasmettere i vecchi localizzatori ed eliminarli quando non sono più necessari.

Dopo la migrazione, è consigliabile evitare di effettuare chiamate all'API v2 per modificare i localizzatori di streaming o gli asset.

La crittografia dinamica protegge i supporti dal momento in cui lascia il computer attraverso l'archiviazione, l'elaborazione e il recapito. Con Servizi multimediali è possibile distribuire contenuti live e su richiesta crittografati dinamicamente con Advanced Encryption Standard (AES-128) o uno dei tre principali sistemi DRM: Microsoft PlayReady, Google Widevine e Apple FairPlay. Per altre informazioni, vedere Proteggere il contenuto con la crittografia dinamica di Servizi multimediali.

I clienti spesso si chiedono se devono usare la crittografia AES o un sistema DRM. La differenza principale tra i due sistemi è che con la crittografia AES, la chiave di contenuto viene trasmessa al client tramite TLS. La chiave viene crittografata in transito senza alcuna crittografia aggiuntiva ("in chiaro"). Di conseguenza, la chiave usata per decrittografare il contenuto è accessibile al lettore client e può essere visualizzata in una traccia di rete nel client in testo normale. La crittografia con chiave non crittografata AES-128 è adatta nei casi in cui il visualizzatore è attendibile (ad esempio, la crittografia di video aziendali distribuiti all'interno di un'azienda per essere visualizzati dai dipendenti).

I sistemi DRM come PlayReady, Widevine e FairPlay forniscono un livello aggiuntivo di crittografia sulla chiave usata per decrittografare il contenuto, rispetto a una chiave cancellata AES-128. La chiave di contenuto viene crittografata in una chiave protetta dal runtime DRM oltre a qualsiasi crittografia a livello di trasporto fornita da TLS. La decrittografia viene gestita in un ambiente sicuro a livello di sistema operativo, dove è più difficile che un utente malintenzionato attacchi. È consigliabile DRM per i casi d'uso in cui il visualizzatore potrebbe non essere una parte attendibile e è necessario il livello di sicurezza più alto.

Non è necessario usare alcun provider di token specifico, ad esempio Azure Active Directory (Azure AD). È possibile creare il proprio provider JWT (cosiddetto Servizio token sicuro o STS) usando la crittografia della chiave asimmetrica. Nel servizio di sicurezza personalizzato è possibile aggiungere attestazioni in base alla logica di business.

Assicurarsi che l'autorità emittente, il pubblico e le attestazioni corrispondano esattamente tra ciò che è in JWT e il ContentKeyPolicyRestriction valore usato in ContentKeyPolicy.

Per altre informazioni, vedere Proteggere il contenuto usando la crittografia dinamica di Servizi multimediali.

Per l'ambiente di produzione, è necessario disporre del servizio token sicuro, ovvero un servizio Web, che genera un token JWT in base a una richiesta HTTPS. Per il test, è possibile usare il codice visualizzato nel metodo definito in GetTokenAsyncProgram.cs.

Dopo l'autenticazione di un utente, il lettore effettua una richiesta a STS per tale token e lo assegna come valore del token. È possibile usare l'API di Azure Media Player.

Per un esempio di esecuzione di STS con una chiave simmetrica o una chiave asimmetrica, vedere lo strumento JWT. Per un esempio di lettore basato su Azure Media Player che usa un token JWT, vedere lo strumento di test multimediale di Azure. Espandere il collegamento player_settings per visualizzare l'input del token.

L'approccio corretto consiste nell'usare il servizio token sicuro. Nel servizio token di sicurezza, a seconda del profilo utente, aggiungere attestazioni diverse, ad esempio "Utente Premium", "Utente basico" o "Utente di valutazione gratuita". Con diverse attestazioni in un token JWT, l'utente può visualizzare diversi tipi di contenuto. Per contenuti o asset diversi, ContentKeyPolicyRestriction avrà il valore corrispondente RequiredClaims .

Usare le API di Servizi multimediali di Azure per configurare la distribuzione di licenze/chiavi e crittografare gli asset, come illustrato in questo esempio.

Questo comportamento sembra essere predefinito nell'app di esempio. Quando è presente una traccia audio alternativa (che è il caso di HLS) durante la modalità offline, sia iOS 10 che iOS 11 predefinito per la traccia audio alternativa.When an alternate audio track is present (which is the case for HLS) during offline mode, both iOS 10 and iOS 11 default to the alternate audio track. Per compensare questo comportamento in modalità offline FPS, rimuovere la traccia audio alternativa dal flusso. Per eseguire questa operazione in Servizi multimediali, aggiungere il filtro manifesto dinamico solo audio=false. In altre parole, un URL HLS termina con .ism/manifest(format=m3u8-aapl,audio-only=false).

A seconda della progettazione della chiave della cache per la rete per la distribuzione di contenuti, il contenuto potrebbe essere memorizzato nella cache. Ripulire la cache.

La struttura del file scaricato in un dispositivo iOS è simile a quella illustrata nello screenshot seguente. La cartella _keys archivia le licenze FPS scaricate, con un file archiviato per ogni host del servizio licenze. La cartella .movpkg archivia il contenuto audio e video.

La prima cartella con un nome che termina con un trattino seguito da un numero contiene contenuto video. Il valore numerico è la larghezza di banda massima dei rendering video. La seconda cartella con il nome che termina con un trattino seguito da 0 include contenuto audio. La terza cartella denominata Data contiene la playlist master del contenuto FPS. Infine, boot.xml fornisce una descrizione completa del contenuto della cartella .movpkg .

Ecco un file di esempio 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>

Poiché Servizi multimediali v3 consente a un asset di avere più StreamingLocator istanze, è possibile avere:

• Un'istanza ContentKeyPolicy con license_type = "persistent", ContentKeyPolicyRestriction con un'attestazione in "persistent"e la relativa StreamingLocator istanza.
• Un'altra ContentKeyPolicy istanza con license_type="nonpersistent", ContentKeyPolicyRestriction con un'attestazione su "nonpersistent" e la relativa StreamingLocator istanza.
• Due StreamingLocator istanze con valori diversi ContentKey .

In base alla logica di business del servizio token di sicurezza personalizzato, nel token JWT vengono rilasciate diverse attestazioni. Con il token, può essere ottenuta solo la licenza corrispondente e può essere usato solo il relativo URL.

La panoramica dell'architettura DRM Widevine di Google definisce tre livelli di sicurezza. Tuttavia, la documentazione di Servizi multimediali di Azure nel modello di licenza Widevine descrive cinque livelli di sicurezza (requisiti di affidabilità del client per la riproduzione).

Google Widevine definisce entrambi i set di livelli di sicurezza. La differenza è nel livello di utilizzo: architettura o API. I cinque livelli di sicurezza vengono usati nell'API Widevine. Il servizio licenze Widevine di Servizi multimediali di Azure deserializza l'oggetto content_key_specs , che contiene security_levele lo passa al servizio di distribuzione globale Widevine. Nella tabella seguente viene illustrato il mapping tra i due set di livelli di sicurezza.

Usare Monitoraggio di Azure per tenere traccia delle operazioni eseguite con le risorse di Servizi multimediali. Per altre informazioni, vedere Monitorare Servizi multimediali. Le guide sono elencate alla fine della pagina.

Usare Griglia di eventi di Azure per monitorare l'evento live senza un servizio di polling. Vedere Creare e monitorare gli eventi di Servizi multimediali con Griglia di eventi usando il portale di Azure.

Servizi multimediali funziona con molti lettori. Vedi l'elenco dei lettori multimediali compatibili o prova gli esempi di lettore di terze parti.

Per informazioni su Servizi multimediali e disponibilità elevata, vedere Disponibilità elevata con Servizi multimediali e Video on Demand (VOD).

È stata creata una guida completa per la migrazione dalla versione 2 alla versione 3. Siamo interessati a conoscere l'esperienza e le esigenze della migrazione, quindi è possibile fornire commenti e suggerimenti tramite il problema o il ticket di supporto di GitHub.

I codici di errore sono stati documentati nei riferimenti seguenti: Codici di errore dell'endpoint di streaming, Codici di errore degli eventi live e Codici errore del processo. Se non riesci a trovare risposte, crea un ticket di supporto.

È possibile reimpostare le credenziali dell'account usando l'interfaccia della riga di comando di Azure.

Vedere la guida ai prezzi di Servizi multimediali.

Vedere Quote e limiti di Servizi multimediali.

I clienti collegano i propri account di archiviazione agli account di Servizi multimediali di Azure. Tutti i dati degli asset vengono archiviati in questi account di archiviazione associati e il cliente controlla la posizione e il tipo di replica di questa risorsa di archiviazione.

I dati aggiuntivi associati a un account di Servizi multimediali (incluse le chiavi di crittografia del contenuto, le chiavi di verifica del token, gli URL JobInputHttp e altri metadati di entità) vengono archiviati nella risorsa di archiviazione di proprietà di Microsoft all'interno dell'area selezionata per l'account di Servizi multimediali.

A causa dei requisiti di residenza dei dati in Brasile meridionale e Asia sud-orientale, i dati aggiuntivi dell'account vengono archiviati in modo con ridondanza della zona e sono contenuti in una singola area. Per l'Asia sud-orientale, tutti i dati aggiuntivi dell'account vengono archiviati a Singapore. Per il Brasile meridionale, i dati vengono archiviati in Brasile. Nelle aree diverse dal Brasile meridionale e dall'Asia sud-orientale, i dati aggiuntivi dell'account possono essere archiviati anche nella risorsa di archiviazione di proprietà di Microsoft nell'area abbinata.

Servizi multimediali di Azure è un servizio a livello di area e non offre disponibilità elevata o replica dei dati. È consigliabile che i clienti che necessitano di queste funzionalità per creare una soluzione usando gli account di Servizi multimediali in più aree. Un esempio che illustra come creare una soluzione per la disponibilità elevata con video su richiesta di Servizi multimediali è disponibile come guida.