Recherche avancée

Sur d’autres sites (5367)

• Display FFMPEG decoded frame in a GLFW window

  17 juin 2020, par Infecto

  I am implementing the client program of a game where the server sends encoded frames of the game to the client (via UDP), while the client decodes them (via FFMPEG) and displays them in a GLFW window. 
My program has two threads :

  



  

  1. Thread 1 : renders the content of the uint8_t* variable dataToRender

  


  2. Thread 2 : keeps obtaining frames from the server, decodes them and updates dataToRender accordingly

  


  



  Thread 1 does the typical rendering of a GLFW window in a while-loop. I have already tried to display some dummy frame data (a completely red frame) and it worked :

  



  while (!glfwWindowShouldClose(window)) {
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
    ...

    glBindTexture(GL_TEXTURE_2D, tex_handle);
    glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, window_width, window_height, 0, GL_RGB, GL_UNSIGNED_BYTE, dataToRender);
    ...
    glfwSwapBuffers(window);
}


  



  Thread 2 is where I am having trouble. I am unable to properly store the decoded frame into my dataToRender variable. On top if it, the frame data is originally in YUV format and needs to be converted to RGB. I use FFMPEG's sws_scale for that, which also gives me a bad dst image pointers error output in the console. Here's the code snippet responsible for that part :

  



          size_t data_size = frameBuffer.size();  // frameBuffer is a std::vector where I accumulate the frame data chunks
        uint8_t* data = frameBuffer.data();  // convert the vector to a pointer
        picture->format = AV_PIX_FMT_RGB24;
        av_frame_get_buffer(picture, 1);
        while (data_size > 0) {
            int ret = av_parser_parse2(parser, c, &pkt->data, &pkt->size,
                data, data_size, AV_NOPTS_VALUE, AV_NOPTS_VALUE, 0);
            if (ret < 0) {
                fprintf(stderr, "Error while parsing\n");
                exit(1);
            }
            data += ret;
            data_size -= ret;

            if (pkt->size) {
                swsContext = sws_getContext(
                    c->width, c->height,
                    AV_PIX_FMT_YUV420P, c->width, c->height,
                    AV_PIX_FMT_RGB24, SWS_BILINEAR, NULL, NULL, NULL
                );
                uint8_t* rgb24[1] = { data };
                int rgb24_stride[1] = { 3 * c->width };
                sws_scale(swsContext, rgb24, rgb24_stride, 0, c->height, picture->data, picture->linesize);

                decode(c, picture, pkt, outname);
                // TODO: copy content of picture->data[0] to "dataToRender" maybe?
            }
        }


  



  I have already tried doing another sws_scale to copy the content to dataToRender and I cannot get rid of the bad dst image pointers error. Any advice or solution to the problem would be greatly appreciated as I have been stuck for days on this.

  


• Evolution #3638 : Utiliser la rechercher Fulltext par défaut pour le critère {recherche}

  6 mai 2017, par guytarr °

  Gilles VINCENT a écrit :

  Je suis d’accord que la recherche fulltext ne fonctionne qu’avec mysql.
  Mais est-ce une raison suffisante pour tirer les performances vers le bas ?
  Pour ma part je ne pense pas.

  Ensuite, si le plugin Fulltext répond à la demande (à savoir pourvoir faire une recherche sur "chercher un mot" qui soit pertinente) alors peut-être qu’il faut le mettre par défaut dans plugins-dist, et ne l’activer que si les conditions sur la base de données sont réunies. Comme cela, on ne change rien à l’api générale, et les recherches deviennent meilleurs. Tout le monde est satisfait !

  Qu’en dites-vous ?

  Une simple remarque : je pense qu’il faut proposer lorsque c’est possible une recherche basée sur un outil qui est conçu pour (sphinx, elasticsearch).
  Autant pour la partie publique c’est au cas par cas, autant pour l’espace privé on sait à quoi s’attendre et on pourrait proposer une solution intelligente (et performante) basée là-dessus et où plugins (objets) pourraient se brancher simplement.
  Le fulltext est pas mal mais il y a des contraintes de version, de moteur sgbd, etc... Je pense que l’on va s’embêter pour obtenir un moins bon résultat au lieu de déléguer ça à un outil qui sait bien le faire.

• Anomalie #3647 : #INTRODUCTION

  11 janvier 2016, par Ivan Lewkowitz

  Hello Franck, désolé, voici plus de détails :

  Il s’agit d’un Spip 3.0.21 mis à jour en 3.1 via Spip_loader.
  J’ai suivi les indications de maj. Les plugins sont compatibles (couteau suisse).
  Base de données : MySQL (exportée du site online via l’admin de Spip et réimportée en local, toujours via l’admin Spip, même version évidemment). Le fichier se termine en .sqlite (et non .dump ou autre).
  Le codage de la base est tout en utf-8, idem pour le site lui-même.

  Online, le site est en Spip 3.1 et Php 5.2 (module Apache) alors que dans Mamp, c’est Php 5.6.10 qui tourne (ou Php 7 au choix). Quand on passe d’une version à l’autre de Php en local, la première balise #INTRODUCTION est ignorée (le DIV accueillant l’intro est vide au lieu d’afficher un paragraphe).
  Ça c’est pour l’intro dans une boucle ARTICLES.
  

  
  [(#INTRODUCTION800|liens_ouvrants|propre)]
  

  Mais bizarrement, j’appelle aussi l’intro en survol sur des titres d’articles plus loin, et ça fonctionne sans problème :
  

  Donc… mystère. Donc pour résumer ma première balise intro ne saute qu’en local et avec Php 7 (donc rien de dramatique). J’ai pas essayé d’activer Php 7 chez mon hébergeur ; c’est proposé en beta encore.
  A ta dispo.