As an usecase of URI fragment, it can indicate temporal or spatial
dimension of a media stream. To easily parse key-value pair,
newly added gst_uri_get_media_fragment_table () API will provide
the table of key-value pair likewise URI query.
See also https://www.w3.org/TR/media-frags/https://bugzilla.gnome.org/show_bug.cgi?id=774830
So from this point, the remaining warning for libgstreamer are about
protected member not showing in the doc. This may need some discussion
with upstream gtk-doc people.
* Remove % in from of none macro
* Fixed GST_TYPE_FAGS -> GST_TYPE_FAG_SET
* Minor wording fix
* Can't link to GstUri.port, so split the .port part
Make host IPs in square brackets store only the IP, i.e. strip the brackets.
Strip leading whitespace characters in URIs.
Fail parsing when host part does not match any valid formats from RFC3986.
https://bugzilla.gnome.org/show_bug.cgi?id=743195
These are actually not true.
gsturi.c: In function '_gst_uri_string_to_table.constprop':
gsturi.c:1316:27: error: 'pct_kv_sep' may be used uninitialized in this function [-Werror=maybe-uninitialized]
for (next_sep = strcasestr (value, pct_kv_sep); next_sep;
^
gsturi.c:1283:24: error: 'pct_part_sep' may be used uninitialized in this function [-Werror=maybe-uninitialized]
next_sep = strcasestr (next_sep + 1, pct_part_sep)) {
^
Support for (nullable) was added to G-I at the same time as nullable
return values. Previous versions of G-I will not mark return values as
nullable, even when an (allow-none) annotation is present, so it is
not necessary to add (allow-none) annotations for compatibility with
older versions of G-I.
https://bugzilla.gnome.org/show_bug.cgi?id=730957
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
We added a minimum length of three letters originally so we would
fail to recognise DOS/Windows-style filenames as valid URIs (as we
should). Two should be just fine as well.
No one but filesrc used that API. Should probably be replaced by
requiring an "uri" property instead, and then objects can do a
notify on that. Also removed interface structure padding, it's
not needed.
Add function that (unlike the GLib equivalent) also accepts paths that
aren't absolute and will clean up relative markers such as ./ and ../
before forming a URI.
Fixes warnings with e.g. filesrc location=foo ! typefind caused by the
recent switch to g_filename_to_uri(), but also actually creates valid
URIs for the first time.
Windows code paths could need some more work, e.g. we don't clean up
the relative markers there for now (because path could have \ and /
as separators).
API: gst_filename_to_uri()