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
scrubby has two options, wav and playbin. Wav takes a file location so make
the playbin option take a file location as well instead of an uri. This also
means the usage help string will be correct for the playbin option.
In scrubby, there is no need to link wavparse with the sink dynamically.
The pad is available when the element is generated.
Change video and audio sinks to the automatically detected sinks.
gtk_widget_set_double_buffered () has been deprecated since GTK 3.14.
Also, widgets are realized automatically and gtk_wiget_realize () is only
meant to be used in widget implementations.
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
