Recherche avancée

Sur d’autres sites (12848)

• OpenGL and ffmpeg make video with stable fps

  27 août 2022, par Turgut

  I've made a program that takes multiple vidoes as inputs, have ffmpeg decode them, send them to opengl, then create a window using glfw, draw textures on the screen using those videos (Edits those textures), then I read the screen using glReadPixels so ffmpeg can encode it. I send the read frames to the encoder and it encodes it. I specify the fps on start, but the problem is the video is faster then it's supposed to be. Now I can do something like this :

  


  double pt_in_seconds = pts * (double)time_base.num / (double)time_base.den;
while (pt_in_seconds > glfwGetTime()) {
      glfwWaitEventsTimeout(pt_in_seconds - glfwGetTime());
}


  


  But the problem with this is that this approach makes the run-time really long. So if I input a 1 hour video I have to wait for 1 hours. If I don't use this code snippet it generates the output as fast as it can, but like I said the output video is faster than it's supposed to be. Whats shown in the glfw window is irrelevant, it's hidden anyways, it's just there to manipulate/merge input videos.

  


  Is there a better way for ffmpeg to stabilize the encoded information ? At the end of the day glfw just displays the decoded videos, since they are both on the same iteration.

  


  It looks roughly like this :

  


  ...
while(true)
{
   // The actual program originally reads every input inside a vector here.
   // But since the program itself is really long I just did this as a representation
   uint8_t* decoded_data = decoder.decode_one_frame();
   
   // draw_frame_on_screen returns glReadPixels result.
   uint8_t* screen_data = opengl_engine.draw_frame_on_screen(decoded_data);

   encoder.encode_one_frame(screen_data);
}


  


  Encoder is entirely just muxing.c from ffmpegs official docs, I've just removed the dummy image and added my screen_data as input.

  


  Using ubuntu, GLFW, GLAD, ffmpeg.

  


• avr32 : remove explicit support

  9 juin 2024, par Rémi Denis-Courmont

  avr32 : remove explicit support
  The vendor has long since switched to Arm, with the last product
  
  reaching their official end-of-life over 11 years ago. Linux support for
  
  the ISA was dropped 7 years ago. More importantly, this architecture was
  
  never supported by upstream GCC, and the vendor fork is stuck at version
  
  4.2, which FFmpeg no longer supports (as per C11 requirement).
  Presumably, this is still the case given the lack of vendor support.
  
  Indeed all of the code being removed here consisted of inline assembler
  
  scalar optimisations. A sane C compiler should be able to perform those
  
  automatically nowadays (with the sole exception of fast CLZ detection),
  
  but this is moot as this architecture is evidently dead.
  

  • [DH] configure
  • [DH] libavcodec/avr32/mathops.h
  • [DH] libavcodec/mathops.h
  • [DH] libavutil/avr32/intreadwrite.h
  • [DH] libavutil/intreadwrite.h

• fate/webp : add test for webp lossless decoding (rgb and rgba)

  25 juin 2016, par Martin Vignali

  fate/webp : add test for webp lossless decoding (rgb and rgba)
  output have been compared with official decoding tool output (dwebp)
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] tests/fate/image.mak
  • [DH] tests/ref/fate/webp-rgb-lossless
  • [DH] tests/ref/fate/webp-rgba-lossless