Question

J'ai créé un serveur java, qui prend des captures d'écran, les redimensionne et les envoie via TCP / IP à mon application iPhone. L'application utilise ensuite nsInputStream pour recueillir les données d'image entrants, créer une instance NSMutableData avec le tampon d'octets, puis créer un objet UIImage pour afficher sur l'iPhone. Screenshare, essentiellement. Mon code iPhone pour collecter les données d'image est actuellement comme suit:

- (void)stream:(NSStream *)theStream handleEvent:(NSStreamEvent)streamEvent{


if(streamEvent == NSStreamEventHasBytesAvailable && [iStream hasBytesAvailable]){
        uint8_t buffer[1024];

    while([iStream hasBytesAvailable]){
        NSLog(@"New Data");

        int len = [iStream read:buffer maxLength:sizeof(buffer)];

        [imgdata appendBytes:buffer length:len];
        fullen=fullen+len;

        /*Here is where the problem lies.  What should be in this
         if statement in order to make it test the last byte of
         the incoming buffer, to tell if it is the End of Image marker
         for the end of incoming JPEG file?
         */
        if(buffer[len]=='FFD9'){
        UIImage *img = [[UIImage alloc] initWithData:imgdata];
        NSLog(@"NUMBER OF BYTES: %u", len);

        image.image = img;
        }
    }

}
}

Mon problème, comme l'indique le commentaire dans le code, est de trouver quand arrêter la collecte de données dans l'objet NSMutableData, et utiliser les données pour créer un UIImage. Il semble logique de chercher la fin du JPEG marqueur de fichier - marqueur de fin de l'image (EOI) (FFD9) - dans les octets entrants, comme l'image sera prêt pour l'affichage lorsque cela est envoyé. Comment puis-je tester cela? Je manque quelque chose soit sur la façon dont les données sont stockées, ou sur le marqueur dans le fichier JPEG, mais toute aide dans les tests pour ce serait grandement apprécié!

James

Était-ce utile?

La solution

Vous ne voulez évidemment pas fermer le flux parce que cela tue la performance.

Depuis que vous contrôlez la connexion client-serveur, envoyez sur le # d'octets dans l'image avant d'envoyer les données d'image. Mieux encore, envoyez vers le bas Nombre d'octets dans l'image, les données d'image, et un numéro de série facilement identifié à la fin afin que vous puissiez vérifier rapidement que les données ont effectivement arrivé.

Beaucoup plus facile et plus efficace que la vérification en fait la marque de fin de fichier. Bien que, bien sûr, vous pouvez aussi simplement vérifier que, après le # d'octets ont été reçus, aussi. Assez facile.

Bien sûr, tout cela va être totalement inefficace pour des fins de style partage d'écran dans tous les cas sauf hors du commun. Dans la plupart des cas, seule une petite partie de l'écran à miroir change réellement à chaque trame. Si vous essayez d'envoyer tout l'écran avec chaque image, vous saturez rapidement votre connexion et du côté client horriblement et ne répond pas laggy.

Étant donné que c'est un marché extrêmement mature, il y a des tonnes de solutions et un bon nombre de bits open source à partir de laquelle vous pouvez tirer une solution pour répondre à vos besoins (voir VNC, par exemple).

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top