Playback and recording freezes while receiving RTSP H264 stream (1.2.4)

Sebastian Dröge sebastian at centricular.com
Fri Jun 6 02:33:59 PDT 2014


On So, 2014-06-01 at 01:23 +0100, Panagiotis Sourtzinos wrote:
> Hello everyone,
> 
> I dont know if this is a bug or if I am missing something.
> I am using gstreamer 1.2.4
> I have tried to just playback, or record or both from an IP camera using
> RTSP.
> The pipeline for displaying and recording is the following:
> 
> gst-launch-1.0 -v -e rtspsrc location="rtsp:........"   ! queue
> max-size-bytes=0 max-size-buffers=0 max-size-time=0 flush-on-eos=true !
> rtph264depay ! h264parse  !
> "video/x-h264,width=704,height=576,framerate=(fraction)25/1,stream-format=byte-stream"
> ! tee name=t ! queue max-size-bytes=0 max-size-buffers=0 max-size-time=0  !
> avdec_h264 ! autovideosink sync=false  t. ! queue ! filesink
> location=test-write.avi
> 
> 
> What happens is that, everything goes well for 27 minutes and then the
> display freezes the recording stops, while the process is still running. I
> have tried with changing the buffer-mode , the ntp-sync, the latency but
> still always the same result. I have run the pipeline with level 4 debug
> and the last entry before the freeze is:
> 
> d3dvideosink
> d3dhelpers.c:1813:d3d_render_buffer:<autovideosink0-actual-sink-d3dvideo>
> Render 0:27:46.002722198
> 
> and generally seems ok.
> Then while nothing happens if I terminate the process no log is added to
> the debug log. However if I leave for a while the time to pass and then
> kill the process I can see entries in the debug log like:
> 
> rtpjitterbuffer
> gstrtpjitterbuffer.c:2160:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0>
> Packet #32766 too late as #65534 was already popped, dropping
> .
> .
> .
> rtpjitterbuffer
> gstrtpjitterbuffer.c:2160:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0>
> Packet #65534 too late as #65534 was already popped, dropping
> 
> and then goes to
> 
> rtpjitterbuffer rtpjitterbuffer.c:764:rtp_jitter_buffer_insert: duplicate
> packet 0 found
> 0:54:40.586390831 11832 0000000002791A80 WARN         rtpjitterbuffer
> gstrtpjitterbuffer.c:2168:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0>
> Duplicate packet #0 detected, dropping
> 
> 
> it is always the #65534 there, dont know if it is just a coincidence but
> also it is very close to the number 65536 which is the 10000000000000000 in
> binary.
> 
> Please if you need any other information let me know.

Can you run your application in a debugger and check what all threads
are doing when it freezes? Also is there something in the debug logs
that suggests that any queues are full? That would be my first guess for
such a problem if it's not a deadlock somewhere...

-- 
Sebastian Dröge, Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140606/039922c6/attachment.sig>


More information about the gstreamer-devel mailing list