Videodecoder does late renegotiation, it will wait for the next
buffer before renegotiating its caps and bufferpool. It might happen
that downstream element switched from passthrough to non-passthrough
and sent a reconfigure upstream (that caused this renegotiation).
This downstream element will ask the video sink below for the bufferpool
with an allocation query and will get the same bufferpool that
videodecoder is holding, too.
When renegotiating, if videodecoder deactivates its bufferpool it
might be deactivating the bufferpool that some element downstream
is using and cause the pipeline to fail.
https://bugzilla.gnome.org/show_bug.cgi?id=727498
Clock slaving can clip start time to zero, giving us a shorted
duration than we originally got. To keep in sync, we must then
discard the samples falling before that zero timestamp.
This possibly fixes random distortion caused by constant PA
underflows which are never resynced.
The KEMAC payload actually needs to have subpayloads and the key should
go into the KEY_DATA subpayload. Add support for subpayloads and
implement the KEY_DATA payload.
Add some pointers to the conversion functions that allow us to add
encryption and decryption later.
baseparse will reverse each GOP for us already, so the segment events can
be after our keyframe. Make sure to get it and all other relevant sticky
events before starting to decode.
MIKEY is defined in RFC 3830 and is used to exchange SRTP encryption
parameters between a sender and a receiver in a secure way.
This library implements a subset of the features, enough to implement
RFC 4567, using MIKEY in SDP and RTSP.
* Only check for conditions we are interested in.
* Makes no sense to specify G_IO_ERR and G_IO_HUP in condition, they
will always be reported if they are true.
* Do not create timed source if timeout is NULL.
* Correctly wait for sources to be dispatched, context_iteration() is
not guaranteed to always block even if set to do so.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=726641
This provides an audio-filter and video-filter property to allow
applications to set filter elements/bins. The idea is that these will
e
applied if possible -- for non-raw sinks, the filters will be skipped.
If the application wishes to force the application of the filters, this
can be done by setting the new flag introduced on playsink -
GST_PLAY_FLAG_FORCE_FILTERS.
https://bugzilla.gnome.org/show_bug.cgi?id=679031
This provides an audio-filter and video-filter property to allow
applications to set filter elements/bins. The idea is that these will be
applied if possible -- for non-raw sinks, the filters will be skipped.
If the application wishes to force the application of the filters, this
can be done by setting the new flag introduced on playsink -
GST_PLAY_FLAG_FORCE_FILTERS.
https://bugzilla.gnome.org/show_bug.cgi?id=679031
Re-generate .args and .signals file from scratch so that
old signals that no longer exist (such as the 'new-decoded-pad'
signal on decodebin) no longer show up in the documentation.
Add an extra function to the oggstream map to inform it about
the incoming buffers. This way oggmux can keep a count on the
vp8 invisible frames and calculate the granulepos correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=722682
vp8 stream header shouldn't be assumed to be provided in caps always
as this would repeat the same code in all demuxers/encoders. Instead,
make oggmux generate them if they are not supplied.
https://bugzilla.gnome.org/show_bug.cgi?id=722682
2 seconds might be too small for some container formats, e.g.
MPEGTS with some video codec and AAC/ADTS audio with 700ms
long buffers. The video branch of multiqueue can run full while
the audio branch is completely empty, especially because there
are usually more queues downstream on the audio branch.
Usually these buffers are multiple seconds large, and having a maximum
of 5 buffers in the multiqueue there can use a lot of memory. Lower
this to 2 for adaptive streaming demuxers.
The typefinder returns LIKELY for as little as one possible
sync and no bad sync (not even taking into account how much
data was looked at for that). It's generally just not fit
for purpose, so should just not return anything like LIKELY
at all ever, even more so since it only recognises one out
of ten H263 files, and likes to mis-detect mp3s as H263.
https://bugzilla.gnome.org/show_bug.cgi?id=700770https://bugzilla.gnome.org/show_bug.cgi?id=725644
