[Bug 762793] New: taginject does not copy the tag list it sends, so changes by other elements are propagated later

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 762793
           Summary: taginject does not copy the tag list it sends, so
                    changes by other elements are propagated later
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Mac OS
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: gnome-bugzilla at sjor.sg
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 322552
  --> https://bugzilla.gnome.org/attachment.cgi?id=322552&action=edit
Patch: "When sending a tag event in GstTagInject, ensure that changes by other
elements do not influence the tags sent in the future."

taginject, a debugtools element, is configured to add specific tags to the
pipeline. Upon init(), it converts this to a GstTagList* (self->tags), which it
pushes towards the elements after it in gst_tag_inject_transform_ip().

However, since it does not make a copy of this list, any changes to the list by
further elements effectively influence self->tags. Thus, upon pipeline changes,
when it decides to re-send its tag list, it does not send the tags from the
configured 'tags' property, but the tags as modified by further elements.

The attached patch fixes this.

I reported a bug resulting from this issue against GStreamer Editing Services
at <https://phabricator.freedesktop.org/T7332>. There, taginject is used to
inject replaygain peak, gain and reference levels, which are then interpreted
by rgvolume to apply the correct volume normalizations and subsequently removed
from the tag list. However, as soon as NLE makes a pipeline change, the tag
list no longer contains the values to correctly compute the replay gain
normalization, causing the normalization to fall away. More details can be
found at the link above.

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