[Bug 759539] Stopping a stream with AAC very soon after starting crashes

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=759539

--- Comment #2 from davecraig at unbalancedaudio.com ---
(In reply to Sebastian Dröge (slomo) from comment #1)
> Can you check the other audio/video parsers too for more of the similar
> problem?
Yes, I did take a look. None of the audio or video parsers looked to have a
similar problem.

However, some of the other plugins had things that I thought looked sketchy.
Using gst_pad_has_current_caps() to decide whether to call
gst_pad_get_current_caps e.g. from gst_flac_enc_sink_query


      if (gst_pad_has_current_caps (pad)) {
        acceptable = gst_pad_get_current_caps (pad);
      } else {
        acceptable = gst_pad_get_pad_template_caps (pad);
      }

This would seem better:

      acceptable = gst_pad_get_current_caps (pad);
      if(acceptable == NULL) {
        acceptable = gst_pad_get_pad_template_caps (pad);
      }

Anywhere that calls gst_pad_get_current_caps based on the result of
gst_pad_has_current_caps looks to me to be problematic. These are the ones I
found:

gst_flac_enc_getcaps
gst_flac_enc_sink_query
gst_shape_wipe_video_sink_getcaps
gst_shape_wipe_mask_sink_getcaps
gst_shape_wipe_src_getcaps
gst_flv_mux_create_metadata
gst_image_freeze_sink_getcaps
gst_aspect_ratio_crop_set_property
gst_rtp_h264_set_src_caps
gst_disparity_handle_query
gst_rtp_h265_set_src_caps

The other places that looked problematic were in demuxes, though it may be that
these are ok e.g. call to gst_pad_get_current_caps in
gst_deinterlace_output_frame. I guess all calls to gst_pad_get_current_caps
checking for NULL is the only way to be sure.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.