[gstreamer-bugs] [Bug 614872] [tag] Add basic exif support
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Tue Apr 6 02:46:17 PDT 2010
https://bugzilla.gnome.org/show_bug.cgi?id=614872
GStreamer | gst-plugins-base | git
--- Comment #3 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2010-04-06 09:46:16 UTC ---
Review of attachment 157971:
--> (https://bugzilla.gnome.org/review?bug=614872&attachment=157971)
::: gst-libs/gst/tag/gstexiftag.c
@@ +72,3 @@
+static const GstExifTagMatch tag_map[] = {
+ {GST_TAG_COPYRIGHT, 0x8298, EXIF_TYPE_ASCII},
+ {NULL, 0, 0}
We could save the NULL-terminator entry and use G_N_ELEMENTS to iterate the
table.
@@ +112,3 @@
+ return i;
+ }
+ }
This is going to loop endlessly if tag != tag_map[0].gst_tag, isn't it? I'd
suggest a for-loop with G_N_ELEMENTS (tag_map).
@@ +131,3 @@
+ return i;
+ }
+ }
Same as above: endless loop?
@@ +313,3 @@
+ * Since: 0.10.29
+ */
+/* FIXME How to add the next IFD address? */
What about this then? :)
@@ +316,3 @@
+GstBuffer *
+gst_tag_list_to_exif_buffer (const GstTagList * taglist, gint byte_order,
+ guint32 base_offset)
byte_order: can't we just always write everything in little endian or big
endian (or host order)? I mean, does the caller really *need* to specify the
byte order in some cases?
base_offset: maybe make normal guint?
@@ +389,3 @@
+GstTagList *
+gst_tag_list_from_exif_buffer (const GstBuffer * buffer, gint byte_order,
+ guint32 base_offset)
Can we somehow figure out the byte_order ourselves? Having to pass in the byte
order seems a bit awkard. Where does this info come from?
I would make base_offset a normal integer, even if it's limited to 32-bit in
the format, just seems nicer. Others may disagree of course :)
--
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.
More information about the Gstreamer-bugs
mailing list