Video multitraccia di Amazon IVS: guida all'integrazione del software di trasmissione

PDFRSS

Introduzione

Per poter affermare che uno strumento o servizio software di emittente di terze parti supporta il video multitraccia IVS, è necessario che lo strumento o servizio segua questa guida e implementi le due funzionalità richieste, ossia la configurazione automatica del flusso e le metriche delle prestazioni di trasmissione. Consigliamo vivamente di implementare anche le funzionalità consigliate.

Il diagramma seguente mostra le interazioni di alto livello tra il software di trasmissione dell'utente e Amazon IVS:

Destinatari

Questo documento è destinato agli sviluppatori di software che desiderano implementare il supporto client per video multitraccia per:

• Software di trasmissione di un creatore progettato per lo streaming su Amazon IVS o su servizi che utilizzano video multitraccia Amazon IVS.

• Piattaforme di streaming di terze parti che offrono simulcast o transcodifica lato server, con utenti che trasmettono in streaming su Amazon IVS o servizi che utilizzano video multitraccia Amazon IVS.

Terminologia

Questo documento utilizza alcuni termini in modo intercambiabile:

• Utente, creatore, emittente: l'utente finale che utilizza software di trasmissione per creare e trasmettere contenuti originali.

• Servizio, piattaforma: una piattaforma o un servizio video come Amazon IVS.

• Cliente: un'azienda che può utilizzare un servizio come Amazon IVS per supportare un sito di video.

Funzionalità richiesta: configurazione automatica del flusso

La configurazione automatica del flusso aiuta gli utenti a iniziare rapidamente e migliora automaticamente la qualità dei flussi nel tempo. Invece di scegliere manualmente le impostazioni (ad esempio, bitrate, risoluzione, framerate) che vengono impostate una sola volta e raramente modificate, la configurazione automatica del flusso considera le impostazioni software correnti, la configurazione hardware e il supporto della piattaforma ogni volta che l'utente avvia un nuovo flusso. Ad esempio, quando un utente aggiorna la configurazione (ad esempio, con una nuova GPU), installa un nuovo driver GPU o la destinazione inizia a supportare un nuovo codec (ad esempio, H.265/HEVC), la configurazione automatica dello streaming reagisce e migliora la qualità del flusso successivo dell'utente.

Trasmissione

Quando un utente avvia lo streaming, il software deve richiedere informazioni sulla configurazione hardware e software dell'utente, chiamare GetClientConfiguration, configurare lo scaler/codificatore video e aprire una connessione tramite RTMP avanzato (E-RTMP). Questi passaggi vengono descritti dettagliatamente più avanti.

Utilizzo di GetClientConfiguration

GetClientConfiguration richiede informazioni sulla configurazione hardware e software dell'utente.

L'algoritmo tiene in considerazione molti fattori per fornire una configurazione che:

• Ottimizzi il sistema per garantire la migliore esperienza di visualizzazione: risoluzione massima, framerate massimo, bitrate massimo, maggior numero di tracce, codec nuovi/migliori e migliori impostazioni del codificatore video.

• Sia supportata efficacemente dal software di configurazione e trasmissione dello streamer, dai limiti configurati dall'utente e dal servizio di destinazione.

Nel mondo reale, le limitazioni includono GPU più vecchie, reti di primo miglio scadenti, impostazioni utente specifiche, la mancanza di risorse GPU e il supporto limitato dei codec della piattaforma. Di fronte a queste limitazioni, la configurazione automatica del flusso dovrebbe eseguire il fall-back in modo graduale e ragionevole. Per esempio:

• Varia la larghezza di banda di streaming richiesta tra 10,2 Mb/s (5 rendering) e 1,5 Mb/s (2 rendering).

• Varia la risoluzione massima della traccia di qualità più elevata da 1080p (4 o 5 rendering) a 480p (2 rendering).

• Varia il numero di rendering tra 5 (1080p, 720p, 480p, 360p, 160p) e 2 (480p, 360p).

• Varia la selezione di rendering tra un ampio set di risoluzioni supportate (1080p, 720p, 540p, 480p, 360p, 240p e 160p).

• Varia i bitrate dei singoli rendering da 6 Mb/s (ad esempio, 1080p60 AVC) fino a 200 Kb/s (ad esempio, 160p AVC).

• Modifica il framerate tra alto (60, 50 o 48 fps) e standard (30, 25 o 24 fps).

• Modifica il codec video per bilanciare sicurezza/supporto per gli spettatori ed efficienza del codec (ad esempio, H.264/AVC e H.265/HEVC).

• Modifica l'algoritmo dello scaler per bilanciare le risorse della GPU (ad esempio, Lanczos, bicubica e bilineare).

• Modifica le impostazioni di codifica video (tra cui profilo del codec, codificatore preimpostato, finestra di visualizzazione, QA psicovisuale e numero di B-frame), a seconda del fornitore della GPU e della versione del driver (ad esempio, P6 su NVIDIA GeForce RTX 4080 fino a P4 su NVIDIA GeForce GTX 950).

Esposizione delle preferenze all'utente

È necessario consentire all'utente di configurare le seguenti impostazioni:

• Risoluzione di output

• Framerate di output

• Numero massimo di tracce video

• Bitrate massimo di streaming

Facoltativo: impostazione dei limiti nel software di trasmissione

Il software o il servizio in uso possono fornire impostazioni predefinite o limitare la capacità dell'utente di configurare tali impostazioni. Ad esempio, se il software o il servizio deve conservare le risorse della GPU e si desidera limitare il numero di sessioni di codifica video utilizzate dai video multitraccia, è possibile scegliere di limitare gli utenti a un massimo di 3 tracce video e indicare chiaramente all'utente che Auto significa “fino a 3”.

Limiti definiti dalla destinazione

La chiave di flusso nella richiesta GetClientConfiguration è necessaria per consentire al servizio di identificare il canale e determinare se esistono vincoli per lo stesso. Ad esempio, Amazon IVS fornisce una proprietà multitrackInputConfiguration.maximumResolution per i canali STANDARD. Questo metodo può essere usato per limitare la risoluzione di ogni singola traccia, in modo che i clienti possano rendere disponibili qualità speciali (ad esempio, streaming 720p60 o 1080p60) a creatori specifici o controllare in altro modo i costi di output.

Gestione degli avvisi e degli errori

GetClientConfiguration restituisce avvisi ed errori in diverse circostanze, quindi è necessario implementare il supporto rivolto agli utenti per gestire sia gli avvisi sia gli errori.

Gli avvisi sono informativi. All'utente dovrebbe essere consentito di continuare lo streaming o annullarlo. Di seguito puoi trovare un esempio di avviso:

• La versione del driver NVIDIA installata sul computer dell'utente non sarà più supportata dalla data GG/MM/AAAA.

Gli errori sono considerati fatali. All'utente non dovrebbe essere consentito di continuare lo streaming. Di seguito sono riportati alcuni esempi di errori:

• Il canale non è configurato per supportare video multitraccia.

• La versione del driver della GPU non è aggiornata/supportata.

• La GPU non è supportata.

• La chiave di flusso fornita non è valida.

• Il framerate 59,94 in uso non è supportato dai video multitraccia di Amazon IVS. In Impostazioni > Video, seleziona uno dei seguenti valori supportati: 24, 25, 30, 48, 50, 60.

• Nella richiesta di configurazione mancano i dati richiesti (versione del driver della GPU, modello della GPU e così via).

Configurazione del dimensionamento e della codifica dei video

GetClientConfiguration restituisce impostazioni di dimensionamento e codifica ottimizzate per la migliore esperienza di visualizzazione possibile senza influire sulle prestazioni dell'applicazione (ad esempio, software di gioco/trasmissione) e tenendo conto delle impostazioni dell'utente. Utilizza le esatte impostazioni di dimensionamento e codifica restituite da GetClientConfiguration. GetClientConfiguration tiene conto delle esigenze specifiche dei diversi fornitori e delle architetture GPU che cambiano nel tempo.

Oltre alle impostazioni di dimensionamento e codifica (come quelle preimpostate), è necessario:

• Allineare tutti i codificatori e assicurarsi che gli IDR di tutti i rendering abbiano lo stesso PTS. Ciò è richiesto per evitare la necessità di eseguire la transcodifica lato server per allineare più rendering quando il video viene distribuito e visualizzato utilizzando HLS segmentato. Se gli IDR non sono allineati tra le tracce video, gli spettatori riscontreranno scarti temporali e ritardi del flusso audio durante il cambio di rendering nella riproduzione ABR. Per una rappresentazione grafica, consulta la figura in Metriche delle prestazioni di trasmissione.

• Clonare i dati SEI/OBU (ad esempio i sottotitoli) su tutte le tracce video. Ciò è necessario affinché il lettore video possa accedere ai dati SEI/OBU, indipendentemente dalla qualità individuale guardata.

Connessione tramite RTMP avanzato

Per la documentazione sullo streaming multitraccia tramite RTMP avanzato, consulta la specifica RTMP avanzato v2.

Quando ci si connette con RTMP avanzato, i video multitraccia di Amazon IVS hanno diversi requisiti:

• La traccia video principale e di alta qualità deve essere impacchettata e inviata come pacchetti video a traccia singola con RTMP avanzato. Ad esempio, videoPacketType può essere CodedFrames, CodedFramesX, SequenceStart e SequenceEnd.

• Tutte le tracce video aggiuntive devono essere impacchettate e inviate come pacchetti video multitraccia con RTMP avanzato (ad esempio, videoPacketType è Multitrack), con il tipo di pacchetto multitraccia impostato su una traccia (ad esempio, videoMultitrackType è OneTrack).

• Per connettersi al server RTMP è necessario utilizzare la chiave di flusso nel campo authentication restituita da GetClientConfiguration.

• Il valore config_id restituito da GetClientConfiguration deve essere aggiunto come argomento di query alla stringa di connessione RTMP con il valore clientConfigId della chiave.

Di seguito è riportato un esempio di configurazione del flusso:

videoPacketType	videoMultitrackType	trackId	Risoluzione
CodedFrames CodedFramesX SequenceStart SequenceEnd	NA: videoMultitrackType non viene inviato con RTMP avanzato a traccia singola.	NA: trackId non viene inviato con RTMP avanzato a traccia singola.	1920 x 1080
Multitrack	OneTrack	1	1280 x 720
Multitrack	OneTrack	2	852 x 480
Multitrack	OneTrack	3	640 x 360

Il software di trasmissione deve utilizzare i dati restituiti da GetClientConfiguration in ingest_endpoints e il protocollo (RTMP o RTMPS) selezionato dall'utente per identificare l'endpoint a cui connettersi. Utilizza url_template e la chiave di flusso restituita in authentication per creare un URL e includi config_id come argomento della query clientConfigId. Se consenti all'utente di specificare argomenti di query RTMP (ad esempio, ?bandwidthtest=1), devi aggiungerli oltre a specificare clientConfigId. Di seguito puoi trovare un esempio di risposta da GetClientConfiguration:

{
   "ingest_endpoints": [
      {
         "protocol": "RTMP",
         "url_template": "rtmp://iad05.contribute.live-video.net/app/{stream_key}",
         "authentication": "v1_5f2e593731dad88b6bdb03a3517d306ef88a73e29619ee4b49012d557e881484_65c5dc81_7b2276223a302c2262223a393939392c2274223a5b7b2277223a3634302c2268223a3336302c2262223a3530302c226330223a312c226331223a302c226332223a307d2c7b2277223a313238302c2268223a3732302c2262223a313730302c226330223a312c226331223a302c226332223a307d2c7b2277223a313932302c2268223a313038302c2262223a363030302c226330223a312c226331223a302c226332223a307d5d7d_live_495665160_FC45sNuCYUwLnCVtCnXSjEWkusXzJI"
      },
      {
         "protocol": "RTMPS",
         "url_template": "rtmps://iad05.contribute.live-video.net/app/{stream_key}",
         "authentication": "v1_5f2e593731dad88b6bdb03a3517d306ef88a73e29619ee4b49012d557e881484_65c5dc81_7b2276223a302c2262223a393939392c2274223a5b7b2277223a3634302c2268223a3336302c2262223a3530302c226330223a312c226331223a302c226332223a307d2c7b2277223a313238302c2268223a3732302c2262223a313730302c226330223a312c226331223a302c226332223a307d2c7b2277223a313932302c2268223a313038302c2262223a363030302c226330223a312c226331223a302c226332223a307d5d7d_live_495665160_FC45sNuCYUwLnCVtCnXSjEWkusXzJI"
      }
   ],
   "meta": {
      "config_id": "d34c2f7e-ce3a-4be4-a6a0-f51960abbc4f",
      …
   }
   …
}

Quindi, se l'utente ha selezionato RTMP, si aprirà la connessione a:

rtmp://iad05.contribute.live-video.net/app/v1_5f2e593731dad88b6bdb03a3517d306ef88a73e29619ee4b49012d557e881484_65c5dc81_7b2276223a302c2262223a393939392c2274223a5b7b2277223a3634302c2268223a3336302c2262223a3530302c226330223a312c226331223a302c226332223a307d2c7b2277223a313238302c2268223a3732302c2262223a313730302c226330223a312c226331223a302c226332223a307d2c7b2277223a313932302c2268223a313038302c2262223a363030302c226330223a312c226331223a302c226332223a307d5d7d_live_495665160_FC45sNuCYUwLnCVtCnXSjEWkusXzJI?clientConfigId=d34c2f7e-ce3a-4be4-a6a0-f51960abbc4f

Gestione delle disconnessioni video

Il sistema video multitraccia impone diversi limiti. In generale, le limitazioni esistono per tre motivi:

1. Sicurezza del sistema: IVS deve limitare l'input per garantire la scalabilità. Gli esempi includono un limite di larghezza di banda di streaming per canale che influisce sull'elaborazione di input, un diritto al bitrate in base alla traccia o alla risoluzione che influisce sulla capacità/sul costo di output e l'autorizzazione al numero di tracce che influisce sulla capacità di replica/consegna della CDN.

2. Funzionalità del sistema: il servizio deve limitare l'input per garantire la compatibilità delle funzionalità (ad esempio, supporto della piattaforma per i singoli codec o supporto dei container di consegna per codec avanzati).

3. Esperienza degli spettatori: il servizio deve limitare l'input per l'esperienza degli spettatori e la reputazione del marchio. Ad esempio, il servizio controlla l'algoritmo ABR del player che determina il QoE su tutti i dispositivi degli utenti di destinazione (desktop, dispositivi mobili, TV/OTT, ecc.) e le app (browser, native, ecc.).

Il sistema video disconnette il client in diversi scenari:

• Il client tenta di connettersi al server RTMP con video multitraccia ma non utilizza la chiave di flusso restituita da GetClientConfiguration.

• Il client fornisce un video multitraccia che non corrisponde alla specifica restituita da GetClientConfiguration; ad esempio:

  • Il numero di tracce non corrisponde.

  • Una singola traccia ha un codec non corrispondente.

  • Una singola traccia ha una risoluzione non corrispondente.

  • Una singola traccia ha un framerate non corrispondente.

  • Una singola traccia ha un bitrate non corrispondente.

• Il client non fornisce tracce video con IDR allineati.

• Le metriche delle prestazioni di trasmissione non precedono tutti gli IDR su ogni traccia.

Le disconnessioni possono verificarsi all'inizio dello streaming (ad esempio, il canale non viene mai trasmesso in diretta) o durante lo streaming (ad esempio, il canale è in diretta, viene rilevata una mancata corrispondenza e quindi il client viene disconnesso).

Riconnessione automatica

La validità della chiave di flusso restituita da GetClientConfiguration è di 48 ore o fino a quando la chiave di flusso non viene invalidata chiamando DeleteStreamKey. La durata massima dei flussi IVS è 48 ore; successivamente, il flusso viene terminato e la sessione di streaming viene disconnessa. Una riconnessione riuscita (automaticamente o manualmente) avvia un nuovo flusso.

Il software di trasmissione potrebbe implementare la riconnessione automatica. Se supporti la riconnessione automatica, dovresti consentire agli utenti di abilitarla o disabilitarla e seguire queste linee guida:

• Implementa un ritardo di riprova con backoff esponenziale (inclusa una piccola deviazione casuale) tra i tentativi di connessione.

• Esegui al massimo 25 tentativi di connessione. Ad esempio, OBS Studio riprova 25 volte, con un tempo di attesa che aumenta esponenzialmente tra i tentativi ed è limitato a 15 minuti. In pratica, ciò significa che l'ultimo tentativo avviene circa 3 ore dopo la disconnessione.

• Se ti disconnetti subito dopo l'invio di publish durante la connessione, chiama GetClientConfiguration, riconfigura le impostazioni del codificatore e prova a connetterti di nuovo.

Interruzione del flusso e disconnessione

Quando l'utente interrompe lo streaming e se la connessione TCP è ancora aperta (ad esempio, la connessione di livello inferiore non è stata ripristinata), è necessario inviare FCUnpublish (implementazione di esempio in OBS Studio) prima di chiudere la connessione RTMP. Questo è fondamentale per segnalare l'intenzione dell'utente di terminare il flusso, poiché il corretto funzionamento delle funzionalità downstream dipende da esso.

Funzionalità richiesta: metriche delle prestazioni di trasmissione (BPM)

Per consentire il miglioramento continuo della configurazione automatica del flusso e fornire le migliori impostazioni di streaming possibili, è necessario misurare e inviare le metriche delle prestazioni di trasmissione (BPM).

Le metriche vengono raccolte e inviate in banda tramite messaggi SEI (per AVC/HEVC). Vengono raccolte due classi di dati:

• I timestamp vengono raccolti per misurare la latenza end-to-end tra l'emittente e lo spettatore. Sono utili per:

  • fornire all'emittente o al pubblico una stima della latenza end-to-end;

  • analizzare il jitter del timestamp, che può indicare lo stress del sistema o una scarsa connettività di rete del primo miglio;

  • fare riferimento all'ora degli eventi del mondo reale per allineare e aggregare i dati dei contatori delle serie temporali.

  Il timestamp inviato dall'emittente si basa su un orologio di riferimento comune globale, in genere un orologio sincronizzato con NTP che utilizza il fuso orario UTC+0. Per questo scenario di “ora di Internet” viene comunemente utilizzato RFC3339. Ciò fornisce un riferimento assoluto, facilitando i calcoli delle differenze temporali.

• I contatori di fotogrammi vengono raccolti per misurare le prestazioni del software di trasmissione e dei codificatori video a livello di fotogramma. Sono utili per:

  • fornire agli emittenti un pannello di controllo delle prestazioni che include segnali aggiuntivi, per aiutarle a migliorare la configurazione dello streaming;

  • fornire un segnale proattivo che può essere correlato a cambiamenti ambientali, come i driver GPU appena rilasciati o le versioni/patch del sistema operativo;

  • fornire feedback per consentire ai servizi video di iterare e rilasciare miglioramenti in modo sicuro a GetClientConfiguration, incluso il supporto per nuovi fornitori di hardware, nuovi modelli di GPU, nuovi codec, nuove funzionalità dei driver, ottimizzazione aggiuntiva delle impostazioni del codificatore video e nuove preimpostazioni controllate dall'utente (ad esempio, “Dual PC Setup” rispetto a “Gaming+Streaming Setup”).

Inserimento di messaggi SEI/OBU

Fai riferimento alla sezione Definizioni dei messaggi BPM specifiche del flusso di byte dei messaggi.

Le metriche BPM devono essere inserite su tutte le tracce video subito prima dell'IDR. I tre messaggi (BPM TS, BPM SM e BPM ERM) devono essere inviati insieme, ma ciascuno deve essere inviato come NUT (AVC/HEVC) separato.

BPM SM e BPM ERM inviati nel primo segmento devono avere i contatori di frame impostati su 0. All'inizio ciò può sembrare controintuitivo; tuttavia, contatori come il numero di fotogrammi codificati per rendering non posseggono dati significativi fino a quando non è stata completata la codifica, e come risultato i contatori di fotogrammi nel segmento N si allineano con il segmento N-1. È meglio pensare alle metriche BPM come a una serie di dati temporizzati che vengono forniti nel bitstream video a intervalli IDR. Se necessario, il ricevitore deve eseguire un riallineamento preciso delle serie di dati utilizzando i timestamp forniti.

L'illustrazione seguente illustra uno scenario tipico per un flusso multitraccia a tre rendering. Con una dimensione tipica del segmento di due secondi, le metriche verranno inviate ogni due secondi per ogni rendering.

Funzionalità consigliate

Consenti la selezione automatica del server

La selezione automatica del server consente agli utenti di selezionare il server di importazione migliore a cui connettersi per le proprie dirette streaming in base ai cambiamenti delle condizioni di rete globali e alla disponibilità del PoP (Point of Presence) di importazione.

Se il software di trasmissione supporta la selezione automatica del server, prevediamo un comportamento diverso a seconda che il software implementi GetClientConfiguration e/o FindIngest. Ciascuno scenario è elencato separatamente di seguito.

Se il software di trasmissione implementa sia GetClientConfiguration sia FindIngest:

Selezione dell'interfaccia utente	Connettiti all'endpoint di importazione specificato da...
Auto (Automatico)	GetClientConfiguration
Endpoint di importazione specifico da FindIngest	Selezione dell'utente
Specifica server personalizzato	Selezione dell'utente

Se il software di trasmissione implementa GetClientConfiguration ma non FindIngest:

Selezione dell'interfaccia utente	Connettiti all'endpoint di importazione specificato da...
Auto (Automatico)	GetClientConfiguration
Specifica server personalizzato	Selezione dell'utente

Se il software di trasmissione non implementa GetClientConfiguration ma implementa FindIngest:

Selezione dell'interfaccia utente	Connettiti all'endpoint di importazione specificato da...
Auto (Automatico)	FindIngest
Endpoint di importazione specifico da FindIngest	Selezione dell'utente
Specifica server personalizzato	Selezione dell'utente

Se il software di trasmissione non implementa GetClientConfiguration né FindIngest:

Selezione dell'interfaccia utente	Connettiti all'endpoint di importazione specificato da...
Auto (Automatico)	URL di importazione globale: Per RTMP: rtmp://ingest.global-contribute.live-video.net/app Per RTMPS: rtmps://ingest.global-contribute.live-video.net:443/app
Specifica server personalizzato	Selezione dell'utente

Per ulteriori informazioni sull'utilizzo degli endpoint di importazione specificati da FindIngest, consulta la pagina Utilizzo di un server FindIngest per la destinazione di streaming automatica.

Consentire agli utenti di configurare la destinazione di streaming

Quando gli utenti configurano le proprie destinazioni di streaming, è necessario interrogare FindIngest e fornire all'utente la possibilità di:

• Scegliere tra RTMP o RTMPS (impostazione predefinita per Amazon IVS).

• Selezionare Automatico per il server.

• Selezionare un server specifico dall'elenco restituito da FindIngest

• Inserire un server personalizzato; ad esempio, utilizzare Specifica server personalizzato.

È possibile filtrare l'elenco restituito da FindIngest in base al protocollo selezionato dall'utente (RTMP o RTMPS) o ad altre considerazioni.

Ad esempio, l'implementazione di Amazon IVS in OBS Studio consente di raggiungere questo obiettivo fornendo un semplice menu a discesa Server con le seguenti opzioni:

• Automatico (RTMPS, consigliato)

• Automatico (RTMP)

• Stati Uniti orientali: Ashburn, VA (5) (RTMPS)

• Stati Uniti orientali: New York, NY (50) (RTMPS)

• Stati Uniti orientali: New York, NY (RTMPS)

• Stati Uniti orientali: Ashburn, VA (5) (RTMP)

• Stati Uniti orientali: New York, NY (50) (RTMP)

• Stati Uniti orientali: New York, NY (RTMP)

• Specifica server personalizzato

Quando è selezionato Specifica server personalizzato, viene fornita una casella di testo in cui l'utente può inserire un URL RTMP.

Utilizzo di un server FindIngest per la destinazione di streaming automatica

Se utilizzi gli endpoint di importazione specificati da FindIngest quando è stato specificato Automatica per la destinazione di streaming, utilizza la voce con il valore di priority più basso restituito da FindIngest. Per ridurre il tempo necessario alla trasmissione di un flusso, puoi memorizzare nella cache la risposta FindIngest. Se memorizzi la risposta nella cache, aggiorna regolarmente il valore memorizzato nella cache.

Se l'utente seleziona RTMP, utilizza la stringa url_template come destinazione di trasmissione RTMP. Se l'utente seleziona RTMP, utilizza la stringa url_template_secure come destinazione di trasmissione RTMPS. In entrambi i casi, sostituisci {stream_key} con la chiave di flusso dell'utente.

Definizioni dei messaggi relativi alle metriche delle prestazioni di trasmissione (BPM)

I messaggi BPM si basano sulla sintassi SEI standard H.264. Per riferimento, la sintassi SEI non registrata dei dati utente secondo la specifica H.264 è:

Per i messaggi BPM, si applicano tutte le regole di analisi e notazione dello standard H.264, ad esempio “u(128)” indica un numero intero senza segno a 128 bit, prima MSB.

Per BPM sono definiti tre messaggi SEI:

• BPM TS SEI: messaggio di timpestamp

• BPM SM SEI: messaggio relativo alle metriche della sessione

• BPM ERM SEI: messaggio sulle metriche di rendering codificato

Tutti i messaggi BPM SEI inviano un UUID a 128 bit richiesto dalla sintassi user_data_unregistered(), seguito da un ciclo di byte di payload. Il messaggio risultante viene quindi incapsulato in una semantica di livello superiore (ad esempio, NALU, RBSP e prevenzione dell'emulazione del codice di avvio).

BPM TS (Timestamp) SEI

Il messaggio BPM TS SEI trasmette uno o più timestamp correlati. Ad esempio, il client può segnalare i timestamp per la composizione del fotogramma, la richiesta di codifica del fotogramma, il completamento della richiesta di codifica del fotogramma e l'interlacciamento del pacchetto in un singolo messaggio SEI, e il client può decidere se ciascuno di questi timestamp deve essere inviato come orologio da parete (stile RFC3339/ISO8601), come orologio delta (differenziale) o come durata a partire dall'epoca. Dovrebbe essere presente un timestamp che fornisca un riferimento per i tipi di delta; questo dovrebbe essere curato dall'implementazione e non da alcun vincolo sintattico.

user_data_unregistered_bpm_ts( payloadSize ) {	C	Descrittore
uuid_iso_iec_11578	5	u(128)
ts_reserved_zero_4bits	5	b(4)
num_timestamps_minus1	5	u(4)
for( i = 0; i <= num_timestamps_minus1; i++ ) {
timestamp_type[i]	5	u(8)
timestamp_event[i]	5	u(8)
if (timestamp_type[i] == 1)
rfc3339_ts[i]	5	st(v)
else if (timestamp_type[i] == 2)
duration_since_epoch_ts[i]	5	u(64)
else if (timestamp_type[i] == 3)
delta_ts[i]	5	i(64)
}
}

Tabella di descrizione del campo BPM TS SEI

Campo	Descrizione
uuid_iso_iec_11578	Imposta su esadecimale: 0aecffe752724e2fa62fd19cd61a93b5 Con l'utilizzo del messaggio SEI non registrato, è necessario un UUID per distinguere questo messaggio da qualsiasi altro non registrato.
ts_reserved_zero_4bits	Riservato per uso futuro. Imposta su b('0000'). Il destinatario deve ignorare questi bit.
num_timestamps_minus1	num_timestamps=num_timestamps_minus1+1 num_timestamps_minus1 deve essere compreso tra 0 e 15, il che significa che possono essere segnalati tra 1 e 16 timestamp.
timestamp_type	Consultare Tabella timestamp_type.
timestamp_event	Una delle seguenti: BPM_TS_EVENT_CTS = 1 // Evento del momento della composizione BPM_TS_EVENT_FER = 2 // Evento di richiesta di codifica del fotogramma BPM_TS_EVENT_FERC = 3 // Evento di completamento della richiesta di codifica del fotogramma BPM_TS_EVENT_PIR = 4 // Evento di richiesta di interlacciamento del pacchetto Non esiste un discriminatore sintattico per identificare l'unicità nei casi in cui num_timestamps_minus1 è maggiore di 0 (ad esempio, viene segnalato più di un timestamp); quindi, timestamp_event dovrebbe essere unico all'interno del ciclo SEI. La segnalazione di più timestamp con lo stesso timestamp_event non è preclusa; tuttavia, l'interpretazione dei timestamp non rientra nell'ambito del messaggio.

Tabella timestamp_type

timestamp_type specifica tipi come:

• Formati “Orologio da parete” in cui vengono segnalate la data e l'ora basate sul calendario.

• Durata a partire dall'epoca.

• Timestamp delta in cui viene segnalata la differenza tra due eventi.

• Formati di timestamp aggiuntivi che potrebbero essere necessari in futuro.

timestamp_type	Nome	Descrizione
0	indefinito	Non definito: non utilizzare.
1	rfc3339_ts	RFC3339 è un profilo di ISO8601 per l'utilizzo di Internet, che limita alcune delle opzioni in ISO8601. timestamp_type==1 deve utilizzare la notazione temporale basata su RFC3339. Nota che RFC3339 non supporta i fusi orari. Tutti i timestamp sono relativi al fuso orario UTC (noto anche come ora “Zulu”), che per definizione ha un offset UTC di 00:00. fc3339_ts deve essere una stringa. st(v) è definito nella sezione 7.2 dello standard H.264. Vedi la nota sui secondi intercalari sotto questa tabella. Esempio: 2024-03-25T15:10:34.489Z (489 si riferisce ai millisecondi)
2	duration_since_epoch_ts	Durata a partire dall'epoca 1970-01-01T00:00:00Z000 in millisecondi. Vedi la nota sui secondi intercalari sotto questa tabella.
3	delta_ts	Timestamp delta, che esprime la differenza in nanosecondi tra due eventi. I numeri interi con segno consentono di segnalare delta positivi e negativi.
4-255	Riservata	Riservata.

Nota sui secondi intercalari: è importante notare che è stato raggiunto un accordo per eliminare gradualmente l'uso dei secondi intercalari entro il 2035. Vedi la voce di Wikipedia sui secondi intercalari per i dettagli. Ti consigliamo di utilizzare timestamp che escludano i secondi intercalari. Ciò è in linea con le pratiche che verranno adottate entro il 2035 ed evita possibili errori di calcolo delle tempistiche.

BPM SM (metriche di sessione) SEI

Il messaggio BPM SM SEI trasmette l'insieme di metriche relative alla sessione complessiva del mittente. In OBS Studio, ciò significa inviare i seguenti contatori di fotogrammi:

• Fotogrammi di sessione renderizzati

• Fotogrammi di sessione annullati

• Fotogrammi di sessione ritardati

• Fotogrammi di sessione di output

Questo messaggio SEI include anche un timestamp. Questo è ridondante rispetto al BPM TS SEI; tuttavia, l'indicazione di un timestamp esplicito in ogni messaggio SEI fornisce un'unità di comportamento atomico e riduce il carico di riallinamento dei dati per il ricevitore. Inoltre, in caso di necessità di annullare o non inviare BPM TS SEI, nel messaggio BPM SM SEI dovrebbe comunque essere presente un timestamp esplicito da utilizzare.

user_data_unregistered_bpm_sm( payloadSize ) {	C	Descrittore
uuid_iso_iec_11578	5	u(128)
ts_reserved_zero_4bits	5	b(4)
num_timestamps_minus1	5	u(4)
for( i = 0; i <= num_timestamps_minus1; i++ ) {
timestamp_type[i]	5	u(8)
timestamp_event[i]	5	u(8)
if (timestamp_type[i] == 1)
rfc3339_ts[i]	5	st(v)
else if (timestamp_type[i] == 2)
duration_since_epoch_ts[i]	5	u(64)
else if (timestamp_type[i] == 3)
delta_ts[i]	5	i(64)
}
ts_reserved_zero_4bits	5	b(4)
num_counters_minus1	5	u(4)
for( i = 0; i <= num_counters_minus1; i++ ) {
counter_tag[i]	5	b(8)
counter_value[i]	5	b(32)
}
}

Tabella di descrizione del campo BPM SM SEI

Molti campi in questo messaggio SEI sono simili ai campi BPM TS SEI. Le differenze significative sono il valore UUID, il numero di timestamp previsti e i contatori trasmessi.

Campo	Descrizione
uuid_iso_iec_11578	Imposta su esadecimale: ca60e71c-6a8b-4388-a377-151df7bf8ac2 Con l'utilizzo del messaggio SEI non registrato, è necessario un UUID per distinguere questo messaggio da qualsiasi altro non registrato.
ts_reserved_zero_4bits	Riservato per uso futuro. Imposta su b('0000'). Il destinatario deve ignorare questi bit.
num_timestamps_minus1	num_timestamps=num_timestamps_minus1+1 num_timestamps_minus1 deve essere compreso tra 0 e 15, il che significa che possono essere segnalati tra 1 e 16 timestamp. Al momento, è 0 (che indica un singolo timestamp).
timestamp_type	Consultare Tabella timestamp_type. Per BPM SM SEI, deve essere una stringa di tipo 1 - RFC3339.
timestamp_event	Una delle seguenti: BPM_TS_EVENT_CTS = 1 // Evento del momento della composizione BPM_TS_EVENT_FER = 2 // Evento di richiesta di codifica del fotogramma BPM_TS_EVENT_FERC = 3 // Evento di completamento della richiesta di codifica del fotogramma BPM_TS_EVENT_PIR = 4 // Evento di richiesta di interlacciamento del pacchetto Non esiste un discriminatore sintattico per identificare l'unicità nei casi in cui num_timestamps_minus1 è maggiore di 0 (ad esempio, viene segnalato più di un timestamp); quindi, timestamp_event dovrebbe essere unico all'interno del ciclo SEI. La segnalazione di più timestamp con lo stesso timestamp_event non è preclusa; tuttavia, l'interpretazione dei timestamp non rientra nell'ambito del messaggio. Nota: Amazon IVS prevede l'utilizzo di BPM SM SEI utilizzando timestamp_event solo impostato su 4 (BPM_TS_EVENT_PIR). Questo cambierà man mano che verrà aggiunto il supporto per ulteriori eventi di timestamp.
num_counters_minus1	num_counters=num_counters_minus1+1 num_counters_minus1 deve essere compreso tra 0 e 15, il che significa che possono essere segnalati tra 1 e 16 contatori. Per BPM SM SEI, deve essere 3 (ossia 4 contatori).
counter_tag	Una delle seguenti: BPM_SM_FRAMES_RENDERED = 1 // Fotogrammi renderizzati dal compositore BPM_SM_FRAMES_LAGGED = 2 // Fotogrammi ritardati dal compositore BPM_SM_FRAMES_DROPPED = 3 // Fotogrammi annullati a causa della congestione della rete BPM_SM_FRAMES_OUTPUT = 4//Totale fotogrammi in uscita (somma di tutti i sink di rendering del codificatore video)
counter_value	Il valore di differenza a 32 bit per il valore counter_tag specificato rispetto all'ultima volta in cui è stato inviato. Ad esempio, con un rendering a 60 fps, ogni 2 secondi counter_value dovrebbe essere 120.

Esempio di BPM SM

Di seguito puoi trovare un esempio di BPM SM SEI inviato ad Amazon IVS:

• uuid_iso_iec_11578 (16 byte): ca60e71c-6a8b-4388-a377-151df7bf8ac2

• ts_reserved_zero_4bits (4 bit): 0x0

• num_timestamps_minus1 (4 bit): 0x0 (significa che viene inviato 1 timestamp)

• timestamp_type (1 byte): 0x01 (timestamp RFC3339 - formato stringa)

• timestamp_event (1 byte): 0x04 (BPM_TS_EVENT_PIR)

• rfc3339_ts: “2024-03-25T15:10:34.489Z”

• ts_reserved_zero_4bits (4 bit): 0x0

• num_counters_minus1 (4 bit): 0x3 (significa che vengono inviati 4 contatori)

• counter_tag (1 byte): 0x01 (fotogrammi renderizzati dal compositore dall'ultimo messaggio)

• counter_value (4 byte)

• counter_tag (1 byte): 0x02 (frame ritardati dal compositore dall'ultimo messaggio)

• counter_value (4 byte)

• counter_tag (1 byte): 0x03 (fotogrammi annullati a causa della congestione della rete dall'ultimo messaggio)

• counter_value (4 byte)

• counter_tag (1 byte): 0x04 (fotogrammi totali di output) (somma di tutti i sink di rendering del codificatore video dall'ultimo messaggio)

• counter_value (4 byte)

BPM ERM (metriche del rendering codificato) SEI

Il messaggio BPM ERM SEI trasmette l'insieme di metriche relative a ciascun rendering codificato. In OBS Studio, ciò significa inviare i seguenti contatori di fotogrammi:

• Fotogrammi di rendering di input

• Fotogrammi di rendering ignorati

• Fotogrammi di rendering di output

Questo messaggio SEI include anche un timestamp. Questo è ridondante rispetto al BPM TS SEI; tuttavia, l'indicazione di un timestamp esplicito in ogni messaggio SEI fornisce un'unità di comportamento atomico e riduce il carico di riallinamento dei dati per il ricevitore. Inoltre, in caso di necessità di annullare o non inviare BPM TS SEI, nel messaggio BPM ERM SEI dovrebbe comunque essere presente un timestamp esplicito da utilizzare.

user_data_unregistered_bpm_erm( payloadSize ) {	C	Descrittore
uuid_iso_iec_11578	5	u(128)
ts_reserved_zero_4bits	5	b(4)
num_timestamps_minus1	5	u(4)
for( i = 0; i <= num_timestamps_minus1; i++ ) {
timestamp_type[i]	5	u(8)
timestamp_event[i]	5	u(8)
if (timestamp_type[i] == 1)
rfc3339_ts[i]	5	st(v)
else if (timestamp_type[i] == 2)
duration_since_epoch_ts[i]	5	u(64)
else if (timestamp_type[i] == 3)
delta_ts[i]	5	i(64)
}
ts_reserved_zero_4bits	5	b(4)
num_counters_minus1	5	u(4)
for( i = 0; i <= num_counters_minus1; i++ ) {
counter_tag[i]	5	b(8)
counter_value[i]	5	b(32)
}
}

Tabella di descrizione del campo BPM ERM SEI

Molti campi in questo messaggio SEI sono simili ai campi BPM TS SEI e ai campi BPM SM SEI. Le differenze significative sono il valore UUID, il numero di timestamp previsti e i contatori trasmessi.

Campo	Descrizione
uuid_iso_iec_11578	Imposta su esadecimale: f1fbc1d5-101e-4fb5-a61e-b8ce3c07b8c0 Con l'utilizzo del messaggio SEI non registrato, è necessario un UUID per distinguere questo messaggio da qualsiasi altro non registrato.
ts_reserved_zero_4bits	Riservato per uso futuro. Imposta su b('0000'). Il destinatario deve ignorare questi bit.
num_timestamps_minus1	num_timestamps=num_timestamps_minus1+1 num_timestamps_minus1 deve essere compreso tra 0 e 15, il che significa che possono essere segnalati tra 1 e 16 timestamp. Al momento, è 0 (che indica un singolo timestamp).
timestamp_type	Consultare Tabella timestamp_type. Deve essere una stringa di tipo 1 - RFC3339.
timestamp_event	Una delle seguenti: BPM_TS_EVENT_CTS = 1 // Evento del momento della composizione BPM_TS_EVENT_FER = 2 // Evento di richiesta di codifica del fotogramma BPM_TS_EVENT_FERC = 3 // Evento di completamento della richiesta di codifica del fotogramma BPM_TS_EVENT_PIR = 4 // Evento di richiesta di interlacciamento del pacchetto Non esiste un discriminatore sintattico per identificare l'unicità nei casi in cui num_timestamps_minus1 è maggiore di 0 (ad esempio, viene segnalato più di un timestamp); quindi, timestamp_event dovrebbe essere unico all'interno del ciclo SEI. La segnalazione di più timestamp con lo stesso timestamp_event non è preclusa; tuttavia, l'interpretazione dei timestamp non rientra nell'ambito del messaggio. Nota: Amazon IVS prevede l'utilizzo di BPM ERM SEI utilizzando timestamp_event solo impostato su 4 (BPM_TS_EVENT_PIR). Questo cambierà man mano che verrà aggiunto il supporto per ulteriori eventi di timestamp.
num_counters_minus1	num_counters=num_counters_minus1+1 num_counters_minus1 deve essere compreso tra 0 e 15, il che significa che possono essere segnalati tra 1 e 16 contatori. Per BPM ERM SEI, deve essere 2 (ossia 3 contatori).
counter_tag	Una delle seguenti: BPM_ERM_FRAMES_INPUT = 1 // Fotogrammi di input nel rendering del codificatore BPM_ERM_FRAMES_SKIPPED = 2 // Fotogrammi ignorati dal rendering del codificatore BPM_ERM_FRAMES_OUTPUT = 3 // Fotogrammi di output (codificati) dal rendering del codificatore
counter_value	Il valore di differenza a 32 bit per il valore counter_tag specificato rispetto all'ultima volta in cui è stato inviato. Ad esempio, con un rendering a 60 fps, ogni 2 secondi counter_value dovrebbe essere 120.

Esempio di ERM BPM

Di seguito puoi trovare un esempio di BPM ERM SEI inviato ad Amazon IVS:

• uuid_iso_iec_11578 (16 byte): f1fbc1d5-101e-4fb5-a61e-b8ce3c07b8c0

• ts_reserved_zero_4bits (4 bit): 0x0

• num_timestamps_minus1 (4 bit): 0x0 (significa che viene inviato 1 timestamp)

• timestamp_type (1 byte): 0x01 (timestamp RFC3339 - formato stringa)

• timestamp_event (1 byte): 0x04 (BPM_TS_EVENT_PIR)

• rfc3339_ts: “2024-03-25T15:10:34.489Z”

• ts_reserved_zero_4bits (4 bit): 0x0

• num_counters_minus1 (4 bit): 0x2 (significa che vengono inviati 3 contatori)

• counter_tag (1 byte): 0x01 (fotogrammi di rendering di input codificati dall'ultimo messaggio)

• counter_value (4 byte)

• counter_tag (1 byte): 0x02 (fotogrammi di rendering codificati ignorati dall'ultimo messaggio)

• counter_value (4 byte)

• counter_tag (1 byte): 0x03 (fotogrammi di rendering di output codificati dall'ultimo messaggio)

• counter_value (4 byte)