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

[Panagiotis Sourtzinos]

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.

Thanks
Panos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140601/c9af391f/attachment.html>