Recherche avancée

Sur d’autres sites (8707)

• configure : Avoid requiring c99wrap for working around msys path issues

  14 novembre 2013, par Martin Storsjö

  configure : Avoid requiring c99wrap for working around msys path issues
  Msys is unable to convert unix style absolute paths to windows style
  
  paths when combined with certain multichar MSVC options such as
  
   Fo<file>. We used to work around this issue by passing them as two
  
  separate parameters separated by a space to c99wrap, which then mapped
  
  them back to the actual parameter format that MSVC uses.
  The only paths that actually are an issue are absolute unix style
  
  paths, and the only place such absolute paths are used with the output
  
  arguments (-Fo, -Fe, -Fi, -out :) are for the temp files within configure.
  By setting TMPDIR to . for msvc/icl builds, we never need to use
  
  absolute unix style paths for the file output, and we can use the
  
  actual proper form of the file output parameters. This avoids requiring
  
  the c99wrap wrapper for remapping the parameters for cases where the
  
  c99 converter isn’t invoked at all (MSVC2013 and ICL).
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DBH] configure

• Reading from a stream while its constantly being written to

  11 octobre 2017, par TomCrow

  I have a ip camera, which I need to read video stream from and get frames to bitmaps. For that I want to use NReco VideoConverter, which is ffmpeg .net wrapper. I use it like this :

  liveTask = ffMpeg.ConvertLiveMedia(inputStream, Format.h264, outputStream, Format.raw_video, new ConvertSettings() { CustomOutputArgs = "-pix_fmt rgb32" });
  
  liveTask.OutputDataReceived += new EventHandler(Recieved);
  
  liveTask.Start();

  Works fine, but my problem is that I need to read frames from that outputStream. The video converter writes to the stream constantly and calls my "Recieved" after every write. What I have is something like this :

  private void Recieved(object sender, EventArgs r)
  
  {
  
      int lenght = Width * Height * 4;
  
      if (outputStream.Length > lenght)
  
      {
  
          outputStream.Seek(0, SeekOrigin.Begin);
  
          byte[] buffer = new byte[lenght];
  
          int ret = outputStream.Read(buffer, 0, buffer.Length);
  
          Bitmap frame = CreateBitmapFromRawDataBuffer(buffer);
  
      }
  
  }

  Works great, but only for the first frame, cause the Seek is a problem, because I think position of the stream is always at the and and I also dont know how to check if there is written another frame, cause the lenght of the whole stream is only adding up. And that would be another problem, cause the streams lenght cant go up forever. The app is supposed to run nonstop 24/7, while decoding h264 data from a ip camera. Could anyone help me with this ? And if Iam using the stream the right way ? Thank you.

  Edit : For reading and writing together I know I could make custom stream with locking and separated positions for reading and writing, but what bothers me is the still adding lenght of the innerstream or outputstream in general and checking if there is next Width * Height * 4 bytes available for reading.

• swscale : fix sws_setColorspaceDetails after sws_init_context

  27 octobre 2023, par Niklas Haas

  swscale : fix sws_setColorspaceDetails after sws_init_context
  More commonly, this fixes the case of sws_setColorspaceDetails after
  
  sws_getContext, since the latter implies sws_init_context.
  The problem here is that sws_init_context sets up the range conversion
  
  and fast path tables based on the values of srcRange/dstRange at init
  
  time. This may result in locking in a "wrong" path (either using
  
  unscaled fast path when range conversion later required, or using
  
  scaled slow path when range conversion becomes no longer required).
  There are two way outs :
  1. Always initialize range conversion and unscaled converters, even if
  
     they will be unused, and extend the runtime check.
  
  2. Re-do initialization if the values change after
  
     sws_setColorspaceDetails.
  I opted for approach 1 because it was simpler and easier to reason
  
  about.
  Reword the av_log message to make it clear that this special converter
  
  is not necessarily used, depending on whether or not there is range
  
  conversion or YUV matrix conversion going on.
  

  • [DH] libswscale/swscale.c
  • [DH] libswscale/utils.c