Problems with renegotiation when using queues

Jose Antonio Santos Cadenas santoscadenas at gmail.com
Fri Jun 6 08:10:14 PDT 2014


Hi Sebastian,

The problem is not with the content of the buffers, thats something that
can be solved easily, the problem is that the source raises a not
negotiated error to the bus and stops the streaming thread. It seems that
the source pad of the queue has a problem sending the sticky events to its
peer (the one that sends the reconfigure event):

0:00:00.031095032  3140      0x2547450 WARN                GST_PADS
gstpad.c:3726:gst_pad_peer_query:<queue1:src> could not send sticky events
.......
0:00:00.032475711  3140      0x2613b50 ERROR       negotiation_test
negotiation_test/main.c:130:bus_message: Error: error message:
0x7fd114002280, time 99:99:99.999999999, seq-num 91, element
'audiotestsrc1', GstMessageError, gerror=(GError)NULL,
debug=(string)"gstbasesrc.c\(2933\):\ gst_base_src_loop\ \(\):\
/GstPipeline:negotiation_test_1/GstAudioTestSrc:audiotestsrc1:\012streaming\
task\ paused\,\ reason\ not-negotiated\ \(-4\)";

...


2014-06-06 11:42 GMT+02:00 Sebastian Dröge <sebastian at centricular.com>:

> On Fr, 2014-06-06 at 10:54 +0200, Jose Antonio Santos Cadenas wrote:
> > Hi,
> >
> > I've been investigating about reconfiguration of pipelines dynamically
> and
> > I run into negotiation problems while changing the caps of a stream while
> > playing.
> >
> > I've developed  a program to test the issue, you can download it here:
> >
> > https://github.com/jcaden/negotiation_test
> >
> > Let me explain the test a little bit (copied from the repo README):
> >
> >   This test creates a simple pipeline and forces caps renegotiation once
> the
> >   GST_MESSAGE_STREAM_START is received on bus. It terminates correctly if
> > the
> >   appsink receives a buffer with the renegotiated format.
> >
> >   This program runs a test continuously until it fails or it is executed
> a
> >   number of times selected by the used with -n option (1000000 by
> default).
> >
> >   If option -q is given, the pipeline is this:
> >
> >     --------------      -------      ---------
> >    | audiotestsrc | -> | queue | -> | appsink |
> >     --------------      -------      ---------
> >
> >   This test frequently fails  (1 on 15?), because audiotestsrc receive a
> >   not negotiated error while pushing a buffer or because no buffer with
> >   the new format is received.
> >
> >    If -q option is not present the pipeline is this:
> >
> >     --------------      ---------
> >    | audiotestsrc | -> | appsink |
> >     --------------      ---------
> >
> >   This second pipeline works properly and renegotiates correctly.
> >
> > I'd like to know if I am suppose to do something else to perform the
> > renegotiation, currently I am blocking the appsink:sink pad to change the
> > appsink caps and send a reconfigure event, then I unblock the pad again.
>
> Renegotiation and the RECONFIGURE event in GStreamer are only "hints",
> not something that makes sure you immediately only get buffers in the
> new format. And especially if a queue is used it can be possible that
> there are still buffers with the old format inside the queue.
>
> Your sink must be able to handle (or at least silently drop) buffers in
> the old format after a reconfigure event.
>
> --
> Sebastian Dröge, Centricular Ltd - http://www.centricular.com
> Expertise, Straight from the Source
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140606/82a4b535/attachment.html>


More information about the gstreamer-devel mailing list