Recherche avancée

Sur d’autres sites (6289)

• avcodec/rl2 : Remove wrong check

  28 septembre 2022, par Andreas Rheinhardt

  avcodec/rl2 : Remove wrong check
  This check is intended to be avoid buffer overflows,
  
  yet there are four problems with it :
  
  1. It has an in-built off-by-one error : len == out_end - out
  
  is perfectly fine and nothing to worry about.
  
  This off-by-one error led to the pixel in the lower-right corner
  
  not being set properly for the back frame of the sample from
  
  the rl2 FATE-test. This pixel is copied to every frame which
  
  is the reason for the update to the reference file of said test.
  
  With this patch, the output of the decoder matches the output
  
  as captured from the reference decoder* (apart from the fact
  
  that said reference somehow lacks the top part of the frame
  
  (copied over from the background frame)).
  
  2. Given that the stride of the buffer may be different
  
  from the width of the video (despite one pixel taking one byte),
  
  there is a second check lateron making the first check redundant
  
  (if one returns immediately ; a simple break at the second check
  
  is not sufficient, because it only exits the inner loop).
  
  3. The check is based around the assumption of the stride being
  
  positive (it has this in common with the other check which
  
  will be fixed in a future commit).
  
  4. Even after fixing the off-by-one error, the check in
  
  question is still triggered by all the non-background frames
  
  in the FATE sample as well as by A1100100.RL2. In all these
  
  cases, they use len == 255 and val == 128. For videos with
  
  background frame this just means "copy from the background
  
  frame", which would be done anyway lateron.* Yet for videos
  
  without it copying it is necessary to avoid leaving
  
  uninitialized parts in the video.
  * : Available in https://samples.mplayerhq.hu/game-formats/voyeur-rl2/
  
  ** : Due to this, the code that copies the rest from the
  
  back frame is no longer executed for any of the samples
  
  available on the sample server. Given that these are only
  
  the files from the demo version of this game, I don't know
  
  whether this code is executed for any file in existence or not.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/rl2.c
  • [DH] tests/ref/fate/rl2

• 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.

  


• Revision 35677 : ajout d’un parametre optionnel "retour" au formulaire spipicious

  27 février 2010, par brunobergot@… — Log

  ajout d’un parametre optionnel "retour" au formulaire spipicious