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 781441 - videotestsrc: add uri handler
videotestsrc: add uri handler
Status: RESOLVED DUPLICATE of bug 795366
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.10.4
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 779765
Blocks:
 
 
Reported: 2017-04-18 10:24 UTC by Marc Leeman
Modified: 2018-10-27 12:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
videotestsrc: add uri handler (6.37 KB, patch)
2017-04-18 10:24 UTC, Marc Leeman
none Details | Review
videotestsrc: add uri-handler (6.25 KB, patch)
2018-10-27 12:56 UTC, Marc Leeman
none Details | Review

Description Marc Leeman 2017-04-18 10:24:00 UTC
Created attachment 349988 [details] [review]
videotestsrc: add uri handler

Add uri-handler to allow using with playbin based decoders.
Comment 1 Niels De Graef 2018-07-02 12:43:57 UTC
Hi, I would be very interested in having this (and bug 781442) land into upstream GStreamer. For all I care, we can leave out the `gst_object_set_properties_from_uri_query_parameters`. Can a maintainer see if it makes sense for them?

The reason why is that it would allow separate testing of uridecodebin (or similar elements) since you can just use a videotestsrc instead of relying on a specific protocol. Another cool thing this would provide is that we can see the difference (if any) in performance/latency between using a uridecodebin or using a videotestsrc directly.
Comment 2 Nicolas Dufresne (ndufresne) 2018-07-02 15:51:09 UTC
Thibault wrote something even better iirc, that could produce both audio and video automatically, le me find it.
Comment 3 Philippe Normand 2018-07-02 16:05:36 UTC
It's called testsrcbin, in debugutilsbad :)
Comment 4 Nicolas Dufresne (ndufresne) 2018-07-03 12:27:15 UTC
Thanks, so uri would be testbin://audio+video .

Or just video if you don't want audio.
Comment 5 Nicolas Dufresne (ndufresne) 2018-07-03 12:29:50 UTC
Marking as dup, as this implementation is a subset. Ping me if you think we need both for specific reason.

*** This bug has been marked as a duplicate of bug 795366 ***
Comment 6 Niels De Graef 2018-08-03 07:39:15 UTC
Don't know if it's enough of a reason for you to reopen this bug, but we might have some reasons for videotestsrc/audiotestsrc to keep being a URI handler:

* internally we already have an element (a simple wrapper around uridecodebin) that, using `gst_object_set_properties_from_uri_query_parameters`, controls the videotestsrc and audiotestsrc elements for test cases. For example, we can use a URI "videotesrc://?num-buffers=100&pattern=7&is-live=1" to simulate a non-infinite live source. The testsrcbin would have to copy all these properties to be a drop-in replacement for us.

* the internal wrapper element also has an "audio" and "video" gboolean property that prevents exposing ghost pads for any audio/video srcpad resp. from uridecodebin. As such, this will also clash for us a bit. It's not a major issue and one that we can solve with a workaround, but will be a minor headache nonetheless.

That being said, testsrcbin seems to be also something very useful for us (we might be able to automate audio/video sync issues with this), but separately from videotestsrc/audiotestsrc.
Comment 7 Marc Leeman 2018-10-27 12:56:47 UTC
Created attachment 374065 [details] [review]
videotestsrc: add uri-handler