Recherche avancée

Sur d’autres sites (15442)

• Proxying an RTSP url using an RTSP Proxy Server

  21 juin 2018, par Sleeba Paul

  I have a use case where I need to restream an RTSP URL.

  For all the below cases, Live555 is built locally by cloning the source.

  For all the below cases, required ports are opened for RTSP in respective servers.

  First I set up a file to be streamed using Live555MediaServer. This is in an AWS instance (AWS1).

  ./Live555MediaServer ashi.webm gives

  rtsp://public_IP_of_instance:8554/ashi.web

  I check whether an incoming stream is working or not, by trying to play it in VLC player. This incoming stream is working fine and playing well on VLC.

  Now, to restream, I tried Live555ProxyServer. Now incoming stream from AWS1 is restreamed to another URL by running Live555ProxyServer on my Mac.

  ./Live555ProxyServer rtsp://public_IP_of_instance_one:8554/ashi.web gives,

  rtsp://localhost:8554/ProxyStream

  This URL is also playable in VLC.

  Now I setup another AWS instance (AWS2) and run ProxyServer on it, listening to AWS1.

  That is,

  ./Live555ProxyServer rtsp://public_IP_of_instance_one:8554/ashi.web gives,

  rtsp://public_IP_of_instance_two:8554/ProxyStream

  This URL is not playable.

  I tried using -t flag for TCP instead of UDP. I tried checking the incoming RTSP stream with ffprobe and the stream is showing all the required details.

  What could be the possible reason ? What is the missing piece in this pipeline ? Do we’ve great industry-grade open source RTSP servers ?

  EDIT :

  I don’t know what is exactly happened, but using VLC as the client to check the stream was the problem. I moved to ffmpeg and tried to write it to a file using

  ffmpeg -i rtsp://public_IP_of_instance_two:8554/proxyStream -acodec copy -vcodec copy abc.webm

  So the stream from ProxyServer is fine.

  The lead to the change of client was the repeated warning from live555ProxyServer about outdated firmware explained here.

  I’m currently using VLC Version 3.0.3 Vetinari (Intel 64bit) in Mac which is the latest version. Maybe VLC is using an old version of Live555 internally.

• 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.