In other words, gst_pad_get_current_caps should never return NULL
in a pad-added callback from the demuxer.
Added tests for the two special cases with AAC and H.264 where this
would happen every time.
https://bugzilla.gnome.org/show_bug.cgi?id=763780
Making the event itself writable is not enough, it won't make
the actual taglist in the event writable as well. Instead, just
make a copy of the taglist and then create a new tag event from
that if required, replacing the old one. Before we would
inadvertently modify taglists upstream elements might still
be holding on to. Add unit test for this as well.
https://bugzilla.gnome.org/show_bug.cgi?id=762793
Use fail_unless and friends instead of g_assert
Factor seq-num checking out to separate function
Check more return-values from push and crank and others
https://bugzilla.gnome.org/show_bug.cgi?id=762254
Set GSETTINGS_BACKEND=memory, apparently there's something
about fork() and the dconf backend (or whatever else that
drags in or activates) that messes up locking and causes
timeouts due to deadlocks in g_mutex_lock(), since
everything works fine with CK_FORK=no as well.
The code is supposed to follow somehow what the comment above says, that
is to have one channel with a wave of freq 440 and the other channel
with a wave of freq 880, but an off by one error results in frequencies
of 0 and 440.
https://bugzilla.gnome.org/show_bug.cgi?id=735673
This way we can use -1 as special value, which is nicer than MAXUINT.
This is backwards compatible even with the GValue API, as shown by
a unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=757892
By not doing this, the muxer is not effectively a rtpmuxer, rather a
funnel, since it should be a single stream that exists the muxer.
If not specified, take the first ssrc seen on a sinkpad, allowing upstream
to decide ssrc in "passthrough" with only one sinkpad.
Also, let downstream ssrc overrule internal configured one
We hence has the following order for determining the ssrc used by
rtpmux:
0. Suggestion from GstRTPCollision event
1. Downstream caps
2. ssrc-Property
3. (First) upstream caps containing ssrc
4. Randomly generated
https://bugzilla.gnome.org/show_bug.cgi?id=752694
Avoid using default accept-caps handler that will query downstream
and is more expensive. Just check if the caps is compatible with
the template and check if the channels are the same.
The time of the first RTCP packet is semi-random, so
sometimes it was produced before enough packets from
the second SSRC were received. First drop queued RTCP
packets, then advance the clock enough to ensure
that at least one new RTCP packet is produced.
https://bugzilla.gnome.org/show_bug.cgi?id=750731
The accept-caps query just does a shallow check at the current
element while at this test we want it to also look at downstream.
So use caps query there.
https://bugzilla.gnome.org/show_bug.cgi?id=753623
1) Tests that using dynamic PT instead of the default ones work
2) If we ever decide to change the codec here we don't need to
worry about change the PT for the default one of the new codec
in the test
https://bugzilla.gnome.org/show_bug.cgi?id=746445
The RTP PT for alaw is 8.
Less than 50 packets are received in the length of this test so it
would never drop a buffer or would drop only the last buffer and
it would fail sometimes when the received wouldn't receive the
retransmission packet in time.
https://bugzilla.gnome.org/show_bug.cgi?id=746445
Some of the subtitle chunks will have embedded
NUL-terminators (last three), some don't (first three),
some will have markup, some won't, some will be valid
UTF-8 (all but last), some won't (last stanza).
https://bugzilla.gnome.org/show_bug.cgi?id=752421
Replace static constants with macros to make gcc happy
CC elements/elements_rtpjitterbuffer-rtpjitterbuffer.o
elements/rtpjitterbuffer.c:387:1: error: initializer element is not constant
static const GstClockTime PCMU_BUF_DURATION = PCMU_BUF_MS * GST_MSECOND;
^
elements/rtpjitterbuffer.c:388:1: error: initializer element is not constant
static const guint PCMU_BUF_SIZE = 64000 * PCMU_BUF_MS / 1000;
^
elements/rtpjitterbuffer.c:390:5: error: initializer element is not constant
PCMU_BUF_CLOCK_RATE * PCMU_BUF_MS / 1000;
The amount of time that is completely expired and not worth waiting for,
is the duration of the packets in the gap (gap * duration) - the
latency (size) of the jitterbuffer (priv->latency_ns). This is the duration
that we make a "multi-lost" packet for.
The "late" concept made some sense in 0.10 as it reflected that a buffer
coming in had not been waited for at all, but had a timestamp that was
outside the jitterbuffer to wait for. With the rewrite of the waiting
(timeout) mechanism in 1.0, this no longer makes any sense, and the
variable no longer reflects anything meaningful (num > 0 is useless,
the duration is what matters)
Fixed up the tests that had been slightly modified in 1.0 to allow faulty
behavior to sneak in, and port some of them to use GstHarness.
https://bugzilla.gnome.org/show_bug.cgi?id=738363
