Push all pending events before pushing the gap. This ensures the
segment is pushed before the gap so it can be properly translated
to the running time
Includes unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=753360
The padding (if any) is included in the length of the last packet, see
RFC 3550.
Section 6.4.1:
padding (P): 1 bit
If the padding bit is set, this individual RTCP packet contains
some additional padding octets at the end which are not part of
the control information but are included in the length field. The
last octet of the padding is a count of how many padding octets
should be ignored, including itself (it will be a multiple of
four).
Section A.2:
* The padding bit (P) should be zero for the first packet of a
compound RTCP packet because padding should only be applied, if it
is needed, to the last packet.
* The length fields of the individual RTCP packets must add up to
the overall length of the compound RTCP packet as received.
https://bugzilla.gnome.org/show_bug.cgi?id=751883
Add flags and enums to support multiview signalling in
GstVideoInfo and GstVideoFrame, and the caps serialisation and
deserialisation.
videoencoder: Copy multiview settings from reference input state
Add gst_video_multiview_* support API and GstVideoMultiviewMeta meta
https://bugzilla.gnome.org/show_bug.cgi?id=611157
According to this section of the rfc.
https://tools.ietf.org/html/rfc5506#section-3.4.2
The validation should be updated to accept more types of RTCP
packages, with this mask change feedback packages will be also
accepted.
Change-Id: If5ead59e03c7c60bbe45a9b09f3ff680e7fa4868
The original 0/1 framerate must still be allowed to be configured
on the upstream side of videorate, otherwise future caps renegotiation
is going to fail.
https://bugzilla.gnome.org/show_bug.cgi?id=750032
[API] gst_discoverer_info_to_variant
[API] gst_discoverer_info_from_variant
[API] GstDiscovererSerializeFlags
+ Serializes as a GVariant
+ Adds a test
+ Does not serialize potential GstToc (s)
https://bugzilla.gnome.org/show_bug.cgi?id=748814
Remove all the bus watch and main loop code from the block_deadlock
test, it's not needed: neither pipeline will ever post an EOS or ERROR
message on the bus, and we're the only ones posting an error, from a
timeout. Might just as well just sleep for a bit and then do whatever
we want to do.
Don't gratuitiously set tcase timeout, just use whatever is the
default (or set via the environment).
Make individual pipeline runs shorter.
Check for valgrind and only do a handful iterations when running
in valgrind, not 100 (each iteration takes about 4s on a core i7).
Make videotestsrc output smaller buffers than the default resolution,
we don't care about the buffer contents here anyway.
Fixes test timeouts when run in valgrind.
On slower systems, or under high system load (e.g. check-valgrind),
the sending_buffers_with_9_gstmemories test would sometimes fail,
because the read call only returns 32 bytes instead of the full
36 bytes expected. This is because multisocketsink might end up
doing a partial write of 32 bytes first, and then write the
missing 4 bytes later, but since we don't wait for all of data
to be written, there's a short window where our read call in the
unit test might then only receive the 32 bytes written so far,
which makes it deeply unhappy.
Instead, make sure we loop to read all bytes.
This test sets a rather short timeout, increase this when
we run under valgrind. Also add a short sleep to the
fakesrc ! fakesink pipeline to avoid thrashing the CPU,
which would often not stop the main loop when it should.
Also fix wrong (0.10) return value from pad probe callback.
In case upstream does not provide videorate with framerate information,
it will detect the current framerate from the buffer it received,
but if downstream forces the use of variable framerate (most probably
through the use of a caps filter with framerate = 0 / 1), videorate will
respect that.
And add some unit tests
https://bugzilla.gnome.org/show_bug.cgi?id=734424
When generating segment, we can't assume the first buffer is actually
the first expected one. If it's not, we need to adjust the segment to
start a bit before.
Additionally, we if don't know when the stream is suppose to have
started (no clock-base in caps), it means we need to keep everything in
running time and only rely on jitterbuffer to synchronize.
https://bugzilla.gnome.org/show_bug.cgi?id=635701
This provides notification that the socket in use was closed by the peer
and gives an opportunity to replace it with a new one which is not
closed, allowing reading from many sockets in order.
I use this in pulsevideo to implement reconnection logic to handle the
pulsevideo service dieing, such that is can be restarted without
disrupting downstream.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=739546
`socketsrc` can be considered a source counterpart to `multisocketsink`.
It can be considered a generalization of `tcpclientsrc` and
`tcpserversrc`: it contains all the logic required to communicate over
the socket but none of the logic for creating the sockets/establishing
the connection in the first place, allowing the user to accomplish this
externally in whatever manner they wish making it applicable to other
types of sockets besides TCP.
This commit essentially copies the implementation directly from
tcpserversrc. Later patches will tidy the implementation up and
re-implement `tcpclientsrc` and `tcpserversrc` in terms of `socketsrc`.
See https://bugzilla.gnome.org/show_bug.cgi?id=739546
If a buffer is made up of non-contiguous `GstMemory`s `gst_buffer_map`
has to copy all the data into a new `GstMemory` which is contiguous. By
mapping all the `GstMemory`s individually and then using scatter-gather
IO we avoid this situation.
This is a preparatory step for adding support to multisocketsink for
sending file descriptors, where a GstBuffer may be made up of several
`GstMemory`s, some of which are backed by a memfd or file, but I think this
patch is valid and useful on its own.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=746150
Should wait state change complete before start another state change.
Can't ensure can received async-done message when state change from PLAYING to PAUSED.
https://bugzilla.gnome.org/show_bug.cgi?id=736655
Don't feed 64-bit integer variable into vararg function that expects
an unsigned integer to go with GST_TAG_TRACK_NUMBER. This would
cause crashes on 32-bit platforms, and if not that then test
failures if the comparisons fail later (at least on big endian
platforms).
Test that a pipeline can change from PLAYING to PAUSED and back in
the following scenarios:
1. One track reach EOS after pushed some buffers while another track
still pushes buffers
2. One track reach EOS without buffers while another track still pushes
buffers
https://bugzilla.gnome.org/show_bug.cgi?id=736655
