GES 1.16.0, caps renegotiation problem

Mathieu Duponchelle mathieu at centricular.com
Wed Jul 24 16:35:47 UTC 2019


Regarding your first question, yes it is fortunately completely acceptable for caps to be
(re)negotiated in a PLAYING pipeline, if it was not then you could not dynamically update
pipelines, which is a feature GES obviously heavily relies on.

Regarding your second question, it looks like there might be some memory corruption going
on, as the expected format for the log message is:

    if (!gst_qtmux_caps_is_subset_full (qtmux, current_caps, caps)) {
      gst_caps_unref (current_caps);
      GST_WARNING_OBJECT (qtmux,
          "pad %s refused renegotiation to %" GST_PTR_FORMAT,
          GST_PAD_NAME (pad), caps);
      gst_object_unref (qtmux);
      return FALSE;
    }

Caps here are supposed to be displayed as a string, if they're not that means GST_IS_CAPS (caps)
failed, which is odd. More generally, qtmux only seems to support renegotiating the caps for an
input stream if the new caps are not a subset of the older ones, however I can't tell if the check
genuinely fails here because the new caps don't fulfill that condition, or because of the apparent
memory corruption.

On 7/24/19 5:56 PM, David Ing wrote:
> I am running a GESTimeline inside of a GstPipeline.  I am attaching an SVG file which illustrates the pipeline when it enters it's READY state.
>
> Soon after the the pipeline begins PLAYING, the muxers receive a request to re-negotiate the caps.
>
> *My first question is:*  Is it normal to re-negotiate caps after a pipeline is already playing?  (This doesn't seem right to me.)
>
> *My second question is:*  How can I determine which element is trying to renegotiate the caps after the pipeline is already PLAYING?
>
> BTW:  Here are the logs I see as it relates to the caps re-negotation error.
> 19-07-24T15:44:36.530562 INFO    pan CompositionJob.cpp:123 Pipeline state changed from PAUSED to PLAYING in 0.000 seconds.
> 19-07-24T15:44:36.925546 WARNING qtmux gstqtmux.c:5118 pad video_0 refused renegotiation to 0x7f7080003000 A
> 19-07-24T15:44:36.925673 WARNING qtmux gstqtmux.c:5118 pad video_0 refused renegotiation to 0x7f7080003000 A
> 19-07-24T15:44:36.925725 WARNING GST_PADS gstpad.c:4230 could not send sticky events
> 19-07-24T15:44:36.927847 WARNING qtmux gstqtmux.c:5118 pad video_0 refused renegotiation to 0x7f7080003000 A
> 19-07-24T15:44:36.927973 WARNING qtmux gstqtmux.c:5118 pad video_0 refused renegotiation to 0x7f7080003000 A
> 19-07-24T15:44:36.928039 WARNING qtmux gstqtmux.c:5118 pad video_0 refused renegotiation to 0x7f7080003000 A
> 19-07-24T15:44:36.932935 WARNING qtdemux qtdemux.c:6607 error: Internal data stream error.
> 19-07-24T15:44:36.933041 WARNING qtdemux qtdemux.c:6607 error: streaming stopped, reason not-negotiated (-4)
> 19-07-24T15:44:36.934955 ERROR   pan CompositionJob.cpp:282 GST_MESSAGE_ERROR received from element qtdemux5 at position 5465466666: Internal data stream error.
> ../gst-plugins-good/gst/isomp4/qtdemux.c(6607): gst_qtdemux_loop (): /GstPipeline:pipeline/GESTimeline:gestimeline0/GESVideoTrack:gesvideotrack0/NleComposition:video_nlecomposition1/GstBin:current-bin/NleSource:GESVideoUriSource:nlesource4/GstBin:videosrcbin/GstURIDecodeBin:uridecodebin2/GstDecodeBin:decodebin9/GstQTDemux:qtdemux5:
> streaming stopped, reason not-negotiated (-4)
>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190724/85fc9607/attachment.html>


More information about the gstreamer-devel mailing list