Dropping buffers when pausing live stream

[Arnout Vandecappelle]

 Hoi all,

 My application is displaying live media that comes in over http or rtsp.  
Sometimes the stream has to be paused (because it is invisible and I don't
want to waste CPU cycles on decoding).  However, simply pausing the pipeline
will eventually disconnect the source because of overflowing socket buffers.  
Also, when playing again, I don't want to render a second of old data.

 The solution I had in mind is to port the dropping behaviour of queue to
multiqueue.  Then I pause the sink elements, which makes the queues fill up
and triggers the dropping.  When playing again, there is still a bit of stale
data but it is recent stale data (and probably rendering delay will cause some
more data to be dropped in the near future).

 Does this sound like a good idea?  Anybody have a better idea?

 Regards,
 Arnout

--
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 [phone]
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  D206 D44B 5155 DF98 550D  3F2A 2213 88AA A1C7 C933

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[attaboy]

Arnout,

 

I can't figure out how to reply on this list and responding by e-mail...

 

Did you consider the valve element for this purpose? The element can be placed upstream of your processor intensive elements and turned on or off using the "drop" property.  When drop is set to TRUE the element drops data thereby preventing buffer overflows.

 

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad-plugins/html/gst-plugins-bad-plugins-valve.html

 

Bill

 

On 10/9/09, Arnout Vandecappelle <[hidden email]> wrote:

Hoi all,

My application is displaying live media that comes in over http or rtsp.
Sometimes the stream has to be paused (because it is invisible and I don't
want to waste CPU cycles on decoding).  However, simply pausing the pipeline
will eventually disconnect the source because of overflowing socket buffers.
Also, when playing again, I don't want to render a second of old data.

The solution I had in mind is to port the dropping behaviour of queue to
multiqueue.  Then I pause the sink elements, which makes the queues fill up
and triggers the dropping.  When playing again, there is still a bit of stale
data but it is recent stale data (and probably rendering delay will cause some
more data to be dropped in the near future).

Does this sound like a good idea?  Anybody have a better idea?

Regards,
Arnout

--
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 [phone]
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  D206 D44B 5155 DF98 550D  3F2A 2213 88AA A1C7 C933

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Olivier Crête-2]

Hi,

If your data is video (and has keyframes), you may want to do something
smarter (like dropping old frames only when you get a new keyframe), so
you can start displaying data faster when you restart playback.

Olivier

On Fri, 2009-10-09 at 18:40 +0200, Arnout Vandecappelle wrote:

> Hoi all,
>
>  My application is displaying live media that comes in over http or rtsp.  
> Sometimes the stream has to be paused (because it is invisible and I don't
> want to waste CPU cycles on decoding).  However, simply pausing the pipeline
> will eventually disconnect the source because of overflowing socket buffers.  
> Also, when playing again, I don't want to render a second of old data.
>
>  The solution I had in mind is to port the dropping behaviour of queue to
> multiqueue.  Then I pause the sink elements, which makes the queues fill up
> and triggers the dropping.  When playing again, there is still a bit of stale
> data but it is recent stale data (and probably rendering delay will cause some
> more data to be dropped in the near future).
>
>  Does this sound like a good idea?  Anybody have a better idea?
>
>  Regards,
>  Arnout
>

--

Olivier Crête
[hidden email]

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Arnout Vandecappelle]

On Saturday 10 October 2009 16:48:58 William Gerecke wrote:
> Did you consider the valve element for this purpose? The element can be
> placed upstream of your processor intensive elements and turned on or off
> using the "drop" property.  When drop is set to TRUE the element drops data
> thereby preventing buffer overflows.
>
> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad-pl
> ugins/html/gst-plugins-bad-plugins-valve.html

 Nice one, I hadn't noticed it when searching with gst-inspect.

 However, it's a bit tricky to insert this element in the middle of
decodebin2, I think.  I don't see how that could be accepted in core
GStreamer.  In addition, as Olivier mentions, it's not good enough, because I
want to keep the last keyframe.  The queue implementation does that IIRC.

 Regards,
 Arnout

>
> Bill
>
> On 10/9/09, Arnout Vandecappelle <[hidden email]> wrote:
> > Hoi all,
> >
> > My application is displaying live media that comes in over http or rtsp.
> > Sometimes the stream has to be paused (because it is invisible and I
> > don't want to waste CPU cycles on decoding).  However, simply pausing the
> > pipeline
> > will eventually disconnect the source because of overflowing socket
> > buffers.
> > Also, when playing again, I don't want to render a second of old data.
> >
> > The solution I had in mind is to port the dropping behaviour of queue to
> > multiqueue.  Then I pause the sink elements, which makes the queues fill
> > up and triggers the dropping.  When playing again, there is still a bit
> > of stale
> > data but it is recent stale data (and probably rendering delay will cause
> > some
> > more data to be dropped in the near future).
> >
> > Does this sound like a good idea?  Anybody have a better idea?
> >
> > Regards,
> > Arnout

--
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 [phone]
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  D206 D44B 5155 DF98 550D  3F2A 2213 88AA A1C7 C933

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[sk_gst]

Hi,

Were you able to do this? I am trying to find out a way in which I can pause
the live video.
Below is my pipeline:
v4l2src -> queue -> h264parse -> avdec_h264 -> glupload -> glcolorconvert ->
gltransformation -> glimagesink

I want to simulate the behaviour where I pause the video at source, and
still be able to stream the last received frame in the sink, till the video
is replayed again.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel