After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 582588 - [API] Add a way to get the pad corresponding to a taglist
[API] Add a way to get the pad corresponding to a taglist
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal blocker
: 0.10.24
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-05-14 10:08 UTC by Sebastian Dröge (slomo)
Modified: 2009-05-31 20:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
message-tag-full.diff (4.14 KB, patch)
2009-05-14 10:10 UTC, Sebastian Dröge (slomo)
committed Details | Review

Description Sebastian Dröge (slomo) 2009-05-14 10:08:40 UTC
Hi,
attached patch adds gst_message_new_tag_full() and gst_message_parse_tag_full() to store the originating source pad. Additionally the patch changes gst_element_found_tags_for_pad() to use this new functions.

This is useful for applications if they need to know from which pad the tags are coming.
Comment 1 Sebastian Dröge (slomo) 2009-05-14 10:10:50 UTC
Created attachment 134638 [details] [review]
message-tag-full.diff
Comment 2 Sebastian Dröge (slomo) 2009-05-14 10:31:09 UTC
commit 18f5b1a59e504d5932f616c209e47e8fd0232a6b
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Thu May 14 12:30:04 2009 +0200

    gst-launch: Print the path string for message sources
    
    This reduces confusion if the message source is a pad
    and only "src" is printed as source.

commit bebfde75027e975b7e7c74c6358c5be83ea4ac9f
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Thu May 14 12:25:20 2009 +0200

    element: Set the originating pad as message source in gst_element_found_tags_f
    
    Fixes bug #582588.
Comment 3 Jan Schmidt 2009-05-26 21:00:54 UTC
Here is what I learned tonight:
<thaytan> so, I just discovered the first victim of changing the TAG message source to be the pad
<thaytan> totem looks at the message source, and if it it's an element, checks the element class to determine if the tags are Audio or Video
<thaytan> no longer works with the source being the pad
<thaytan> furthermore! vorbisdec sometimes posts the tag message itself, rather than calling found_tags_for_pad
<thaytan> meaning you can sometimes get tags from vorbis with the pad as the source, and sometimes with the element!

I don't think this is a tenable change for a stable release series. 
Comment 4 Sebastian Dröge (slomo) 2009-05-27 08:31:34 UTC
Ok, then let's revert this for 0.10 and add a FIXME 0.11 there...

But I don't think the way totem uses it is correct but at least it explains why it doesn't show bitrate tags for audio/video emitted by a demuxer ;) Wouldn't it be better for totem to get the pad corresponding to the taglist and check the caps if they're audio/* or video/*  (and some application/* )? But that's of course unrelated to the change here (although it would be impossible to get the pad corresponding to the taglist without either the attached patch or the committed patch).

Jan, would you be fine to revert the change and commit the attached patch to this bug instead? It's a bit unclean IMHO but doesn't change the sender of the message.
Comment 5 Jan Schmidt 2009-05-27 08:48:27 UTC
Yep, let's revert. I prefer the approach of adding the pad as a property of the tag message. That way existing Totem doesn't change, and future Totem/apps can use it to inspect the caps if they choose to.
Comment 6 Sebastian Dröge (slomo) 2009-05-27 08:54:03 UTC
(In reply to comment #5)
> Yep, let's revert. I prefer the approach of adding the pad as a property of the
> tag message. That way existing Totem doesn't change, and future Totem/apps can
> use it to inspect the caps if they choose to.

Ok, I'll do that then... but for 0.11 you also prefer to have the pad as message source?
Comment 7 Jan Schmidt 2009-05-27 10:18:07 UTC
I guess so - although that means one of two things:

a) Only pads can send tag messages, which implies only pads/streams have tags. A possibly sensible restriction?
b) tag messages can sometimes have a pad as a source, and sometimes other things - which seems awkward on the face of it, but may not be in practice.
Comment 8 Tim-Philipp Müller 2009-05-27 10:30:33 UTC
Why would any application want to know what pad the tags refer to again? I mean, what problem would that solve? Maybe we should try to solve that differently somehow, in a way that doesn't involve pads, like a stream-id of some sorts?
Comment 9 Sebastian Dröge (slomo) 2009-05-27 12:37:08 UTC
commit 4e8f547f9828ff8ffaafe0c7990ef098b5f25342
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Wed May 27 14:32:51 2009 +0200

    API: Add gst_message_{new,parse}_tag_full() to get/set the source pad
    
    Fixes bug #582588.

commit db6f445620c98df8568ec421ce422f9bb5206324
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Wed May 27 14:06:13 2009 +0200

    Revert "element: Set the originating pad as message source in gst_element_fo
    
    This reverts commit bebfde75027e975b7e7c74c6358c5be83ea4ac9f.
    
    This change shouldn't be done in a stable release series as
    applications are actually expecting the sender to be an
    GstElement. One example is totem.
Comment 10 Stefan Sauer (gstreamer, gtkdoc dev) 2009-05-31 20:02:55 UTC
(In reply to comment #8)
> Why would any application want to know what pad the tags refer to again? I
> mean, what problem would that solve? Maybe we should try to solve that
> differently somehow, in a way that doesn't involve pads, like a stream-id of
> some sorts?
> 

I agree here. App would probably look at the pad caps and check if media type is audio/video/image. But in practise they would want the global tags (for the media as such) and tags per stream.