Age | Commit message (Collapse) | Author | Files | Lines |
|
map is the input buffer mapinfo, we actually want to set the
*outgoing* atom size.
|
|
Supports CEA 608 and CEA 708 CC streams
Also supports usage in "Robust Prefill" mode if the incoming caption
stream is constant (i.e. there is one incoming CC buffer for each
video frame).
https://bugzilla.gnome.org/show_bug.cgi?id=606643
|
|
|
|
Only the 'gmin' atom is required. Any other entry within it are
optional.
https://bugzilla.gnome.org/show_bug.cgi?id=606643
|
|
It was similar for all pads
https://bugzilla.gnome.org/show_bug.cgi?id=606643
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=606643
|
|
Comes from gpac apparently. The codec_data uses the same packing
mechanism as matroska.
https://bugzilla.gnome.org/show_bug.cgi?id=738244
|
|
This exposes a new property, mtu, which is used to determine the
initial size of buffers from the buffer pool. If received data
exceeds this, the element gracefully handles that in a manner similar
to what we had previously: a large memory gets filled and reallocated
at the next call to "fill".
The default size is set to 1500, which should cover most use cases.
With contributions from Mathieu Duponchelle <mathieu@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=772841
|
|
Optimize GstUdpSrc for cache performance.
Move the hot properties, which are used by the read function, to the top:
@used_socket, @addr, @cancellable, @skip_first_bytes, @timeout,
@retrieve_sender_address.
Remove the unused property @ttl.
Where needed reorder so that holes are avoided (the 64-bit @timeout)
https://bugzilla.gnome.org/show_bug.cgi?id=772841
|
|
The samples table is sorted by DTS, not PTS. As such we can only get the
correct result when using a binary search on it, if we search for the
DTS.
Also if we only ever search for the frame, where the following frame is
the first one with a PTS after the search position, we will generally
stop searching too early if frames are reordered.
In forwards playback this is not really a problem (after the decoder
reordered the frames, clipping is happening), in reverse playback
it means that we can output one or more frames too few as we stop too
early and the decoder would never receive it.
https://bugzilla.gnome.org/show_bug.cgi?id=782118
|
|
By moving variable declarations out of loop headers.
|
|
|
|
|
|
|
|
As on Ubuntu Trusty.
https://bugzilla.gnome.org/show_bug.cgi?id=794493
|
|
76e458a119926424e9dd5acf3210a592a314d713 changed the conditions from
"queued > threshold" to "queued >= threshold", which broke hlssink2 and
resulting in too small fragments being created although keyframes would
be at *exactly* the configured threshold.
https://bugzilla.gnome.org/show_bug.cgi?id=794440
|
|
Fix compilation with MSVC. We still assume that attribute
is supported by all other relevant compilers, which seems
to be the case since we haven't had any complaints about
similar code in rtpsbcpay.
|
|
Use GLib macro instead, even if it's a bit unwieldy.
|
|
Fixes build with MSVC, and possibly other compilers too.
|
|
|
|
|
|
|
|
These were missed when they were added to Makefile.am
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=793103
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=793103
|
|
|
|
|
|
The muxed buffers will not carry the duration of the
incoming buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=793457
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=793457
|
|
This works around a bug in various ONVIF cameras that implement the
attributes the wrong way around. They still won't work with a
backchannel but at least normal playback will work for the time being.
It restores pre-1.14 behaviour where we would fail to preroll on any SDP
that lists a recvonly stream. For 1.16 a better solution should be
found.
The problem here is that the ONVIF spec has the meaning of the two
attributes the wrong way around in the examples, compared to RFC4566.
https://bugzilla.gnome.org/show_bug.cgi?id=793715
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=793961
|
|
The aggregator segment is now exposed on the src pad
https://bugzilla.gnome.org/show_bug.cgi?id=793945
|
|
As stated in commit c2956036b8da4b8f22a63a4f5a254be03e870aa6 in -bad,
the wasapi elements are now better than directsound, and should be
preferred if they are available.
For a later release, once the elements have more testing, we can
consider moving them to -good.
|
|
or we're muxing only audio
Based on a patch by Nicola Murino <nicola.murino@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=792775
|
|
Only up to timescale * G_MAXINT16 is possible as cluster duration, which
is already higher than our default value. Using higher values would
cause overflows and broken files.
Based on the investigation by Nicola Murino <nicola.murino@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=792775
|
|
Matroska does not support changing the stream type and stream properties
after the headers were started to be written, and for example H264
codec_data changes can't be supported.
https://bugzilla.gnome.org/show_bug.cgi?id=782949
|
|
The default of the allow-no-red-blocks property was changed in a
previous commit, thus breaking the test assumptions
|
|
rtpulpfeccommon.c:432:27: error: format ‘%lx’ expects argument of type
‘long unsigned int’, but argument 10 has type ‘guint64 {aka long long unsigned int}’
https://bugzilla.gnome.org/show_bug.cgi?id=793732
|
|
|
|
|
|
The ulpfecenc "mux-seq" and "ssrc" properties were initially added
because the element did more than implement ULPFEC. As it was
decided that FLEXFEC would be implemented in a separate element,
both properties are now unneeded and confusing.
Change the default for the ulpfecenc multi-packet property,
as it is expected that most users of this element will be protecting video
streams.
Change the default property for the rtpredenc allow-no-red-blocks
property, as it should also be its default mode of operation.
https://bugzilla.gnome.org/show_bug.cgi?id=793843
|
|
It is expected that when connecting to a stream that has
already started, the caps will only arrive at the interval
specified on rtpgstpay, we shouldn't be warning as this is
a normal mode of operation.
https://bugzilla.gnome.org/show_bug.cgi?id=793798
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=793732
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=792696
|
|
|
|
|
|
|
|
Fixes make distcheck
|
|
|
|
|