- 12 Jul, 2015 2 commits
-
-
Tim-Philipp Müller authored
For more optimised RTP packet handling: means we don't need to map the input buffer again but can just re-use the mapping the base class has already done. https://bugzilla.gnome.org/show_bug.cgi?id=750235
-
Tim-Philipp Müller authored
For more optimised RTP packet handling: means we don't need to map the input buffer again but can just re-use the map the base class has already done. https://bugzilla.gnome.org/show_bug.cgi?id=750235
-
- 09 Jul, 2015 7 commits
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
Estimating it from the RTP time will give us the PTS, so in cases of PTS!=DTS we would produce wrong DTS. As now the estimated DTS is based on the clock, don't store it in the jitterbuffer items as it would otherwise be used in the skew calculations and would influence the results. We only really need the DTS for timer calculations. https://bugzilla.gnome.org/show_bug.cgi?id=749536
-
Thiago Santos authored
-
Thiago Santos authored
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;
-
Thiago Santos authored
Fix indent on this file and break some comment lines into two to make it fit 80 chars per line
-
Thiago Santos authored
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.
-
Thiago Santos authored
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.
-
- 08 Jul, 2015 12 commits
-
-
-
Havard Graff authored
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
-
Stian Selnes authored
This reverts commit 05bd708f. 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.
-
Thiago Santos authored
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.
-
Thiago Santos authored
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.
-
Thiago Santos authored
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.
-
Thiago Santos authored
It is allocating samples_count + n_samples, not only n_samples
-
Sebastian Dröge authored
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
-
Sebastian Dröge authored
That is, handle DTS==GST_CLOCK_TIME_NONE correctly. https://bugzilla.gnome.org/show_bug.cgi?id=749536
-
Vineeth T M authored
when seek fails in avidemux, event is not being freed. https://bugzilla.gnome.org/show_bug.cgi?id=752117
-
Stian Selnes authored
Plus new unit test. https://bugzilla.gnome.org/show_bug.cgi?id=752112
-
Vineeth TM authored
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
-
- 07 Jul, 2015 14 commits
-
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
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.
-
Tim-Philipp Müller authored
-
-
-
Stefan Sauer authored
Add symbols or change comment into a regular comment.
-
Stefan Sauer authored
-
Stefan Sauer authored
-
Luis de Bethencourt authored
This reverts commit d46631c5. 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.
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
The handle_buffer vfunc takes ownership of the input buffer. Fixes elements/rtp-payloading under valgrind.
-
Tobias Mueller authored
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
-
Tim-Philipp Müller authored
-
Ohn Yongjin authored
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
-
- 06 Jul, 2015 5 commits
-
-
Jan Alexander Steffens (heftig) authored
Allows for non-keyframe seeks. https://bugzilla.gnome.org/show_bug.cgi?id=738570
-
Thiago Santos authored
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
-
Vineeth TM authored
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
-
Hyunjun Ko authored
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
-
-