We shouldn't register a new GstTag for every unknown tag
we find as this might lead to conflicts and also those
tags are essentially unknown.
Add mappings for some known tags and also convert string
dates to GDate, as found in many FLV files.
Since neither rtpmanager nor any of the payloaders properly implement
pad allocation, there is no way for the rtpmanager to inform downstream elements
of the new SSRC if there is an SSRC collision. So the warning is emitted all the
time and it is confusing.
Fixes#580144
Newer libsoundtouch requires that we include an extra header that wasn't
previously required, so define HAVE_SOUNDTOUCH_1_4 for newer builds so that it
gets included.
When we get bus messages for setting the xid, we have the real sink element
instance as message_src. No need to proxy the xoverlay iface therefore
(autovideosink does not do it either). Also we don't need to rewrite the
message src of all messages from that sink.
When a segment event is received on the active pad, forward it downstream
immediately instead of deferring it until the next data buffer arrives. This
fixes problems with segment updates never being sent downstream, like those
needed for sparse streams, or for closing previously opened segments.
This fixes playback of DVD menus with a still video frame and an audio track,
for example.
Fixes: #577843
modplug's sndfile.h conflicts with libsndfile's sndfile.h, so
we'll access it directly using modplug/sndfile.h. Fixes#573849
Signed-off-by: David Schleef <ds@schleef.org>
Add a virtual method in rawparse to set buffer flags. This doesn't
use API from unreleased -base, since it defines GST_VIDEO_BUFFER_TFF
if it's not defined yet.
This should remove the bogus error messages while still keeping the original
intent of this, which is to inform the pipeline/application/user that we
could not find any valid streams.
There are many reasons why pushing an event can fail, and not all of them are
because there's no link downstream (it could be because it was blocked, or
flushing).
itvhd masks its h264 video stream as a private stream making it harder for
other set top boxes to decode. this checks for specific program number, video
pid and stream type combination before declaring it as h264.
apple's compiler carps, with reason, about some constructs in osxvideosrc.c
fix them.
also it seems that for some reason this required a gst-indent run. whee
