[Bug 634250] deserialize URI strings into GstBuffer

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=634250
  GStreamer | gstreamer (core) | git

--- Comment #4 from Tim-Philipp Müller <t.i.m at zen.co.uk> 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

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.