Origini live

  • Articolo

[La funzionalità associata a questa pagina, DirectShow, è una funzionalità legacy. È stata sostituita da MediaPlayer, FMMediaEngine e Audio/Video Capture in Media Foundation. Queste funzionalità sono state ottimizzate per Windows 10 e Windows 11. Microsoft consiglia vivamente che il nuovo codice usi MediaPlayer, FMMediaEngine e Audio/Video Capture in Media Foundation anziché DirectShow, quando possibile. Microsoft suggerisce che il codice esistente che usa le API legacy venga riscritto per usare le nuove API, se possibile.

Un'origine live, chiamata anche origine push, riceve i dati in tempo reale. Gli esempi includono l'acquisizione video e le trasmissioni di rete. In generale, un'origine dinamica non può controllare la frequenza in cui arrivano i dati.

Un filtro viene considerato come un'origine attiva se una delle seguenti è true:

Se un filtro di origine live fornisce un orologio, Filter Graph Manager preferisce l'orologio quando sceglie l'orologio di riferimento del grafico. Per altre informazioni, vedere Orologi di riferimento .

Latency

La latenza di un filtro è il tempo necessario per elaborare un esempio. Per le origini in tempo reale, la latenza viene determinata dalle dimensioni del buffer usato per contenere esempi. Si supponga, ad esempio, che il grafico del filtro abbia un'origine video con una latenza di 33 millisecondi (ms) e un'origine audio con una latenza di 500 ms. Ogni fotogramma video arriva al renderer video di circa 470 ms prima che l'esempio audio corrispondente raggiunga il renderer audio. A meno che il grafico non compensa la differenza, l'audio e il video non verranno sincronizzati.

Le origini live possono essere sincronizzate tramite l'interfaccia IAMPushSource . Filter Graph Manager non sincronizza le origini live a meno che l'applicazione non consenta la sincronizzazione chiamando il metodo IAMGraphStreams::SyncUsingStreamOffset . Se la sincronizzazione è abilitata, Filter Graph Manager esegue query su ogni filtro di origine per IAMPushSource. Se il filtro supporta IAMPushSource, Filter Graph Manager chiama IAMLatency::GetLatency per recuperare la latenza prevista del filtro. L'interfaccia IAMPushSource eredita IAMLatency. Dai valori di latenza combinata, Filter Graph Manager determina la latenza massima prevista nel grafico. Chiama quindi IAMPushSource::SetStreamOffset per assegnare a ogni filtro di origine un offset di flusso, che tale filtro aggiunge ai timestamp generati.

Questo metodo è destinato principalmente all'anteprima live. Si noti tuttavia che un pin di anteprima su un dispositivo di acquisizione live (ad esempio una fotocamera) non imposta i timestamp sugli esempi che recapita. Pertanto, per usare questo metodo con un dispositivo di acquisizione live, è necessario visualizzare l'anteprima dal pin di acquisizione. Per altre informazioni, vedere Filtri di acquisizione video DirectShow.

Attualmente l'interfaccia IAMPushSource è supportata dal filtro acquisizione VFW e dal filtro Acquisizione audio .

Corrispondenza frequenza

Se un filtro renderer pianifica esempi usando un orologio di riferimento, ma il filtro di origine li produce usando un orologio diverso, glitch possono verificarsi nella riproduzione. Il renderer potrebbe essere eseguito più velocemente dell'origine, causando lacune nei dati. In alternativa, potrebbe essere eseguito più lento rispetto all'origine, causando un "raggruppamento di campioni", fino a quando a un certo punto il grafico rilascia campioni. In genere, un'origine dinamica non può controllare la frequenza di produzione, quindi il renderer deve corrispondere alle tariffe con l'origine.

Attualmente, solo il renderer audio esegue la corrispondenza della frequenza, perché glitch nella riproduzione audio sono più evidenti rispetto agli errori nel video. Per eseguire la corrispondenza della frequenza, il renderer audio deve selezionare un elemento rispetto al quale corrisponderà la frequenza. Usa l'algoritmo seguente:

  • Se il grafico non usa un orologio di riferimento, il renderer audio non tenta di corrispondere alle tariffe. Ogni volta che il grafico non ha un orologio di riferimento, gli esempi vengono sempre visualizzati immediatamente quando arrivano.
  • In caso contrario, se è presente un orologio di riferimento per il grafico, il renderer audio verifica se è presente un upstream di origine live usando i criteri descritti in precedenza. In caso contrario, il renderer audio non corrisponde alle tariffe.
  • Se è presente un upstream di origine live e tale origine espone l'interfaccia IAMPushSource nel relativo pin di output, il renderer audio chiama IAMPushSource::GetPushSourceFlags. Cerca uno dei flag seguenti:
    • AM_PUSHSOURCECAPS_INTERNAL_RM. Questo flag indica che il filtro di origine ha il proprio meccanismo di corrispondenza della frequenza, quindi il renderer audio non corrisponde alle tariffe.
    • AM_PUSHSOURCECAPS_NOT_LIVE. Questo flag indica che il filtro di origine non è davvero un'origine attiva, anche se espone l'interfaccia IAMPushSource . Pertanto, il renderer audio non corrisponde alle tariffe.
    • AM_PUSHSOURCECAPS_PRIVATE_CLOCK. Questo flag indica che il filtro di origine usa un orologio privato per generare i timestamp. In questo caso, il renderer audio corrisponde alle tariffe rispetto ai timestamp. Se gli esempi non dispongono di timestamp, tuttavia, il renderer ignora questo flag.
  • Se GetPushSourceFlags non restituisce flag (zero), il comportamento del renderer audio dipende dall'orologio del grafico e dal fatto che gli esempi dispongano di timestamp:
    • Se il renderer audio non è l'orologio del grafico, e gli esempi hanno timestamp, il renderer audio corrisponde alle tariffe rispetto ai timestamp.
    • Se gli esempi non dispongono di timestamp, il renderer audio tenta di corrispondere alla frequenza di dati audio in ingresso.
    • Se il renderer audio è l'orologio del grafico, prova a corrispondere alla velocità dei dati in ingresso.

Il motivo dell'ultimo caso è il seguente: se il renderer audio è l'orologio di riferimento e il filtro di origine usa lo stesso orologio per generare i timestamp, il renderer audio non può corrispondere alle tariffe rispetto ai timestamp. Se fosse stato fatto, in effetti si sta tentando di trovare la corrispondenza tra i tassi e se stesso, che potrebbe causare la deriva dell'orologio. Pertanto, in questo caso il renderer corrisponde alla frequenza di dati audio in ingresso.

Ora e orologi in DirectShow