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 751450 - parse/grammar.y: Allow multiple links to happen.
parse/grammar.y: Allow multiple links to happen.
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other All
: Normal enhancement
: 1.11.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-06-24 16:39 UTC by Mathieu Duponchelle
Modified: 2016-11-02 01:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
parse/grammar.y: Allow multiple links to happen. (1.15 KB, patch)
2015-06-24 16:39 UTC, Mathieu Duponchelle
none Details | Review
parse/grammar.y: Allow multiple links to happen. (10.01 KB, patch)
2015-06-24 23:16 UTC, Mathieu Duponchelle
none Details | Review
parse-launch: Support linking all pads with new operator (10.66 KB, patch)
2015-06-25 17:31 UTC, Jan Schmidt
none Details | Review
parse-launch: Support linking all pads with new operator (9.91 KB, patch)
2015-06-25 17:36 UTC, Jan Schmidt
needs-work Details | Review
parse-launch: Support linking all pads with new operator (11.25 KB, patch)
2016-11-02 01:11 UTC, Jan Schmidt
none Details | Review

Description Mathieu Duponchelle 2015-06-24 16:39:18 UTC
In such a case : uridecodebin ! encodebin ,
if the encodebin has multiple profiles compatible with the
decodebin, it seems legit to let them happen.

Previously, after one delayed link was successfully done, the
pad-added callback was disconnected.
Comment 1 Mathieu Duponchelle 2015-06-24 16:39:40 UTC
Created attachment 306026 [details] [review]
parse/grammar.y: Allow multiple links to happen.
Comment 2 Jan Schmidt 2015-06-24 17:33:47 UTC
I'm pretty wary of changing that - there's lots of gst-launch scripts out there, and I know I've written some that expect only one link. It might be better to add a new token to the lexer?
Comment 3 Mathieu Duponchelle 2015-06-24 18:05:54 UTC
What token would you think about exactly ? "!!" maybe ?

The thing is I filed that as enhancement, but it could nearly be considered a bug :)

If we chose to add a new token, I'd be concerned about its discoverability, but I understand your concern, even though it kind of reminds me of https://xkcd.com/1172/ :)
Comment 4 Thiago Sousa Santos 2015-06-24 18:15:07 UTC
What would happen if you had a capsfilter between the decodebin and encodebin? Would it detect that it should link all streams that match that caps?
Comment 5 Jan Schmidt 2015-06-24 18:29:24 UTC
(In reply to Mathieu Duponchelle from comment #3)
> What token would you think about exactly ? "!!" maybe ?

Existing pipeline operators are all single char. It's possible to match a regex instead, with a slightly bigger change to parse.l.

I'm not sure what single character might be a good one, so '!!' is probably fine. Else, demux / multiqueue maybe?
 
> The thing is I filed that as enhancement, but it could nearly be considered
> a bug :)

Not really - it does one thing, you want it to do another. Not really a bug - more a difference of opinion.

> If we chose to add a new token, I'd be concerned about its discoverability,
> but I understand your concern, even though it kind of reminds me of
> https://xkcd.com/1172/ :)

I'm more concerned about changing 10 year old behaviour causing even harder-to-discover bugs.

(In reply to Thiago Sousa Santos from comment #4)
> What would happen if you had a capsfilter between the decodebin and
> encodebin? Would it detect that it should link all streams that match that
> caps?

Should do - a filtered link in the grammar just calls gst_element_link_pads_filtered(), which will create a new capsfilter element for each link.
Comment 6 Mathieu Duponchelle 2015-06-24 22:22:20 UTC
"!!" will not work in bash actually :

!!     Refer to the previous command.  This is a synonym for `!-1'.
Comment 7 Mathieu Duponchelle 2015-06-24 23:16:43 UTC
Created attachment 306060 [details] [review]
parse/grammar.y: Allow multiple links to happen.

By introducing a new syntax : element1 ? element2

In such a case : uridecodebin ? encodebin ,
if the encodebin has multiple profiles compatible with the
decodebin, multiple links will be created.

With '!' , after one delayed link is successfully done, the
pad-added callback is disconnected.

The reason this isn't the default behaviour for '!' is legacy,
as it would make previously-working scripts malfunction.

This should be made the default behaviour at some point.
Comment 8 Mathieu Duponchelle 2015-06-24 23:19:14 UTC
I attached a tentative patch with a new token, '?', if everyone is all right with it I'll update the documentation.

It would also be comforting if someone with more flex / bison experience than I reviewed this patch.
Comment 9 Thiago Sousa Santos 2015-06-25 02:22:40 UTC
For the record I don't think this should become the default behavior at some point. This is an interesting addition but being able to specify 'only link once' is very useful, specially because this is a test and debugging tool. Having 'multiple-linking' by default wouldn't allow having a single link and that defeats the flexibility of the tool for testing/debugging.
Comment 10 Sebastian Dröge (slomo) 2015-06-25 07:48:01 UTC
(In reply to Thiago Sousa Santos from comment #9)
> For the record I don't think this should become the default behavior at some
> point.

Definitely not the default behavior, yes :)
Comment 11 Mathieu Duponchelle 2015-06-25 08:27:28 UTC
Yep, didn't think this through :)

Are you folks OK with introducing that new syntax otherwise ?
Comment 12 Jan Schmidt 2015-06-25 08:38:24 UTC
I think we should bike shed exactly which symbol to use until everyone gets bored.

I vote for demux + multiqueue + muxer or demux : multiqueue : muxer (for constrast, vs demux ! multiqueue ! muxer)
Comment 13 Nicolas Dufresne (ndufresne) 2015-06-25 14:48:29 UTC
I thought about * for a moment, but it expends in a shell. So I'm offcially removing this possibility ;-P

If we think of regex, + would be one or more, ? usually means optional. I believe for a pipeline to work, one or more link will have to happen, makes + possibly a better choice.
Comment 14 Jan Schmidt 2015-06-25 15:41:40 UTC
I like either + or : over ?, but I'll survive with any.

There's one thing in the patch that worth noting: with the new link operator, you can only put it on both sides of a capsfilter or neither.

I don't think gst-launch-1.0 videotestsrc ! video/x-raw,format=I420 ? xvimagesink will be parsed. Semantically, it probably makes sense that if either side of the filter is "link_all", then it should link multiple times - it requires creating multiple capsfilter elements either way.
Comment 15 Jan Schmidt 2015-06-25 17:31:32 UTC
Created attachment 306122 [details] [review]
parse-launch: Support linking all pads with new operator

Introduce a new operator ':' - e.g. element1 ':' element2

For example, 'uridecodebin : encodebin' -
if the encodebin has multiple profiles compatible with the
decodebin, multiple links will be created.

With '!' , after one delayed link is successfully done, the
pad-added callback is disconnected.
Comment 16 Jan Schmidt 2015-06-25 17:36:19 UTC
Created attachment 306124 [details] [review]
parse-launch: Support linking all pads with new operator

Introduce a new operator ':' - e.g. element1 ':' element2

For example, 'uridecodebin : encodebin' -
if the encodebin has multiple profiles compatible with the
decodebin, multiple links will be created.

With '!' , after one delayed link is successfully done, the
pad-added callback is disconnected.
Comment 17 Jan Schmidt 2015-08-04 10:02:49 UTC
This sort of stalled out after the last patch. Any opinions on whether to apply it?
Comment 18 Tim-Philipp Müller 2015-08-04 10:28:38 UTC
I would prefer to punt this until after 1.6
Comment 19 Jan Schmidt 2016-09-09 13:38:31 UTC
Going to push this after feature freeze is over.
Comment 20 Tim-Philipp Müller 2016-09-09 13:53:37 UTC
Comment on attachment 306124 [details] [review]
parse-launch: Support linking all pads with new operator

Setting patch status accordingly, so we don't forget
Comment 21 Sebastian Dröge (slomo) 2016-11-01 18:27:10 UTC
Comment on attachment 306124 [details] [review]
parse-launch: Support linking all pads with new operator

Does not apply cleanly
Comment 22 Jan Schmidt 2016-11-02 01:11:12 UTC
Created attachment 338920 [details] [review]
parse-launch: Support linking all pads with new operator

Introduce a new operator ':' - e.g. element1 ':' element2

For example, 'uridecodebin : encodebin' -
if the encodebin has multiple profiles compatible with the
decodebin, multiple links will be created.

With '!' , after one delayed link is successfully done, the
pad-added callback is disconnected.
Comment 23 Jan Schmidt 2016-11-02 01:11:49 UTC
pushed:

commit 5a5ae1be1fc22ab538fb74984a99ce9d8f708f80
Author: Jan Schmidt <jan@centricular.com>
Date:   Fri Jun 26 03:29:27 2015 +1000

    parse-launch: Support linking all pads with new operator
    
    Introduce a new operator ':' - e.g. element1 ':' element2
    
    For example, 'uridecodebin : encodebin' -
    if the encodebin has multiple profiles compatible with the
    decodebin, multiple links will be created.
    
    With '!' , after one delayed link is successfully done, the
    pad-added callback is disconnected.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=751450