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 634250 - deserialize URI strings into GstBuffer
deserialize URI strings into GstBuffer
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-11-07 21:02 UTC by David Schleef
Modified: 2011-03-17 23:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (1.27 KB, patch)
2010-11-07 21:02 UTC, David Schleef
none Details | Review

Description David Schleef 2010-11-07 21:02:48 UTC
Created attachment 174027 [details] [review]
patch

Add ability to deserialize a string containing a URI into a buffer by reading the contents of the URI (only a file:// URI).  This makes it easier to use GstBuffer properties, allowing applications to push binary blobs to elements while simultaneously allowing gst-launch to read a blob from a file.
Comment 1 Tim-Philipp Müller 2011-02-04 00:11:12 UTC
Why not, I guess?

Where/how do you use it exactly?
Comment 2 David Schleef 2011-02-04 00:19:10 UTC
I changed logoinsert in -bad to use a GstBuffer property instead of a location= property.  This allows applications to set the property using a binary blob containing a PNG image, while also allowing the old behavior of using gst-launch to load the image from a file.
Comment 3 Tim-Philipp Müller 2011-02-17 16:11:08 UTC
> I changed logoinsert in -bad to use a GstBuffer property instead of a location=
> property.  This allows applications to set the property using a binary blob
> containing a PNG image, while also allowing the old behavior of using
> gst-launch to load the image from a file.

As I said in our discussion on IRC the other, I think this is awful API. I think the location=localfile.png case is the most common, and I don't see the problem with having a separate "data" property for the buffer data. IIRC you expressed a dislike for having file reading code in elements like this, which I agree with on some level, but we shouldn't invent awkward API to avoid that IMHO.

I would prefer to see this WONTFIXed, and see a plain "location" string property on that overlay element (and additional "data" GstBuffer property if desired).
Comment 4 Tim-Philipp Müller 2011-03-17 23:31:12 UTC
The IRC log, in case anyone's interested:

04-02-2011:
00:39:21 tim: ds, ew @ logoinsert API ;-)
00:40:49 ds: __tim: got a better solution?
00:41:01 tim: dunno, two separate properties?
00:42:27 ds: how is that better?
00:43:57 tim: Seems simpler and more straight-forward to me, and more discoverable
00:45:28 tim: if you want to insert a logo from file with code, you can't do just g_object_set (logoinsert, "location", "/home/me/logo.jpg", NULL);  any more, can you? But you'd have to create a buffer first, wouldn't you?
00:45:58 tim: and convert the filename into an URI
01:02:39 ds: __tim: yeah, the C code to set the property is definitely clumsier
01:04:02 ds: __tim: i'm not a big fan of elements reading files unless that's their main purpose (like filesrc)
01:04:27 tim: ds, but doesn't that happen with your solution as well?
01:04:50 ds: only from gst-launch
01:05:14 tim: oh, I see, so a C application would need to do the file loading itself
01:05:16 ds: right now, there are several elements that load property information from a file
01:05:19 ds: yeah
01:05:29 ds: which we could wrap with a utility function, but still
01:06:05 ds: If every part of the API requires a utility function to use properly, the API is probably not designed right :)
01:06:29 tim: I think I agree with you in general, but for an element like this it seems a little "popier than the pope" :)
01:08:07 ds: it makes a little more sense for the rsvgoverlay (or whatever it's called)
01:08:09 tim: as a user of such an element, I just want to give it a file name and be done with it (unless I have the data)
01:08:23 ds: where you really might want to create SVG programmatically
01:12:08 tim: ds, not sure I follow. Aren't you arguing that a GstBuffer * argument is really sufficient for logoinsert? But then you say that no one is going to create jpg/png data on the fly [unlike svg data], right? Wouldn't that be an argument in favour of just taking a file location instead?
01:12:29 ds: __tim: er, maybe
01:13:03 ds: __tim: unless you're storing the images in a resource fork, or loading them from http, etc.
01:13:35 tim: right
01:13:46 ds: you *could* save them to a file and then load, but then that assumes availablity of a tmp dir
01:14:13 * ds wanders off into weird "what if's"
01:14:44 tim: I have nothing against a GstBuffer * "data" property, it just seems weird to me not to provide a gchar * "location" property that's all
01:14:51 tim: anyway, it's late, I should probably go to sleep
01:15:26 ds: sure.  I just felt a few lines in core would make the location property moot