Also the format must be fixed on the default raw caps. If not
gst_video_info_from_caps() will fail and
gst_video_decoder_negotiate_default_caps() return FALSE.
The test simulates the use case where a gap event is received before
the first buffer causing the decoder to fall back to the default caps.
https://bugzilla.gnome.org/show_bug.cgi?id=773103
Add a test that check that we handle time ranges (a range of time that maps to
the same sample).
Also update the other tests to use our check api to compare int64 values to get
better output on failure.
Split large tests into small tests and name them specifically. Use helpers to
avoid repetition. Make sure the order in the file is the same as we add the to
the suite.
Comparing floats for equality is not necessarily going to
work reliably, so use fail_unless_equals_float() for this.
Test would fail on x86 (Intel Atom x5-Z8300).
Elements inherited from GstAudioDecoder, supporting PLC and introducing
delay produce invalid timestamps. Good example is opusdec with in-band FEC
enabled. After receiving GAP event it delays the audio concealment until
the next buffer arrives. The next buffer will have DISCONT flag set which
will make GstAudioDecoder to reset it's internal state, thus forgetting
the timestamp of GAP event. As a result the concealed audio will have the
timestamp of the next buffer (with DISCONT flag) but not the timestamp
from the event.
The serialization of double typed geographical
coordinates to DMS system supported by the exif
standards was previously truncated without need.
The previous code truncated the seconds part of
the coordinate to a fraction with denominator
equal to 1 causing a bug on the deserialization
when the test for the coordinate to be serialized
was more precise.
This patch applies a 10E6 multiplier to the numerator
equal to the denominator of the rational number.
Eg. Latitude = 89.5688643 Serialization
DMS Old code = 89/1 deg, 34/1 min, 7/1 sec
DMS New code = 89/1 deg, 34/1 min, 79114800UL/10000000UL
Deserialization
DMS Old code = 89.5686111111
DMS New code = 89.5688643
The new test tries to serialize a higher precision
coordinate.
The types of the coordinates are also guint32 instead
of gint like previously. guint32 is the type of the
fraction components in the exif.
https://bugzilla.gnome.org/show_bug.cgi?id=767537
This tag match the EXIF_TAG_FOCAL_LENGTH_IN_35_MM_FILM exif tag and is
stored on a short. Hence there is a precision loss compared to the
GstTag which is a double value.
https://bugzilla.gnome.org/show_bug.cgi?id=753930
Doing so prevents us dropping buffers in the rare, but possible, situations,
when the stream changes SSRC and new sequence numbers does not differ
much from the last sequence number from previous SSRC. For example:
ssrc - 0xaaaa 101,102,103,104 ssrc - 0xbbbb 102, 103, 104, 105...
In the scenario above we don't want to drop the first 3 packets of
0xbbbb stream.
https://bugzilla.gnome.org/show_bug.cgi?id=764459
Encrypted RTP buffers may contain encrypted padding, hence it's
necessary to have an option to relax the validation in order to
successfully map the buffer.
When the flag GST_RTP_BUFFER_MAP_FLAG_SKIP_PADDING is set
gst_rtp_buffer_map() will map the buffer like if padding is not
present.
https://bugzilla.gnome.org/show_bug.cgi?id=752705
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
