Playback of my RTSP streamed video choppy

Kerry Calvert kerry.calvert at micropower.com
Wed Apr 8 15:30:42 PDT 2015


I have built a gstreamer pipeline to play 1280x720 h264 encoded video, making the stream available through the GStreamer RTSP server.   My video playback is choppy on all players I have tried (VLC, Milestone, Avigilon, etc).

VLC complains about pictures maybe being too late to be displayed and picture IS to late to be displayed, which is consistent with choppy rendering.

My pipeline is as follows: appsrc is-live=true name=h264appsrc blocksize=8192 ! h264parse ! rtph264pay name=pay0 pt=96 config-interval=5 perfect-rtptime=false

My code putting data into the app src is scanning the input video stream and breaking it into NAL units.  Each NAL unit is then put into a GSTBUFFER, and the PTS timestamp assigned to the GSTBUFFER is the timestamp of the previous GSTBUFFER + incremental time per frame rate.  So for 5FPS, the timestamps would go 0, 200ms, 400ms, 600ms,800ms, etc.  This algorithm gives us the ability to clearly organize the video data into frames to be played back at a given framerate.

I have the pipeline using gst_app_src_set_callbacks() so the I get a callback when the pipeline needs data.  When I get this callback I feed a NAL unit residing in a GSTBUFFER to the app src with the appropriate frame timestatmp, and repeat until I get the enough_data callback.  The feeding of the GSTBUFFERS to the appsrc occurs in a thread that is enabled and disabled by the needs data and enough data callbacks, the GStreamer modules calling my callbacks are not blocked.

In my encoding, each NAL unit (I and P frames only) is a frame, emitted by my camera at the defined frame rate.

When I look at the flow of my thread pushing data to the appsrc until the enough data/need data cycle repeats, it is pretty much on the edge of feeding in enough GSTBUFFERS to meet the frame rate requirement.

When monitoring the packet flow in Wireshark, I see packets stop flowing from my stream to the VLC player for 200-500 milliseconds.  VLC is griping about packets being late almost non-stop, and my video is choppy.

When I point VLC at a competitors IP camera streaming 1280x720 H264, VLC does not complain at all.   Wireshark shows packet flow stopping for 10's of milliseconds vs my 100's of milliseconds.

I feel like something is inefficient in GStreamer's rtp packetizing or in its ability to push packets onto the network at the desired timing.  I have the same problem whether I run my camera at 10fps or 5fps.

I am looking for some hints for how to determine where this bottleneck is.  I need to determine if the problem is indeed in GStreamer or is in the network layer.

Thanks for your help.

Kerry Calvert
Manager Software Engineering

MicroPower Technologies Inc.
Office: 858-914-5189
Cell: 619-823-2198
kerry.calvert at micropower.com<mailto:kerry.calvert at micropower.com>
www.micropower.com<http://www.micropower.com/>

[cid:4D0D7556-A446-40F0-B4A5-A3A400DF0565 at Home]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150408/be1577cd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 22105 bytes
Desc: image003.png
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150408/be1577cd/attachment-0001.png>


More information about the gstreamer-devel mailing list