What is the proper way to pause/resume an RTP stream?

[Andres Gonzalez]

Hi,

I am streaming an RTP video stream using appsrc and rtpbin. It appears to be
working properly in that I can receive it on a separate local host, and the
timeoverlay of the stream time appears to be steady with no apparent
choppyness.

Question: what is the proper way to pause/resume a live RTP stream?  My
desired functionality is that the stream obviously stop, and when resumed,
it resumes with the current video forgetting about any of the frames that
were dropped when paused.

It appears there are at least 2 issues, the first being the RTP timestamps. 
Currently, if I go to the READY state, then wait several seconds, then back
to the PLAYING state, my streams does indeed stop and then resume, but now
the video is choppy and uneven, and is also delayed by what appears to be
the amount of time the stream was paused. It appears that the pipeline is
retaining several buffers, and indeed, when I then exit the application,
there are many unrefed buffers that are then freed.

I have tried several things: (1) setting queue property flush-on-eos=true,
(2) setting queue property max-size-buffers=10, (3) setting the video buffer
flag to GST_BUFFER_FLAG_LIVE, (4) going to NULL state instead of READY for
pausing, then back to PLAYING.

The 2nd issue I would think is ensuring that the encoder (x264enc) generates
an immediate IDR key frame when the stream resumes after being paused for a
period of time. I am currently configuring the x264enc to generate key
frames every few seconds so I am only occasionally seeing some blockyness
when the stream resumes.

Question: if I transition to NULL for pausing the stream, then back to
PLAYING for resuming the stream, I am assuming that the x264enc element will
reset the encoder so that it will start with a key I frame.  Is this
assumption correct?

Thanks,

-Andres



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/What-is-the-proper-way-to-pause-resume-an-RTP-stream-tp4675941.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.