GMFBridge Problème lors de la recherche de graphique source

Question

J'essaie d'utiliser GMFBridge pour basculer entre plusieurs graphiques de tampon de flux et il me semble avoir deux problèmes.

Voici un diagramme des graphiques: http://massivefailure.net/dshowgraphsalt.jpg

1. Le VMR sur le graphique source de pont qui est relié au pont de rendu graphique est très saccadé - l'affichage d'une nouvelle image toutes les 4-5 secondes. Si je recherche le graphe source branché au graphe de rendu du pont, alors toutes les sorties (les VMR dans la source de pont connectée et les graphes de rendu ainsi que la sortie sur le rendu externe) s'arrêtent pendant environ une minute. Une fois qu'il reprend, le problème du problème n ° 1 a disparu.

J'ai essayé de déconnecter et arrêter le pont rendu graphique avant de chercher et de reconnecter et courir après la recherche, mais je reste toujours des problèmes, soit le gel ou la VMR sur le graphique source de pont connecté affichant un cadre environ toutes les 10 secondes.

type de problème sans importance:

J'ai eu tees intelligents où les tees sont infinies, avec les VMRS connectés aux broches d'aperçu, mais après avoir demandé qu'ils jouerais de retour à 1.5-2x le taux normal jusqu'à ce qu'ils rattrapé avec le flux en direct. Y a-t-il une manière saine de le réparer afin que je puisse retourner à un té futé?

Answer 1

Le pont ajuste les horodatages sur les échantillons entrant dans le graphe de rendu, car l'heure du flux n'est pas la même dans les deux graphiques. Toutefois, le filtre inftee envoie le même échantillon à ses deux sorties. Ainsi, le VMR du graphe source sera (parfois) invité à rendre des échantillons dont les horodatages ont été ajustés dans le graphe de rendu. La lecture saccadée que vous voyez est le résultat d'une tentative de rattrapage sans succès par le VMR.

Vous devez copier les données, ou au moins copier les métadonnées, afin que les horodatages modifiés n'apparaissent pas dans le graphe source. La façon la plus simple de le faire avec des données vidéo non compressées est d'insérer une transformation de copie telle que le convertisseur d'espace colorimétrique (probablement entre l'inftee et l'évier de pont). Pour vous aider à déboguer des problèmes de ce type, vous pouvez créer un fichier vide c: \ gmfbridge.txt et le code de pont créera un journal incluant les ajustements d'horodatage et la latence. L'exemple GMFBridge démontre que vous pouvez diviser une tâche en plusieurs graphes séparés avec très peu de surcharge, et pour cette raison, il évite de copier les données ou d'introduire de nouveaux threads sur un pipeline de livraison. Cependant, pour certaines tâches, cela est trop compliqué et une solution plus simple, plus découplée, est plus appropriée, comme un pool de tampons avec un thread de travail en aval. Sur l'autre question: les tirs intelligents horodatages de la sortie d'aperçu, et ainsi les échantillons en aval du té sont rendus dès qu'ils arrivent. Dans un graphe de capture normal, les échantillons sont horodatés avec leur temps de capture - si vous les transmettez directement à un moteur de rendu, ils seront toujours en retard pour le rendu. La solution appropriée consiste à ajuster les horodatages pour la latence de la capture au rendu, mais la solution brute de suppression des horodatages fonctionne dans la plupart des cas. Le tee intelligent fait cela en dupliquant l'objet IMediaSample, mais en pointant sur le même tampon de données (donc il copie les métadonnées mais pas les données). Notez que le tee intelligent rejettera également les échantillons sur la sortie d'aperçu s'il pense (selon les heuristiques de 1996) que la sortie de capture est en retard.

G