Specifica per l'inserimento live di un flusso MP4 frammentato con Servizi multimediali di AzureAzure Media Services fragmented MP4 live ingest specification

Questa specifica descrive il protocollo e il formato per l'inserimento di streaming live basato sul formato MP4 frammentato per Servizi multimediali di Azure.This specification describes the protocol and format for fragmented MP4-based live streaming ingestion for Azure Media Services. Servizi multimediali fornisce un servizio di streaming live che può essere usato dai clienti per lo streaming di eventi live e la trasmissione di contenuti in tempo reale usando Azure come piattaforma cloud.Media Services provides a live streaming service that customers can use to stream live events and broadcast content in real time by using Azure as the cloud platform. Questo documento contiene anche le procedure consigliate per creare meccanismi di inserimento live solidi e altamente ridondanti.This document also discusses best practices for building highly redundant and robust live ingest mechanisms.

1. Nota di conformità1. Conformance notation

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" usate in questo documento devono essere interpretate come descritto nella specifica RFC 2119.The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this document are to be interpreted as they are described in RFC 2119.

2. Diagramma del servizio2. Service diagram

Il diagramma seguente mostra l'architettura di alto livello del servizio di streaming live in Servizi multimediali:The following diagram shows the high-level architecture of the live streaming service in Media Services:

  1. Un codificatore live invia feed live a canali che sono stati creati e di cui è stato effettuato il provisioning tramite Azure Media Services SDK.A live encoder pushes live feeds to channels that are created and provisioned via the Azure Media Services SDK.
  2. In Servizi multimediali la gestione di tutte le funzionalità di live streaming, tra cui inserimento, formattazione, DVR sul cloud, sicurezza, scalabilità e ridondanza, è affidata a canali, programmi ed endpoint di streaming.Channels, programs, and streaming endpoints in Media Services handle all the live streaming functionalities, including ingest, formatting, cloud DVR, security, scalability, and redundancy.
  3. Facoltativamente, i clienti possono scegliere di distribuire un livello di rete CDN di Azure tra l'endpoint di streaming e gli endpoint client.Optionally, customers can choose to deploy an Azure Content Delivery Network layer between the streaming endpoint and the client endpoints.
  4. Gli endpoint client trasmettono dall'endpoint di streaming tramite protocolli di flusso adattivo HTTP.Client endpoints stream from the streaming endpoint by using HTTP Adaptive Streaming protocols. Alcuni esempi includono Microsoft Smooth Streaming, flusso adattivo dinamico su HTTP (DASH o MPEG-DASH) e Apple HTTP Live Streaming (HLS).Examples include Microsoft Smooth Streaming, Dynamic Adaptive Streaming over HTTP (DASH, or MPEG-DASH), and Apple HTTP Live Streaming (HLS).

Flusso di inserimento

3. Formato del flusso di bit: MP4 frammentato ISO 14496-123. Bitstream format – ISO 14496-12 fragmented MP4

Il formato di trasmissione per l'inserimento di streaming live descritto in questo documento si basa sullo standard [ISO 14496-12].The wire format for live streaming ingest discussed in this document is based on [ISO-14496-12]. Per una spiegazione dettagliata del formato MP4 frammentato e delle estensioni disponibili per i file video on demand e l'inserimento di streaming live, vedere [MS-SSTR].For a detailed explanation of fragmented MP4 format and extensions both for video-on-demand files and live streaming ingestion, see [MS-SSTR].

Definizioni del formato di inserimento liveLive ingest format definitions

L'elenco seguente descrive le definizioni di formato speciali applicabili all'inserimento live in Servizi multimediali di Azure:The following list describes special format definitions that apply to live ingest into Azure Media Services:

  1. Le caselle ftyp, Live Server Manifest Box e moov devono (MUST) essere inviate con ogni richiesta (HTTP POST).The ftyp, Live Server Manifest Box, and moov boxes MUST be sent with each request (HTTP POST). Le caselle devono (MUST) essere inviate all'inizio del flusso e ogni volta che il codificatore deve riconnettersi per riprendere l'inserimento del flusso.These boxes MUST be sent at the beginning of the stream and any time the encoder must reconnect to resume stream ingest. Per altre informazioni, vedere la sezione 6 di [1].For more information, see Section 6 in [1].
  2. La sezione 3.3.2 di [1] definisce una casella facoltativa chiamata StreamManifestBox per l'inserimento live.Section 3.3.2 in [1] defines an optional box called StreamManifestBox for live ingest. A causa della logica di routing del bilanciamento del carico di Azure, l'uso di questa casella è deprecato.Due to the routing logic of the Azure load balancer, using this box is deprecated. La casella non deve (SHOULD NOT) essere presente durante l'inserimento in Servizi multimediali.The box SHOULD NOT be present when ingesting into Media Services. Se la casella è presente, Servizi multimediali la ignora automaticamente.If this box is present, Media Services silently ignores it.
  3. La casella TrackFragmentExtendedHeaderBox definita nella sezione 3.2.3.2 di [1] deve (MUST) essere presente per ogni frammento.The TrackFragmentExtendedHeaderBox box defined in 3.2.3.2 in [1] MUST be present for each fragment.
  4. La versione 2 della casella TrackFragmentExtendedHeaderBox dovrebbe (SHOULD) essere usata per generare segmenti multimediali con URL identici in più data center.Version 2 of the TrackFragmentExtendedHeaderBox box SHOULD be used to generate media segments that have identical URLs in multiple datacenters. Il campo di indice del frammento è obbligatorio (REQUIRED) per il failover tra data center di formati di streaming basati su indice, come Apple HTTP Live Streaming (HLS) e MPEG-DASH basato su indice.The fragment index field is REQUIRED for cross-datacenter failover of index-based streaming formats such as Apple HLS and index-based MPEG-DASH. Per abilitare il failover tra data center, l'indice del frammento deve (MUST) essere sincronizzato tra più codificatori e aumentare di un'unità per ogni frammento multimediale successivo, anche in caso di riavvii o errori del codificatore.To enable cross-datacenter failover, the fragment index MUST be synced across multiple encoders and be increased by 1 for each successive media fragment, even across encoder restarts or failures.
  5. La sezione 3.3.6 di [1] definisce una casella chiamata MovieFragmentRandomAccessBox (mfra), che può (MAY) essere inviata al termine dell'inserimento live per indicare al canale la fine del flusso.Section 3.3.6 in [1] defines a box called MovieFragmentRandomAccessBox (mfra) that MAY be sent at the end of live ingestion to indicate end-of-stream (EOS) to the channel. A causa della logica di inserimento di Servizi multimediali, la fine del flusso è deprecata e la casella mfra per l'inserimento live non deve (SHOULD NOT) essere inviata.Due to the ingest logic of Media Services, using EOS is deprecated, and the mfra box for live ingestion SHOULD NOT be sent. Se viene inviata, Servizi multimediali la ignora automaticamente.If sent, Media Services silently ignores it. Per reimpostare lo stato del punto di inserimento, è consigliabile usare la reimpostazione del canale.To reset the state of the ingest point, we recommend that you use Channel Reset. È anche consigliabile usare l'interruzione del programma per terminare una presentazione e un flusso.We also recommend that you use Program Stop to end a presentation and stream.
  6. La durata del frammento MP4 dovrebbe (SHOULD) essere costante, in modo da ridurre le dimensioni dei manifesti client.The MP4 fragment duration SHOULD be constant, to reduce the size of the client manifests. Una durata costante dei frammenti MP4 migliora anche l'approccio euristico di download del client tramite l'uso di tag ripetuti.A constant MP4 fragment duration also improves client download heuristics through the use of repeat tags. La durata può (MAY) variare per compensare frequenze di fotogrammi costituite da valori non interi.The duration MAY fluctuate to compensate for non-integer frame rates.
  7. La durata del frammento MP4 dovrebbe (SHOULD) essere compresa tra 2 e 6 secondi circa.The MP4 fragment duration SHOULD be between approximately 2 and 6 seconds.
  8. I timestamp e gli indici (TrackFragmentExtendedHeaderBox fragment_ absolute_ time e fragment_index) del frammento MP4 dovrebbero (SHOULD) arrivare in ordine crescente.MP4 fragment timestamps and indexes (TrackFragmentExtendedHeaderBox fragment_ absolute_ time and fragment_index) SHOULD arrive in increasing order. Benché Servizi multimediali sia resiliente alla duplicazione di frammenti, ha una capacità limitata di riordinare i frammenti in base alla sequenza temporale dei contenuti multimediali.Although Media Services is resilient to duplicate fragments, it has limited ability to reorder fragments according to the media timeline.

4. Formato del protocollo: HTTP4. Protocol format – HTTP

L'inserimento live basato sul formato ISO MP4 frammentato per Servizi multimediali usa una richiesta HTTP POST standard a esecuzione prolungata per trasmettere al servizio dati multimediali codificati in formato MP4 frammentato.ISO fragmented MP4-based live ingest for Media Services uses a standard long-running HTTP POST request to transmit encoded media data that is packaged in fragmented MP4 format to the service. Ogni richiesta HTTP POST invia un flusso di bit MP4 frammentato completo ("flusso"), iniziando con le caselle di intestazione (caselle ftyp, Live Server Manifest Box e moov) e continuando con una sequenza di frammenti (caselle moof e mdat).Each HTTP POST sends a complete fragmented MP4 bitstream ("stream"), starting from the beginning with header boxes (ftyp, Live Server Manifest Box, and moov boxes), and continuing with a sequence of fragments (moof and mdat boxes). Per la sintassi dell'URL per la richiesta HTTP POST, vedere la sezione 9.2 di [1].For URL syntax for the HTTP POST request, see section 9.2 in [1]. Un esempio di URL POST è:An example of the POST URL is:

http://customer.channel.mediaservices.windows.net/ingest.isml/streams(720p)

RequisitiRequirements

Di seguito sono elencati i requisiti dettagliati:Here are the detailed requirements:

  1. Il codificatore dovrebbe (SHOULD) avviare la trasmissione inviando una richiesta HTTP POST con un "corpo" vuoto (lunghezza del contenuto pari a zero) mediante lo stesso URL di inserimento.The encoder SHOULD start the broadcast by sending an HTTP POST request with an empty “body” (zero content length) by using the same ingestion URL. In questo modo, il codificatore dovrebbe essere in grado di rilevare rapidamente se l'endpoint di inserimento live è valido e se sono necessarie l'autenticazione o altre condizioni.This can help the encoder quickly detect whether the live ingestion endpoint is valid, and if there are any authentication or other conditions required. Per il protocollo HTTP, il server non è in grado di restituire una risposta HTTP finché non viene ricevuta l'intera richiesta, incluso il corpo della richiesta POST.Per HTTP protocol, the server can't send back an HTTP response until the entire request, including the POST body, is received. A causa dell'esecuzione prolungata di un evento live, senza questo passaggio il codificatore potrebbe non essere in grado di rilevare alcun errore finché non viene completato l'invio di tutti i dati.Given the long-running nature of a live event, without this step, the encoder might not be able to detect any error until it finishes sending all the data.
  2. Il codificatore deve (MUST) gestire eventuali errori o problemi di autenticazione a causa di quanto riportato in [1].The encoder MUST handle any errors or authentication challenges because of (1). Se in (1) è stata restituita una risposta 200, continua.If (1) succeeds with a 200 response, continue.
  3. Il codificatore deve (MUST) avviare una nuova richiesta HTTP POST con il flusso MP4 frammentato.The encoder MUST start a new HTTP POST request with the fragmented MP4 stream. Il payload deve (MUST) iniziare con le caselle di intestazione, seguite dai frammenti.The payload MUST start with the header boxes, followed by fragments. Tenere presente che con ogni richiesta devono (MUST) essere inviate le caselle ftyp, Live Server Manifest Box e moov (in questo ordine), anche nel caso in cui il codificatore debba riconnettersi perché la richiesta precedente è stata terminata prima della fine del flusso.Note that the ftyp, Live Server Manifest Box, and moov boxes (in this order) MUST be sent with each request, even if the encoder must reconnect because the previous request was terminated prior to the end of the stream.
  4. Il codificatore deve (MUST) usare la codifica di trasferimento in blocchi per il caricamento, perché non è possibile prevedere la lunghezza dell'intero contenuto dell'evento live.The encoder MUST use chunked transfer encoding for uploading, because it’s impossible to predict the entire content length of the live event.
  5. Al termine dell'evento, dopo aver inviato l'ultimo frammento, il codificatore deve (MUST) terminare normalmente la sequenza di messaggi della codifica di trasferimento in blocchi. La maggior parte degli stack client HTTP gestisce questo aspetto in modo automatico.When the event is over, after sending the last fragment, the encoder MUST gracefully end the chunked transfer encoding message sequence (most HTTP client stacks handle it automatically). Il codificatore deve (MUST) attendere che il servizio restituisca il codice di risposta finale e quindi terminare la connessione.The encoder MUST wait for the service to return the final response code, and then terminate the connection.
  6. Il codificatore non deve (MUST NOT) usare il nomeEvents() come descritto nella sezione 9.2 di [1] per l'inserimento live in Servizi multimediali.The encoder MUST NOT use the Events() noun as described in 9.2 in [1] for live ingestion into Media Services.
  7. Se la richiesta HTTP POST viene terminata o causa un timeout con errore TCP prima della fine del flusso, il codificatore deve (MUST) inviare un'altra richiesta POST usando una nuova connessione, seguendo i requisiti precedenti.If the HTTP POST request terminates or times out with a TCP error prior to the end of the stream, the encoder MUST issue a new POST request by using a new connection, and follow the preceding requirements. Inoltre, il codificatore deve (MUST) inviare di nuovo i due frammenti MP4 precedenti per ogni traccia nel flusso e riprendere senza introdurre discontinuità nella sequenza temporale dei contenuti multimediali.Additionally, the encoder MUST resend the previous two MP4 fragments for each track in the stream, and resume without introducing a discontinuity in the media timeline. L'invio degli ultimi due frammenti MP4 per ogni traccia impedisce eventuali perdite di dati.Resending the last two MP4 fragments for each track ensures that there is no data loss. In altre parole, se un flusso contiene una traccia audio e una tracia video e la richiesta POST corrente non riesce, il codificatore deve riconnettersi e inviare gli ultimi due frammenti per la traccia audio, già correttamente inviati in precedenza, e gli ultimi due frammenti per la traccia video, anch'essi già inviati correttamente, in modo da garantire che non si siano verificate perdite di dati.In other words, if a stream contains both an audio and a video track, and the current POST request fails, the encoder must reconnect and resend the last two fragments for the audio track, which were previously successfully sent, and the last two fragments for the video track, which were previously successfully sent, to ensure that there is no data loss. Il codificatore deve (MUST) mantenere un buffer "anticipato" di frammenti di contenuti, che invia di nuovo quando si riconnette.The encoder MUST maintain a “forward” buffer of media fragments, which it resends when it reconnects.

5. Scala cronologica5. Timescale

[MS-SSTR] descrive l'utilizzo della scala cronologica per SmoothStreamingMedia (sezione 2.2.2.1), StreamElement (sezione 2.2.2.3), StreamFragmentElement (sezione 2.2.2.6) e LiveSMIL (sezione 2.2.7.3.1).[MS-SSTR] describes the usage of timescale for SmoothStreamingMedia (Section 2.2.2.1), StreamElement (Section 2.2.2.3), StreamFragmentElement (Section 2.2.2.6), and LiveSMIL (Section 2.2.7.3.1). Se non è presente un valore di scala cronologica, viene usato il valore predefinito 10.000.000 (10 MHz).If the timescale value is not present, the default value used is 10,000,000 (10 MHz). Benché le specifiche del formato Smooth Streaming non impediscano l'utilizzo di altri valori di scala cronologica, la maggior parte delle implementazioni dei codificatori usa questo valore predefinito (10 MHz) per generare dati di inserimento Smooth Streaming.Although the Smooth Streaming format specification doesn’t block usage of other timescale values, most encoder implementations use this default value (10 MHz) to generate Smooth Streaming ingest data. A causa della funzionalità di creazione dinamica dei pacchetti di Servizi multimediali di Azure , è consigliabile usare un valore di scala cronologica pari a 90 kHz per i flussi video e a 44,1 o 48,1 kHz per i flussi audio.Due to the Azure Media Dynamic Packaging feature, we recommend that you use a 90-KHz timescale for video streams and 44.1 KHz or 48.1 KHz for audio streams. Se vengono usati valori di scala cronologica differenti per flussi diversi, è necessario (MUST) inviare il valore di scala cronologica del livello di flusso.If different timescale values are used for different streams, the stream-level timescale MUST be sent. Per altre informazioni, vedere [MS-SSTR].For more information, see [MS-SSTR].

6. Definizione di "flusso"6. Definition of “stream”

Il flusso è l'unità operativa di base nel processo di inserimento live per la composizione di presentazioni live, la gestione del failover di streaming e gli scenari di ridondanza.Stream is the basic unit of operation in live ingestion for composing live presentations, handling streaming failover, and redundancy scenarios. Il flusso è definito come un flusso di bit MP4 frammentato univoco che può contenere una singola traccia o più tracce.Stream is defined as one unique, fragmented MP4 bitstream that might contain a single track or multiple tracks. Una presentazione live completa può contenere uno o più flussi, a seconda della configurazione dei codificatori live.A full live presentation might contain one or more streams, depending on the configuration of the live encoders. Gli esempi seguenti mostrano varie modalità d'uso dei flussi per comporre una presentazione live completa.The following examples illustrate various options of using streams to compose a full live presentation.

Esempio:Example:

Un cliente vuole creare una presentazione in streaming live che includa le velocità in bit audio/video seguenti:A customer wants to create a live streaming presentation that includes the following audio/video bitrates:

Video: 3000 kbps, 1500 kbps, 750 kbpsVideo – 3000 kbps, 1500 kbps, 750 kbps

Audio: 128 kbpsAudio – 128 kbps

Opzione 1: tutte le tracce in un flussoOption 1: All tracks in one stream

In questo caso, un unico codificatore genera tutte le tracce audio/video e le aggrega in un flusso di bit MP4 frammentato.In this option, a single encoder generates all audio/video tracks, and then bundles them into one fragmented MP4 bitstream. Il flusso di bit MP4 frammentato viene quindi inviato tramite una singola connessione HTTP POST.The fragmented MP4 bitstream is then sent via a single HTTP POST connection. In questo esempio è presente un solo flusso per la presentazione live.In this example, there is only one stream for this live presentation.

Flussi - Una traccia

Opzione 2: ogni traccia in un flusso separatoOption 2: Each track in a separate stream

In questo caso, il codificatore inserisce una traccia in ogni flusso di bit MP4 frammentato e quindi registra tutti i flussi tramite più connessioni HTTP separate.In this option, the encoder puts one track into each fragment MP4 bitstream, and then posts all of the streams over separate HTTP connections. Questa operazione può essere eseguita con uno o più codificatori.This can be done with one encoder or with multiple encoders. Dal punto di vista dell'inserimento live, questa presentazione live è composta da quattro flussi.The live ingestion sees this live presentation as composed of four streams.

Flussi - Tracce separate

Opzione 3: creare un bundle con una traccia audio e la traccia video a velocità in bit più bassa in un flussoOption 3: Bundle audio track with the lowest bitrate video track into one stream

In questo caso, il cliente sceglie di aggregare la traccia audio alla traccia video con la velocità in bit minore in un flusso di bit MP4 frammentato, lasciando le altre due tracce video come flussi separati.In this option, the customer chooses to bundle the audio track with the lowest-bitrate video track in one fragment MP4 bitstream, and leave the other two video tracks as separate streams.

Flussi - Tracce audio e video

RiepilogoSummary

Questo non è un elenco completo di tutte le possibili opzioni di inserimento applicabili all'esempio.This is not an exhaustive list of all possible ingestion options for this example. In realtà, qualsiasi forma di raggruppamento di tracce in flussi è supportata dal processo di inserimento live.As a matter of fact, any grouping of tracks into streams is supported by live ingestion. Clienti e fornitori di codificatori possono scegliere le proprie implementazioni in base alla complessità di progettazione, alla capacità del codificatore e a considerazioni sui livelli di ridondanza e failover.Customers and encoder vendors can choose their own implementations based on engineering complexity, encoder capacity, and redundancy and failover considerations. Tuttavia, nella maggior parte dei casi è presente solo una traccia audio per l'intera presentazione live.However, in most cases, there is only one audio track for the entire live presentation. Di conseguenza, è importante garantire l'integrità del flusso di inserimento che contiene la traccia audio. Questa considerazione determina spesso la scelta di inserire la traccia audio in un flusso indipendente (come nell'opzione 2) o di aggregarla alla traccia video con velocità in bit minore (come nell'opzione 3).So, it’s important to ensure the healthiness of the ingest stream that contains the audio track. This consideration often results in putting the audio track in its own stream (as in Option 2) or bundling it with the lowest-bitrate video track (as in Option 3). Inoltre, per ottenere ridondanza e tolleranza di errore migliori, l'invio della stessa traccia audio in due flussi diversi (opzione 2 con tracce audio ridondanti) o l'aggregazione della traccia audio con almeno due delle tracce video con velocità in bit minore (opzione 3 con audio aggregato in almeno due flussi video) rappresenta la scelta consigliata per l'inserimento live in Servizi multimediali.Also, for better redundancy and fault tolerance, sending the same audio track in two different streams (Option 2 with redundant audio tracks) or bundling the audio track with at least two of the lowest-bitrate video tracks (Option 3 with audio bundled in at least two video streams) is highly recommended for live ingest into Media Services.

7. Failover del servizio7. Service failover

Data la particolare natura del live streaming, un buon livello di supporto per il failover è essenziale per garantire la disponibilità del servizio.Given the nature of live streaming, good failover support is critical for ensuring the availability of the service. Servizi multimediali è progettato per gestire errori di diversi tipi, tra cui errori di rete, errori del server e problemi di archiviazione.Media Services is designed to handle various types of failures, including network errors, server errors, and storage issues. Se usato insieme a una logica di failover adeguata dal lato del codificatore live, i clienti possono ottenere dal cloud un servizio di streaming live estremamente affidabile.When used in conjunction with proper failover logic from the live encoder side, customers can achieve a highly reliable live streaming service from the cloud.

Questa sezione descrive gli scenari di failover del servizio.In this section, we discuss service failover scenarios. In questo caso, l'errore si verifica in un punto qualsiasi all'interno del servizio e si manifesta come errore di rete.In this case, the failure happens somewhere within the service, and it manifests itself as a network error. Di seguito sono riportati alcuni consigli per implementare il codificatore in modo che sia in grado di gestire il failover del servizio:Here are some recommendations for the encoder implementation for handling service failover:

  1. Usare un timeout di 10 secondi per stabilire la connessione TCP.Use a 10-second timeout for establishing the TCP connection. Se un tentativo di stabilire la connessione richiede più di 10 secondi, interrompere l'operazione e riprovare.If an attempt to establish the connection takes longer than 10 seconds, abort the operation and try again.
  2. Usare un timeout breve per inviare i blocchi del messaggio di richiesta HTTP.Use a short timeout for sending the HTTP request message chunks. Se la durata del frammento MP4 di destinazione è N secondi, usare un timeout di invio compreso tra N e 2N secondi. Se, ad esempio, la durata del frammento MP4 è 6 secondi, usare un timeout compreso tra 6 e 12 secondi.If the target MP4 fragment duration is N seconds, use a send timeout between N and 2 N seconds; for example, if the MP4 fragment duration is 6 seconds, use a timeout of 6 to 12 seconds. Se si verifica un timeout, reimpostare la connessione, aprire una nuova connessione e riprendere l'inserimento del flusso con la nuova connessione.If a timeout occurs, reset the connection, open a new connection, and resume stream ingest on the new connection.
  3. Gestire un buffer in sequenza contenente, per ogni traccia, gli ultimi due frammenti completamente inviati al servizio.Maintain a rolling buffer that has the last two fragments for each track that were successfully and completely sent to the service. Se la richiesta HTTP POST per un flusso viene terminata o scade prima della fine del flusso, aprire una nuova connessione e iniziare un'altra richiesta HTTP POST, quindi inviare nuovamente le intestazioni del flusso e gli ultimi due frammenti per ogni traccia e riprendere il flusso senza introdurre una discontinuità nella sequenza temporale dei contenuti.If the HTTP POST request for a stream is terminated or times out prior to the end of the stream, open a new connection and begin another HTTP POST request, resend the stream headers, resend the last two fragments for each track, and resume the stream without introducing a discontinuity in the media timeline. In questo modo, si riduce il rischio di perdita di dati.This reduces the chance of data loss.
  4. È bene che il codificatore NON limiti il numero di tentativi di riconnessione o di ripresa del flusso dopo un errore TCP.We recommend that the encoder does NOT limit the number of retries to establish a connection or resume streaming after a TCP error occurs.
  5. Dopo un errore TCP:After a TCP error:

    a.a. È necessario (MUST) chiudere la connessione corrente e creare una nuova connessione per una nuova richiesta HTTP POST.The current connection MUST be closed, and a new connection MUST be created for a new HTTP POST request.

    b.b. Il nuovo URL per HTTP POST deve (MUST) corrispondere all'URL relativo al POST iniziale.The new HTTP POST URL MUST be the same as the initial POST URL.

    c.c. La nuove richiesta HTTP POST deve (MUST) includere intestazioni di flusso (caselle ftyp, Live Server Manifest Box e moov) identiche alle intestazioni di flusso della richiesta POST iniziale.The new HTTP POST MUST include stream headers (ftyp, Live Server Manifest Box, and moov boxes) that are identical to the stream headers in the initial POST.

    d.d. Gli ultimi due frammenti inviati per ogni traccia devono essere inviati di nuovo e lo streaming deve riprendere senza introdurre discontinuità nella sequenza temporale dei contenuti multimediali.The last two fragments sent for each track must be resent, and streaming must resume without introducing a discontinuity in the media timeline. I timestamp del frammento MP4 devono aumentare costantemente, anche con richieste HTTP POST diverse.The MP4 fragment timestamps must increase continuously, even across HTTP POST requests.

  6. Se i dati non vengono inviati a una velocità adeguata alla durata del frammento MP4, il codificatore dovrebbe (SHOULD) terminare la richiesta HTTP POST.The encoder SHOULD terminate the HTTP POST request if data is not being sent at a rate commensurate with the MP4 fragment duration. Una richiesta HTTP POST che non invia dati può impedire a Servizi multimediali di disconnettersi rapidamente dal codificatore in caso di aggiornamento del servizio.An HTTP POST request that does not send data can prevent Media Services from quickly disconnecting from the encoder in the event of a service update. Per questo motivo, la richiesta HTTP POST per tracce di tipo sparse (segnale dell'annuncio) dovrebbe (SHOULD) avere breve durata e terminare non appena viene inviato il frammento di tipo sparse.For this reason, the HTTP POST for sparse (ad signal) tracks SHOULD be short-lived, terminating as soon as the sparse fragment is sent.

8. Failover del codificatore8. Encoder failover

Il failover del codificatore è il secondo tipo di scenario di failover che deve essere affrontato per la distribuzione di un live streaming end-to-end.Encoder failover is the second type of failover scenario that needs to be addressed for end-to-end live streaming delivery. In questo scenario la condizione di errore avviene sul lato del codificatore.In this scenario, the error condition occurs on the encoder side.

Failover del codificatore

Di seguito è descritto il comportamento previsto in corrispondenza dell'endpoint di inserimento live quando si verifica il failover del codificatore:The following expectations apply from the live ingestion endpoint when encoder failover happens:

  1. Deve (MUST) essere creata una nuova istanza del codificatore per poter proseguire lo streaming, come mostrato nel diagramma (flusso per video a 3000 K con linea tratteggiata).A new encoder instance SHOULD be created to continue streaming, as illustrated in the diagram (Stream for 3000k video, with dashed line).
  2. Il nuovo codificatore deve (MUST) usare per le richieste HTTP POST lo stesso URL dell'istanza non riuscita.The new encoder MUST use the same URL for HTTP POST requests as the failed instance.
  3. La richiesta POST del nuovo codificatore deve (MUST) includere le stesse caselle di intestazione del flusso MP4 frammentato presenti nell'istanza non riuscita.The new encoder’s POST request MUST include the same fragmented MP4 header boxes as the failed instance.
  4. Il nuovo codificatore deve (MUST) essere sincronizzato correttamente con tutti gli altri codificatori in esecuzione per la stessa presentazione live, in modo da generare campioni audio/video sincronizzati con i limiti di frammento allineati.The new encoder MUST be properly synced with all other running encoders for the same live presentation to generate synced audio/video samples with aligned fragment boundaries.
  5. Il nuovo flusso deve (MUST) essere semanticamente equivalente al flusso precedente e intercambiabile a livello di intestazione e di frammento.The new stream MUST be semantically equivalent with the previous stream, and interchangeable at the header and fragment levels.
  6. Il nuovo codificatore deve (MUST) tentare di ridurre al minimo la perdita di dati.The new encoder SHOULD try to minimize data loss. I valori fragment_absolute_time e fragment_index dei frammenti multimediali dovrebbero (SHOULD) aumentare dall'ultimo punto in cui si è interrotto il codificatore.The fragment_absolute_time and fragment_index of media fragments SHOULD increase from the point where the encoder last stopped. I valori fragment_absolute_time e fragment_index dovrebbero (SHOULD) aumentare in modo costante ma, se necessario, è possibile introdurre una discontinuità.The fragment_absolute_time and fragment_index SHOULD increase in a continuous manner, but it is permissible to introduce a discontinuity, if necessary. Poiché Servizi multimediali ignora i frammenti già ricevuti ed elaborati, è preferibile sbagliare inviando di nuovo frammenti già ricevuti piuttosto che introdurre discontinuità nella sequenza temporale dei contenuti.Media Services ignores fragments that it has already received and processed, so it's better to err on the side of resending fragments than to introduce discontinuities in the media timeline.

9. Ridondanza del codificatore9. Encoder redundancy

In caso di eventi live critici che richiedono livelli superiori di disponibilità e qualità dell'esperienza, è consigliabile usare codificatori ridondanti di tipo attivo-attivo per ottenere un failover efficiente senza perdita di dati.For certain critical live events that demand even higher availability and quality of experience, we recommended that you use active-active redundant encoders to achieve seamless failover with no data loss.

Ridondanza del codificatore

Come mostrato in questo diagramma, due gruppi di codificatori inviano contemporaneamente due copie di ogni flusso al servizio live.As illustrated in this diagram, two groups of encoders push two copies of each stream simultaneously into the live service. Questa configurazione è supportata perché Servizi multimediali è in grado di escludere i frammenti duplicati in base all'ID flusso e al timestamp del frammento.This setup is supported because Media Services can filter out duplicate fragments based on stream ID and fragment timestamp. L'archivio e il flusso live risultanti saranno costituiti da un'unica copia di tutti i flussi, ovvero dalla migliore aggregazione possibile a partire dalle due origini.The resulting live stream and archive is a single copy of all the streams that is the best possible aggregation from the two sources. In un ipotetico caso estremo, ad esempio, purché per ogni flusso sia presente un codificatore in esecuzione (non necessariamente lo stesso) in ogni momento, il flusso live risultante dal servizio sarà continuo, senza perdita di dati.For example, in a hypothetical extreme case, as long as there is one encoder (it doesn’t have to be the same one) running at any given point in time for each stream, the resulting live stream from the service is continuous without data loss.

I requisiti per questo scenario sono molto simili a quelli descritti per il failover del codificatore, ad eccezione del fatto che il secondo set di codificatori viene eseguito contemporaneamente ai codificatori primari.The requirements for this scenario are almost the same as the requirements in the "Encoder failover" case, with the exception that the second set of encoders are running at the same time as the primary encoders.

10. Ridondanza del servizio10. Service redundancy

Per una distribuzione globale altamente ridondante, è necessario eseguire un backup tra più aree per poter gestire situazioni di emergenza nelle aree interessate.For highly redundant global distribution, sometimes you must have cross-region backup to handle regional disasters. Estendendo la topologia descritta in "Ridondanza del codificatore", i clienti possono scegliere di distribuire un servizio ridondante in un'area diversa associata al secondo set di codificatori.Expanding on the “Encoder redundancy” topology, customers can choose to have a redundant service deployment in a different region that's connected with the second set of encoders. I clienti possono anche usare un provider di rete CDN per distribuire uno strumento di gestione del traffico globale per le due distribuzioni del servizio, in modo da indirizzare correttamente il traffico client.Customers also can work with a Content Delivery Network provider to deploy a Global Traffic Manager in front of the two service deployments to seamlessly route client traffic. I requisiti per i codificatori sono gli stessi di quelli per il caso di ridondanza del codificatore.The requirements for the encoders are the same as the “Encoder redundancy” case. L'unica eccezione è che il secondo set di codificatori deve puntare a un endpoint di inserimento live diverso.The only exception is that the second set of encoders needs to be pointed to a different live ingest endpoint. Il diagramma seguente mostra questa configurazione:The following diagram shows this setup:

Ridondanza del servizio

11. Tipi speciali di formati di inserimento11. Special types of ingestion formats

Questa sezione descrive alcuni tipi speciali di formati di inserimento live, progettati per gestire scenari specifici.This section discusses special types of live ingestion formats that are designed to handle specific scenarios.

Traccia di tipo sparseSparse track

Quando si trasmette una presentazione in streaming live con un'esperienza cliente avanzata, spesso è necessario trasmettere eventi sincronizzati o segnali in banda con i principali dati multimediali.When delivering a live streaming presentation with a rich client experience, often it's necessary to transmit time-synced events or signals in-band with the main media data. Un esempio di questo scenario è l'inserimento dinamico di annunci live.An example of this is dynamic live ad insertion. La segnalazione per questo tipo di eventi è diversa dal normale streaming di flussi audio/video a causa della particolare natura di tipo sparse.This type of event signaling is different from regular audio/video streaming because of its sparse nature. In altre parole, i dati di segnalazione non hanno in genere un andamento costante e può essere molto difficile determinare l'intervallo.In other words, the signaling data usually does not happen continuously, and the interval can be hard to predict. Il concetto di traccia di tipo sparse è stato sviluppato per consentire l'inserimento e la trasmissione di dati di segnalazione in banda.The concept of sparse track was designed to ingest and broadcast in-band signaling data.

I passaggi seguenti costituiscono un'implementazione consigliata per l'inserimento di una traccia di tipo sparse:The following steps are a recommended implementation for ingesting sparse track:

  1. Creare un flusso di bit MP4 frammentato separato contenente solo le tracce di tipo sparse, senza tracce audio/video.Create a separate fragmented MP4 bitstream that contains only sparse tracks, without audio/video tracks.
  2. In Live Server Manifest Box, come definito nella sezione 6 di [1], usare il parametro parentTrackName per specificare il nome della traccia padre. Per altre informazioni, vedere la sezione 4.2.1.2.1.2 di [1].In the Live Server Manifest Box as defined in Section 6 in [1], use the parentTrackName parameter to specify the name of the parent track. For more information, see section 4.2.1.2.1.2 in [1].
  3. In Live Server Manifest Box manifestOutput deve (MUST) essere impostato su true.In the Live Server Manifest Box, manifestOutput MUST be set to true.
  4. A causa della natura sparse dell'evento di segnalazione, è consigliabile quanto segue:Given the sparse nature of the signaling event, we recommended the following:

    a.a. All'inizio dell'evento live, il codificatore invia le caselle di intestazione iniziali al servizio, in modo che questo possa registrare la traccia di tipo sparse nel manifesto client.At the beginning of the live event, the encoder sends the initial header boxes to the service, which allows the service to register the sparse track in the client manifest.

    b.b. Il codificatore dovrebbe (SHOULD) terminare la richiesta HTTP POST quando i dati non sono ancora stati inviati.The encoder SHOULD terminate the HTTP POST request when data is not being sent. Una richiesta HTTP POST a esecuzione prolungata che non invia dati può impedire a Servizi multimediali di disconnettersi rapidamente dal codificatore in caso di aggiornamento del servizio o riavvio del server.A long-running HTTP POST that does not send data can prevent Media Services from quickly disconnecting from the encoder in the event of a service update or server reboot. In questi casi, il server dei contenuti multimediali è temporaneamente bloccato in un'operazione di ricezione nel socket.In these cases, the media server is temporarily blocked in a receive operation on the socket.

    c.c. Durante il periodo in cui i dati di segnalazione non sono disponibili, il codificatore dovrebbe (SHOULD) chiudere la richiesta HTTP POSTDuring the time when signaling data is not available, the encoder SHOULD close the HTTP POST request. e inviare i dati mentre la richiesta POST è ancora attiva.While the POST request is active, the encoder SHOULD send data.

    d.d. Per l'invio di frammenti di tipo sparse, il codificatore può impostare esplicitamente l'intestazione Content-Length, se disponibile.When sending sparse fragments, the encoder can set an explicit content-length header, if it’s available.

    e.e. Per l'invio di frammenti di tipo sparse con una nuova connessione, il codificatore dovrebbe (SHOULD) inviare prima le caselle di intestazione e quindi i nuovi frammenti.When sending sparse fragments with a new connection, the encoder SHOULD start sending from the header boxes, followed by the new fragments. Questo consente di gestire casi in cui il failover avviene tra una connessione e l'altra e la nuova connessione di tipo sparse viene stabilita con un nuovo server che non ha mai visto prima la traccia di tipo sparse.This is for cases in which failover happens in-between, and the new sparse connection is being established to a new server that has not seen the sparse track before.

    f.f. Il frammento della traccia di tipo sparse è disponibile al client nel momento in cui il frammento della traccia padre corrispondente, con valore di timestamp uguale o maggiore, viene reso disponibile al client.The sparse track fragment becomes available to the client when the corresponding parent track fragment that has an equal or larger timestamp value is made available to the client. Ad esempio, se il frammento di tipo sparse ha un timestamp t = 1000, dopo che il client rileva il timestamp del frammento video (presupponendo che il nome della traccia padre sia "video") maggiore o uguale a 1000, può scaricare il frammento di tipo sparse t = 1000.For example, if the sparse fragment has a timestamp of t=1000, it is expected that after the client sees "video" (assuming the parent track name is "video") fragment timestamp 1000 or beyond, it can download the sparse fragment t=1000. Tenere presente che il segnale effettivo può essere usato anche per una posizione diversa nella sequenza temporale della presentazione rispetto a quella designata.Note that the actual signal could be used for a different position in the presentation timeline for its designated purpose. In questo esempio è possibile che il frammento di tipo sparse con t = 1000 includa un payload XML che consente di inserire un annuncio in una posizione di pochi secondi successiva.In this example, it’s possible that the sparse fragment of t=1000 has an XML payload, which is for inserting an ad in a position that’s a few seconds later.

    g.g. Il payload dei frammenti della traccia di tipo sparse può avere formati diversi, ad esempio, XML, testo o binario, a seconda dello scenario.The payload of sparse track fragments can be in different formats (such as XML, text, or binary), depending on the scenario.

Traccia audio ridondanteRedundant audio track

In un tipico scenario di streaming adattivo HTTP, ad esempio Smooth Streaming o DASH, spesso l'intera presentazione contiene una sola traccia audio.In a typical HTTP adaptive streaming scenario (for example, Smooth Streaming or DASH), often, there's only one audio track in the entire presentation. Diversamente dalle tracce video, in cui il client può scegliere tra più livelli di qualità in condizioni di errore, la traccia audio può costituire un singolo punto di errore se il processo di inserimento del flusso contenente la traccia audio viene interrotto.Unlike video tracks, which have multiple quality levels for the client to choose from in error conditions, the audio track can be a single point of failure if the ingestion of the stream that contains the audio track is broken.

Per risolvere questo problema, Servizi multimediali supporta l'inserimento live di tracce audio ridondanti.To solve this problem, Media Services supports live ingestion of redundant audio tracks. L'idea è quella di poter inviare più volte la stessa traccia audio in flussi diversi.The idea is that the same audio track can be sent multiple times in different streams. Benché il servizio registri la traccia audio una sola volta nel manifesto client, può usare tracce audio ridondanti come backup, in modo da recuperare i frammenti audio in caso di problemi nella traccia audio principale.Although the service only registers the audio track once in the client manifest, it can use redundant audio tracks as backups for retrieving audio fragments if the primary audio track has issues. Per poter inserire tracce audio ridondanti, il codificatore deve:To ingest redundant audio tracks, the encoder needs to:

  1. Creare la stessa traccia audio in più flussi di bit MP4 frammentati.Create the same audio track in multiple fragment MP4 bitstreams. Le tracce audio ridondanti devono (MUST) essere semanticamente equivalenti ai timestamp degli stessi frammenti e intercambiabili a livello di intestazione e di frammento.The redundant audio tracks MUST be semantically equivalent, with the same fragment timestamps, and be interchangeable at the header and fragment levels.
  2. Assicurarsi che la voce "audio" in Live Server Manifest (sezione 6 di [1]) sia uguale per tutte le tracce audio ridondanti.Ensure that the “audio” entry in the Live Server Manifest (Section 6 in [1]) is the same for all redundant audio tracks.

Di seguito è riportata l'implementazione consigliata per le tracce audio ridondanti:The following implementation is recommended for redundant audio tracks:

  1. Inviare ogni singola traccia audio in un flusso separato.Send each unique audio track in a stream by itself. Inviare inoltre un flusso ridondante per ognuno di questi flussi di traccia audio, in cui il secondo flusso differisca dal primo solo per l'identificatore nell'URL HTTP POST: {protocollo}://{indirizzo server}/{percorso punto di pubblicazione}/Streams({identificatore}).Also, send a redundant stream for each of these audio track streams, where the second stream differs from the first only by the identifier in the HTTP POST URL: {protocol}://{server address}/{publishing point path}/Streams({identifier}).
  2. Usare flussi distinti per inviare le due velocità in bit video più basse.Use separate streams to send the two lowest video bitrates. Ciascuno di questi flussi dovrebbe (SHOULD) inoltre contenere una copia di ogni singola traccia audio. Se, ad esempio, sono supportate più lingue, i flussi dovrebbero (SHOULD) contenere tracce audio per ogni lingua.Each of these streams SHOULD also contain a copy of each unique audio track. For example, when multiple languages are supported, these streams SHOULD contain audio tracks for each language.
  3. Usare istanze del server (codificatore) distinte per codificare e inviare i flussi ridondanti citati in (1) e (2).Use separate server (encoder) instances to encode and send the redundant streams mentioned in (1) and (2).

Percorsi di apprendimento di Servizi multimedialiMedia Services learning paths

Altre informazioni sui percorsi di apprendimento di Servizi multimediali di Azure:Read about the Azure Media Services learning paths:

Fornire commenti e suggerimentiProvide feedback

Usare il forum di suggerimenti degli utenti per fornire commenti e suggerimenti su come migliorare Servizi multimediali di Azure.Use the User Voice forum to provide feedback and make suggestions on how to improve Azure Media Services. È anche possibile passare direttamente a una delle categorie seguenti:You also can go directly to one of the following categories: