[Bug 779613] New: In ADTS scenario, aacparse element does not set src CAPS again if pipeline had been set to play->null->play
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Sun Mar 5 14:17:34 UTC 2017
https://bugzilla.gnome.org/show_bug.cgi?id=779613
Bug ID: 779613
Summary: In ADTS scenario, aacparse element does not set src
CAPS again if pipeline had been set to
play->null->play
Classification: Platform
Product: GStreamer
Version: 1.11.x
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-plugins-good
Assignee: gstreamer-bugs at lists.freedesktop.org
Reporter: praduri at gmail.com
QA Contact: gstreamer-bugs at lists.freedesktop.org
GNOME version: ---
Created attachment 347266
--> https://bugzilla.gnome.org/attachment.cgi?id=347266&action=edit
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)) {
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list