Recherche avancée

Sur d’autres sites (10407)

• Error while capturing video via RTSP from a network camera using OpenCV and FFMPEG

  29 octobre 2012, par Dídac Pérez

  I am using OpenCV and FFMPEG to capture frames from a network camera using RTSP. The point is that OpenCV successfully loads the FFMPEG .dll but icvCreateFileCapture_FFMPEG_p returns false in the following code of cap_ffmpeg.cpp :

  virtual bool open( const char* filename )
  
  {
  
      close();
  
  
  
      icvInitFFMPEG();
  
      if( !icvCreateFileCapture_FFMPEG_p )
  
          return false;
  
      ffmpegCapture = icvCreateFileCapture_FFMPEG_p( filename );
  
      return ffmpegCapture != 0;
  
  }

• How to get the http status code after call avformat_seek_file of ffmpeg ?

  22 avril 2024, par 砸石头的西西弗

  How to get the http status code after call avformat_seek_file of ffmpeg to get a http url video ?

  


  I have a video source which is provided as a http url link, I want to get a snapshot of it , so I call avformat_seek_file to find a frame, but I find that it returns value is not < 0, even if the http call not return 200 or 206, so I want to know how to get the response of http calling in avformat_seek_file.

  &#xA;

• avformat/mux : Fix double-free when using AVPacket.opaque_ref

  1er septembre 2021, par Andreas Rheinhardt

  avformat/mux : Fix double-free when using AVPacket.opaque_ref
  Up until now, ff_write_chained() copied the packet (manually, not with
  
  av_packet_move_ref()) from a packet given to it to a stack packet whose
  
  timing and stream_index is then modified before being sent to another
  
  muxer via av_(interleaved_)write_frame(). Afterwards it is intended to
  
  sync the fields of the packet relevant to freeing again ; yet this only
  
  encompasses buf, side_data and side_data_elems and not the newly added
  
  opaque_ref. The other fields are not synced so that the returned packet
  
  can have a size > 0 and data != NULL despite its buf being NULL (this
  
  always happens in the interleaved codepath ; before commit
  
  fe251f77c80b0512ab8907902e1dbed3f4fe1aad it could also happen in the
  
  noninterleaved one). This leads to double-frees if the interleaved
  
  codepath is used and opaque_ref is set.
  This commit therefore changes this by directly reusing the packet
  
  instead of a spare packet. Given that av_write_frame() does not
  
  change the packet given to it, one only needs to restore the timing
  
  information to return it as it was ; for the interleaved codepath
  
  it is not possible to do likewise*, because av_interleaved_write_frame()
  
  takes ownership of the packets given to it and returns blank packets.
  
  But precisely because of this users of the interleaved codepath
  
  have no legitimate expectation that their packet will be returned
  
  unchanged. In line with av_interleaved_write_frame() ff_write_chained()
  
  therefore returns blank packets when using the interleaved codepath.
  Making the only user of said codepath compatible with this was trivial.
  * : Unless one wanted to create a full new reference.
  Reviewed-by : Lynne <dev@lynne.ee>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavformat/internal.h
  • [DH] libavformat/mux.c
  • [DH] libavformat/segment.c