Ignoring errors of fdsink

[Arnout Vandecappelle]

 Hoi all,

 I have a pipeline with a tee element connected to several fdsink elements.  
Each fdsink writes to a socket, which can be terminated by the remote end at
any time.  If this happens, the chain function of fdsink posts an error on
the bus and returns GST_FLOW_ERROR.

 Since I want the pipeline to continue when one of the clients disconnects, I
handle the error message on the bus and remove the fdsink.  This often works.  
Indeed, the GST_FLOW_ERROR is captured by a queue in the pipeline and doesn't
arrive at the tee element.  Unfortunately, it is possible that the next
buffer is pushed into the queue before I can handle the error message.  In
that case, the queue returns a GST_FLOW_ERROR as well, it goes all the way up
to the source element, which sends an EOS down the pipeline.

 Is there any way to intercept the error before it passes the queue?

 If there is no solution, I think I'll patch the tee element to (optionally)
ignore downstream errors until all pads are in error.

 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

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Wim Taymans]

On Thu, 2009-05-14 at 16:19 +0200, Arnout Vandecappelle wrote:

> Hoi all,
>
>  I have a pipeline with a tee element connected to several fdsink elements.  
> Each fdsink writes to a socket, which can be terminated by the remote end at
> any time.  If this happens, the chain function of fdsink posts an error on
> the bus and returns GST_FLOW_ERROR.
>
>  Since I want the pipeline to continue when one of the clients disconnects, I
> handle the error message on the bus and remove the fdsink.  This often works.  
> Indeed, the GST_FLOW_ERROR is captured by a queue in the pipeline and doesn't
> arrive at the tee element.  Unfortunately, it is possible that the next
> buffer is pushed into the queue before I can handle the error message.  In
> that case, the queue returns a GST_FLOW_ERROR as well, it goes all the way up
> to the source element, which sends an EOS down the pipeline.
>
>  Is there any way to intercept the error before it passes the queue?
>
>  If there is no solution, I think I'll patch the tee element to (optionally)
> ignore downstream errors until all pads are in error.

You could use multifdsink, it handles client disconnects gracefully
without disrupting the dataflow.

Wim
>
>  Regards,
>  Arnout


------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Arnout Vandecappelle]

On Thursday 14 May 2009 16:29:50 Wim Taymans wrote:
> You could use multifdsink, it handles client disconnects gracefully
> without disrupting the dataflow.

 Works like a charm, thanks!

 Do you happen to also know of a way to find out when the last fd has been
removed, or should I keep track of them myself with the
client-added/client-removed signals?

 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

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Wim Taymans]

On Fri, 2009-05-15 at 14:03 +0200, Arnout Vandecappelle wrote:
> On Thursday 14 May 2009 16:29:50 Wim Taymans wrote:
> > You could use multifdsink, it handles client disconnects gracefully
> > without disrupting the dataflow.
>
>  Works like a charm, thanks!
>
>  Do you happen to also know of a way to find out when the last fd has been
> removed, or should I keep track of them myself with the
> client-added/client-removed signals?

It seems you have to do that yourself for now. A patch to implement a
property that returns the amount of clients would be accepted, though :)

Wim
>
>  Regards,
>  Arnout
>


------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Arnout Vandecappelle]

On Friday 15 May 2009 14:47:48 Wim Taymans wrote:

> On Fri, 2009-05-15 at 14:03 +0200, Arnout Vandecappelle wrote:
> > On Thursday 14 May 2009 16:29:50 Wim Taymans wrote:
> > > You could use multifdsink, it handles client disconnects gracefully
> > > without disrupting the dataflow.
> >
> >  Works like a charm, thanks!
> >
> >  Do you happen to also know of a way to find out when the last fd has
> > been removed, or should I keep track of them myself with the
> > client-added/client-removed signals?
>
> It seems you have to do that yourself for now. A patch to implement a
> property that returns the amount of clients would be accepted, though :)

 Me, submitting patches?  Never! :-)

http://bugzilla.gnome.org/show_bug.cgi?id=582819


--
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

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel