This also copies the caps. Otherwise we could end up pusing
the first buffer without any caps, which causes downstream
to not get notified about the caps.
Fixes bug #664892.
there is at least two use cases where default frame rate
should or may be disabled:
- vp8 stream with altref frame enabled. If default frame rate
is enabled, some players will missinterprete it (critical!)
- for webm container, to reduce micro overhead
- for stream with variable frame rate.
Signed-off-by: Alexey Fisher <bug-track@fisher-privat.net>
Handle corner case where we try to read beyond the end of the
last file part, in which case we want to return a short read.
If we get fewer bytes than expected for any other file part,
we should just error out, since something fishy's going on
then.
Looks like some parsers (in some versions at least) expect the
offsets to be set, and behave weird if that's not the case
(e.g. off-by-one in h264parse).
Support for TAG_IMAGE and TAG_ATTACHMENT is commented out; this requires caps
on buffers which is gone from 0.11.
Segment handling in the demuxer is a bit complex; I added some FIXME comments
in places where I'm not yet sure if I ported correctly.
Conflicts:
ext/pulse/pulseaudiosink.c
ext/pulse/pulsesrc.c
gst/audioparsers/gstaacparse.c
gst/audioparsers/gstamrparse.c
gst/audioparsers/gstdcaparse.c
gst/audioparsers/gstflacparse.c
gst/effectv/gstradioac.c
gst/effectv/gstradioac.h
gst/effectv/gstripple.c
Some possible FIXMEs remaining in the audio parser getcaps functions.
PulseAudio 1.0 supports per-source-output volumes, and this exposes the
functionality via the GstStreamVolume interface.
When compiled against pre-1.0 PulseAudio, the interface is not
implemented, and the "volume" or "mute" properties are not available.
This bit of ugliness will go away when we can depend on PulseAudio 1.0
or greater.
https://bugzilla.gnome.org/show_bug.cgi?id=595055
Tests fail to build because g_mkdtemp is available from glib since
2.26.
This patch adds a condition around the redefinition of
g_mkdtemp on the tests to only build it if glib is older than
2.26.
Let's initialize them to zero. It looks alright, but then it
also looks alright with v3, or with the corresponding pixels
from the source. I don't know what the original intent would
be, and the original effectv source also has this bug/feature.
https://bugzilla.gnome.org/show_bug.cgi?id=661841
