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
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
Also make it so that the mtu is always set if specified, not
only in case of the rather weird bufferlist test code path.
This allows us to easily make the payloader fragment a payload
across multiple output packets by setting a small MTU on it.
Implementation according to RFC 4587.
Payloader create fragments on MB boundaries in order to match MTU size
the best it can. Some decoders/depayloaders in the wild are very strict
about receiving a continuous bit-stream (e.g. no no-op bits between
frames), so the payloader will shift the compressed bit-stream of a
frame to align with the last significant bit of the previous frame.
Depayloader does not try to be fancy in case of packet loss. It simply
drops all packets for a frame if there is a loss, keeping it simple.
https://bugzilla.gnome.org/show_bug.cgi?id=751886
If we have a clock, update "now" now with the very latest running time we have.
If timers are unscheduled below we otherwise wouldn't update now (it's only updated
when timers expire), and also for the very first loop iteration now would otherwise
always be 0.
Also the time is used for the timeout functions, e.g. to calculate any times
for the next timeouts and we would otherwise pass too old times there.
https://bugzilla.gnome.org/show_bug.cgi?id=751636
The mp4 muxer now writes a place-holder mdat as a free
atom followed by a 0-byte mdat that covers the rest of the
file, making it possible to rewrite it as 64-bit, or leave
it as-is if nothing else is written afterward
The calculations were a bit off everywhere, even before the changes done
recently to the delay for RTX of expected future packets. It only worked by
accident, but now the calculations are all correct again. Hopefully.
Both input streams in this test have a segment.start = 10s, so
output should start from 0 anyway.
Another test has both starting at non-0 segments, but the running
time of both streams should still start from 0
