Recherche avancée

Sur d’autres sites (11758)

• FPS from RTSP stream info does not match actual framerate

  17 mai 2021, par Krapow

  I have a 25FPS RTSP stream coming from an IP-camera. I can successfully display the video stream. But when analyzing the stream with ffmpeg (ffprobe actually), I observe fewer frames per second rate :

  


  $ ffprobe -rtsp_transport tcp -i rtsp://camera_ip:554/stream -select_streams v:0 -show_frames -show_entries frame=coded_picture_number,pkt_pts_time -of csv=p=0
Stream #0:0: Video: h264 (Main), yuvj420p(pc, bt709, progressive), 640x480, 25 fps, 25 tbr, 90k tbn, 50 tbc
0.400000,0
0.080000,1
0.120000,2
0.200000,3
0.240000,4
0.320000,5
0.360000,6
0.440000,7
0.480000,8
0.560000,9
0.600000,10
0.680000,11
0.720000,12
0.800000,13
0.840000,14
0.920000,15
0.960000,16
1.040000,17
1.080000,18
1.160000,19
1.200000,20
1.280000,21
1.320000,22
1.400000,23
1.440000,24
1.520000,25
1.560000,26
1.640000,27
1.680000,28
1.760000,29
1.800000,30
1.880000,31
1.920000,32
2.000000,33


  


  We can clearly see the 80ms gap between some of the frames, resulting in a 16fps stream.

  


  I have observed the same framerate issue with GStreamer (printing information in the rtpjitterbuffer indicates the frame gap is sometimes 80ms and sometimes 40ms). But the weird thing is, I encountered the same issue with an HDMI-RJ45 decoder, and I doubt the same issue comes from 2 different devices.
I didn't get much more informations using -loglevel debug or trace.
Does anybody have an idea about what is going wrong in the stream ?

  


  (I used ffprobe 4.2.3 and the last "2021-05-09-git-8649f5dca6-full_build-www.gyan.dev" with the same results, and GStreamer 1.16.2 with a pipeline like "urisourcebin ! h264depay ! h264parse ! fakesink")

  


  EDIT : The camera skipping of frames was caused by the activation of a third stream in the options. I find it really weird that it skips exactly the same frames every seconds. However, I still haven't found the cause of the downrate on my RTSP encoder.
Anyway, this was actually hardware related and not software related.

  


• Does this code contain a potential memory leak ?

  26 juillet 2017, par Johnnylin

  Here is the code :

  cv::Mat YV12ToBRG24_FFmpeg(unsigned char* pYUV, int width,int height)
  
  {
  
      if (width < 1 || height < 1 || pYUV == nullptr){
  
          return cv::Mat();
  
      }
  
  
  
      cv::Mat result(height,width,CV_8UC3, cv::Scalar::all(0));
  
      uchar* pBGR24 = result.data;
  
  
  
      AVFrame* pFrameYUV = av_frame_alloc();
  
      pFrameYUV->width = width;
  
      pFrameYUV->height = height;
  
      pFrameYUV->format = AV_PIX_FMT_YUV420P;
  
      av_image_fill_arrays(pFrameYUV->data, pFrameYUV->linesize, pYUV, AV_PIX_FMT_YUV420P, width, height, 1);
  
  
  
      //U,V exchange
  
      uint8_t * ptmp=pFrameYUV->data[1];
  
      pFrameYUV->data[1]=pFrameYUV->data[2];
  
      pFrameYUV->data[2]=ptmp;
  
  
  
      AVFrame* pFrameBGR = av_frame_alloc();
  
      pFrameBGR->width = width;
  
      pFrameBGR->height = height;
  
      pFrameBGR->format = AV_PIX_FMT_BGR24;
  
      av_image_fill_arrays(pFrameBGR->data, pFrameBGR->linesize, pBGR24, AV_PIX_FMT_BGR24, width, height, 1);
  
  
  
      struct SwsContext* imgCtx = nullptr;
  
      imgCtx = sws_getContext(width,height,AV_PIX_FMT_YUV420P,width,height,AV_PIX_FMT_BGR24,SWS_BILINEAR,0,0,0);
  
      if (imgCtx != nullptr){
  
          sws_scale(imgCtx,pFrameYUV->data,pFrameYUV->linesize,0,height,pFrameBGR->data,pFrameBGR->linesize);
  
          sws_freeContext(imgCtx);
  
          imgCtx = nullptr;
  
          ptmp = nullptr;
  
          pBGR24 = nullptr;
  
          av_frame_free(&pFrameYUV);
  
          av_frame_free(&pFrameBGR);
  
          return result;
  
      }
  
      else{
  
          sws_freeContext(imgCtx);
  
          imgCtx = nullptr;
  
          ptmp = nullptr;
  
          pBGR24 = nullptr;
  
          av_frame_free(&pFrameYUV);
  
          av_frame_free(&pFrameBGR);
  
          return cv::Mat();
  
      }
  
  }

  This function is called every 40 ms (25 fps) and I saw a significant memory increase after several days(like 12GB). But if I ran this code for hours, the memory leak problem would not be obvious enough to be observed.

  Can anyone help ?
  Thanks.

• Prevent suspend event when streaming video via HTML video tag

  24 septembre 2014, par jasongullickson

  I seem to be having the opposite problem of most people who are streaming video using the HTML video tag ; I’m saturating the client with data.

  When playing a long video served via ffserver (webm container) everything works great but eventually the browser (Chrome in this case) will begin throwing "suspend" events. After a number of these ( 50-100), a "stalled" event will fire and playback will stop.

  I believe the problem is that once Chrome has buffered a certain amount of video it goes into "suspend" and stops downloading more data. I’ve tested this theory by throttling the speed at which video data is delivered, and if I keep the delivered frame rate close to the playback rate, I can prevent this from happening, but of course deliberately holding back server performance isn’t ideal.

  What I’m looking for is either a way to suppress this "suspend" behavior altogether, or alternatively a way to respond to the event that prevents the eventual "stalled" state.

  Presumably the browser at some point exits the "suspend" state and begins requesting data again, but I haven’t actually observed this occurring. I’m using a chain of mpeg2 -> ffmpeg -> ffserver to stream the video so if the browser is attempting to resume loading data I don’t see the request in my application. I could use a proxy or a sniffer to watch for the traffic but I would expect that maybe there is an ffserver log that can tell me the same thing ? In any event if it’s attempting to resume the download it’s failing, and there’s no indication server-side that there’s a reason for the request to fail (in fact I can pull up the same video feed from ffserver and see it playing correctly).

  So I feel like I’ve isolated this to a client-side playback issue, and one where the browser is voluntarily giving up on loading the data, but I’m not sure how to convince it to "not do that", or at least attempt to resume when it runs the buffer dry.