Discussion :

[Advance_]

Bonjour à tous,

Je suis en train de réaliser un projet de Vidéo Surveillance. J'utilise Silverlight côté client (je pense que c'est évident d'après le titre ^^ ) et un service web Duplex WCF. Mon client est divisé en 2 : 1 client diffuseur (diffuse l'image de sa webcam sur le serveur) et un client visualiseur (récupère l'image sur le serveur et l'affiche).
Pour une question de simplicité, mon client transmet des images (pour l'instant 1 par seconde) et non un flux vidéo.

Mon projet et quasiment fini, mais j'ai cependant un gros problème. Je vais vous expliquez brièvement comment fonctionne mon appli et vous présenter ce problème :

Mon client diffuseur va poster à intervalle régulier l'image de sa webcam, grâce à un Timer. Pour l'instant tout va bien.

Mon client visualiseur va récupérer cette image à intervalle régulier aussi, grâce à un DispatcherTimer (j'aurais pu aussi utiliser un Timer). Et c'est là que j'ai un problème. La méthode est bien appelé, mais le problème est qu'il faut que j'attende 5 secondes avant d'avoir ma valeur de retour (image). Pourquoi est-ce si long, je n'en sais rien.
Mais avant que l'image n'arrive, le client a déjà fait une nouvelle requête au serveur, donc le temps pour que cette image parvienne au client est repoussé de 5 secondes et ainsi de suite pour toutes les autres images. Ce qui fait que lorsque j'arrête mon DispatcherTimer, il n'y a plus d'appels de méthode donc les images peuvent arriver et c'est ce qu'elles font. Je les ai toutes d'un coup.

J'ai essayé en mettant la fréquence du DispatcherTimer à 15 secondes et je n'ai pas ce problème comme les valeurs de retour ont le temps d'arriver jusqu'au client.


Auriez vous une solution à mon problème, qui est, si je ne me trompe pas, dû au fait que les échanges faits avec Silverlight sont Asynchrone.


Merci d'avance pour vos réponses.

[Invité]

Auriez vous une solution à mon problème, qui est, si je ne me trompe pas, dû au fait que les échanges faits avec Silverlight sont Asynchrone.

En lisant dés le début, je savais que le problème serait en rapport l'intervalle de temps qui est d'une seconde. Pour la lenteur des réponses c'est normal c'est du client/serveur. Il y a envoi vers + reception du serveur et je doute que ces deux actions soient instantanées.

Le plus simple c'est :

• d'obliger ton client à lire un flux vidéo (apparemment t'aimes pas ça)
• de dire à ton à timer de n'envoyer une autre requête vers le serveur si et seulement la réponse de la dernière requête est bien reçue. Pour cela tu utilises un flag IsBusy que tu assignes à true lors de l'envoie d'une requête (bien sûr tu vérifies si il est à false avant d'envoyer la requête) et à false lorsque la requête est terminée.

[anthyme]

Ton image est brut peut etre ? Si c'est du bitmap c'est normal que ce soir long ! Il faudrait compresser.

[Invité]

Question bête : vu que tu renvoies des images à intervalle déterminé. Comment fais-tu pour le son ?

[Arnard]

En vidéosurveillance le son est secondaire, du moment que tu as x images à la seconde, ça suffit à la plupart des besoins !

[Advance_]

Merci pour vos réponses.

Ton image est brut peut etre ? Si c'est du bitmap c'est normal que ce soir long ! Il faudrait compresser.

En faite pour l'instant je fais avec des string (j'aurais peut être dû préciser dsl), pour les tests et pour que se soit plus simple. C'est pour ça que je trouve que c'est long. Mais sinon je vais utiliser un writeablebitmap.

Le plus simple c'est :
d'obliger ton client à lire un flux vidéo (apparemment t'aimes pas ça)

En faite j'ai fait avec des images parce que je pensais que ça allait être plus simple. Est-ce tu pourrais me développer un peu plus sur ce point si c'est possible? Si ce n'est pas trop dure et pas trop long je vais me lancer dans cette voie. En faite il ne me reste qu'une semaine pour finir ce projet, j'ai rencontré plein de problèmes tout au long du projet, c'était la première fois que j'utilisais Silverlight et WCF et je faisais du développement web aussi poussé.

Edit : J'ai regarder un peu sur google et j'ai trouvé ça : http://msdn.microsoft.com/fr-fr/library/cc668792.aspx
C'est ça qu'il faut utiliser?

de dire à ton à timer de n'envoyer une autre requête vers le serveur si et seulement la réponse de la dernière requête est bien reçue. Pour cela tu utilises un flag IsBusy que tu assignes à true lors de l'envoie d'une requête (bien sûr tu vérifies si il est à false avant d'envoyer la requête) et à false lorsque la requête est terminée.

Merci pour l'astuce, mais du coup je n'aurais qu'une image toutes les 4 secondes environ. Tu aurais un petit lien qui décrit son fonctionne et comment l'utiliser, parce que j'ai cherché un peu et je n'ai pas été satisfait de mes recherches. A la limite si ce n'est pas parfait mais que ça marche, je pense que ça passera à la soutenance de projet.

[Arnard]

je vois déjà un élément à étudier : la durée côté serveur pour générer l'image et la sérialiser en byte[]... Essaies de mettre un StopWatch côté serveur et de logger les mesures... De plus, pour de la vidéosurveillance, il aurait été bien de te renseigner sur les pratiques de cet univers, la vidéo, tu peux voir ça comme un byte[] à l'affichage, mais des protocoles spéciaux existent, comme rtp/rtsp, pour faire transiter ça de manière optimisée.

De plus, quelle est la résolution de ta caméra ? Une caméra HD induira un surcoût en temps de traitement et de communication.

Data Service n'est pas fait pour ça. A mon sens, test déjà pour déterminer le pourquoi du mets autant de temps pour récupérer une image, la première optimisation est là...

Tu vises quelle vitesse d'affichage ? 6 img/Sec ? 12 ?

[The_badger_man]

Merci pour vos réponses.

Edit : J'ai regarder un peu sur google et j'ai trouvé ça : http://msdn.microsoft.com/fr-fr/library/cc668792.aspx
C'est ça qu'il faut utiliser?

Ce que je ne comprend pas c'est pourquoi tu utilises un timer avec un service web Duplex WCF.
Avec ce type de service, lorsque le serveur reçoit une image, ton client en est immédiatement notifié, et cela automatiquement, sans avoir à faire toi même la requête.