GES 1.16.0, caps renegotiation problem

[Mathieu Duponchelle]

valgrind comes to mind, though you'll need to use the appropriate suppression files to get
a sensible result, see the commands used for example by gst-validate-launcher when running
a test with the -vg switch.

On 7/24/19 6:55 PM, David Ing wrote:
> Can anyone recommend some techniques for diagnosing heap corruption issues on Linux (Fedora 30)?
>
> If I were on Windows I would use gflags (to set up guard pages) and windbg (for kernel-level debugging) but I don't know what is available on Linux.
>
> On Wed, Jul 24, 2019 at 9:35 AM Mathieu Duponchelle <mathieu at centricular.com <mailto:mathieu at centricular.com>> wrote:
>
>     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 <mailto: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/e88a04b8/attachment-0001.html>