Recherche avancée

Sur d’autres sites (8326)

• Remove some redundant NULL checks and fix a free on error return.

  3 mars 2012, par Tim Terriberry

  Remove some redundant NULL checks and fix a free on error return.
  ref_frame_data was being allocated with the aligned allocator, but
  
   freed with the normal _ogg_free() function on failure, which
  
   doesn’t work.
  
  This would only cause a problem if there was just enough memory to
  
   satisfy the reference frame allocation (just over 4.5 or 9 bytes
  
   per pixel) but not enough for the fragment buffer offets (1/16 or
  
   1/8th byte per pixel).
  git-svn-id : http://svn.xiph.org/trunk/theora@18219 0101bb08-14d6-0310-b084-bc0e0c8e3800
  

  • [DH] lib/internal.c
  • [DH] lib/state.c

• android ffmpeg opengl es render movie

  18 janvier 2013, par broschb

  I am trying to render video via the NDK, to add some features that just aren't supported in the sdk. I am using FFmpeg to decode the video and can compile that via the ndk, and used this as a starting point. I have modified that example and instead of using glDrawTexiOES to draw the texture I have setup some vertices and am rendering the texture on top of that (opengl es way of rendering quad).

  Below is what I am doing to render, but creating the glTexImage2D is slow. I want to know if there is any way to speed this up, or give the appearance of speeding this up, such as trying to setup some textures in the background and render pre-setup textures. Or if there is any other way to more quickly draw the video frames to screen in android ? Currently I can only get about 12fps.

  glClear(GL_COLOR_BUFFER_BIT);
  
  glEnableClientState(GL_VERTEX_ARRAY);
  
  glEnableClientState(GL_TEXTURE_COORD_ARRAY);
  
  glBindTexture(GL_TEXTURE_2D, textureConverted);
  
  
  
  //this is slow
  
  glTexImage2D(GL_TEXTURE_2D, /* target */
  
  0, /* level */
  
  GL_RGBA, /* internal format */
  
  textureWidth, /* width */
  
  textureHeight, /* height */
  
  0, /* border */
  
  GL_RGBA, /* format */
  
  GL_UNSIGNED_BYTE,/* type */
  
  pFrameConverted->data[0]);
  
  
  
  glEnableClientState(GL_TEXTURE_COORD_ARRAY);
  
  glTexCoordPointer(2, GL_FLOAT, 0, texCoords);
  
  glVertexPointer(3, GL_FLOAT, 0, vertices);
  
  glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_BYTE, indices);
  
  glDisableClientState(GL_VERTEX_ARRAY);
  
  glDisableClientState(GL_TEXTURE_COORD_ARRAY);

  EDIT
  I changed my code to initialize a gltextImage2D only once, and modify it with glSubTexImage2D, it didn't make much of an improvement to the framerate.

  I then modified the code to modify a native Bitmap object on the NDK. With this approach I have a background thread that runs that process the next frames and populates the bitmap object on the native side. I think this has potential, but I need to get the speed increased of converting the AVFrame object from FFmpeg into a native bitmap. Below is currently what I am using to convert, a brute force approach. Is there any way to increase the speed of this or optimize this conversion ?

  static void fill_bitmap(AndroidBitmapInfo*  info, void *pixels, AVFrame *pFrame)
  
  {
  
  uint8_t *frameLine;
  
  
  
  int  yy;
  
  for (yy = 0; yy < info->height; yy++) {
  
      uint8_t*  line = (uint8_t*)pixels;
  
      frameLine = (uint8_t *)pFrame->data[0] + (yy * pFrame->linesize[0]);
  
  
  
      int xx;
  
      for (xx = 0; xx < info->width; xx++) {
  
          int out_offset = xx * 4;
  
          int in_offset = xx * 3;
  
  
  
          line[out_offset] = frameLine[in_offset];
  
          line[out_offset+1] = frameLine[in_offset+1];
  
          line[out_offset+2] = frameLine[in_offset+2];
  
          line[out_offset+3] = 0;
  
      }
  
      pixels = (char*)pixels + info->stride;
  
  }
  
  }

• Revision cbc249ba00 : Fix encoder mem allocation when picture size is changed After the picture size

  31 juillet 2012, par Attila Nagy

  Changed Paths : Modify /vp8/encoder/onyx_if.c Fix encoder mem allocation when picture size is changed After the picture size was changed to a bigger one, the internal memory was corrupted and multithreaded encoder was deadlocking. Memory for last frame's MVs, segmentation map and active map (...)