GNOME Bugzilla – Bug 772527
tags: Add support for remaining Dublin Core metadata
Last modified: 2018-11-03 12:36:38 UTC
Created attachment 337102 [details] [review] gstreamer: Support the full set of tags in Dublin Core. Parse TDT, TOT and SDT messages from DVB. Pass the date and time from TDT into GST_TAG_DATE_TIME, and pass the SDT service name and service provider as GST_TAG_SOURCE and GST_TAG_PUBLISHER. This patch includes the addition of all missing tags in Dublin Core.
Created attachment 337103 [details] [review] gst-plugins-base: Support the full set of tags in Dublin Core.
Created attachment 337105 [details] [review] gst-plugins-bad: Parse TDT, TOT and SDT messages from DVB.
Review of attachment 337102 [details] [review]: Maybe these should be moved into libgsttag into a separate namespace for dublin core? But generally seems fine to have them in core I guess, except for: ::: gst/gsttaglist.h @@ +485,3 @@ +#define GST_TAG_COVERAGE "coverage" +/** + * GST_TAG_IDENTIFIER: This seems a bit generic. DUBLIN_CORE_IDENTIFIER maybe? @@ +505,3 @@ + * Since: 1.9 + */ +#define GST_TAG_LANGUAGE "language" There's also LANGUAGE_NAME and LANGUAGE_CODE. How is this one different? @@ +507,3 @@ +#define GST_TAG_LANGUAGE "language" +/** + * GST_TAG_PUBLISHER: There already is GST_TAG_PUBLISHER since 1.2 @@ +540,3 @@ +#define GST_TAG_SOURCE "source" +/** + * GST_TAG_GENRE: GST_TAG_GENRE exists since forever already
Review of attachment 337103 [details] [review]: ::: gst-libs/gst/tag/gstxmptag.c @@ +953,3 @@ + _gst_xmp_schema_add_simple_mapping (schema, GST_TAG_IDENTIFIER, + "dc:identifier", GstXmpTagTypeSeq, NULL, NULL); + _gst_xmp_schema_add_simple_mapping (schema, GST_TAG_LANGUAGE, LANGUAGE_NAME or LANGUAGE_CODE?
Review of attachment 337105 [details] [review]: ::: gst/mpegtsdemux/mpegtsbase.c @@ +1205,3 @@ + return FALSE; + + if (G_UNLIKELY (GST_DEBUG_IS_ENABLED ())) { Usually we just put these into #ifndef GST_DISABLE_GST_DEBUG blocks
> Maybe these should be moved into libgsttag into a separate > namespace for dublin core? But generally seems fine to have > them in core I guess, except for: Right now we support roughly half of Dublin Core, this patch adds the other half following the same conventions as already established. > This seems a bit generic. DUBLIN_CORE_IDENTIFIER maybe? The formal definition is here: http://dublincore.org/documents/dces/ "An unambiguous reference to the resource within a given context. Recommended best practice is to identify the resource by means of a string conforming to a formal identification system." Seems Dublin Core expects this to be generic. > There's also LANGUAGE_NAME and LANGUAGE_CODE. How is this one different? The formal defition of GST_TAG_LANGUAGE is an RFC4646 language tag. I am not seeing that LANGUAGE_NAME or LANGUAGE_CODE have such a strict definition. > There already is GST_TAG_PUBLISHER since 1.2 Will fix. > GST_TAG_GENRE exists since forever already Will fix.
Created attachment 338097 [details] [review] gstreamer: Support the full set of tags in Dublin Core. Removed duplicated elements, clarified format of GST_TAG_LANGUAGE to indicate RFC 4646.
(In reply to minfrin from comment #6) > > This seems a bit generic. DUBLIN_CORE_IDENTIFIER maybe? > > The formal definition is here: > > http://dublincore.org/documents/dces/ > > "An unambiguous reference to the resource within a given context. > Recommended best practice is to identify the resource by means of a string > conforming to a formal identification system." > > Seems Dublin Core expects this to be generic. Add something to the name to make it dublin core specific then :) > > There's also LANGUAGE_NAME and LANGUAGE_CODE. How is this one different? > > The formal defition of GST_TAG_LANGUAGE is an RFC4646 language tag. I am not > seeing that LANGUAGE_NAME or LANGUAGE_CODE have such a strict definition. LANGUAGE_CODE is according to ISO-639-2 or ISO-639-1. RFC4646 seems to be a superset of that.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/191.