GNOME Bugzilla – Bug 779613
In ADTS scenario, aacparse element does not set src CAPS again if pipeline had been set to play->null->play
Last modified: 2018-11-03 15:16:49 UTC
Created attachment 347266 [details] [review] patch created on 1.8.1 version In aacparse element, setting pipeline from PLAYING to NULL does not reset gint sample_rate; gint channels; properties. Therefore in the ADTS scenario, when moving pipeline to PAUSE state again, src CAPS are not created in gst_aac_parse_handle_frame. In fact the following if statement is checked and if match occurs CAPS are not being created if (G_UNLIKELY (rate != aacparse->sample_rate || channels != aacparse->channels)) Actual result: audio streaming is not recovered and gstreamer aac elemnt issues: gst_base_parse_push_frame <aac-parse> error: No caps set A similar fix exists for LOAS scenario, where /* We want to set caps both at start, and when rate/channels change. Since only some LOAS frames have that info, we may receive frames before knowing about rate/channels. */ if (setcaps || !gst_pad_has_current_caps (GST_BASE_PARSE_SRC_PAD (aacparse))) { if (!gst_aac_parse_set_src_caps (aacparse, NULL)) {
Review of attachment 347266 [details] [review]: While this looks correct (please provide a "git format-patch" formatted patch with a commit message though), your initial observation that those fields are not reset is also correct. They should be reset in PAUSED->READY. Can you provide a patch for that too? Nonetheless, what this patch here does should still be done.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/350.