Recherche avancée

Sur d’autres sites (7200)

• Extract frames as images from an RTMP stream in real-time

  7 novembre 2014, par SoftForge

  I am streaming short videos (4 or 5 seconds) encoded in H264 at 15 fps in VGA quality from different clients to a server using RTMP which produced an FLV file. I need to analyse the frames from the video as images as soon as possible so I need the frames to be written as PNG images as they are received.

  Currently I use Wowza to receive the streams and I have tried using the transcoder API to access the individual frames and write them to PNGs. This partially works but there is about a second delay before the transcoder starts processing and when the stream ends Wowza flushes its buffers causing the last second not to get transcoded meaning I can lose the last 25% of the video frames. I have tried to find a workaround but Wowza say that it is not possible to prevent the buffer getting flushed. It is also not the ideal solution because there is a 1 second delay before I start getting frames and I have to re-encode the video when using the transcoder which is computationally expensive and unnecessarily for my needs.

  I have also tried piping a video in real-time to FFmpeg and getting it to produce the PNG images but unfortunately it waits until it receives the entire video before producing the PNG frames.

  How can I extract all of the frames from the stream as close to real-time as possible ? I don’t mind what language or technology is used as long as it can run on a Linux server. I would be happy to use FFmpeg if I can find a way to get it to write the images while it is still receiving the video or even Wowza if I can find a way not to lose frames and not to re-encode.

  Thanks for any help or suggestions.

• Solid FFMPEG in background worker fails on user pc

  17 février 2015, par jon783

  I’m using Solid FFPEG to rip out individual frames from a video, I’m using this to ’play’ the video (so it rips out each frame). I’m using a background worker to keep the UI responsive. Running on my PC I have no problems, but on the test PC it will not display the frames, I get the below error from the background workers RunWorkerCompleted method.

  System.InvalidCastException: Unable to cast COM object of type 'System.__ComObject' to interface type 'CAVEditLib.ICAVConverter'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{59C19DEF-02ED-44CD-BFD8-2FD09DBDC9F9}' failed due to the following error: Error loading type library/DLL. (Exception from HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY)) at System.StubHelpers.StubHelpers.GetCOMIPFromRCW(Object objSrc, IntPtr pCPCMD, IntPtr& ppTarget, Boolean& pfNeedsRelease)
  
     at CAVEditLib.ICAVConverter.get_AVPrope()
  
     at RoutePlotter.VideoManager.UpdateAllFrames(Decimal frontNumericValue, Decimal backNumericValue, Decimal leftNumericValue, Decimal rightNumericValue)
  
     at RoutePlotter.MainForm.backgroundWorker_DoWork(Object sender, DoWorkEventArgs e)
  
     at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e)
  
     at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)

  The cavEditLib.dll file seems to be registered on the Test PC, but the background worker won’t work.

  Thanks fro any help.

• libavformat : Improve ff_configure_buffers_for_index for excessive deltas

  21 mars 2023, par Martin Storsjö

  libavformat : Improve ff_configure_buffers_for_index for excessive deltas
  Previously, the ff_configure_buffers_for_index function had
  
  upper sanity limits of 16 MB (1<<24) for buffer_size and
  
  8 MB (1<<23) for short_seek_threshold.
  However, if the index contained entries with a much larger
  
  delta, setting pos_delta to a value larger than the sanity
  
  limit, we would end up not increasing the buffer size at all.
  Instead, ignore the individual deltas that are excessive, but
  
  increase the buffer size based on the deltas that are below the
  
  sanity limit.
  Only count deltas that are below 1<<23, 8 MB ; pos_delta gets doubled
  
  before setting the buffer size - this matches the previous maximum
  
  buffer size of 1<<24, 16 MB.
  This can happen e.g. with a mov file with some tracks containing
  
  some samples that belong in the start of the file, at the end of
  
  the mdat, while the rest of the file is mostly reasonably interleaved ;
  
  previously those samples caused the maximum pos_delta to skyrocket,
  
  skipping any buffer size enlargement.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavformat/seek.c