<div dir="ltr">Hi Jan,<div><br></div><div>I've tested the patch and it works, but I think that is a workaround of the real problem, this solution is not valid in all situations, think for example in a valve that stops dropping and the sink part of the pipeline has changed, in this case will be tricky to manage the caps to include the previous one.</div>
<div><br></div><div>I've been investigating the issue a little bit further and I think that the problem is that the pad does not check if its reconfiguring. It just acts like the configuration has already being done sending previous caps event when sticky events are asked to be resend. I fact no special action (except marking the pad with the reconfigure flag) seems to be done when reconfigure events arrives to a pad.</div>
<div><br></div><div>I attach a log where you can see that the pads has problems doing a query because of sticky events.</div><div><br></div><div>Regards</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2014-06-14 13:04 GMT+02:00 Jan Schmidt <span dir="ltr"><<a href="mailto:thaytan@noraisin.net" target="_blank">thaytan@noraisin.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 07/06/14 01:10, Jose Antonio Santos Cadenas wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Sebastian,<br>
</blockquote>
<br>
Hi Jose,<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The problem is not with the content of the buffers, thats something that<br>
can be solved easily, the problem is that the source raises a not<br>
negotiated error to the bus and stops the streaming thread. It seems<br>
that the source pad of the queue has a problem sending the sticky events<br>
to its peer (the one that sends the reconfigure event):<br>
<br>
0:00:00.031095032 3140 0x2547450 WARN GST_PADS<br>
gstpad.c:3726:gst_pad_peer_<u></u>query:<queue1:src> could not send sticky events<br>
.......<br>
0:00:00.032475711 3140 0x2613b50 ERROR negotiation_test<br>
negotiation_test/main.c:130:<u></u>bus_message: Error: error message:<br>
0x7fd114002280, time 99:99:99.999999999, seq-num 91, element<br>
'audiotestsrc1', GstMessageError, gerror=(GError)NULL,<br>
debug=(string)"gstbasesrc.c\(<u></u>2933\):\ gst_base_src_loop\ \(\):\<br>
/GstPipeline:negotiation_test_<u></u>1/GstAudioTestSrc:<u></u>audiotestsrc1:\012streaming\<br>
task\ paused\,\ reason\ not-negotiated\ \(-4\)";<br>
<br>
</blockquote>
<br></div>
I've attached a patch for your test case that makes it run successfully to completion. The change is to ensure that when you renegotiate, the sink still accepts buffers with the old caps until the caps change. Because the new caps are first in the list, they will be preferred over the old caps as the chosen format by upstream.<br>
<br>
Regards,<br>
Jan.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
...<br>
<br>
<br>
2014-06-06 11:42 GMT+02:00 Sebastian Dröge <<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.com</a><br></div>
<mailto:<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.<u></u>com</a>>>:<div><div class="h5"><br>
<br>
On Fr, 2014-06-06 at 10:54 +0200, Jose Antonio Santos Cadenas wrote:<br>
> Hi,<br>
><br>
> I've been investigating about reconfiguration of pipelines<br>
dynamically and<br>
> I run into negotiation problems while changing the caps of a<br>
stream while<br>
> playing.<br>
><br>
> I've developed a program to test the issue, you can download it<br>
here:<br>
><br>
> <a href="https://github.com/jcaden/negotiation_test" target="_blank">https://github.com/jcaden/<u></u>negotiation_test</a><br>
><br>
> Let me explain the test a little bit (copied from the repo README):<br>
><br>
> This test creates a simple pipeline and forces caps<br>
renegotiation once the<br>
> GST_MESSAGE_STREAM_START is received on bus. It terminates<br>
correctly if<br>
> the<br>
> appsink receives a buffer with the renegotiated format.<br>
><br>
> This program runs a test continuously until it fails or it is<br>
executed a<br>
> number of times selected by the used with -n option (1000000 by<br>
default).<br>
><br>
> If option -q is given, the pipeline is this:<br>
><br>
> -------------- ------- ---------<br>
> | audiotestsrc | -> | queue | -> | appsink |<br>
> -------------- ------- ---------<br>
><br>
> This test frequently fails (1 on 15?), because audiotestsrc<br>
receive a<br>
> not negotiated error while pushing a buffer or because no<br>
buffer with<br>
> the new format is received.<br>
><br>
> If -q option is not present the pipeline is this:<br>
><br>
> -------------- ---------<br>
> | audiotestsrc | -> | appsink |<br>
> -------------- ---------<br>
><br>
> This second pipeline works properly and renegotiates correctly.<br>
><br>
> I'd like to know if I am suppose to do something else to perform the<br>
> renegotiation, currently I am blocking the appsink:sink pad to<br>
change the<br>
> appsink caps and send a reconfigure event, then I unblock the pad<br>
again.<br>
<br>
Renegotiation and the RECONFIGURE event in GStreamer are only "hints",<br>
not something that makes sure you immediately only get buffers in the<br>
new format. And especially if a queue is used it can be possible that<br>
there are still buffers with the old format inside the queue.<br>
<br>
Your sink must be able to handle (or at least silently drop) buffers in<br>
the old format after a reconfigure event.<br>
<br>
--<br>
Sebastian Dröge, Centricular Ltd - <a href="http://www.centricular.com" target="_blank">http://www.centricular.com</a><br>
Expertise, Straight from the Source<br>
<br>
______________________________<u></u>_________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.<u></u>freedesktop.org</a><br></div></div>
<mailto:<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.<u></u>freedesktop.org</a>><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/gstreamer-<u></u>devel</a><div class=""><br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.<u></u>freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/gstreamer-<u></u>devel</a><br>
<br>
</div></blockquote>
</blockquote></div><br></div>