Condividi tramite

Debug dei filtri DirectShow

  • Articolo

[La funzionalità associata a questa pagina, DirectShow, è una funzionalità legacy. È stata sostituita da MediaPlayer, IMFMediaEngine 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, IMFMediaEngine e Audio/Video Capture in Media Foundation invece di DirectShow, quando possibile. Microsoft suggerisce che il codice esistente che usa le API legacy venga riscritto per usare le nuove API, se possibile.

Molte delle funzionalità di debug descritte in questo argomento vengono implementate nella libreria di classi di base DirectShow. Per altre informazioni, vedere Classi di base DirectShow.

Controllo asserzione

Usare il controllo delle asserzioni in modo liberale. Le asserzioni possono verificare i presupposti che si fanno nel codice sulle precondizioni e le postcondizioni. DirectShow fornisce diverse macro di asserzione. Per altre informazioni, vedere Assert e Breakpoint Macros.

Nomi di oggetti

Nelle compilazioni di debug è presente un elenco globale di oggetti che derivano dalla classe CBaseObject . Man mano che gli oggetti vengono creati, vengono aggiunti all'elenco. Quando vengono distrutti, vengono rimossi dall'elenco. Per visualizzare un elenco di tali oggetti, chiamare la funzione DbgDumpObjectRegister .

Il metodo del costruttore per la classe di base CBaseObject , e la maggior parte delle classi derivate, include un parametro per il nome dell'oggetto. Assegnare nomi univoci agli oggetti per identificarli. Utilizzare la macro NAME quando si dichiara il nome, in modo che il nome venga allocato solo nelle compilazioni di debug. Nelle build di vendita al dettaglio il nome diventa NULL.

Registrazione debug

La funzione DbgLog visualizza i messaggi di debug durante l'esecuzione del programma. Usare questa funzione per tracciare l'esecuzione dell'applicazione o del filtro. È possibile registrare i codici restituiti, i valori delle variabili e qualsiasi altra informazione pertinente.

Ogni messaggio di debug ha un tipo, ad esempio LOG_TRACE o LOG_ERROR, e un livello di debug, che indica l'importanza del messaggio. I messaggi con livelli di debug inferiori sono più importanti di quelli con livelli più elevati.

Nell'esempio seguente un filtro ipotetico disconnette un pin da una matrice di pin. Se il tentativo di disconnessione ha esito positivo, il filtro visualizza un messaggio di LOG_TRACE. Se il tentativo non riesce, viene visualizzato un messaggio di LOG_ERROR:

hr = m_PinArray[iPin]->Disconnect();
if (FAILED(hr))
{
    DbgLog((
        LOG_ERROR, 
        1, 
        TEXT("Could not disconnect pin %d. HRESULT = %#x", 
        iPin, 
        hr
        ));
 
   // Error handling code (not shown).
}
DbgLog((LOG_TRACE, 3, TEXT("Disconnected pin %d"), iPin));

Quando si esegue il debug, è possibile impostare il livello di debug per ogni tipo di messaggio. Inoltre, ogni modulo (DLL o eseguibile) gestisce i propri livelli di debug. Se si esegue il test di un filtro, aumentare i livelli di debug per la DLL che contiene il filtro.

Per altre informazioni, vedere Funzioni di output di debug.

Sezioni critiche

Per semplificare il rilevamento dei deadlock, includere asserzioni che determinano se il codice chiamante possiede una determinata sezione critica. Le funzioni CritCheckIn e CritCheckOut indicano se il thread chiamante possiede una sezione critica. In genere, queste funzioni vengono chiamate dall'interno di una macro assert.

È anche possibile usare la funzione DbgLockTrace per tracciare quando vengono mantenute o rilasciate sezioni critiche.

Debug in DirectShow