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 781152 - gst-device-monitor: print the gst-launch line for a device
gst-device-monitor: print the gst-launch line for a device
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal enhancement
: 1.11.91
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-04-10 19:58 UTC by Olivier Crête
Modified: 2017-04-11 18:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
tools: gst-device-monitor: Print gst-launch example (3.93 KB, patch)
2017-04-10 19:59 UTC, Olivier Crête
committed Details | Review
gstdevice: Document that the tool expects only properties to change (1.17 KB, patch)
2017-04-11 17:47 UTC, Olivier Crête
rejected Details | Review

Description Olivier Crête 2017-04-10 19:58:44 UTC
The attached patch makes the command line tool print a gst-launch line. The reason I didn't commit this right away is that the GstDevice* API currently doesn't guarantee that setting properties is all a GstDevice object does when creating an element. It could also, for example, create a bin with multiple elements which each have properties.
Comment 1 Olivier Crête 2017-04-10 19:59:05 UTC
Created attachment 349621 [details] [review]
tools: gst-device-monitor: Print gst-launch example

Print a gst-launch-1.0 line that could get to this device,
useful as we don't have other ways to see what it does exactly.
This may not work if the create element has configurations other than
properties.
Comment 2 Tim-Philipp Müller 2017-04-10 21:39:57 UTC
I think this is a good idea.

Device monitors shouldn't do weird stuff like you describe imho, not without exposing an element for the bin then at least. Maybe we should document that somewhere, or introduce some API / object flag that tells us if that's the case?
Comment 3 Olivier Crête 2017-04-11 17:47:06 UTC
Created attachment 349693 [details] [review]
gstdevice: Document that the tool expects only properties to change

I'm a bit worried about restricting the API too much for a debugging tool, maybe we can document it in a comment in case we want to revisit this later. I'm not sure where to put that comment, but I tried putting it here in gstdevice.h. But it seems strange to have a comment telling people to update "core" code in the documentation.
Comment 4 Tim-Philipp Müller 2017-04-11 18:01:20 UTC
Hrm, yes, that doesn't really look right, does it?

Maybe let's just get the tool change in and see what we want to do about the other case later when we have a real-world example where it doesn't do the right thing?
Comment 5 Olivier Crête 2017-04-11 18:28:24 UTC
Review of attachment 349621 [details] [review]:

Pushed as:
commit 41c1064f5f1c82b203958c5a7b3c021c77fb6ce0
Author: Olivier Crête <olivier.crete@collabora.com>
Date:   Mon Apr 10 15:35:41 2017 -0400

    tools: gst-device-monitor: Print gst-launch example
    
    Print a gst-launch-1.0 line that could get to this device,
    useful as we don't have other ways to see what it does exactly.
    This may not work if the create element has configurations other than
    properties.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=781152