GNOME Bugzilla – Bug 582588
[API] Add a way to get the pad corresponding to a taglist
Last modified: 2009-05-31 20:02:55 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.
Created attachment 134638 [details] [review] message-tag-full.diff
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.
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.
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.
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.
(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?
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.
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?
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.
(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.