Compartilhar via

Fontes dinâmicas

  • Artigo

[O recurso associado a esta página, DirectShow, é um recurso herdado. Foi substituído por MediaPlayer, IMFMediaEnginee Audio/Video Capture na Media Foundation. Esses recursos foram otimizados para Windows 10 e Windows 11. A Microsoft recomenda fortemente que o novo código use MediaPlayer, IMFMediaEngine e Audio/Video Capture no Media Foundation em vez de DirectShow, quando possível. A Microsoft sugere que o código existente que usa as APIs herdadas seja reescrito para usar as novas APIs, se possível.]

Uma fonte dinâmica, também chamada de de origem por push, recebe dados em tempo real. Exemplos incluem captura de vídeo e transmissões de rede. Em geral, uma fonte dinâmica não pode controlar a taxa na qual os dados chegam.

Um filtro será considerado uma fonte dinâmica se qualquer um dos seguintes valores for verdadeiro:

Se um filtro de origem dinâmica fornecer um relógio, o Gerenciador de Grafo de Filtro preferirá esse relógio quando escolher o relógio de referência do grafo. Consulte relógios de referência para obter mais informações.

de Latência

A latência de um filtro é a quantidade de tempo que leva o filtro para processar uma amostra. Para fontes dinâmicas, a latência é determinada pelo tamanho do buffer usado para armazenar amostras. Por exemplo, suponha que o grafo de filtro tenha uma fonte de vídeo com uma latência de 33 milissegundos (ms) e uma fonte de áudio com uma latência de 500 ms. Cada quadro de vídeo chega ao renderizador de vídeo cerca de 470 ms antes que o exemplo de áudio correspondente atinja o renderizador de áudio. A menos que o grafo compense a diferença, o áudio e o vídeo não serão sincronizados.

As fontes dinâmicas podem ser sincronizadas por meio da interfaceIAMPushSource. O Gerenciador de Grafo de Filtro não sincroniza fontes dinâmicas, a menos que o aplicativo habilite a sincronização chamando o método IAMGraphStreams::SyncUsingStreamOffset. Se a sincronização estiver habilitada, o Gerenciador de Grafos de Filtro consultará cada filtro de origem para IAMPushSource. Se o filtro der suporte a IAMPushSource, o Gerenciador do Grafo de Filtro chamará IAMLatency::GetLatency para recuperar a latência esperada do filtro. (A interface IAMPushSource herda IAMLatency.) Nos valores de latência combinados, o Gerenciador de Grafo de Filtro determina a latência máxima esperada no grafo. Em seguida, ele chama IAMPushSource::SetStreamOffset para dar a cada filtro de origem um deslocamento de fluxo, que esse filtro adiciona aos carimbos de data/hora gerados.

Esse método destina-se principalmente à visualização ao vivo. No entanto, observe que um pino de visualização em um dispositivo de captura ao vivo (como uma câmera) não define carimbos de data/hora nos exemplos que ele fornece. Portanto, para usar esse método com um dispositivo de captura ao vivo, você deve visualizar a partir do pino de captura. Para obter mais informações, consulte Filtros de Captura de Vídeo do DirectShow.

Atualmente, a interfaceIAMPushSource é compatível com o filtro de Captura de VFW e o filtro de Captura de Áudio.

de correspondência de taxa de

Se um filtro de renderizador agendar exemplos usando um relógio de referência, mas o filtro de origem os produzir usando um relógio diferente, falhas poderão ocorrer na reprodução. O renderizador pode ser executado mais rápido que a origem, causando lacunas nos dados. Ou pode ser mais lento do que a origem, fazendo com que os exemplos sejam "agrupado", até que, em algum momento, o grafo remova amostras. Normalmente, uma fonte dinâmica não pode controlar sua taxa de produção, portanto, em vez disso, o renderizador deve corresponder as taxas com a origem.

Atualmente, somente o renderizador de áudio executa a correspondência de taxa, pois falhas na reprodução de áudio são mais perceptíveis do que falhas no vídeo. Para executar a correspondência de taxa, o renderizador de áudio deve selecionar algo em relação ao qual ele corresponderá às taxas. Ele usa o seguinte algoritmo:

  • Se o grafo não estiver usando um relógio de referência, o renderizador de áudio não tentará corresponder às taxas. (Sempre que o grafo não tem relógio de referência, os exemplos são sempre renderizados imediatamente quando chegam.)
  • Caso contrário, se houver um relógio de referência para o grafo, o renderizador de áudio verificará se há uma fonte dinâmica upstream usando os critérios descritos anteriormente. Caso contrário, o renderizador de áudio não corresponderá às taxas.
  • Se houver uma fonte dinâmica upstream e essa fonte expor a interface IAMPushSource em seu pino de saída, o renderizador de áudio chamará IAMPushSource::GetPushSourceFlags. Ele procura um dos seguintes sinalizadores:
    • AM_PUSHSOURCECAPS_INTERNAL_RM. Esse sinalizador significa que o filtro de origem tem seu próprio mecanismo de correspondência de taxa, portanto, o renderizador de áudio não corresponde às taxas.
    • AM_PUSHSOURCECAPS_NOT_LIVE. Esse sinalizador significa que o filtro de origem não é realmente uma fonte dinâmica, embora exponha a interface IAMPushSource. Portanto, o renderizador de áudio não corresponde às taxas.
    • AM_PUSHSOURCECAPS_PRIVATE_CLOCK. Esse sinalizador significa que o filtro de origem está usando um relógio privado para gerar carimbos de data/hora. Nesse caso, o renderizador de áudio corresponde às taxas em relação aos carimbos de data/hora. (No entanto, se os exemplos não tiverem carimbos de data/hora, o renderizador ignorará esse sinalizador.)
  • Se GetPushSourceFlags não retornará sinalizadores (zero), o comportamento do renderizador de áudio dependerá do relógio de grafo e se os exemplos têm carimbos de data/hora:
    • Se o renderizador de áudio não for o relógio de grafo, e os exemplos tiverem carimbos de data/hora, o renderizador de áudio corresponderá às taxas em relação aos carimbos de data/hora.
    • Se os exemplos não tiverem carimbos de data/hora, o renderizador de áudio tentará corresponder à taxa de dados de áudio de entrada.
    • Se o renderizador de áudio for o relógio de grafo, ele tentará corresponder à taxa de dados de entrada.

O motivo do último caso é o seguinte: se o renderizador de áudio for o relógio de referência e o filtro de origem estiver usando o mesmo relógio para gerar carimbos de data/hora, o renderizador de áudio não poderá corresponder às taxas com os carimbos de data/hora. Se isso acontecesse, na verdade, estaria tentando corresponder as taxas consigo mesmo, o que poderia fazer com que o relógio se descompasse. Portanto, nesse caso, o renderizador corresponde à taxa de dados de áudio de entrada.

hora e relógios no directshow