Frame Rate slows Down

Robin Aproskie raproskie at tellumat.com
Fri Aug 22 06:45:51 PDT 2014


Hi  Thanks

The stream sets the IDC to encode one full frame per second. And that is what I'm seeing.

I did not try the rtpjitterbuffer it just seemed like extra overload. But I did manage a workaround. 

What I do when my cairoOverlay get called I increment a frame buffer, The overlay information is periodic and I check the last frame I overlaid. If the frames are the same I know I have lost the connection. All I do is Set the Pipeline to Paused to Ready to Playing.
As soon as the Udp stream comes back the pipeline some how reads the correct information and everything is seamless even My Record Pipeline.

I can reproduce the problem without removing the Stream/Network cable Buy Putting the pipeline into Pause and back to Playing. 

The problem also repairs itself if the source changes from Format (i.e. PAL to HD )

Thanks Robin

-----Original Message-----
From: gstreamer-devel [mailto:gstreamer-devel-bounces at lists.freedesktop.org] On Behalf Of Sebastian Dröge
Sent: 06 August 2014 09:28 AM
To: Discussion of the development of and with GStreamer
Subject: Re: Frame Rate slows Down

On Do, 2014-07-31 at 10:24 +0200, Robin Aproskie wrote:
> Hi
> 
> I have a Pipeline in  C  
> udpsrc->rtph264depay->queue->h264parse->queue->avdec_h264->queue->auto
> videoConvert->cairoOverlay->autoVideoConvert->d3dvideosink
> 
> The Stream is over a an IP Microwave Radio. (multicast UDP (RTP )h.264   )
> 
> It displays Fine and works at 50fps in PAL and 25 fps in HD I can Play 
> and Stop and replay the stream.
> 
> If the Radio Link goes Down and then comes Back up the Frame Rate of 
> the Diplay only shows at 1fps as far as I can See. If I stop the 
> stream and restart the stream it displays fine. so It seems the 
> Streaming in not a problem becasue this does not happen if I use VLC 
> (SDP Session)
> 
> Any Ideas Please on how to fix this, or to refresh the stream after signal is re-established?

That sounds like a problem with the timestamps somewhere. If you get debug logs with GST_DEBUG=basesink:6 there should be some information about why it drops everything and only shows a single frame per second as fallback (it's the fallback mechanism if every frame was too late to show anything at all).

Independent of that you should use rtpbin in your pipeline between udpsrc and the depayloader, and also have a queue immediately after udpsrc. See the example shell scripts in http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/tests/examples/rtp

--
Sebastian Dröge, Centricular Ltd - http://www.centricular.com Expertise, Straight from the Source
**********************************************************************
Relevant company disclaimers are available at the following addresses:
  Tellumat (Pty) Ltd e-mail:  mailto:disclaimer at tellumat.com?Subject=Tellumat_Disclaimer
  Web:   http://www.tellumat.com/email.aspx
**********************************************************************



More information about the gstreamer-devel mailing list