A race was observed between query() and setcaps() where the latter would
change the ringbuffer spec while the former was performing operations
based this data.
Observed a case where the src went to null-state during the query,
hence the spec pointer was no longer valid, and
gst_util_unit64_scale_int crashed (assertion `denom > 0´failed)
Add locking to make sure the ringbuffer can't disappear.
Given a large enough drift-tolerance, one could end up in a situation
where one would keep aligning the written buffers behind the current
read-segment position. The result for the reader would be complete
silence, possible preceded by very choppy audio.
By checking the available headroom, one can determine if there is
room to do alignment, or if one should resort to a resync instead to get
the pointers back on track.
Also refactor the alignment-logic out of the render function for cleaner
code.
This is the official, standardized way of embedding pictures
inside vorbiscomments now. Parsing code taken from flacparse
and slightly changed.
Fixes bug #635669.
Commit ba2e500bd9 ensured to provide
a running clock when EOS had finished rendering. However,
other measures are needed (and were in place before) to ensure a
running clock when EOS still needs rendering (i.e. waiting).
So, specifically, re-introduce eos_rendering removed in aforementioned commit,
this time as a public variable so subclasses can be aware of the situation.
Fixes (part of) #645961.
API: GstBaseAudioSink:eos_rendering
The GstTagXmpWriter interface is to be implemented on elements that
provide xmp serialization. It allows users to select which
xmp schemas should be used on serialization.
API: GstTagXmpWriter
https://bugzilla.gnome.org/show_bug.cgi?id=645167
This fixes a regression that an assertion would happen if
gst_video_get_component_offset would be called with width or
height as 0.
Calling it with 0 is fine if the format isn't yuv and this
was already being used in some other places of video.c
Subtitle streams being parse can cause the pipeline to wait indefinitely
to PREROLL. This makes subtitle streams got to PAUSED even if no data is
available. This should not be a cause for concern as we don't expect to
get much data for subtitle streams other than language tags from the
container.
https://bugzilla.gnome.org/show_bug.cgi?id=632291
Maps to GST_BUFFER_FLAG_MEDIA4. The purpose is to explicitly indicate
whether a telecined buffer is progressive or not without having to make
assumptions based on previous buffers.
This makes sure we maintain a ref on the discoverer object while the
async timeout callback is alive to prevent a potential crash if the
object is freed while the callback is pending.
https://bugzilla.gnome.org/show_bug.cgi?id=641706
We want to make sure the discoverer object passed to the various
callbacks doesn't become invalid if a callback is pending and the object
is free'd in the mean time.
https://bugzilla.gnome.org/show_bug.cgi?id=641706
Otherwise, having 2 tagdemux in a row followed by an element operating in
pull mode will make the second tagdemux implictly eat the first tagdemux'
tag event(s).
Fixes (part of) #641047.
... as that is the specification and fixes compilation on Cygwin:
gstxmptaag.c: In function 'read_one_tag':
gstxmptag.c:1015: error: array subscript has type 'char'
Variable was being written to and could cause crashes
if multiple elements were parsing xmp at the same time.
Moving it to local scope solves the problem.
This makes sure we do not touch the stream taglist once the pipeline has
been prerolled. Adding of stream tags happens in the pad event probe
which runs in a different thread from discoverer stream processing, so
modifying the tag list while discoverer might be processing it can
sometimes cause a crash.
https://bugzilla.gnome.org/show_bug.cgi?id=639778
This avoids a race where the timeout callback is scheduled to run but we
get sufficient information to finish discovery before actually getting
around to executing the callback. See the documentation of
g_source_is_destroyed() for more details.
https://bugzilla.gnome.org/show_bug.cgi?id=639730
This ensures that everything is properly cleaned up before the
GstDiscoverer object is freed. Specifically, it makes sure that we've
removed the async timeout callback before freeing the object to avoid a
potential crash later on.
https://bugzilla.gnome.org/show_bug.cgi?id=639755
Use LC_MESSAGES rather than LC_ALL. Save/load description as untranslated string
when using an English language locale. Strip locale information to the language,
so we don't save keys like description[fr_FR.UTF-8]=...
https://bugzilla.gnome.org/show_bug.cgi?id=638860
Makes things work again properly in uninstalled setups (and
presumably in installed setups where GStreamer is installed
into a non-standard prefix). Requires fixes from core git.
https://bugzilla.gnome.org/show_bug.cgi?id=639039
Need to pass libgstreamer-0.10 explicitly to linker, since we're
calling gst_init(), which in turn is needed because the encoding
target get_type() function calls gst_value_register().
https://bugzilla.gnome.org/show_bug.cgi?id=639039
Make sure to use the PKG_CONFIG_PATH set at configure time instead of
just relying on an env-var set one. This makes sure both g-ir-compiler
and g-ir-scanner use the same PKG_CONFIG_PATH for determining include
paths etc.
Observed a case where the sink went to null-state during the query,
hence the ringbuffer-pointer was NULL, causing a crash.
Moving the ringbuffer-check code until after the query, and hold the
lock during the check and while using the spec-values. It should not matter
to the query wether the ringbuffer is present or not, and it actually
gets a time bit more time to get the ringbuffer set up in this case!
Fixes#635231
When we have an invalid running-time (because we clipped, for example) use the
RTP base time for timestamping instead of generating wrong RTP timestamps.
with i686-apple-darwin10-gcc-4.2.1:
encoding-profile.h:134: warning: type qualifiers ignored on function return type
encoding-profile.c:240: warning: type qualifiers ignored on function return type
gstencodebin.c: In function 'next_unused_stream_profile':
gstencodebin.c:454: warning: format '%d' expects type 'int', but argument 8 has type 'GType'
gstencodebin.c:464: warning: format '%d' expects type 'int', but argument 8 has type 'GType'
gst_discoverer_discover_uri() expects the caller to unref the returned
GstDiscovererInfo object. The corresponding gtk-doc annotation was not
updated to reflect this.
We want to send the keealive message a little earlier than the timeout value
specifies. Scale this based on the value of the timeout instead of just assuming
5 seconds.
Because we should act before the rtsp server does a timeout, we
reduce the timeout-time with 5 seconds, this should be safe to always
keep te rtsp connection alive.
https://bugzilla.gnome.org/show_bug.cgi?id=633455
Use GstDiscoverer{Audio,Video}Info in getters like
gst_discoverer_{audio,video}_info_get_*(). This avoids the casts in the macros,
help language bindings and is more correct.
Force regeneration of marshal.[ch] files after prefix changes in
Makefile.am, to avoid build errors for those of us who don't
habitually make clean first.
Adds a tag to inform what mode was used by a camera to calculate
the picture capturing exposure
Also adds mapping to exif and tests
API: GST_TAG_CAPTURING_METERING_MODE
https://bugzilla.gnome.org/show_bug.cgi?id=631773
Adds new tag for tagging sharpness processing used
when capturing an image. Also maps it in the exif
tags.
Tests included.
API: GST_TAG_CAPTURING_SHARPNESS
https://bugzilla.gnome.org/show_bug.cgi?id=631773
There's no reason to make the marshaller public API. Don't install
pbutils-marshal.h header file and use prefix that makes sure the
symbol doesn't get exported.
