Buffer is added to the internal cache, and pushed only when accumulated
buffer duration crosses 200 ms. So when the chain ends, the buffer accumulated
is not freed. Freeing the cache when the state changes from PAUSED to READY.
https://bugzilla.gnome.org/show_bug.cgi?id=754212
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
If seeking targets an empty segment skip it as there is no media
offset to get from it. Instead look for the next one.
This doesn't make seeking in push-mode work if you seek to an
empty segment but at least won't get you to wrong offsets.
https://bugzilla.gnome.org/show_bug.cgi?id=753484
mux_start_time refers to the running_time of the buffer
that goes first in the output file. Normally this time is
0, so this variable is initialized to 0 during the state
change to PAUSED.
However, when dealing with dynamic pipelines and starting
a recording while the pipeline has already run for a while,
the running_time of the first buffer is > 0 and this causes
a problem with detecting the end of the first file(s) when
splitting by duration, because the code will later compare
the threshold_time with (last buffer running_time - mux_start_time)
and will get it wrong until mux_start_time advances enough
to make this difference < threshold_time, creating empty files
in the meantime.
https://bugzilla.gnome.org/show_bug.cgi?id=753624
During reverse playback, the media should stop playing at segment.start
This does not happen, and avidemux continues to process data even when
current timestamp is less that segment.start.
https://bugzilla.gnome.org/show_bug.cgi?id=755094
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.
Caps from the pad template are being leaked. In any case it is
from a static pad template and will 'leak' in the end, just doing
the cleanup for the good practice.
On reading LOAS config, flag v=1 and vA=1 combination can occur, leading to warning
"Spec says "TBD"...". Returning TRUE on this case while parameters 'sample_rate' and
'channels' are pointing to uninitialized values can end on setting random values as
rate and channels on src caps.
https://bugzilla.gnome.org/show_bug.cgi?id=755611
Otherwise we end up considering the values did not change and we wrongly
work with the old video format (which will lead to wrong
behaviour/segfaults).
https://bugzilla.gnome.org/show_bug.cgi?id=755621
eceb2ccc73 broke segment seeks by always
accumulating segments manually when activating a segment. This is only
needed when handling edit lists, not when activating a segment because of a
seek. Do the accumulation when switching edit list segments instead.
This fixes segment seeks again, while keeping edit lists playback working.
https://bugzilla.gnome.org/show_bug.cgi?id=755471
* use g_list_free_full(), don't iterate elements maually when freeing
* call gst_rtp_*_pay_clear_packet(), don't duplicate its code
* use gst_buffer_unref() to clarify that it is buffers being released,
instead of refering directly to gst_mini_object_unref()
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=755277
It's normal when dropping into the middle of a stream to
not always have the config available immediately, so skip LOAS
until a valid config is seen without either setting invalid
caps or erroring out.
https://bugzilla.gnome.org/show_bug.cgi?id=751386
flac contains the sample offset in the frame header, so after a seek
without index flacparse will know the exact position we landed on and
timestamp buffers accordingly. It only set the pts though, which means
the baseparse-set dts which was set to the seek position prevails, and
since the seek was based on an estimate, there's likely a discrepancy
between where we wanted to land and where we did land, so from here on
that dts/pts difference will be maintained, with dts possibly multiple
seconds ahead of pts, which is just wrong. The easiest way to fix this
is to just set both pts and dts based on the sample offset, but perhaps
parsed audio should just not have dts set at all.
https://bugzilla.gnome.org/show_bug.cgi?id=752106
One-line removal of tags_written++
This should fix rtmp output to crtmpserver, and hopefully
noone is expecting that the element count includes the end
element, as different bits of documentation say different
things about whether it should or not.
https://bugzilla.gnome.org/show_bug.cgi?id=661624
Apparently the Microsoft Azure RTMP server requires that the
videodatarate and audiodatarate metadata be provided, so
set those, even if it's to 0. Use the actual input bitrate
tags if available.
In parse_keymgmt(), don't mutate the input string that's been passed
as const, especially since we might need the original value again if
the same key info applies to multiple streams (RTX, for example).
When a resource is 404, and we have auth info - retry with the auth
info the same as if we had receive unauthorised, in case the resource
isn't even visible until credentials are supplied.
Fix a memory leak handling Mikey data.
When generating a random keystring, don't overrun the 30 byte
buffer by generating 32 bytes into it.
In gst_smpte_collected(), check upfront if input formats are same
or not. This avoids allocation of in1 and in2 buffers and
subsequent memory leak when input formats do not match.
https://bugzilla.gnome.org/show_bug.cgi?id=754153
When we haven't started yet, set the start_index when we set the index property,
so that we start at the right index position after the initial seek. The index
property was never really meant to be for writing, but it used to work, so let's
support it for backwards compatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=739472
Commit 7d7e54ce68 added support for
DASH common encryption, however commit
bb336840c0 that went onto master
shortly before the CENC commit caused the calculation of the CENC
aux info offset to be incorrect.
The base_offset was being added if present, but if the base_offset
is relative to the start of the moof, the offset was being added twice.
The correct approach is to calculate the offset from the start of the
moof and use that offset when parsing the CENC aux info.
Sometimes it is useful to know this information on the
server side. Other popular implementations (vlc, ffmpeg, ...)
also send this header on every message.
This includes a new "user-agent" property that the user
can set to use a custom User-Agent string. The default
is "GStreamer/<version>"
https://bugzilla.gnome.org/show_bug.cgi?id=750101
Use constantDuration to calculate the timestamp of non-first AU in the
RTP packet.
If constantDuration is not present in the MIME parameters, its value
must be calculated based on the timing information from two consecutive
RTP packets with AU-Index equal to 0.
https://bugzilla.gnome.org/show_bug.cgi?id=747881
The payloader didn't copy anything so far, the depayloader copied every
possible meta. Let's make it consistent and just copy all metas without
tags or with only the video tag.
https://bugzilla.gnome.org/show_bug.cgi?id=751774
This commit adds support for ISOBMFF Common Encryption (cenc), as
defined in ISO/IEC 23001-7. It uses a GstProtection event to
pass the contents of PSSH boxes to downstream decryptor elements
and attached GstProtectionMeta to each sample.
https://bugzilla.gnome.org/show_bug.cgi?id=705991
GstRTSPMedia uses this classification to detect the real payloader
inside a dynpay bin and asserts if it doesn't find it, therefore
it is required
https://bugzilla.gnome.org/show_bug.cgi?id=753325
Initialize the PT to the default value of the codec and check if
it is still the default before declaring the pt to be dynamic or
not when setting the caps.
Also use the PT constants from the rtp lib when possible
https://bugzilla.gnome.org/show_bug.cgi?id=747965
We need a proper caps event from upstream with the full RTP caps as we can't
create caps ourselves from thin air. Fixes usage of rtpstreamdepay after e.g.
a filesrc or any other element that supports pull mode.
https://bugzilla.gnome.org/show_bug.cgi?id=753066
h264parse does the same, let's keep the behaviour consistent. As we now
include the codec_data inside the stream too here, this causes less caps
renegotiation.
The spec says:
When a picture parameter set NAL unit with a particular value of
pic_parameter_set_id is received, its content replaces the content of the
previous picture parameter set NAL unit, in decoding order, with the same
value of pic_parameter_set_id (when a previous picture parameter set NAL unit
with the same value of pic_parameter_set_id was present in the bitstream).
If the GOP is completed, pads have to start gathering for the
next one but it is possible that the the state might go to
COLLECTING_GOP_START and back to WAITING_GOP_COMPLETE before the
thread has a chance to wake up and proceed, leaving it trapped in
the check_completed_gop loop and deadlocking the other threads
waiting for it to advance.
To solve it, this patch also checks that tha input running time
hasn't changed to prevent this scenario.
h264parse does the same and this fixes decoding of some streams with 32 SPS
(or 256 PPS). It is allowed to have SPS ID 0 to 31 (or PPS ID 0 to 255), but
the field in the codec_data for the number of SPS or PPS is only 5 (or 8) bit.
As such, 32 SPS (or 256 PPS) are interpreted as 0 everywhere.
This looks like a mistake in the part of the spec about the codec_data.
In media to caps function, reserved_keys array is being used for variable i,
leading to GLib-CRITICAL **: g_ascii_strcasecmp: assertion 's1 != NULL' failed
changed it to variable j
https://bugzilla.gnome.org/show_bug.cgi?id=753009
Skip keys from the fmtp, which we already use ourselves for the
caps. Some software is adding random things like clock-rate into
the fmtp, and we would otherwise here set a string-typed clock-rate
in the caps... and thus fail to create valid RTP caps
https://bugzilla.gnome.org/show_bug.cgi?id=753009
Don't hold the main splitmux part lock over
the parent state change function, as it prevents
posting error messages that happen. Since the purpose
is to prevent typefinding from proceeding, use a
separate mutex just for that.
Need to check that the number of bytes we want to copy from the adapter
actually is available and handle the error case gracefully. This error
may happen if malformed packets are received and we don't have a
complete frame.
https://bugzilla.gnome.org/show_bug.cgi?id=752663
The subtitle buffer we push out should not include a NUL terminator
as part of the data, we just add such a terminator for safety, but
it should not be included in the buffer size.
A NUL terminator is not valid UTF-8, so checks will fail if it's
included in the size, and the NUL will be replaced by the fallback
character specified when converting, i.e. '*'.
https://bugzilla.gnome.org/show_bug.cgi?id=752421
In certain applications, splitting into files named after a base
location template and an incremental sequence number is not enough.
This signal gives more fine-grained control to the application to
decide how to name the files.
https://bugzilla.gnome.org/show_bug.cgi?id=750106
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
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
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
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.
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 05bd708fc5.
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.
This reverts commit d46631c5c7.
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.
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
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
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;
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
We always pushed one buffer into the adapter, then handled exactly that one
buffer and flushed it from the adapter. Now also don't memcpy() the actual
payload but just attach the input buffer's data to the output buffer.
This code still needs some serious refactoring/rewriting.
This reverts commit 0c21cd7177.
If we have multiple immediate timers, we want to first handle the one with the
lowest sequence number... which would be broken now.
Instead of this we should just use a GSequence for the timers, and have them
sorted first by timestamp, and for equal timestamps by sequence number. Then
we would always only have to take the very first timer from the list and never
have to look at any others.
Most files don't contain the values for transposing the coordinates
back to the positive quadrant so qtdemux was ignoring the rotation
tag. To be able to properly handle those files qtdemux will also ignore
the transposing values to only detect the rotation using the values
abde from the transformation matrix:
[a b c]
[d e f]
[g h i]
https://bugzilla.gnome.org/show_bug.cgi?id=738681
The media start has nothing to do with the shift we have applied
but with the value of the first PTS. This is defined as:
Dt(0) = 0
Ct(0) = Dt(0) + CTTS(0)
So the media start is always the first CTTS.
https://bugzilla.gnome.org/show_bug.cgi?id=751361
Allows playing edts editted files with proper synchronization of
streams. This patch fixes the regression introduced by
bf95f93c01 that was added to fix
segment seeks handling.
Having the accumulated_base separated from the main segment.base
allows handling both segment seeks and edts editted files.
https://bugzilla.gnome.org/show_bug.cgi?id=751361
Buffers need not to start at running-time 0 so the last_dts needs
to be the value of the first buffer's dts as it is used to compute
the duration of the buffers. If it was left at 0 the first buffer
would have a larger duration when it shouldn't
https://bugzilla.gnome.org/show_bug.cgi?id=751361
Fix 2 startup races when things happen too quickly, and 1
at shutdown by holding a ref to the pads in use until the
loop functions exit.
Handle errors activating file parts and publish them on
the bus.
https://bugzilla.gnome.org/show_bug.cgi?id=750747
Sometimes, extra async-start/done from the internal sink
while the element is still starting up can cause splitmuxsink
to stall in PAUSED state when it has been set to PLAYING
by the app. Drop the child's async-start/done messages while
switching, so they don't cause state changes at the
splitmuxsink level.
https://bugzilla.gnome.org/show_bug.cgi?id=750747
Move the multiview caps calculations to the configure_stream()
function, so the rest of the video info is available, and
use the gst_video_multiview_guess_half_aspect() function to
determine if the half-aspect flag should be set on frame-packed
video.
The cslg atom provide information about the DTS shift. This is
needed in recent version of ctts atom where the offset can be
negative. When cslg is missing, we parse the CTTS table as proposed
in the spec to calculate these values.
In this implementation, we only need to know the shift. As GStreamer
cannot transport negative timestamps, we shift the timestamps forward
using that value and adapt the segment to compensate. This patch also
removes bogus offset of ctts_soffset, this offset shall be included
in the edit list.
https://bugzilla.gnome.org/show_bug.cgi?id=751103
We shift DTS forward to avoid negative timestamps which cannot be
represented with version 0 of the CTTS table. To stick with that
version (backward compatibility), the spec recommend using an
edit list entry to move back the presentation time to where it
should be.
https://bugzilla.gnome.org/show_bug.cgi?id=751242
No need to check for context availability while freeing. We are inside
inside a code block with a condition that dereferences context.
if (context->type == 0 ...
https://bugzilla.gnome.org/show_bug.cgi?id=751306
If update_receiver_stats() fails, we can't really do anything with this buffer
anymore and have to drop it. This happens if there's a big seqnum
discontinuity for example.
https://bugzilla.gnome.org/show_bug.cgi?id=751311
The new property allows to select the time source that should be used for the
NTP time in RTCP packets. By default it will continue to calculate the NTP
timestamp (1900 epoch) based on the realtime clock. Alternatively it can use
the UNIX timestamp (1970 epoch), the pipeline's running time or the pipeline's
clock time. The latter is especially useful for synchronizing multiple
receivers if all of them share the same clock.
If use-pipeline-clock is set to TRUE, it will override the ntp-time-source
setting and continue to use the running time plus 70 years. This is only kept
for backwards compatibility.
In presence of a CTTS, the segment start/stop must be offset so
the segment start/stop include the PTS. This is needed since the
PTS cannot be negative in this format. This fixes issues where the
running time of the first buffer isn't at the start.
https://bugzilla.gnome.org/show_bug.cgi?id=740575
This is done by using new feature of the CollectPad clip function
which sets the DTS as a gint64 in the collected data. It also simplify
the code a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=740575
When deciding whether it's time to switch to a new file, take into
account data that's been released for pushing, but hasn't yet
been pushed - because downstream is slow or the threads haven't been
scheduled.
Fixes a race in the unit test and probably in practice - sometimes
failing to switch when it should for an extra GOP or two.
Also fix a problem in splitmuxsrc where playback sometimes
stalls at startup if types are found too quickly.
https://bugzilla.gnome.org/show_bug.cgi?id=750747
Remove a custom specialized version of gst_buffer_new_wrapped by
using gst_buffer_new_wrapped_full inside a macro to simplify
parameters and give it a more meaningful name.
It is only used to create temporary buffers to have its data copied.
Adds AC-3 muxing support. It is defined for mp4 and 3gp formats.
One extra feature that was added was the ability to add extension
atoms after set_caps as the AC-3 extension atom needs some data
that has to be extracted from the stream itself and is not
present on caps.
Implement support for the packed video formats WebM
uses, not all the values that Matroska might use.
In practice, it's really hard to find any samples in the
wild of any.
Supported in both the muxer and demuxer.
The MPEG-A format provides an extension to the ISO base media
file format to store stereoscopic content encoded with different
codecs like H.264 and MPEG-4:2. The stereo video media information(svmi)
atom declares the presence and storage method for the video.
Stereo video information for MPEG-A can also be supplied through
the 'stvi' atom (ref: ISO/IEC_14496-12, ISO/IEC_23000-11), which
is not implemented in this patch.
Also missing is support for stereo video encoded as separate video tracks
for now.
Based on a patch by Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=611157
When performing seek, segment->start is being updated with desired_offset,
but in case of reverse playback segment->start should be 0 and
segment->stop should be updated with desired offset.
https://bugzilla.gnome.org/show_bug.cgi?id=750675
Build fails with the latest snapshot of gcc-4.9 because param1 and param2 might
possibly be used uninitialized. They are set depending on the cases of a switch
statement and the compiler sees this as not a complete guarantee.
Set them to 0 if the switch statement falls down to the default case.
https://bugzilla.gnome.org/show_bug.cgi?id=750566#c6
Compiling (with gcc-4.9-20150603) produces an error because of an access beyond
the end of an array. This patch fixes the error by initializing the loop
control/array index variable (i) to 1 and returning i - 1 when a match is found.
Also, because the values stored in the array increase in value as the index
increases, the >= test unnecessary, so it is removed.
Only update the moov header into the caps if it's the finalised
moov at EOS time. Avoids posting a bogus moov at startup and
repeated updates in robust-recording mode
Implement a robust recording mode, where the output
file is always in a playable state, seeking and rewriting
the moov header at a configurable interval. Rewriting
moov is done using reserved space at the start of
the file, and a ping-pong strategy where the moov
is replaced atomically so it's never invalid.
Track when tags have actually changed, and don't write them into
the moov unless they've changed. Clear any existing tags when
re-writing them, so we can do progressive moov updating in robust
recording mode.
Write placeholder mdat as a free atom plus a 32-bit mdat
with '0' size, which means "rest of the file" in the spec.
Re-write it later to a full 64-bit extended size atom if needed.
Correctly update any edit lists each time the moov is recalculated,
updating existing table entries if they already exist instead of just
adding new ones.
self->channels is being incremented only when
channel-positions-from-input is set as TRUE. So in case of FALSE
self->func is not set and hence creating assertion error.
Hence removing the condition to increment self->channels.
https://bugzilla.gnome.org/show_bug.cgi?id=744211
According to RFC 5506, reduce size packages can be sent, this
packages may not be compound, so we need to add support for
getting ssrc from other types of packages.
https://bugzilla.gnome.org/show_bug.cgi?id=750327
This depayloader clash with the standard one for H263p. It produces an
H263p stream with a modified header. It uses encoding-name that is the
same as H263p (H263-1998) though the resulting ES is not decodable or
parsable in GStreamer, making it unsuable in dynamic pipeline. This
patch unrank this specialized depayloader since it can only be used in
custom pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=739935
Otherwise we will have 10s-100s of thread wakeups in feedback profiles, create
RTCP packets, etc. just to suppress them in 99% of the cases (i.e. if no
feedback is actually pending and no regular RTCP has to be sent).
This improves CPU usage and battery life quite a lot.
https://bugzilla.gnome.org/show_bug.cgi?id=746543
If we may suppress the packet due to the rules of RFC4585 (i.e. when
below the t-rr-int), we can send a smaller RTCP packet without RRs
and full SDES. In theory we could even send a minimal RTCP packet
according to RFC5506, but we don't support that yet.
https://bugzilla.gnome.org/show_bug.cgi?id=746543
Otherwise we can't properly schedule RTCP in feedback profiles as we need to
distinguish the time when we last checked for sending RTCP (tp) but might have
suppressed it, and the time when we last actually sent a non-early RTCP
packet.
This together with the other changes should now properly implement RTCP
scheduling according to RFC4585, and especially allow us to send feedback
packets a lot if needed but only send regular RTCP packets every once in a
while.
https://bugzilla.gnome.org/show_bug.cgi?id=746543
And modify our RTCP scheduling algorithm accordingly. We now can send more
RTCP packets if needed for feedback, but will throttle full RTCP packets by
rtcp-min-interval (t-rr-int from RFC4585).
In non-feedback mode, rtcp-min-interval is Tmin from RFC3550, which is
statically set to 1s or 0s by RFC4585. Tmin defines how often we should
send RTCP packets at most.
https://bugzilla.gnome.org/show_bug.cgi?id=746543
Otherwise we constantly create/close event file descriptors,
every time we call g_socket_condition_timed_wait() or
g_socket_send_message(s)(), i.e. a lot. Which is not
particularly good for performance.
Can't create GCancellable in ::start() here because it's used
in client_new() which may be called via the add-client action
signal which may be called before the element is up and running.
Otherwise we constantly create/close event file descriptors,
every single time we call g_socket_condition_timed_wait() or
g_socket_receive_message(), i.e. twice per packet received!
This was not particularly good for performance.
Also only create GCancellable on start-up.
qtdemux creates a samples array and gets the timestamps for buffers by
accumulating their durations. When doing reverse playback of fragments,
accumulating samples will lead to wrong timestamps as the timestamps
should go decreasing from fragment to fragment and the accumulation
will produce wrong results.
In this case, when receiving a discont for fragmented reverse playback,
the previous samples information should be flushed before new data
is processed.
This new mode ensures that files will never exceed a certain duration
based on incoming buffer PTS (and duration if present)
Note:
* You need timestamped buffers (duh). If some of the incoming buffers don't
have PTS, then it will just accept them in the current file
This property can be used in combination with next-file=max-size
(and perhaps a future next-file=max-duration) to make sure that
each file part starts cleanly with a key frame and the appropriate headers.
In order for this property to work correctly, upstream elements should make
sure than any headers that need to be written in a standalone file are:
1) in the streamheader caps field
2) and/or in the stream as one or more buffers marked with GST_BUFFER_FLAG_HEADER
that are just before the keyframe buffer
This is useful for MPEG-TS/MPEG-PS file segmenting in
combination with mpegtsmux or mpegpsmux.
Original patch by: Tim-Philipp Müller <tim@centricular.com>
From the API documentation: "Note that it is generally not
a good idea to reuse an existing cancellable for more
operations after it has been cancelled once, as this
function might tempt you to do. The recommended practice
is to drop the reference to a cancellable after cancelling
it, and let it die with the outstanding async operations.
You should create a fresh cancellable for further async
operations."
https://bugzilla.gnome.org/show_bug.cgi?id=739132
It might just be a late retransmission or spurious packet from elsewhere, but
resetting everything would mean that we will cause a noticeable hickup. Let's
get some confidence first that the sequence numbers changed for whatever
reason.
https://bugzilla.gnome.org/show_bug.cgi?id=747922
The gst-launch script for example launch line to test qtdemux is
missing a queue before the decodebins, otherwise the gst-launch-1.0
command won't work.
https://bugzilla.gnome.org/show_bug.cgi?id=749054
This reverts commit d22ec49632.
Application code might expect that it only gets external sources on those
signals, and get confused by this. If anything we would need to add new
signals.
Without this it seems impossible for an application to easily get notified
about the internal ssrcs that are created, e.g. sender sources, and also
to know when they are active and produce RTCP packets.
https://bugzilla.gnome.org/show_bug.cgi?id=746747
We now take the maximum of 2*jitter and 0.5*packet_spacing for the extra
delay. If jitter is very low, this should prevent unnecessary retransmission
requests to some degree.
https://bugzilla.gnome.org/show_bug.cgi?id=748041
When we are in passthrough, the transform function doesn't run and if the
passthrough check is in this function it will never be deactivated. Fix this by
checking directly whenever a gain is changed.
Also set the passthrough to TRUE at init because the gains default to 0, so we
can passthrough until any gain property is changed.
https://bugzilla.gnome.org/show_bug.cgi?id=748068
Prevents an extra unref of GstBuffer when passing a non-icy stream through
icydemux with metadata-interval set to 0.
Reproducible with:
gst-launch-1.0 filesrc location=~/testsong.mp3 ! \
'application/x-icy,metadata-interval=(int)0' ! icydemux ! decodebin ! wavenc ! \
filesink location=~/testsong.wav
https://bugzilla.gnome.org/show_bug.cgi?id=748024
because _release_pad tries to release it from ctx->sinkpad, which is
multiqueue's sink pad, and currently fails because the probe is not
installed there
This also happens in the very beginning when we receive the first packet, a
warning would be very confusing here. In all places where we should warn about
this, we would've printed a warning already before.
Right above we consider lost_packet packets, each of them having duration,
as lost and triggered their timers immediately. Below we use expected_dts
to schedule retransmission or schedule lost timers for the packets that
come after expected_dts.
As we just triggered lost_packets packets as lost, there's no point in
scheduling new timers for them and we can just skip over all lost packets.
https://bugzilla.gnome.org/show_bug.cgi?id=739868
Resetting the jitterbuffer drops all packets and other things, and will cause
a discontinuity in the packets received by the depayloaders. They should now
also flush anything they had pending as the new data will start at a different
position.
https://bugzilla.gnome.org/show_bug.cgi?id=739868
When doing key uint seek, qtdemux calls gst_qtdemux_adjust_seek
to get proper offset. And then this offset is set to
segment.position and segment.time in gst_qtdemux_perform_seek but
segment.start is not updated.
After that, application sends segment query,
qtdemux sets start and stop to query using gst_segment_to_stream_time. Due
to the wrong value in segment.start, the stop position is smaller than
it should.
https://bugzilla.gnome.org/show_bug.cgi?id=746822
We always write the CTTS in qtmux. Ideally we only want to do that
for streams that need DTS, it should be present on the track information
rather than be decided based on each buffer
As qt uses durations, it doesn't matter, only the difference
between consecutive buffers is important. Also, collectpads
already replaces PTS/DTS with the running times for them.
Instead of checking various state variables around the muxer,
track the current muxing mode in a single 'mux_mode' enum.
Add some implementation notes about the different mux modes
gst_segment_do_seek() does that for us already, and doing it twice
will break non-flushing seeks in interesting ways. Leftover from 1.0
porting.
Also copy over segment offset and applied_rate, just in case.
When multifilesink is operating in any mode other than one file
per buffer, the last file created won't have a file message posted
as multifilesink doesn't handle the EOS event.
This patch fixes it by using the last position to post a file
message when EOS is received. This should ensure at least the
time related data and the filename are posted to the application
or other elements
https://bugzilla.gnome.org/show_bug.cgi?id=747000
When not in fast-start or fragmented mode, we need to be able
to rewrite the size of the mdat atom, or else the output just
won't be playable - the mdat placeholder with size == 0 will
cover the rest of the file, including any moov atom we write out.
https://bugzilla.gnome.org/show_bug.cgi?id=708808
New tags can be found on different parts of the file, so this patch
keeps the stream taglists around for the life cycle of the pad
and adds those new tags as found. Then a new tag is found, the
pad's is marked with a tags changed flag, making the element push
a new tag event on the next check. Before this, we were sending
only the newly found tags, as the element was losing its taglist
when pushing the event.
Global tags are already being read in matroskaparse, but they are not
currently being sent.
This patch makes global tags get sent incrementally whenever new ones
are found.
https://bugzilla.gnome.org/show_bug.cgi?id=746242
When planes property is set to 0, the pipeline executes in
an infinite loop and never exits. Since planes must never
be 0, set the minimum value in the property description
to 1.
https://bugzilla.gnome.org/show_bug.cgi?id=743906
It is expected that buffers are time-stamped with running time. Set
a segment accordingly. In this case we pick 0,-1 as this is what udpsrc
would do. Depayloaders will update the segment to reflect the playback
position.
https://bugzilla.gnome.org/show_bug.cgi?id=635701
The segment start/stop in the query is meant to represent the seekable
portion of the stream. It does not match the segment start/stop. Instead
export 0 to duration.
Previously we were setting new caps with the same content for every H264 or
AAC codec_data we found in the stream, spamming everything and causing
renegotiations.
Instead delay creating the caps until we read the codec_data from the stream,
or fail if we get normal data before the codec_data.
AAC raw caps and H264 avc caps always need codec_data, setting caps on the pad
without them is going to make negotiation fail most of the time. Even if we
later set new caps with the codec_data, that's usually going to be too late.
https://bugzilla.gnome.org/show_bug.cgi?id=746682
Make sure that the sync_src pad has caps before the segment event.
Otherwise we might get a segment event before caps from the receive
RTCP pad, and then later when receiving RTCP packets will set caps.
This will results in a sticky event misordering warning
This fixes warnings in the rtpaux unit test but also in the
rtpaux and rtx examples in tests/examples/rtp
https://bugzilla.gnome.org/show_bug.cgi?id=746445
Before we only started it when either:
- there is no send RTP stream
or
- we received an RTP packet for sending
This could mean that if the send RTP pads are connected but never receive any
RTP data, and the same session is also used for receiving RTP/RTCP, we would
never start the RTCP thread and would never send RTCP for the receiving part
of the session.
This can be reproduced with a pipeline like:
gst-launch-1.0 rtpbin name=rtpbin \
udpsrc port=5000 ! "application/x-rtp, media=video, clock-rate=90000, encoding-name=H264" ! rtpbin.recv_rtp_sink_0 \
udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 \
rtpbin.send_rtcp_src_0 ! fakesink name=rtcp_fakesink silent=false async=false sync=false \
rtpbin.recv_rtp_src_0_2553225531_96 ! decodebin ! xvimagesink \
fakesrc ! valve drop=true ! rtpbin.send_rtp_sink_0 \
rtpbin.send_rtp_src_0 ! fakesink name=rtp_fakesink silent=false async=false sync=false -v
Before this change the rtcp_fakesink would never send RTCP for the receiving
part of the session (i.e. no receiver reports!), after the change it does.
And before and after this change it would send RTCP for the receiving part of
the session if the sender part was omitted (the last two lines).
