An ALSA sink may select a different rate (as we use the _set_rate_near
API, which is not guaranteed to set the exact target rate).
The rest of the code seems to already handle this well, as output
from a 88200 Hz file seems to have the correct pitch when selecting
a 96 kHz rate.
For the USE_TREMOLO case, GstVorbisDec doesn't have
a vb member. Besides, Tremolo's vorbis_dsp_synthesis()
expects a vorbis_dsp_state to be passed as first
argument. Not a vorbis_block.
I'm not 100% sure this is valid on any other X server than mine,
but since the XFree call does not take the context as a parameter,
it seems pretty certain it's the right thing to do, but I'll put
this caveat here in case someone checks in the future.
Fix building of the libgstvideo module on Android by adding the
missing and needed $(DEFAULT_INCLUDES) to CFLAGS for the
androgenizer call on gst-libs/gst/video/Makefile.am
Before this change, building was failing due to gst-plugins-base/
and gst-plugins-base/gst-libs/gst/video being left out of the
include path.
When I first implemented push mode seeking, I removed the chain
freeing there as it could be used later. The current code does not
seem to do that though, so I'm restoring the previous freeing,
which plugs the leak while apparently not reintroducing use of
freed data with chained and normal files, both with gst-launch
playbin2 and Totem.
This reverts commit 5df30c1b90.
I must have dreamt the Valgrind logs, reverting this reintroduces
no leak, and gets rid of the test failures it introduced :S
Not that I have ever seen these in practice, but if they
can't happen we may just as well just assign the new tag
list. Merge properly to be on the safe side, and also
avoid a useless tag list copy in the normal case where
there is no tag list yet.
A first hang was happening when trying to locate a page backwards,
where we'd sync forever on the same page.
With that fixed, a second hang would happen after preparing an EOS
event, but with no chain created yet to send it to, the pipeline
would stay idle forever.
An element error is now emitted for this case.
RTCP header can be (2^16 + 1) * 4 bytes long, so when validating a bogus
packet it was possible to get a 16bit overflow resulting in a length of 0.
This would put the gst_rtcp_buffer_validate_data function in a endless loop.
https://bugzilla.gnome.org/show_bug.cgi?id=667313
... to avoid unnecessary spurious errors (upon e.g. shutdown).
If a real error is applicable in this unusual circumstance (missing other pad),
other (STREAM_LOCK protected) call paths can take care of that.
Pads are initialized twice: when requesting pads and when
initializing collectpads. Avoid double initialization by
checking if collectpads are still going to be initialized when
creating request pads.
When the payload for an Exif tag is less than or equal to 4 bytes,
the data is simply put into the offset field. Fix writing these
kinds of payloads on big endian systems (and possibly also on
little endian systems). The caller will have already formatted
the bytes in memory according to the writer's endianness, so just
write out the bytes as they are in this case. Fixes tags unit test
on big endian systems.
We used to add a trailing \n to the end of generated xmp packets.
Windows viewer was unhappy with it and we fixed it in
96d2120c2b
The problem is that this caused xmp generated before this fix
to not be recognized and parsed anymore. This patch makes it
recognize xmp with the trailing \n and without, fixing the
regression. Also adds tests for it.
