| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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;
|
|
Fix indent on this file and break some comment lines into two to make
it fit 80 chars per line
|
|
When a new time segment is received upstream is going to restart
with a new atom. Make the neededbytes and todrop variables
reflect that to avoid waiting too much or dropping the
initial bytes that contain the header.
|
|
The adapter might have data remaining from the previous segment,
push it all before clearing the adapter and starting a new segment.
It can accumulate data if it had pushed and got not-linked, returning
immediately without processing all the data. Before starting a new
segment this data should be handled.
|
|
packet after a reset
https://bugzilla.gnome.org/show_bug.cgi?id=749536
|
|
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
|
|
This reverts commit 05bd708fc5e881390fe839803b53144393d95ab0.
The reverted patch is wrong and introduces a regression because there
may still be time to receive some of the packets included in the gap
if they are reordered.
|
|
Avoids accumulating all samples from a fragmented stream that could
lead to a 'index-too-big' error once it goes over 50MB of data. It
could reach that before 2h of playback so it doesn't take that long.
As upstream elements are providing data in time format they should
be the ones that have more information about the full media index
and should be able to seek if possible.
|
|
upstream_newsegment isn't really clear on what it means, it is set
to TRUE when the upstream element sends a segment in TIME format, so
rename it to be more clear about it.
It is important to know this because it means that upstream has
a notion of time and qtdemux is likely being driven by an upstream
element that is reading from a higher level abstraction than a file,
such as a DASH, MSS or DLNA element.
|
|
In fragmented streaming, multiple moov/moof will be parsed and their
previously stored samples array might leak when new values are parsed.
The parse_trak and callees won't free the previously stored values
before parsing the new ones.
In step-by-step, this is what happens:
1) initial moov is parsed, traks as well, streams are created. The
trak doesn't contain samples because they are in the moof's trun
boxes. n_samples is set to 0 while parsing the trak and the samples
array is still NULL.
2) moofs are parsed, and their trun boxes will increase n_samples and
create/extend the samples array
3) At some point a new moov might be sent (bitrate switching, for example)
and parsing the trak will overwrite n_samples with the values from
this trak. If the n_samples is set to 0 qtdemux will assume that
the samples array is NULL and will leak it when a new one is
created for the subsequent moofs.
This patch makes qtdemux properly free previous sample data before
creating new ones and adds an assert to catch future occurrences of
this issue when the code changes.
|
|
It is allocating samples_count + n_samples, not only n_samples
|
|
This is required to properly schedule packet loss timers and make
sure all our calculations work properly.
https://bugzilla.gnome.org/show_bug.cgi?id=749536
|
|
overflowing calculations
That is, handle DTS==GST_CLOCK_TIME_NONE correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=749536
|
|
when seek fails in avidemux, event is not being freed.
https://bugzilla.gnome.org/show_bug.cgi?id=752117
|
|
Plus new unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=752112
|
|
v_len is of type guint64, but while print the value(16 + len_size + v_len)
G_GSIZE_FORMAT is being used instead of G_GUINT64_FORMAT
https://bugzilla.gnome.org/show_bug.cgi?id=752100
|
|
|
|
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.
|
|
|
|
http://tools.ietf.org/html/rfc6597
|
|
http://tools.ietf.org/html/rfc6597
|
|
Add symbols or change comment into a regular comment.
|
|
|
|
|
|
This reverts commit d46631c5c7312ad613397f8238c7a9714ae3ae94.
pad only handle EOS events but not EOS flow, and will push the buffer again
resulting in an assertion error. So we should not handle the buffer
and return EOS flow.
|
|
|
|
The handle_buffer vfunc takes ownership of the input buffer.
Fixes elements/rtp-payloading under valgrind.
|
|
goom_core.c: In function 'goom_update':
goom_core.c:685:5: error: 'param2' may be used uninitialized in this function [-Werror=maybe-uninitialized]
goom_lines_switch_to (goomInfo->gmline2, mode, param2, amplitude, couleur);
^
goom_core.c:684:5: error: 'param1' may be used uninitialized in this function [-Werror=maybe-uninitialized]
goom_lines_switch_to (goomInfo->gmline1, mode, param1, amplitude, couleur);
^
https://bugzilla.gnome.org/show_bug.cgi?id=752053
|
|
|
|
endpos variable does not correctly understand in the
4.6.3 GCC version. So compile error appears when we do
compile rtph261pay using jhbuild.
This patch is fixed the compile error in 4.6.3 GCC version.
https://bugzilla.gnome.org/show_bug.cgi?id=751985
|
|
Allows for non-keyframe seeks.
https://bugzilla.gnome.org/show_bug.cgi?id=738570
|
|
It gets stuck if it only finds a moof and no mfra/mfro or moov
atoms. Skip the moof to continue the parsing to have it either
play or error out.
https://bugzilla.gnome.org/show_bug.cgi?id=745089
|
|
for files which have corrupted header, libflac is not able to
process the metadata properly. We just try to ignore the error
and continue with the processing, since metadata parsing is not
making much of a difference to libflac
https://bugzilla.gnome.org/show_bug.cgi?id=751334
|
|
ximage metadata can't be transformed or copied, but provide an empty
transformation function instead of NULL to allow unconditional calling
of metas' transform functions.
https://bugzilla.gnome.org/show_bug.cgi?id=751778
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=752012
|
|
Draft 16 of "RTP Payload Format for VP8" states in section 4.2 that:
R: Bit reserved for future use. MUST be set to zero and MUST be
ignored by the receiver.
https://bugzilla.gnome.org/show_bug.cgi?id=751929
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=751982
|
|
From f74b2df to 9aed1d7
|
|
gstrtph261pay.c: In function 'gst_rtp_h261_pay_class_init':
gstrtph261pay.c:1003:17: error: variable 'gobject_class' set but not used [-Werror=unused-but-set-variable]
GObjectClass *gobject_class;
|
|
flow return
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
When there are a lot of small gaps, we can consider that there is
a big gap (too losses) to reset the buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=751636
|
