It is the 35 mm equivalent focal length of the lens, mainly used in
photography. Tag value is stored in a double value to be consistent with
GST_TAG_CAPTURING_FOCAL_LENGTH.
https://bugzilla.gnome.org/show_bug.cgi?id=753930
When g_option_context_parse fails, context and error variables are not getting free'd
which results in memory leaks. Free'ing the same.
And replacing g_error_free with g_clear_error, which checks if the error being passed
is not NULL and sets the variable to NULL on free'ing.
https://bugzilla.gnome.org/show_bug.cgi?id=753852
Use g_utf16_to_utf8() instead of the more generic g_convert(), so
that we can extract text in UTF-16 format even on embedded systems
with crippled iconv support.
This code path is exercised by the id3demux test_unsync_v23
check in gst-plugins-good.
https://bugzilla.gnome.org/show_bug.cgi?id=741144
Bypass g_convert/iconv if there's nothing to convert. That way,
conversion won't fail on systems where iconv doesn't support
converting utf-8 to latin1 and there's nothing to convert.
https://bugzilla.gnome.org/show_bug.cgi?id=723252
The spec for this does not say nor imply how this should be
interpreted. The previous code would try to shift by 64 bits,
which is undefined.
Coverity 1195119
https://bugzilla.gnome.org/show_bug.cgi?id=727955
Otherwise upstream can get confused about offsets as there will
be a jump once the tags have been parsed due to the stripped area.
If upstream pulls from 0 to 100, and then tagdemux does the
tag reading and finds out that the first 200 bytes are the tag, the
next pull from upstream will have an offset of 200 bytes. So
upstream will get the following data:
0 - 100, 300 - (EOS), as it will continue requesting from where
it has last stopped, but tagdemux will add an offset to skip the
tags.
This patch makes sure that the tags have been parsed and skipped
since the first pull range call.
https://bugzilla.gnome.org/show_bug.cgi?id=744580
Accumulate buffers in an adapter instead of appending them because append causes
a lot of memcpys.
Keep track of the last tagsize and accumulate enough data before attempting to
parse more data.
This patch implements a minimal amount of changes in order to not change the
behaviour. We should really rewrite the tag handling and trimming using
the adapter API instead of merging and trimming into a buffer.
id3mux and id3v2mux expect GST_TAG_ID3V2_FRAME type to be stored in a
GstSample and not a buffer, which is also needed because we can't
attach extradata/caps to buffers any more. These are private tags
no one should be poking at, and also the extra info is missing.
https://bugzilla.gnome.org/show_bug.cgi?id=707765
The _1_0 suffixed environment variables override the
non-suffixed ones, so if we're in an environment that
sets the _1_0 suffixed ones, such as jhbuild, we need
to set those to make sure ours actually always get
used.
This reverts commit e39fbe6b7e.
Looks like we need to pass the full .la file after all in a setup
with libtool, or it might not find the library, e.g. like
ERROR: can't resolve libraries to shared libraries: gstfft-1.0
Conflicts:
gst-libs/gst/audio/Makefile.am
gst-libs/gst/pbutils/Makefile.am
Also see https://bugzilla.gnome.org/show_bug.cgi?id=603710