Recherche avancée

Sur d’autres sites (6430)

• h264 : drop redundant initialization in init()

  21 mars 2015, par Anton Khirnov

  h264 : drop redundant initialization in init()
  There is no real advantage to initializing any of those in init,
  
  assuming yuv420, before the real stream parameters are known.
  

  • [DBH] libavcodec/h264.c

• Application Crashes With No Exception

  24 octobre 2017, par Frank Natoli

  Have a relatively complex C# Windows Forms application that makes use of C++ bridge DLL to call FFmpeg DLLS to concurrently write multiple MP4 files directly from imagery downloaded from real time cameras using a separate thread for each camera.

  On my Windows 7 development laptop, Toshiba Tecra with i7 vPro eight core CPU and 16GB RAM, and on customer laptop, application runs fine.
  But on customer desktop, configuration unknown, when the application finishes recording and begins downloading imagery from the real time cameras and thus begins calling FFmpeg DLLs, the application disappears without a trace, no exception message, no "program has stopped working", nothing. Normal program exit writes an "application exiting" message to a log file which is NOT happening, so I am reasonably certain the program is not normally exiting.
  What might result in a C# Windows Forms application crash with no exception report from Windows ?

• Portable YUV Drawing Context

  1er juin 2017, par Leif Andersen

  I have a stream of YUV data (from a video file) that I want to stream to a screen in real time. (Basically, I want to write a program that plays the video in real time.)

  As such, I am looking for a portable way to send YUV data to the screen. I would ideally like to use something portable so I don’t have to reimplement it for every major platform.

  I have found a few options, but all of them seem to have significant issues. They are :

  1. Use OpenGL directly, converting the YUV data to RGB. (And using the single quad for the whole screen trick.)

  This obviously won’t work because converting RGB to YUV on the CPU is going to be too slow for displaying images in real time.

  2. Use OpenGL, but use a shader to convert the YUV stream to RGB.

  This option is a bit better. Although the problem here is that (afaict), this will involve making two streams and splicing them together. It might work, but may have issues with larger resolutions.

  3. Instead use SDL, which has the option of creating a YUV context directly.

  The problem with this is I already am using a cross platform widget library for other aspects of my program (such as playback controls). As far as I can tell, SDL only opens up in its on (possibly borderless) window. I would ideally like my controls and drawing context to be in the same window. Which I can do with opengl, but not SDL.

  4. Use SDL, and also use something like Qt for the on screen widgets, use a message passing protocol to communicate between the two libraries. Have the (borderless) SDL window constantly move itself on top of the opengl window.

  While this approach is clever, it seems like the two windows could get out of sink easily making the user experience sub-optimal.

  5. Forget a cross platform library, do thinks OS specific, making use of hardware acceleration if present.

  This is a fine solution although its not cross platform.

  As such, is there any good way to draw YUV data to a screen that ideally is :

  1. Portable (at least to the major platforms).
  2. Fast enough to be real time.
  3. Allows other widgets in the same window.