<html style="direction: ltr;">
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;"
bidimailui-detected-decoding-type="latin-charset" bgcolor="#FFFFFF"
text="#000000">
OK, this discussion now makes me go back to the original "dynamic
pipeline" documentation. If setting state to NULL does all the
"draining" work for sinks, why do we have to do the EOS loop with
the pad probes for non-sink elements? How are they any different?
Why wouldn't just blocking the pad and setting it to NULL be enough?<br>
<br>
On 12/31/2012 09:14 AM, Tim-Philipp Müller wrote:<br>
<blockquote cite="mid:1356966872.27218.11.camel@zingle" type="cite">
<pre wrap="">On Mon, 2012-12-31 at 16:53 +0200, Mohammed Sameer wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">It should not matter. If there's a leak or warning or crash, that's a
bug that needs to be fixed. But I would expect udpsink to be fairly
well-tested and robust in this respect.
Setting the sink to NULL state from a running pipeline is quite normal
when an application shuts down a pipeline. Whether you unlink upstream
before that or not should not make a difference in this case.
</pre>
</blockquote>
<pre wrap="">
I'm not yet familiar with 1.0 but I'm sure we cannot generalize.
At least in 0.10, sink element might be responsible for memory allocation and
it can free that memory when we set it to NULL. Of course GstBuffer is reference
counted and it should free the underlying memory segment when it gets destroyed
but think of hardware backed address segment which has to be either freed when
sink is not playing or leaked.
I hope I'm not mistaken here.
</pre>
</blockquote>
<pre wrap="">
The mechanisms are slightly different in 1.0 (bufferpools and memory
allocators and such are all exposed as part of the API now), but in
principle it's still the same.
You are right of course that sinks that do this kind of thing (allocate
special memory) must take care to make sure the memory doesn't get freed
while someone is still holding on to buffers. So you need to separate
that from the freeing of the sink element.
That doesn't change the fact that this should still work fine in
general, and if it doesn't, it's probably a bug somewhere (or a sink
plugin taking shortcuts for convenience).
But anyway, the question was about udpsink.
Cheers
-Tim
_______________________________________________
gstreamer-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>