ok. gstplayer.c @ 1562 :

    if (gst_tag_list_get_scope (tags) == GST_TAG_SCOPE_GLOBAL) {

captured tags have STREAM scope, so never registered for media and other streams

> when a custom source element is selected by playbin, and this element posts
> TAG messages, mediainfo or audio/video info have TagList empty or NULL.
> 
> TagList exists & captured if you add watch on playbin's bus.

Your source element should push the tags downstream as event, not post them on the bus. The sink will then post them on the bus.

And STREAM scope tags are collected by playbin in front of the sinks (if you send them as an event as you should), while GLOBAL scope tags are collected by GstPlayer from the bus. The STREAM scope tags are available via the tags of the specific stream in the GstPlayerMediaInfo, the GLOBAL scope tags are available directly in the GstPlayerMediaInfo.

no effects. plugin tags have GLOBAL scope and sent with event, media info & streams have empty tags.

Can you update the code of your source accordingly so we can reproduce the problem? It's still posting the tags as a message only here: https://github.com/inizan-yannick/gst-plugins/blob/2dea2fa7a9ef5e5999650081cd137a6f048ae7ec/src/WebVideoSrc.vala#L29

updated, but no effect. same thing if srcpad receive this event.

Can you provide a testcase that does not depend on gxml (it's not packaged by Debian), or can you provide a debug log to see what happens with the tags?

In theory they should appear in gstplayer.c:tags_cb() and then be merged into the media info. Note that you should wait for the media-info-updated signal, it might appear only a bit later than the state change.

Created attachment 317988 [details] [review]
GstPlayer: Merge tags until media-info creation

<breizhodrome> slomo, finally I solved my bug : https://bugzilla.gnome.org/show_bug.cgi?id=759871
<slomo> breizhodrome|out: the fix is not correct. the problem is that some element in the pipeline is not properly doing the tag aggregation
<slomo> breizhodrome|out: some element should do what you did there, but instead just posted tags as is
<slomo> breizhodrome|out: thanks for noticing :) now we only need to find the problematic element

Yannick, can you send a pipeline picture, i.e. a .dot file of the pipeline? Would be good to find the elements that are doing things wrong :)

As I see it, playbin and decodebin could possibly get some improvements for merging global tags and not forwarding tag messages of stream tags.

Might be related to a demuxer, most demuxers don't expect upstream to send any tags, but just extract them from the stream.

Created attachment 318010 [details]
[graph] null-ready pipeline state change

Created attachment 318011 [details]
[graph] ready-paused pipeline state change

Created attachment 318012 [details]
[graph] paused-playing pipeline state change

So here it's at least matroskademux which does not expect tags from upstream and does not merge them with its own tags. It needs to do that in gst_matroska_demux_handle_sink_event() and wherever else it is outputting tags by itself it needs to merge them with the upstream ones first.

Do you want to provide a patch?

I've tried gst_element_send_event & gst_pad_push_event (gst_pad_send_event doesn't work - wrong direction) in my plugin, GST_EVENT_TAG never captured in gst_matroska_demux_handle_sink_event

<slomo> breizhodrome: interesting. can you get me a debug log with GST_DEBUG=6 and attach it to the bug?
<slomo> breizhodrome: that will explain what is happening here :)
<slomo> breizhodrome: push_event() is correct though. push sends the event to the peer pad. send lets a pad handle the event

log (49 MB) : http://www78.zippyshare.com/v/gMwDdu0H/file.html

The problem here is typefind. It's activating in PULL mode (your source supports that?) and in PULL mode we don't really forward events from upstream. Not only in typefind but everywhere.

Created attachment 318063 [details] [review]
typefind: Push cached events downstream in PULL mode if we don't handle them ourselves already

Otherwise upstream can't provide e.g. tags in PULL mode.

(In reply to Sebastian Dröge (slomo) from comment #20)
> Created attachment 318063 [details] [review] [review]
> typefind: Push cached events downstream in PULL mode if we don't handle them
> ourselves already
> 
> Otherwise upstream can't provide e.g. tags in PULL mode.

Undecided if this is a good idea. Opinions? :)

After typefinding has finished we would forward the events anyway (gst_pad_event_default() would).

From looking shortly at your code, I think you could base your source on giostreamsrc directly (i.e. make it a bin that has a giostreamsrc).

And also it seems like you always claim to support PULL mode, but whenever something is pulling data from a different offset you would return GST_FLOW_NOT_SUPPORTED unless the stream supports seeking. That's not ideal :) It should be known upfront if that can be done or not, and if you do PULL mode you must handle it.

> > typefind: Push cached events downstream in PULL mode if we don't handle them
> > ourselves already
> > 
> > Otherwise upstream can't provide e.g. tags in PULL mode.
> 
> Undecided if this is a good idea. Opinions? :)
> 
> After typefinding has finished we would forward the events anyway
> (gst_pad_event_default() would).

Not sure I like this. It kind of blurs the boundaries a bit. I think the source should operate in push mode in this case.

Does pull mode really make sense here?

It doesn't, PULL mode generally is a bad idea for anything network based.

(In reply to Tim-Philipp Müller from comment #23)

> Not sure I like this. It kind of blurs the boundaries a bit.

Note that gst_pad_event_default() would forward events in PULL mode anyway. The event is only not forwarded here because we cache events before typefinding has finished. If the source would send the event later, it would work.

Gst.WebSrc is a subclass of Gst.Base.PushSrc in this branch, with srcpad.push_event for tags : https://github.com/inizan-yannick/gst-plugins/tree/push-mode

and player's media-info doesn't receive tags

Can you provide another debug log with that branch? Also you should consider making that branch the default, push mode is really better in your scenario here :)

Created attachment 318349 [details]
GstWebSrc as GstPushSrc (debug log)

GST_DEBUG=6 debug log please :)

Level 6 debug log : http://www11.zippyshare.com/v/KEH6KBwK/file.html

Ok, this is now matroskademux getting the TAG event but not doing anything with it. It should merge it with its own global tags and forward it.

ok. close it (because not a bug) and submit my patch for good plugins