How to view FPS of received RTSP stream

[Aswin Pranav]

Hey Nicolas,

Thanks for your advice, but I have a couple of follow-up questions based on
my observations.
1) You were right, it was text-overlay = true (on a near-4K stream) that
was causing the near 5 s lag. However, even on this pipeline:
gst-launch-1.0 rtspsrc location= rtsp://10.20.12.191:8554/test name=r
latency=0 ! rtph264depay ! avdec_h264 ! fpsdisplaysink name=fpssink
text-overlay=true video-sink=xvimagesink sync=0 -v   => I get results like
this: /GstPipeline:pipeline0/GstFPSDisplaySink:fpssink: last-message =
rendered: 334, dropped: 0, current: 18.77, average: 19.07
Note that I am attempting to stream 30 fps video from source. If I average
a frame rate of 19 fps, where are the other frames? For sure they don't
show up under dropped, and I have latency = 0 (no jitterbuffer).

However, with the above pipeline but text-overlay= false, I get
near-realtime stream with results like this:
/GstPipeline:pipeline0/GstFPSDisplaySink:fpssink: last-message = rendered:
1234, dropped: 0, current: 30.68, average: 29.76

However, with sync=1, I *seem* to get a near realtime stream without any
dropped frames, but here is the log from the shell:
/GstPipeline:pipeline0/GstFPSDisplaySink:fpssink: last-message = rendered:
5, dropped: 5021, fps: 0.00, drop rate: 30.89
This log seems to update once every half-second, with about increase of 15
in the 'dropped' parameter.

I know I am probably beating around the bush, but what's going on here?
Which of these reflects the 'true' FPS?  Is there anything else I can do
about measuring the actual FPS? You mentioned something about a weird
timestamp, what can I do about it?

Thanks,
-Aswin


On Thu, 16 Jun 2016 at 18:32 Nicolas Dufresne <nicolas at ndufresne.ca> wrote:

>
> Le 16 juin 2016 5:36 PM, "Aswin Pranav" <aswin2pranav at gmail.com> a écrit :
> >
> > Thanks for the input guys, but now my problem is:
> > When my receiver pipeline is simply " gst-launch-1.0 rtspsrc location=
> rtsp://10.20.13.24:8554/test name=r latency=0 ! rtph264depay ! avdec_h264
> ! xvimagesink sync=0" it *appears* that my video is almost-realtime (150 ms
> latency between server and client using a stopwatch) and is rendering
> smoothly at 30 fps (this value was set at the server source). But then when
> I modify my pipeline to this: "gst-launch-1.0 rtspsrc location= rtsp://
> 10.20.13.24:8554/test name=r latency=0 ! rtph264depay ! avdec_h264 !
> fpsdisplaysink name=fpssink video-sink=xvimagesink sync=0 -v" I get
> considerable latency between server and client (almost 5 seconds), the
> video visibly stutters, and the frame rate comes up to an average of 18 ms
> with 0 dropped frames.
> >
> > When I set sync=1, all hell breaks loose and I get a drop rate of 30 fps
> (on avg)! I get maximum frame rendered per second . What is going on?! Does
> fpsdisplaysink influence the speed of my receiver pipeline in some manner?
> What can I do about it? Is there a lower overhead way of checking fps?
>
> By setting rtspsrc latency to 0 you prevent the jitterbuffer from doing
> its job, so you most likely have weird timestamp.. So forget about sync=1
> unless you increase the latency. Now, you should set the sync= on
> fpsdidplaysink, it will take care of the internal a sink. Overlay are
> expensive, for high resolution it could be too slow.
>
> >
> > Thanks.
> >
> >
> > On Wed, 15 Jun 2016 at 19:37 Nicolas Dufresne <nicolas at ndufresne.ca>
> wrote:
> >>
> >>
> >> Le 2016-06-15 16:03, "Sankar,Aswin Pranav" <apsankar at ufl.edu> a écrit :
> >> >
> >> > Hi all,
> >> >
> >> >
> >> > Here's my gstreamer receiver pipeline: gst-launch-1.0 rtspsrc
> location= rtsp://10.20.13.24:8554/test name=r latency=0 ! rtph264depay !
> avdec_h264 ! fpsdisplaysink name=fpssink text-overlay=false
> video-sink=xvimagesink signal-fps-measurements=true
> >> >
> >> >
> >> > When I launch this pipeline, I receive the rtp stream, but it appears
> in a normal window, i.e, like an xvimagesink. I cannot see any frame rate
> counter or indicator. What do I need to change?
> >>
> >> You have disabled the overlay, so the information will be posted as
> application message. Implement a bus handler to receive those. With
> gst-launch you can add the -m parameter to trace messages.
> >>
> >> >
> >> >
> >> > Thanks,
> >> >
> >> > -Aswin
> >> >
> >> >
> >> > _______________________________________________
> >> > gstreamer-devel mailing list
> >> > gstreamer-devel at lists.freedesktop.org
> >> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >> >
> >>
> >> _______________________________________________
> >> gstreamer-devel mailing list
> >> gstreamer-devel at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
> >
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160621/594bddf4/attachment-0001.html>