The code before copied GstStructure twice. The first time inside
gst_value_set_structure and the second time in g_value_array_append.
Optimized version does no copies, just transfers ownership to
GValueArray. It takes advantage of the fact that array has already
enough elements preallocated and the memory is zero initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=795139
If obtain_internal_source() returns a source that is not internal it
means there exists a non-internal source with the same ssrc. Such an
ssrc collision should be handled by sending a GstRTPCollision event
upstream and choose a new ssrc, but for now we simply drop the packet.
Trying to process the packet further will cause it to be pushed
usptream (!) since the source is not internal (see source_push_rtp()).
https://bugzilla.gnome.org/show_bug.cgi?id=795139
If there is an external source which is about to timeout and be removed
from the source hashtable and we receive feedback RTCP packet with the
media ssrc of the source, we unlock the session in
rtp_session_process_feedback before emitting 'on-feedback-rtcp' signal
allowing rtcp timer to kick in and grab the lock. It will get rid of
the source and rtp_session_process_feedback will be left with RTPSource
with ref count 0.
The fix is to grab the ref to the RTPSource object in
rtp_session_process_feedback.
https://bugzilla.gnome.org/show_bug.cgi?id=795139
These are the sources we send from, so there is no reason to
report receive statistics for them (as we do not receive on them,
and the remote side has no knowledge of them).
https://bugzilla.gnome.org/show_bug.cgi?id=795139
Whenever got new moov or new stream-start,
demux will try to expose new pad by following rule.
Comparing stream-id in the current moov with previous one, then
* If matched stream-id is found from previous one,
reuse existing pad (most common case)
* Otherwise, expose new pad with new stream-start
* No more used stream will be freed
https://bugzilla.gnome.org/show_bug.cgi?id=684790
Whenever demux got moov, demux will create new stream. Only exception is
duplicated track-id in a moov box. In that case the first stream
will be accepted. This patch is pre-work for rework of moov handling.
https://bugzilla.gnome.org/show_bug.cgi?id=684790
Supports CEA 608 and CEA 708 CC streams
Also supports usage in "Robust Prefill" mode if the incoming caption
stream is constant (i.e. there is one incoming CC buffer for each
video frame).
https://bugzilla.gnome.org/show_bug.cgi?id=606643
ULP FEC, as defined in RFC 5109, has the protected and protection
packets sharing the same ssrc, and a different payload type, and
implies rewriting the seqnums of the protected stream when encoding
the protection packets. This has the unfortunate drawback of not
being able to tell whether a lost packet was a protection packet.
rtpbasedepayload relies on gaps in the seqnums to set the DISCONT
flag on buffers it outputs. Before that commit, this created two
problems:
* The protection packets don't make it as far as the depayloader,
which means it will mark buffers as DISCONT every time the previous
packets were protected
* While we could work around the previous issue by looking at
the protection packets ignored and dropped in rtpptdemux, we
would still mark buffers as DISCONT when a FEC packet was lost,
as we cannot know that it was indeed a FEC packet, even though
this should have no impact on the decoding of the stream
With this commit, we consider that when using ULPFEC, gaps in
the seqnums are not a reliable indicator of whether buffers should
be marked as DISCONT or not, and thus rewrite the seqnums on
the decoding side as well to form a perfect sequence, this
obviously doesn't prevent the jitterbuffer from doing its job
as the ulpfec decoder is downstream from it.
https://bugzilla.gnome.org/show_bug.cgi?id=794909
This reverts commit af273b4de9.
While RFC 3264 (SDP) says that sendonly/recvonly are from the point of view of
the requester, the actual RTSP RFCs (RFC 2326 / 7826) disagree and say
the opposite, just like the ONVIF standard.
Let's follow those RFCs as we're doing RTSP here, and add a property at
a later time if needed to switch to the SDP RFC behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=793964
After a CAPS event, in theory a new stream can start and it might start
with the FLAC headers again. We can't detect FLAC headers in the middle
of the stream, so we drain the parser to be able to detect either FLAC
headers after the CAPS event or the continuation of the previous stream.
This fixes for example
gst-launch-1.0 audiotestsrc num-buffers=200 ! flacenc ! c. \
audiotestsrc num-buffers=200 freq=880 ! flacenc ! c. \
concat name=c ! rtpgstpay ! udpsink host=127.0.0.1 port=5000
gst-launch-1.0 udpsrc multicast-group=127.0.0.1 port=5000 \
caps=application/x-rtp,media=application,clock-rate=90000,encoding-name=X-GST ! \
rtpgstdepay ! flacparse ! flacdec ! audioconvert ! pulsesin
gst_qt_mux_can_renegotiate () gets called everywhere following
that pattern:
return gst_qt_mux_can_renegotiate (ref(self));
This means the reference must be released both in the success
and failure cases, it was only done in the success case.
It can happen during teardown that the reference context becomes NULL.
In that case, trying to send the fragment-opened-closed message would
lead to a crash.
Corrupted files could potentially have multiple cdat/cdt2 atoms in
a sample entry, which is unclear how to handle.
Ignore repeated ones.
CID #1434162
CID #1434159
The code responsible for creating retransmitted buffers
assumed the stored buffer had been created with
rtp_buffer_new_allocate when copying the extension data,
which isn't necessarily the case, for example when
the rtp buffers come from a udpsrc.
https://bugzilla.gnome.org/show_bug.cgi?id=794958
Similar to the get-session and get-internal-session signals,
we expose a get-storage signal in addition to the
get-internal-storage signal to give access to the actual
element for applications that need to set properties on the
element, in particular "size-time"
https://bugzilla.gnome.org/show_bug.cgi?id=794910
With this the muxer is not set to NULL after each segment but instead
only flush events are sent to it to reset the EOS state.
As a result, the muxer will keep stream state and e.g. mpegtsmux will
keep the packet continuity counter continuous between segments as needed
by hlssink2.
https://bugzilla.gnome.org/show_bug.cgi?id=794816
The value stored in cenc_aux_sample_count wasn't in sync with the
parsing code that followed which checks whether all entries are
valid and present.
Only write the actual sample count when we know for sure.
CID #1427087
This exposes a new property, mtu, which is used to determine the
initial size of buffers from the buffer pool. If received data
exceeds this, the element gracefully handles that in a manner similar
to what we had previously: a large memory gets filled and reallocated
at the next call to "fill".
The default size is set to 1500, which should cover most use cases.
With contributions from Mathieu Duponchelle <mathieu@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=772841
Optimize GstUdpSrc for cache performance.
Move the hot properties, which are used by the read function, to the top:
@used_socket, @addr, @cancellable, @skip_first_bytes, @timeout,
@retrieve_sender_address.
Remove the unused property @ttl.
Where needed reorder so that holes are avoided (the 64-bit @timeout)
https://bugzilla.gnome.org/show_bug.cgi?id=772841
The samples table is sorted by DTS, not PTS. As such we can only get the
correct result when using a binary search on it, if we search for the
DTS.
Also if we only ever search for the frame, where the following frame is
the first one with a PTS after the search position, we will generally
stop searching too early if frames are reordered.
In forwards playback this is not really a problem (after the decoder
reordered the frames, clipping is happening), in reverse playback
it means that we can output one or more frames too few as we stop too
early and the decoder would never receive it.
https://bugzilla.gnome.org/show_bug.cgi?id=782118
76e458a119 changed the conditions from
"queued > threshold" to "queued >= threshold", which broke hlssink2 and
resulting in too small fragments being created although keyframes would
be at *exactly* the configured threshold.
https://bugzilla.gnome.org/show_bug.cgi?id=794440
Fix compilation with MSVC. We still assume that attribute
is supported by all other relevant compilers, which seems
to be the case since we haven't had any complaints about
similar code in rtpsbcpay.
This works around a bug in various ONVIF cameras that implement the
attributes the wrong way around. They still won't work with a
backchannel but at least normal playback will work for the time being.
It restores pre-1.14 behaviour where we would fail to preroll on any SDP
that lists a recvonly stream. For 1.16 a better solution should be
found.
The problem here is that the ONVIF spec has the meaning of the two
attributes the wrong way around in the examples, compared to RFC4566.
https://bugzilla.gnome.org/show_bug.cgi?id=793715
Only up to timescale * G_MAXINT16 is possible as cluster duration, which
is already higher than our default value. Using higher values would
cause overflows and broken files.
Based on the investigation by Nicola Murino <nicola.murino@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=792775
Matroska does not support changing the stream type and stream properties
after the headers were started to be written, and for example H264
codec_data changes can't be supported.
https://bugzilla.gnome.org/show_bug.cgi?id=782949
rtpulpfeccommon.c:432:27: error: format ‘%lx’ expects argument of type
‘long unsigned int’, but argument 10 has type ‘guint64 {aka long long unsigned int}’
https://bugzilla.gnome.org/show_bug.cgi?id=793732
The ulpfecenc "mux-seq" and "ssrc" properties were initially added
because the element did more than implement ULPFEC. As it was
decided that FLEXFEC would be implemented in a separate element,
both properties are now unneeded and confusing.
Change the default for the ulpfecenc multi-packet property,
as it is expected that most users of this element will be protecting video
streams.
Change the default property for the rtpredenc allow-no-red-blocks
property, as it should also be its default mode of operation.
https://bugzilla.gnome.org/show_bug.cgi?id=793843
It is expected that when connecting to a stream that has
already started, the caps will only arrive at the interval
specified on rtpgstpay, we shouldn't be warning as this is
a normal mode of operation.
https://bugzilla.gnome.org/show_bug.cgi?id=793798
We expose a set of new elements:
* ULPFEC encoder / decoder
* A storage element, which should be placed before jitterbuffers,
and is used to store packets in order to attempt reconstruction
after the jitterbuffer has sent PacketLost events
* RED encoder / decoder (RFC 2198), these are necessary to
use FEC in webrtc, as browsers will propose and expect ulpfec
packets to be wrapped in red packets
With contributions from:
Mathieu Duponchelle <mathieu@centricular.com>
Sebastian Dröge <sebastian@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=792696
Packets with these payload types will be dropped. A use case
for this is FEC, where we want FEC packets to go through the
jitterbuffer, but not be output by rtpbin.
https://bugzilla.gnome.org/show_bug.cgi?id=792696
All received configurations are parsed and added to a list, this lead
to an unbounded memory usage. As the configuration is resent every
second this quickly lead to a large memory usage.
Add a check to only add the config if it is not already available in
the list. This fix only handle the typical case of a well behaved
stream, a malicious server could still send many useless
configurations to raise the client memory usage.
The smallest possible is 24 (and not 25) bytes.
The last "name" field can according to QTFF specifications not be present
at all. The parser will handle this fine and so will the rest of
the qtdemux code.
If codec_data is changed, the stream is no longer valid.
Rather than keeping running when refusing new caps,
this patch send a warning to the bus.
Also fix up splitmuxsink to ignore this warning while changing caps.
https://bugzilla.gnome.org/show_bug.cgi?id=790000
We would accidentally pass through the duration value from the
demuxer from a single fragment, which causes problems when
feeding the stream from splitmuxsrc to rtsp-server. Streaming
would stop after one fragment due to that.
https://bugzilla.gnome.org/show_bug.cgi?id=792861
total_duration is initialised to CLOCK_TIME_NONE, not 0, so check
for that as well in order not to return an invalid duration to
a duration query. Doesn't fix anything particular observed in
practice, just seemed inconsistent.
With this patch we can now provide a set of files
created by multifilesink as a source for uri elements.
e.g. gst-launch-1.0 playbin uri=multifile://img%25d.ppm
Note that for the %d pattern you need to replace % with %25.
This is to be compliant with URL naming standards.
https://bugzilla.gnome.org/show_bug.cgi?id=783581
It generally makes not much sense to configure it for all pads/traks at
once as this value is usually different for each of them. As such, add a
new property on the pads in addition to the existing property on the
whole muxer.
https://bugzilla.gnome.org/show_bug.cgi?id=792649
We can't handle recvonly streams, sendonly streams are perfectly fine.
The direction is the one from the point of view of the SDP offerer
(i.e. the RTSP server), and a recvonly stream would be one where the
server expects us to send media.
RFC 3264, section 5.1:
If the offerer wishes to only send media on a stream to its peer, it
MUST mark the stream as sendonly with the "a=sendonly" attribute.
This is mixed up in the ONVIF streaming specification examples, but
actual implementations and conformance tools seem to not care at all
about the attributes.
https://bugzilla.gnome.org/show_bug.cgi?id=792376
Raw AAC streams might have very small frames, e.g. 6 byte frames
when encoding silence. These frames are then smaller than aacparse's
default min_frame_size of 10 bytes (ADTS_MAX_SIZE).
When passthrough is disabled or aacparse has to output ADTS, GstBaseParse
will concatenate these short frames to the following frame before
handling them to aacparse, which processes each input buffer as a single
frame, producing bad output.
To avoid this problem, set the min_frame_size to 1 when receiving a raw
stream.
https://bugzilla.gnome.org/show_bug.cgi?id=792644
When the signal returns a floating reference, as its return type
is transfer full, we need to sink it ourselves before passing
it to gst_bin_add (which is transfer floating).
This allows us to unref it in bin_remove_element later on, and
thus to also release the reference we now own if the signal
returns a non-floating reference as well.
As we now still hold a reference to the element when removing it,
we also need to lock its state and setting it to NULL before
unreffing it
Also update the request_aux_sender test.
https://bugzilla.gnome.org/show_bug.cgi?id=792543
TOC support in mastroskamux has been deactivated for a couple of years. This commit updates it to recent GstToc evolutions and introduces toc unit tests for both matroska-mux and matroska-demux.
There are two UIDs for Chapters in Matroska's specifications:
- The ChapterUID is a mandatory unsigned integer which internally refers to a given chapter. Except for title & language which use dedicated fields, this UID can also be used to add tags to the Chapter. The tags come in a separate section of the container.
- The ChapterStringUID is an optional UTF-8 string which also uniquely refers to a chapter but from an external perspective. It can act as a "WebVTT cue identifier" which "can be used to reference a specific cue, for example from script or CSS".
During muxing, the ChapterUID is generated and checked for unicity, while the ChapterStringUID receives the user defined UID. In order to be able to refer to chapters from the tags section, we maintain an internal Toc tree with the generated ChapterUID.
When demuxing, the ChapterStringUIDs (if available) are assigned to the GstTocEntries UIDs and an internal toc mimicking the toc is used to keep track of the ChapterUIDs and match the tags with the appropriate GstTocEntries.
https://bugzilla.gnome.org/show_bug.cgi?id=790686
If we saw empty segments, we previously unconditionally pushed a
GAP event downstream regardless of the duration of that empty
segment.
In order to avoid issues with initial negotiation of downstream elements
(which would negotiate to something before receiving any data due to
that initial GAP event), check if there's at least a second of difference
(like we do for other GAP-related checks in qtdemux) before
deciding to push a GAP event downstream.
Otherwise baseparse will incrementally send us bigger buffers until the
full header size is reached, which is not only pointless but also means
that baseparse will reallocate and copy into a bigger buffer for every
input buffers. In pull mode that's done in 64kb increments, in push mode
usually in much smaller increments, causing a lot of overhead for
example when parsing high-quality coverart.
When receiving a seek event, check whether we can actually seek based
on the information the server provided.
Also add more documentation on what the seekable field means
If a reserved-max-duration is set, we should always track
and update the reserved-duration-remaining estimate, even
if we're not sending periodic moov updates downstream for
full robust muxing.
If the use-robust-muxing property is set, check if the
assigned muxer has reserved-max-duration and
reserved-duration-remaining properties, and if so set
the configured maximum duration to the reserved-max-duration
property, and monitor the remaining space to start
a new file if the reserved header space is about to run out -
even though it never ought to.
Switching to a new fragment because the input caps have
changed didn't properly end the previous file. Use the normal
EOS sequence to ensure that happens. Add a test that it works.
Only for byte-stream or hev1. For hvc1 the SPS/PPS are in the
caps as codec_data field and in this case they shouldn't be in
the stream data as well. The output caps should be updated with
the new codec_data if needed, for hvc1.
We keep the boolean byte_stream around since it's nicer for
readability and most of the code just cares about byte_stream
or not. This is useful for future-proofing the code for when
we add support for hev1 output as well.
This would happen if input is byte-stream with four-byte
sync markers instead of three-byte ones. The code that
scans for sync markers will place the start of the NALU
on the third-last byte of the NALU sync marker, which
means that any additional zeros may be counted as belonging
to the previous NALU instead of being part of the next sync
marker. Fix that so we don't send VPS/SPS/PPS with trailing
zeros in this case.
See https://bugzilla.gnome.org/show_bug.cgi?id=732758
There is no difference between pushing out a buffer directly
with gst_rtp_base_depayload_push() and returning it from the
process function. The base class will just call _depayload_push()
on the returned buffer as well.
So instead of marshalling buffers through three layers and back,
just push them from one place in handle_nal() and always return
NULL from the process vfunc. This simplifies the code a little.
Also rename _push_fragmentation_unit() to _finish_fragmentation_unit()
for clarity. Push sounds like it means being pushed out, whereas
it might just be pushed into an adapter.
This change has the side-effect that multiple NALs in a single STAP
(such as SPS/PPS) may no longer be pushed out as a single buffer if
we output NALs in byte-stream format (i.e. not aggregate AUs), but
that shouldn't really make any difference to anyone.
This would happen if input is byte-stream with four-byte
sync markers instead of three-byte ones. The code that
scans for sync markers will place the start of the NALU
on the third-last byte of the NALU sync marker, which
means that any additional zeros may be counted as belonging
to the previous NALU instead of being part of the next sync
marker. Fix that so we don't send SPS/PPS with trailing
zeros in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=732758
Returning FALSE because we drop an event means that
internal sources like qtdemux might throw an error
and break the whole pipeline. The only time it can
happen is either flushing or shutdown, and those
will be handled anyway.
... and forward colorimetry to downstream. The Colour element describes
various color information (similar to 'colr' box in isobmff).
Note that, due to the comparatively limited syntax for color information
in vpx codecs, the color information in mkv/wemb container level
should be used for sophisticated color handling (e.g., HDR video).
https://bugzilla.gnome.org/show_bug.cgi?id=790023
The G722 payload only accepts G722 audio with channels=1, so it must
specify the encoding-params=1 in its src caps, otherwise it causes issues
with farstream which thinks it supports 2 channels G722 and when
confronted with a remote that has G722/8000/2, it will negotiate it
and error out with a not-negotiated when the caps don't intersect
at runtime.
https://bugzilla.gnome.org/show_bug.cgi?id=789878
When XR packet is detected, warning message leads to misunderstandings.
Until RFC3611 is implemented in gst-plugins-base, the level needs to
be downgraded to avoid confusion.
https://bugzilla.gnome.org/show_bug.cgi?id=789746
It is possible that the mdat has more data than what was stored in the
headers file. If we put that to the output the file will have bogus data
at the end and some players will complain.
https://bugzilla.gnome.org/show_bug.cgi?id=784258
qtdemux.c: In function ‘gst_qtdemux_configure_stream’:
qtdemux.c:7764:34: error: suggest parentheses around ‘&&’ within ‘||’ [-Werror=parentheses]
if ((stream->n_samples == 1) && (stream->first_duration == 0)
~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Avoid computing frame rate when a stream contain moof with only one
sample, to avoid an assert. The moof is considered as still picture.
The same is already done for one sample given in the moov.
https://bugzilla.gnome.org/show_bug.cgi?id=782217
Linear interpolation adds quite some noise, and it's unlikely that
anybody will ever need sub-sample accurate delays. Proper resampling
before that will lead to better results.
When a truncated FLV is provided and processed in pull mode, we
may endup trying to pull passed EOS, causing a rather confusing
warning as the pull offset is an integer overflow.
https://bugzilla.gnome.org/show_bug.cgi?id=787795
This code basically skip over codec_data with empty payload. In
this case, the codec_data variable is the size of the header for
the CODEC part of Video Tag. The remaining is supposed to be the
H.264 codec data, hence should not be empty.
https://bugzilla.gnome.org/show_bug.cgi?id=787795
Meaning that the interleave fields have to be updated as
if streams setup was working when using pipelined setup
request. Otherwise there is a mismatch between the server
channel count and our own.
This also makes RTSP 2.0 over HTTP working.
https://bugzilla.gnome.org/show_bug.cgi?id=781446
- Handle version negotation:
Added a `default-version` property so that the user can configure
what to use in case the server does not support version negotation
(which actually exist)
- Handle pipelined requests, which allow avoiding full round trip to
setup the RTP streams (request are sent in a raw, and response are
handled as they arrive).
- Handle the new Media-Properties header
- Handle the new Seek-Style header
- Handle the new Accept-Ranges header
Handling of IPV6 should already be OK.
We are still missing (at least) the following features (which do not
seem really mandatory as they require a "persistent connection between
server and client"):
- Server to Client TEARDOWN command (Not so usefull fmpov)
- PLAY_NOTIFY (not needed for our server yet)
- Support for the new REDIRECT features
and probably some more protocol changes might not be handled yet.
https://bugzilla.gnome.org/show_bug.cgi?id=781446
This then just counts samples and calculates the output timestamps based
on that and the very first observed timestamp. The timestamps on the
buffers are continued to be used to detect discontinuities that are too
big and reset the counter at that point.
When receiving data via Bluetooth, many devices put completely wrong
values into the RTP timestamp field. For example iOS seems to put a
timestamp in milliseconds in there, instead of something based on the
current sample offset (RTP clock-rate == sample rate).
https://bugzilla.gnome.org/show_bug.cgi?id=787297
Doesn't do anything fancy yet, but still avoids lots of
unnecessary locking/unlocking that would happen if the
default chain_list fallback function in GstPad got invoked.
Timestamp offsets needs to be checked to detect unrealistic values
caused for example by NTP clocks not in sync. The new parameter
max-ts-offset lets the user decide an upper offset limit. There
are two different cases for checking the offset based on if
ntp-sync is used or not:
1) ntp-sync enabled
Only negative offsest are allowed since a positive offset would
mean that the sender and receiver clocks are not in sync.
Default vaule of max-ts-offset = 0 (disabled)
2) ntp-sync disabled
Both positive and negative offsets are allowed.
Default vaule of max-ts-offset = 3000000000
The reason for different default values is to be backwards
compatible.
https://bugzilla.gnome.org/show_bug.cgi?id=785733
Instant large changes to ts_offset may cause timestamps to move
backwards and also cause visible effects in media playback. The new
option max-ts-offset-adjustment lets the application control the rate to
apply changes to ts_offset.
https://bugzilla.gnome.org/show_bug.cgi?id=784002
* use INFO/DEBUG/LOG/TRACE equaly and meaningfully;
previously rtprtxsend:LOG and rtprtxreceive:LOG would generate
a totally different amount of log traffic and sometimes it was
impossible to see the information you wanted without useless
spam being printed around
* improve the wording, give a reasonable and self-explanatory
amount of information
* print SSRCs in hex
* avoid G_FOO_FORMAT for readability (we are just printing integers)
If one requests the send_rtcp_src_%u pad before a recv_rtcp_sink_%u pad,
the session/pad would never be created and NULL was returned.
Switching the request order would work.
https://bugzilla.gnome.org/show_bug.cgi?id=786718
Fix chain function not handling not-linked from baseparse.
When an input data is separated into 2 buffers, the second buffer
would not be pushed into the adapter if baseparse returns not-linked
for first buffer.
This caused glitches when switching streams and selecting
a stream that was previously unselected.
https://bugzilla.gnome.org/show_bug.cgi?id=786268
Callers of the API (rtpsource, rtpjitterbuffer) pass clock_rate
as a signed integer, and the comparison "<= 0" is used against
it, leading me to think the intention was to have the field
be typed as gint32, not guint32.
This led to situations where we could call scale_int with
a MAX_UINT32 (-1) guint32 as the denom, thus raising an
assertion.
https://bugzilla.gnome.org/show_bug.cgi?id=785991
... which no longer worked due to unconditionally clearing sample info and
ending up in inconsistent state. Let's tread a bit more carefully and also
allow for the old seek handling that resorts to scanning if no mfra info
is available.
Do not allocate payload size outbuf if appending payload buffer.
The commit 137672ff18 attached payload
to the output buffer but forgot to remove payload allocation. That
effectively doubled payload size and add zero'ed or random bytes.
Makes the following pipeline work again:
gst-launch-1.0 -v audiotestsrc wave=2 ! gsmenc ! rtpgsmpay ! rtpgsmdepay ! gsmdec ! autoaudiosink
https://bugzilla.gnome.org/show_bug.cgi?id=784616
gst_util_uint64_scale_int takes a gint as denom parameter
whereas ctx->clock_rate is a guint32.
It happens when gst_rtp_packet_rate_ctx_reset set clock_rate
to -1.
So just define clock_rate as gint like it is done in rtpsource.h
https://bugzilla.gnome.org/show_bug.cgi?id=784250
When set this property will allow the jitterbuffer to start delivering
packets as soon as N most recent packets have consecutive seqnum. A
faststart-min-packets of zero disables this feature. This heuristic is
also used in rtpsource which implements the probation mechanism and a
similar heuristic is used to handle long gaps.
https://bugzilla.gnome.org/show_bug.cgi?id=769536
We currently send data to the RTSP connection from multiple threads:
whenever a command is to be handled and whenever RTCP is generated. This
can cause data corruption or worse if both happen at the same time.
As such, protect gst_rtsp_connection_send() and gst_rtsp_connection_receive()
calls with a mutex. While this means that we hold a mutex during the IO
operation, this is not actually a problem as the IO operation can be
interrupted (gst_rtsp_connection_flush()) at any time and is blocking by
itself anyway.
The last entry will most likely get new samples added to it in "robust"
muxing mode, changing the samples_per_chunk and thus making it wrong to
keep the last two entries merged. It will run into an assertion later
when adding a new sample to the chunk.
Thanks to gdiener@cardinalpeak.com for the analysis of the bug and
proposal for a solution.
There might be other chunks after the data chunk, so clipping the chunk
size with the data size can lead to a negative number and all following
calculations go wrong and cause crashes or worse.
This was introduced in 3ac119bbe2.
https://bugzilla.gnome.org/show_bug.cgi?id=783760
They can cause us to deadlock, while we're waiting for a new frame and
upstream is waiting for the allocation query to be answered before
sending a frame
https://bugzilla.gnome.org/show_bug.cgi?id=783753
There is no difference between pushing out a buffer directly
with gst_rtp_base_depayload_push() and returning it from the
process function. The base class will just call _depayload_push()
on the returned buffer as well.
So instead of marshalling buffers through three layers and back,
just push them from one place in handle_nal() and always return
NULL from the process vfunc. This simplifies the code a little.
Also rename _push_fragmentation_unit() to _finish_fragmentation_unit()
for clarity. Push sounds like it means being pushed out, whereas
it might just be pushed into an adapter.
This change has the side-effect that multiple NALs in a single STAP
(such as SPS/PPS) may no longer be pushed out as a single buffer if
we output NALs in byte-stream format (i.e. not aggregate AUs), but
that shouldn't really make any difference to anyone.
Use the ::process_rtp_packet() vfunc to avoid mapping the
RTP buffer twice.
gst_rtp_buffer_get_payload_buffer() returns a new sub-buffer
which will always be writable, so no need to make it writable.
Every g_quark_from_static_string() is a hash table lookup serialised
on the global quark lock in GLib. Let's just look up the two quarks
we need once and cache them locally for future use. While we're at it,
add new utility functions for the two most commonly used tags
(audio + video). Make first argument a gpointer so we don't have to
cast and make the code ugly. These are used for logging purposes
only anyway.
Since the move from CVS the property name of the documentation example
has been filename instead of location. Users trying the gst-launch
command as is will get:
no property name "filename" in element
Fixing it.
If a non-reference stream is behind the reference stream by an amount of
time smaller than the alignment threshold (in nsec), it counts as being
after it.
https://bugzilla.gnome.org/show_bug.cgi?id=782563
Timecode trak is only supported for mov right now, not for mp4. That
code would otherwise create an invalid trak if the muxed video contained
timecode metadata.
https://bugzilla.gnome.org/show_bug.cgi?id=782684
We only accept new caps if they are basically the same. We don't want to
reset anything as if the caps are new, otherwise various state could get
out of sync with the current run.
We have some padding added after the initial moov, so a bigger updated
moov can be handled to some degree and is expected. Previously we just
ignored the padding and errored out in cases when the padding would've
just been enough.
This sets up a moov with the correct sample positions beforehand and
only works with constant framerate, I-frame only streams.
Currently only support for ProRes and raw audio is implemented but
adding new codecs is just a matter of defining appropriate maximum frame
sizes.
https://bugzilla.gnome.org/show_bug.cgi?id=781447
When muxing raw audio, we have no way of storing timestamps but are just
storing a continuous stream of audio samples. If the difference between
the expected and the real timestamp becomes to big, we should error out
instead of silently creating files with wrong A/V sync.
https://bugzilla.gnome.org/show_bug.cgi?id=780679
Re-arrange order of index entry struct members to avoid padding
bytes in the middle of the struct, thus potentially reducing the
overall size of the struct and reducing memory used by the index.
On Linux x86_64 the size goes down from 32 bytes to 24 bytes for
each index entry.
If no clock was provided directly by rtspsrc. This behaviour was removed
by f8013487c9 and results in rtspsrc not
providing the system clock via the rtpjitterbuffer.
As a result, if another element like an audio sink, provides a clock,
the pipeline would select that (when going to PAUSED/PLAYING again later).
Audio clocks usually don't progress in PAUSED, and thus our live source
won't be able to use the clock to produce data, making the sink never
preroll and everything is stuck.
... unless the muxer uses the same audio pad template name as
splitmuxsink. We can't request a pad called "audio_0" on a muxer that
wants pads to be "sink_%d".
In push mode we process as much as possible in the adapter. When we receive
a DISCONT buffer which we can't match to an actual sample (based on the existing
sample table) and there is still data remaining in the incoming adapter,there is
one of two cases happening:
1) We are doing reverse playback, in which case we should flush out all pending
data
2) We have leftover data from the previous incoming buffer... which we can't do
anything about.
For the second case, make sure we flush out the remaining data so that we can start
parsing again from scratch.
https://bugzilla.gnome.org/show_bug.cgi?id=781319
They should have ideally the same timescale of the video track, which we
can't guarantee here as in theory timecode configuration and video
framerate could be different. However we should set a correct timescale
based on the framerate given in the timecode configuration, and not just
use the framerate numerator.
Make sure offset and neededbytes are properly resetted when all
streams are EOS in push-mode.
Avoids cases when some data might still be pushed by upstream (because
it didn't yet see the resulting GST_FLOW_EOS yet) and qtdemux gets
completely lost.
https://bugzilla.gnome.org/show_bug.cgi?id=781266
buf is the current pad->last_buf value. If ever it gets copied/unreffed,
we need to make sure to write back the new pointer to the last_buf
variable.
Fixes using wrong pointer values in the case of decrasing DTS value
Before pushing a sample, check if there was a change in the current
stsd entry. This patch also assumes that the first stsd entry is
used as default for the first sample. It might cause an uneeded
caps renegotiation when this isn't the case.
stsd can have multiple format entries, parse them all.
This is required to play DVB DASH profile that uses multiple entries
to identify the different available bitrates/options on dash streams
The stream format-specific data is not stored into QtDemuxStreamStsdEntry
Instead of using the stsd as a base pointer, use the actual stsd
entry as the stsd can have multiple entries. This is rarely used
for file playback but is a possible profile with in DVB DASH specs.
This still doesn't support stsd with multiple entries but makes it
easier to do so.
AudioSpecifigConfig is used in a variety of AAC streams but was
being parsed differently. Instead, make everyone use the same parsing.
* Remove unused 'bits' field (it was always set to 0 if present)
* Add proper GAConfig parsing (to know the number of samples per frame
if present).
Fixes wrong rate/channels configuration in streams coming from qtdemux
https://bugzilla.gnome.org/show_bug.cgi?id=780966
According to ISO/IEC:14496-2:2009 , in the case of HE-AACv2 (audioObjecType
29) parametric stereo is used (a single mono track is used and then
transformations are applied to it to provide a stereo output).
We therefore report two channels in the case where there is one reported
in the audioChannelConfiguration.
Fixes the various issues where a demuxer would report two channels, but
then the parser would say there's only one channel, and then the decoder
would output two channels.
last_buf is the one we're going to write next, not buf. As such we
should check timestamps against that one if there is one to select the
earliest pad.
Also remember the currently selected pad in the very beginning when
storing the first last_buf.
This both solves some edge cases where not the correct next pad was
selected corresponding to the target interleave.
This is an update of d78d589627
We still exit as early as possible in case of non-ok/non-unlinked combined
flow, but we first make sure that we update the internal position variables.
This ensures that if upstreams "ignores" the flow return (and carries on pushing),
we don't end up processing data with completely bogus variables/positions.
If self->channel_positions == NULL (which seems unlikely),
self->default_channels_ordering_map will be used unintialised.
We avoid that by keeping track of the channel_mask, which is set when
the ordering map is initialised.
https://bugzilla.gnome.org/show_bug.cgi?id=780331
When there are more than 64 channels, we don't want to exceed the
bounds of the ordering_map buffer, and in these cases we don't want to
rempa at all. Here we avoid doing that.
https://bugzilla.gnome.org/show_bug.cgi?id=780331
TFDTs with time 0 are being ignored since commit 1fc3d42f. They're
mistaken with the case of not having TFDT, but those two cases
must be distinguished in some way.
This patch passes an extra boolean flag when the TFDT is present.
This is now the condition being evaluated, instead of checking for
0 time.
https://bugzilla.gnome.org/show_bug.cgi?id=780410
If we have multiple tracks with timecodes, or it's not the first track
that has timecodes, or not the first buffer, we already started a chunk
for media data. We now need to "close" that chunk because we wrote data
for the timecode track and a new chunk has to be started for the
original track the next time it has data.
Similar to what was done in adaptivedemux, ignore seek
events we've already handled - such as when they are received
on every srcpad of files with lots of streams.
Otherwise mdatleft will have a value calculated from the initial
mdatsize minus the parts of the stream that we saw, which is not
including all the parts of the stream that might've been skipped.
This breaks gst-validate on the build server (though not locally),
and a unit test, and I can't run unit tests right now for some
unrelated reason.
This reverts commit 0747b56f8e.
This debug statement is meant to print the time since the last (early)
RTCP transmission, not the last regular RTCP transmission (which also
happens to be set a few lines above to current_time, so the debug output
is just confusing)
Take into account the atoms at the end of the 'trak' atom when
recovering it. So that its size (already computed and added in the trak
size) isn't making offsets wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=771478
Fix the check for whether the start time of the segment has
been reached when playing in reverse. Otherwise, playback
stops after reaching the start of any file part, instead of
continuing until all parts within the segment have played
We parse the next moof in advance of having pushed
all samples from the previous one in some cases, and
we'll still need the crypto info from the previous
fragment so keep around any unused crypto info entries
when adding new ones
qtdemux.c: In function ‘qtdemux_parse_samples’:
qtdemux.c:8450:39: error: ‘*’ in boolean context, suggest ‘&&’ instead [-Werror=int-in-bool-context]
if (stream->samples_per_frame * stream->bytes_per_frame) {
~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
gstmpegaudioparse.c: In function ‘gst_mpeg_audio_parse_reset’:
gstmpegaudioparse.c:209:3: error: ‘memset’ used with length equal to number of elements without multiplication by element size [-Werror=memset-elt-size]
memset (mp3parse->xing_seek_table_inverse, 0, 256);
^~~~~~
gstmpegaudioparse.c: In function ‘gst_mpeg_audio_parse_handle_first_frame’:
gstmpegaudioparse.c:951:7: error: ‘memset’ used with length equal to number of elements without multiplication by element size [-Werror=memset-elt-size]
memset (mp3parse->xing_seek_table_inverse, 0, 256);
^~~~~~
This prevents storing an infinite amount of e.g. comment headers if they
come without a new initialization header in front of them. There can
only be one header of each type.
If we also replace all headers when receiving any possibly following
comments header, we would throw away the config header before being able
to make use of it.
A sparse stream's ending timestamp can be considerably smaller
than the ending timestamps of the other streams, which can lead
to skipping considerable time from the next part.
https://bugzilla.gnome.org/show_bug.cgi?id=761086
In function rtp_jitter_buffer_calculate_pts: If gap in incoming RTP
timestamps is more than (3 * jbuf->clock_rate) we call
rtp_jitter_buffer_reset_skew which resets pts to 0. So components down
the pipeline (playes, mixers) just skip frames/samples until pts becomes
equal to pts before gap.
In version 1.10.2 and before this checking was bypassed for packets with
"estimated dts", and gaps were handled correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=778341
The payloader needs to reset and update the vorbis config data which is
pushed on the network if it receives new headers, or at least, it may
have to do so.
Without this, the stream configuration could change without the
payloader sending the new configuration to the other side.
This reverts commit 107902ec51.
This commit intended to ensure that keyframe seeks land at the
start timestamp of a keyframe, rather than in the middle of one,
but they cause trouble on files with sparse streams, or with
JPEG 'cover art' tracks that have only one or a few JPEG samples
with very long durations.
That's still desirable for doing seamless cutting of videos,
but needs a rethink for implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=778690
Add a new boolean surround-delay property that makes
audioecho just apply a delay to certain channels to create
a surround effect, rather than an echo on all
channels. This is useful when upmixing from stereo - for example.
Add a surround-mask property to control which channels
are considered surround sound channels when adding a
delay with surround-delay = true
Original patch from Jochen Henneberg <jh@henneberg-systemdesign.com>
This goes around the inefficient control message based filtering and
does all the filtering kernel-side. Unfortunately this is Linux-only and
there is no IPv6 variant of it (yet).
Some radio streams uses StreamTitle='' to reset the title after a
track stopped playing, e.g. while the host talks between tracks or
during news segments.
This change forces an empty tag object to be distributed if
StreamTitle or StreamUrl is received with empty value, thus allowing
downstream elements to get notified about this.
https://bugzilla.gnome.org/show_bug.cgi?id=778437
Upstream elements like videoflip can transform caps, such as changing width and height.
When an imagefreeze downstream receives an ACCEPT_CAPS query it will NOW return
all caps that it can accept.
https://bugzilla.gnome.org/show_bug.cgi?id=778389
Used signed calculations when measuring the max_ts of an input
fragment, so as to calculate the correct duration and offset
when buffers have timestamps preceding their segment
The n_frames field (frames per second) should follow the nominal frame
rate for drop-frame timecodes.
Also, the trak's timescale (and duration, accordingly) should follow the
STSD entry's timescale and frame duration (fps_n and fps_d accordingly),
not the other way around.
https://bugzilla.gnome.org/show_bug.cgi?id=777832
In case wavparse receives a manually injected FLUSH_STOP event
while operating in pull mode we get criticals because we'd try
to clear a NULL adapter.
https://bugzilla.gnome.org/show_bug.cgi?id=777123
Insert VPS/SPS/PPS before the first NAL unit containing an I-frame in an
access unit only. If an access unit consists of several such NAL units
(tiles) VPS/SPS/PPS should only be inserted before the first of them so
that parameters are only updated between frames.
Do not insert VPS/SPS/PPS before P-frames when config-interval is -1.
https://bugzilla.gnome.org/show_bug.cgi?id=775817
qtdemux_handle_xmp_taglist() requires a writable taglist,
but qtdemux->tag_list can become non-writable, specifically
after sending global tags (qtdemux.c:958), which adds a
second reference. Ensure the list is made writable before
calling (make_writable will copy the list if necessary).
https://bugzilla.gnome.org/show_bug.cgi?id=766177
These are usually much bigger than icon size and required by
iTunes to be certain fairly large sizes. In qtmux it is also
the IMAGE tags which we write out as 'covr' atoms.
When reset, don't restart request pad numberings, as
request pads can survive across state changes. Only
restart at 0 if all request pads are handed back first.
https://bugzilla.gnome.org/show_bug.cgi?id=777174
'stream-format' and 'alignment' are defined in pad template caps so
there is no need to check them again here. Also remove bitrate parsing from
caps as bitrate in caps doesn't make sense but from tags, which is
actually the case.
https://bugzilla.gnome.org/show_bug.cgi?id=777181
Needed for QuickTime 7 to properly play files.
Also write the clap atom for MOV files always, not only when ProRes is
used as a video codec. It's mandatory for MOV.
https://bugzilla.gnome.org/show_bug.cgi?id=777100
The seqh buffer allocated in qtdemux_parse_svq3_stsd_data() needs to
be freed by the caller after use.
https://bugzilla.gnome.org/show_bug.cgi?id=777157
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
If a fragmented stream doesn't have a tfdt, don't
reset the output timestamps at each fragment boundary
by erroneously using the default value of 0. Introduced
by commit 69fc48
https://bugzilla.gnome.org/show_bug.cgi?id=754230
Majorly change the way that splitmuxsink collects
incoming data and sends it to the output, so that it
makes all decisions about when / where to split files
on the input side.
Use separate queues for each stream, so they can be
grown individually and kept as small as possible.
This removes raciness I observed where sometimes
some data would end up put in a different output file
over multiple runs with the same input.
Also fixes hangs with input queues getting full
and causing muxing to stall out.
Add a new signal for formatting the filename, which receives
a GstSample containing the first buffer from the reference
stream that will be muxed into that file.
Useful for creating filenames that are based on the
running time or other attributes of the buffer.
To make it work, opening of files and setting filenames is
now deferred until there is some data to write to it,
which also requires some changes to how async state changes
and gap events are handled.
When performing a key-unit seek, always snap to the start ts
of the keyframe buffer we landed on so that the keyframe is
entirely within the resulting outgoing segment. That seems
the most sensible result, since the user requested snapping
to the keyframe position.
Segments times and seek requests are stored and handled
in raw 'PTS' time, without the cslg_shift - which only applies
to outgoing samples. Omit the cslg_shift portion when
extracting PTS to compare for internal seek snaps.
If the cslg_shift is included, then keyframe+snap-before seeks
generate a segment start/stop time that already includes the
cslg_shift, and it's then added a 2nd time, causing the
first buffer(s) to have timestamps that are out of segment.
Remove an old check from atom_stsc_add_new_entry() that
extends the last entry in the STSC if the samples per chunk
matches, as the new interleave merging logic requires that
the final entry by updateable. There's already code
below which simply merges the final entry into the previous
one when needed, so rely on that instead.
Fixes asserts like:
ERROR:atoms.c:2940:atom_stsc_update_entry: assertion failed:
(atom_array_index (&stsc->entries, len - 1).first_chunk == first_chunk)
Make sure the state of the parser is set to
collecting streams before chaining up to the
parent change_state() method, to close a
small window that can cause playback to
never commence.
Use GQueue instead of a GSList so we don't have to traverse
the whole list to append something every time. And it also
keeps track of the number of items in it for us.
Add a function to add filenames to the list of old files and
use it in more places, so that memory doesn't build up in
other modes either if no max_files limit is specified.
https://bugzilla.gnome.org/show_bug.cgi?id=766991
Technically we weren't leaking the memory, just storing it internally
and never using it until the element is freed. But we'd still use more
and more memory over time, so this is not good over longer periods
of time. Only keep track of files if there's actually a limit set,
so that we will prune the list from time to time.
https://bugzilla.gnome.org/show_bug.cgi?id=766991
Previously, seeking to position y where y is (strictly) within a keyframe
would seek to that keyframe both with SNAP_BEFORE and SNAP_AFTER,
where the latter is now adjusted to really snap to the next keyframe.
Rather amazingly (and equally unnoticed), keyunit seeking resulted in segments
where start != time (which is bogus for simple avi timeline). So, properly
adjust the segment (start) rather than fiddling with segment time (only).
... by using the original seek event's flags rather than the corresponding
segment flags, which do not have such counterpart flags (and
do no longer have them covertly sneaking in nowadays).
With Xiph codecs the stream header buffers are both in the caps and are
usually also at the beginning of each input stream, but it's perfectly
possible that the input stream does not have the stream header buffers
inline in the data. Matroskamux would drop the first N buffers assuming
they're stream headers, but this meant it would drop actual payload data
when the stream didn't contain the stream headers inline. Fix this by
only dropping leading buffers if they're flagged as stream headers. This
fixes issues with streams that are being tapped into after streaming
has started.
https://bugzilla.gnome.org/show_bug.cgi?id=749098
That is, whenever we go through start/stop we have to ensure that on the
next opportunity the buffers are reallocated again. Otherwise the
buffers might be NULL because the element was reused with the same
configuration as before (i.e. set_caps() wouldn't have reinited the
buffers).
https://bugzilla.gnome.org/show_bug.cgi?id=775898
Redirect on PLAY wasn't doing the necessary session cleanup. Fixed by
removing code from gst_rtspsrc_send that changed the state varable upon
encountering a redirect. Better to let the redirect handlers in
gst_rtspsrc_retrieve_sdp and gst_rtspsrc_play do their own
state-dependent cleanup.
https://bugzilla.gnome.org/show_bug.cgi?id=775543
When providing items with a seqnum, there is a (very small) probability
that an element with the same seqnum already exists. Don't forget
to free that item if it wasn't inserted.
And avoid returning undefined values when dealing with duplicate items
We can't simply assume that the length of the tag value as given
inside the stream is correct but should also check against the amount of
data we have actually available.
https://bugzilla.gnome.org/show_bug.cgi?id=775451
qtdemux.c: In function ‘qtdemux_parse_trak’:
qtdemux.c:10184:38: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 9 has type ‘gint {aka const int}’ [-Werror=format=]
GST_DEBUG_OBJECT (qtdemux, "Found jpeg: len %u, need %lu", len,
^
If an element queries the number of retransmission buffers pushed
*while* the push is still taking place (and before the object lock
is taken just after) it would end up with the wrong statistic
being reported.
Increment it just before the push, avoids races when getting statistics
https://bugzilla.gnome.org/show_bug.cgi?id=768723
39f7e52266 was setting the buffer duration
to 0 if is not valid, under the assumption that this is "the last"
buffer and no others are coming next. This is wrong, last_buf is the
previous buffer and not the very last one.
4e3c13c87c was setting DTS to 0 if there
was none. This will set DTS to 0 for all e.g. audio streams, completely
messing up calculations if streams don't start at 0.
https://bugzilla.gnome.org/show_bug.cgi?id=774840
Solves overreading/writing the given arrays and will error out if the
streams asks to do that.
Also does more error checking that the stream is valid and won't
overrun any allocated arrays. Also mitigate integer overflow errors
calculating allocation sizes.
https://bugzilla.gnome.org/show_bug.cgi?id=774859
After finding a cluster id in the byte reader, we skip ahead the reader
position by one further byte to be able to continue searching from there
inside the same chunk if the cluster candidate was a false positive.
We have to accomodate for that additional byte when resuming the search,
otherwise all following pulls are off-by-one for every resume and we run
into an assertion.
bf43f44fcf was comparing an unsigned
expression to be < 0 which was always false.
gstflxdec.c: In function ‘flx_decode_brun’:
gstflxdec.c:322:33: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
if ((glong) row - count < 0) {
^
gstflxdec.c:332:33: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
if ((glong) row - count < 0) {
^
https://bugzilla.gnome.org/show_bug.cgi?id=774834
| ../../../git/gst/isomp4/qtdemux.c: In function 'qtdemux_parse_tree':
| ../../../git/gst/isomp4/qtdemux.c:10224:24: error: 'size' may be used uninitialized in this function [-Werror=maybe-uninitialized]
| offset += size;
| ^~
| ../../../git/gst/isomp4/qtdemux.c:10197:25: note: 'size' was declared here
| guint32 size, tag;
| ^~~~
https://bugzilla.gnome.org/show_bug.cgi?id=774747
Always write an edit list for the whole track. In general this is not
necessary except for the case of having a gap or DTS adjustment but
it allows to give the whole track's duration in the usually more
accurate media timescale.
https://bugzilla.gnome.org/show_bug.cgi?id=774403
splitmuxsink requests pad from element using pad template like "video_%u", "audio_%u" and "sink_%d". This is true for most of the muxers.
But splitmuxsink not able to request pad to flvmux as flvmux has "audio" and "video" as pad templates.
fix: splitmuxsink should fallback to "audio" and "video" when template not found.
https://bugzilla.gnome.org/show_bug.cgi?id=774507
A new signal named on-bundled-ssrc is provided and can be
used by the application to redirect a stream to a different
GstRtpSession or to keep the RTX stream grouped within the
GstRtpSession of the same media type.
https://bugzilla.gnome.org/show_bug.cgi?id=772740
aacparse resizes input buffer while converting ADTS stream to RAW,
During buffer resize buffer write permission is not checked.
This throws gst_buffer_is_writable assertion and leads to AV sync issue some times.
It is corrected by making buffer writeable using gst_buffer_make_writable
https://bugzilla.gnome.org/show_bug.cgi?id=774129
TIME segment implies that stream/running time is being handled by upstream.
So, we shouldn't override it without any clue.
This patch is for fixing seek in DASH streaming.
https://bugzilla.gnome.org/show_bug.cgi?id=774196
The accumulator is filled by intersecting with all the pad caps, as such
it must be initialized with ANY (like it is before the iteration is
started) and not to EMPTY.
Fixes the CAPS query always returning EMPTY caps when resyncing happened
during the query, e.g. because pads were added/removed.
The g_object_unref (saddr) before receiving message seems to be redundant as it
is done just before jumping to retry
Though not directly related, part of
https://bugzilla.gnome.org/show_bug.cgi?id=772841
Control messages are used only in multicast mode - to detect if the destination
address is not ours and possibly drop the packet. However in non-multicast
modes the messages are still allocated and freed even if not used. Therefore
request control messages from g_socket_receive_message() only in multicast
mode.
https://bugzilla.gnome.org/show_bug.cgi?id=772841
Do not use last buffer TS + buffer duration because buffer duration
might be inaccurate, especially for frame rates like 30fps where a
rounding error is observed.
https://bugzilla.gnome.org/show_bug.cgi?id=773785
When doing rtx, the jitterbuffer will always add an rtx-timer for the next
sequence number.
In the case of the packet corresponding to that sequence number arriving,
that same timer will be reused, and simply moved on to wait for the
following sequence number etc.
Once an rtx-timer expires (after all retries), it will be rescheduled as
a lost-timer instead for the same sequence number.
Now, if this particular sequence-number now arrives (after the timer has
become a lost-timer), the reuse mechanism *should* now set a new
rtx-timer for the next sequence number, but the bug is that it does
not change the timer-type, and hence schedules a lost-timer for that
following sequence number, with the result that you will have a very
early lost-event for a packet that might still arrive, and you will
never be able to send any rtx for this packet.
Found by Erlend Graff - erlend@pexip.comhttps://bugzilla.gnome.org/show_bug.cgi?id=773891
The lost-event was using a different time-domain (dts) than the outgoing
buffers (pts). Given certain network-conditions these two would become
sufficiently different and the lost-event contained timestamp/duration
that was really wrong. As an example GstAudioDecoder could produce
a stream that jumps back and forth in time after receiving a lost-event.
The previous behavior calculated the pts (based on the rtptime) inside the
rtp_jitter_buffer_insert function, but now this functionality has been
refactored into a new function rtp_jitter_buffer_calculate_pts that is
called much earlier in the _chain function to make pts available to
various calculations that wrongly used dts previously
(like the lost-event).
There are however two calculations where using dts is the right thing to
do: calculating the receive-jitter and the rtx-round-trip-time, where the
arrival time of the buffer from the network is the right metric
(and is what dts in fact is today).
The patch also adds two tests regarding B-frames or the
“rtptime-going-backwards”-scenario, as there were some concerns that this
patch might break this behavior (which the tests shows it does not).
The new timeout is always going to be (timeout + delay), however, the
old behavior compared the current timeout to just (timeout), basically
being (delay) off.
This would happen if rtx-delay == rtx-retry-timeout, with the result that
a second rtx attempt for any buffers would be scheduled immediately instead
of after rtx-delay ms.
Simply calculate (new_timeout = timeout + delay) and then use that instead.
https://bugzilla.gnome.org/show_bug.cgi?id=773905
Commit 83e718 added a pad template to splitmux request
pads, which means that GstElement now releases the pads on
dispose, but after having removed all elements in the bin
and unlinked them. Make sure we can handle cleanup in that case
without throwing assertions.
https://bugzilla.gnome.org/show_bug.cgi?id=773784
qtdemux.c: In function ‘qtdemux_parse_tree’:
qtdemux.c:10139:16: error: ‘color_table_id’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (color_table_id != 0) {
^
qtdemux.c:10121:19: note: ‘color_table_id’ was declared here
guint16 color_table_id;
^~~~~~~~~~~~~~
The ProRes guidelines suggest an interleave of 0.5s is common, but
specifies that for ProRes at most 2MB (for SD) and 4MB (for HD) should
be used per chunk.
It might also make sense to use similar numbers in general.
https://bugzilla.gnome.org/show_bug.cgi?id=773217
Previously we were switching from one chunk to another on every single
buffer. This wastes some space in the headers and, depending on the
software, might depend in more reads (e.g. if the software is reading
multiple samples in one go if they're in the same chunk).
The ProRes guidelines suggest an interleave of 0.5s is common, but
specifies that for ProRes at most 2MB (for SD) and 4MB (for HD) should
be used per chunk. This will be handled in a follow-up commit.
https://bugzilla.gnome.org/show_bug.cgi?id=773217
It's required for ProRes to work with other software.
It is also in the MP4 standard, but inventing values here seems a bit
tricky for the general case and it does not really give any extra
information.
https://bugzilla.gnome.org/show_bug.cgi?id=769048
Some buggy payloaders, e.g. rtph263pay, may use mode B for packets
that starts with a picture (or GOB) start code although it's not
allowed. Let's be nice and not drop these packets/frames.
https://bugzilla.gnome.org/show_bug.cgi?id=773516
Bump the bitstream parsing to TRACE log level so it doesn't flood the
output when trying to read the more useful DEBUG and LOG messages.
Also use GST_DEBUG_OBJECT instead of GST_DEBUG in various places
https://bugzilla.gnome.org/show_bug.cgi?id=773514
Altough commits 6a16be7, 64f9d08 and 0c7e3a8 fixed some issues they
introduced others. This patch fixes the leak of one macroblock for every
B fragment.
Macroblock structures must not be freed immediately after finding the
boundaries as they are stored and used later. However the inital dummy
structure (used for finding the first boundary) must be freed.
CID #1212156https://bugzilla.gnome.org/show_bug.cgi?id=773512
Instead of sending EOS when a source byes we have to wait for
all the sources to be gone, which means they already sent BYE and
were removed from the session. We now handle the EOS in the rtcp
loop checking the amount of sources in the session.
https://bugzilla.gnome.org/show_bug.cgi?id=773218
Improve RFC2326 - chapter C.3 compatibility:
In case just a single stream is specified in SDP and the control attribute
is missing do not drop the stream but rather assume "a=control:*"
https://bugzilla.gnome.org/show_bug.cgi?id=770568
Use the number of milliframes per second for integral and drop-frame
framerates, as suggested by the QT file format specification and other
places. We already did that for integral framerates before, but not for
drop-frame framerates. This now keeps precision better.
For all other framerates, check if it's close to a well-known framerate
and use that instead.
https://bugzilla.gnome.org/show_bug.cgi?id=769041
We consider there's a sifnificant difference when it's larger than on second
or than half the duration of the last processed fragment in case the latter is
larger.
https://bugzilla.gnome.org/show_bug.cgi?id=754230
With MSVC, this gives the following warning:
warning C4305: 'function': truncation from 'double' to 'gfloat'
Apparently, MSVC does not figure out what type to use for constants
based on the assignment. This warning is very spammy, so let's try to
fix it.
Modify the caps string to allow width and height greater than 4096.
There is no need to restrict it since the matroska format allows the
width and height values to be up to eight bytes long.
https://bugzilla.gnome.org/show_bug.cgi?id=773582
This solves a hanging mainloop in following scenario:
* connect to source
* network/server drops
* pipeline set to NULL (and connection to flushing as part)
* pipeline set to PAUSED/PLAYING (connection to non-flushing, but not recorded)
* [connecting still not possible]
* pipeline set to NULL => mainloop hangs (since no actual flushing is done)
The pacing of the overall muxing is controlled
by the video GOPs arriving, so we can only handle
1 video stream, and the request pad is named accordingly.
Ignore a request for a 2nd video pad if there's already
an active one.
In file included from ../subprojects/gst-plugins-good/gst/monoscope/gstmonoscope.c:42:0:
../subprojects/gst-plugins-base/gst-libs/gst/audio/audio.h:26:39: fatal error: gst/audio/audio-enumtypes.h: No such file or directory
#include <gst/audio/audio-enumtypes.h>
^
compilation terminated.
https://ci.gstreamer.net/job/GStreamer-master-meson/271/console
Found via the Jenkins CI:
FAILED: subprojects/gst-plugins-good/gst/multifile/gstmultifile@sha/gstsplitmuxsink.c.o
[...]
In file included from ../subprojects/gst-plugins-good/gst/multifile/gstsplitmuxsink.h:24:0,
from ../subprojects/gst-plugins-good/gst/multifile/gstsplitmuxsink.c:59:
../subprojects/gst-plugins-base/gst-libs/gst/pbutils/pbutils.h:30:43: fatal error: gst/pbutils/pbutils-enumtypes.h: No such file or directory
#include <gst/pbutils/pbutils-enumtypes.h>
^
compilation terminated.
https://ci.gstreamer.net/job/GStreamer-master-meson/263/console
If the seek stop point (or start, during reverse play)
was within the segment we just finished, go EOS immediately
instead of proceeding through all other parts and sending
0 length seeks to them.
https://bugzilla.gnome.org/show_bug.cgi?id=772138
When one part moves ahead of the others - due to excessive
downstream queueing, or really small input files - then
we can end up activating parts more than once. That can lead to
effects like shutting down pad tasks prematurely.
https://bugzilla.gnome.org/show_bug.cgi?id=772138
This reverts commit f1ceaab02f.
This broke atomic file writes in "buffer" mode. It did make
sure that any streamheaders are prepended to each file in
buffer mode as well, but that's not really needed in practice,
whereas atomic file writes are, so let's restore the status
quo ante for now since this was primarily a code cleanup anyway,
and if anyone needs to streamheaders in buffer mode too they
can make a patch to implement that differently. Re-implementing
the atomic writes in the element also seems way too much work.
https://bugzilla.gnome.org/show_bug.cgi?id=766990
We were just picking the timestamp of the last buffer pushed into our
adapter before we had enough data to push out.
This fixes things to figure out how large each frame is and what
duration it covers, so we can set both the timestamp and duration
correctly.
Also adds some DISCONT handling.
The basic idea is this:
1. For *larger* rtx-rtt, weigh a new measurement as before
2. For *smaller* rtx-rtt, be a bit more conservative and weigh a bit less
3. For very large measurements, consider them "outliers"
and count them a lot less
The idea being that reducing the rtx-rtt is much more harmful then
increasing it, since we don't want to be underestimating the rtt of the
network, and when using this number to estimate the latency you need for
you jitterbuffer, you would rather want it to be a bit larger then a bit
smaller, potentially losing rtx-packets. The "outlier-detector" is there
to prevent a single skewed measurement to affect the outcome too much.
On wireless networks, these are surprisingly common.
https://bugzilla.gnome.org/show_bug.cgi?id=769768
Assuming equidistant packet spacing when that's not true leads to more
loss than necessary in the case of reordering and jitter. Typically this
is true for video where one frame often consists of multiple packets
with the same rtp timestamp. In this case it's better to assume that the
missing packets have the same timestamp as the last received packet, so
that the scheduled lost timer does not time out too early causing the
packets to be considered lost even though they may arrive in time.
https://bugzilla.gnome.org/show_bug.cgi?id=769768
There is no need to schedule another EXPECTED timer if we're already
past the retry period. Under normal operation this won't happen, but if
there are more timers than the jitterbuffer is able to process in
real-time, scheduling more timers will just make the situation worse.
Instead, consider this packet as lost and move on. This scenario can
occur with high loss rate, low rtt and high configured latency.
https://bugzilla.gnome.org/show_bug.cgi?id=769768
This patch fixes an issue with the estimated gap duration when there is
a gap immediately after a lost timer has been processed. Previously
there was a discrepancy beteen the gap in seqnum and gap in dts which
would cause wrong calculated duration. The issue would only be seen with
retranmission enabled since when it's disabled lost timers are only
created when a packet is received and the actual gap length and last dts
is known.
https://bugzilla.gnome.org/show_bug.cgi?id=769768
Stats should also be collected for unsuccessful packets.
rtx-rtt is very important for determining the necessary configured
latency on the jitterbuffer. It's especially important to be able to
increase the latency when retransmitted packets arrive too late and are
considered lost. This patch includes these late packets in the
calculation of the various rtx stats, making them more correct and
useful.
Also in the case where the original packet arrives after a NACK is sent,
the received RTX packet should update the stats since it provides useful
information about RTT.
The RTT is only updated if and only if all requested retranmissions are
received. That way the RTT is guaranteed to make sense. If not we don't
know which request the packet is a response to and the RTT may be bogus.
A consequence of this patch is that RTT is not updated for a request
when one of the RTX packets for that seqnum is lost, but that since
measured RTT will be more accurate.
The implementation store the RTX information from the timed out timers
and use this when the retransmitted packet arrives. For performance
these timers are stored separately from the "normal" timers in order to
not impact performance (see attached performance test).
https://bugzilla.gnome.org/show_bug.cgi?id=769768
When disabled we can save some iterations over timers.
There is probably an argument for rtx-delay-reorder to exist, but
for normal operations, handling jitter (reordering) is something a
jitterbuffer should do, and this variable feels like functionality that
is not "in-sync" with what the jitterbuffer is trying to achieve.
Example: You have 50ms jitter on your network, and are receiving
audio packets with 10ms durations. An audio packet should not be
considered late until its rtx-timeout has expired (and hence a rtx-event
is sent), but with rtx-delay-reorder, events will be sent pretty much
all the time due to the jitter on the network.
Point being: The jitterbuffer should adapt its size to the measured network
jitter, and then rtx-delay-reorder needs to adapt as well, or simply
get out of the way and let the other (better) rtx-mechanisms do their job.
Also change find_timer to only use seqnum as an argument, since there
will only ever be one timer per seqnum at any given time. In the
one case where the type matters, the caller simply checks the type.
https://bugzilla.gnome.org/show_bug.cgi?id=769768
And actually calculate the field duration instead of a frame duration so
that we can properly timestamp output frames in fields=all mode.
This is probably still broken for reverse playback in telecine mode.
This may cause a few packets to be processed by the parser, but it's
better than never pushing out buffers from a slightly broken stream
where no marker bits are set.
To be able to cap the number of allowed streams for one session.
This is useful for preventing DoS attacks, where a sender can change
SSRC for every buffer, effectively bringing rtpbin to a halt.
https://bugzilla.gnome.org/show_bug.cgi?id=770292
Under certain conditions gst_rtp_buffer_get_payload() returns a copy of
the payload. In this case the payload modifications will not affect the
rtp buffer. So instead of modifying the payload buffer directly we
should modify the buffer that actually gets pushed on the adapter.
It implements now this interface with its video-direction
property. Values are changed to GstVideoOrientationMethod but they have
the same value than the originals.
https://bugzilla.gnome.org/show_bug.cgi?id=768687
On 32-bit x86: gstsplitmuxsink.c:966:31: warning: format ‘%u’ expects
argument of type ‘unsigned int’, but argument 9 has type
‘guint64 {aka long long unsigned int}’
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
Some servers add properties like charset, e.g.
application/sdp; charset=utf8
Ideally we should also parse the charset and do conversion of all messages,
but that's for a later time.
This reverts commit fa008f271a.
async-handling in GstBin causes the pipeline to spin at 100%
CPU as the top-level pipeline tries to change that state
to PLAYING constantly. This is a workaround for a core
problem, essentially, but an improvement in this case for now.
After dropping the splitmux lock, re-check the state,
don't just fall through and sleep unconditionally,
as we may have already missed the wakeup.
https://bugzilla.gnome.org/show_bug.cgi?id=769514
The current 'l' pointer will be NULL when the loop
is interrupted with a 'break' statement. Need to have
it advance to the next list item before interrupting.
And don't just reset everything. This makes sure that we can continue to
handle data in the following scenario:
moov: discont
moof: discont
mdat: continuous
Previously this would fail because the offset would be the accumulated offset
from moov and moof at the mdat position, while the buffer offset might be
something completely different.
Use signed clock times for running time everywhere
so that we handle negative running times without
going haywire, similar to what queue and multiqueue
do these days.
Always intersect with the filter caps in the getcaps function
to make sure we return a subset of what was requested.
Other payloaders also have this problem and need fixing
in future commits.
When parsing NAL unit type in codec_data, check the 6bits of
NAL_unit_type only and do not require the array_completeness bit to be
0, since the default and mandatory value of array_completeness is 1 for
hvc1.
https://bugzilla.gnome.org/show_bug.cgi?id=768653
We should add all pads, no matter if they are linked or active or not at this
point. Skipping some that are not will cause different behaviour than with
other muxers.
This can only happen if a) upstream somehow gets around the CAPS event failing
or b) there never being any CAPS event.
The following code assumes that all pads have a codec-id.
https://bugzilla.gnome.org/show_bug.cgi?id=768509
Handle sprop-vps, sprop-sps and sprop-pps in caps instead of
sprop-parameter-sets.
rtph265pay works with byte-stream and hvc1 formats but not hev1 yet. It
handles profile-id, tier-flag and level-id in caps query.
https://bugzilla.gnome.org/show_bug.cgi?id=753760
The FLV header cannot be trusted to indicate video or
audio presence, as the comments already mention. Don't
delay pushing tags waiting for streams that might never
appear.
Tags are now pushed immediately after they change:
- After parsing an onMetaData script object
- After negotiating caps on a pad
https://bugzilla.gnome.org/show_bug.cgi?id=768440
As seen in the parent switch for object_type_id, the 4 possible values are
0x40, 0x66, 0x67 and 0x68. Fixing the nested switch to match these values.
Looks like it was a typo making them decimal instead of hexadecimal.
CID 1363328
Without, raw AAC can't be handled and we have some information available in
the decoder that most likely allows us to decode the stream in one way or
another. This is the same code already used by matroskademux for the same
reasons, and ffmpeg/vlc play such files just fine too by guesswork.
This is to handle cases where upstream handles the fragmented streaming in TIME
segments and sends us data with gaps within fragments. This would happen when dealing
with trick-modes.
When upstream (push-based, TIME SEGMENT) wishes to send discontinuous samples,
it must obey the following rules:
* The buffer containing the [moof] must have a valid GST_BUFFER_OFFSET
* The buffers containing the first sample after a gap:
* MUST start at the beginning of a sample,
* MUST have the DISCONT flag set,
* MUST have a valid GST_BUFFER_OFFSET relative to the beginning of the fragment.
https://bugzilla.gnome.org/show_bug.cgi?id=767354
If we consider the RTSP state, what can happen is that it is PLAYING but the
element already asynchronously tried to PAUSE and it just did not happen yet.
We would then override this setting to PAUSED (while the element actually is
in PAUSED) and set the RTSP state to PLAYING again. This would then cause us
to produce packets while the sinks are all PAUSED, piling up thousands of
packets in the rtpjitterbuffer and other elements and finally failing.
This is supposed to be either in the codec_data (avc stream format) or inside
the stream, and we extract it from there. It should not be set from a
property as it's stream specific.
https://bugzilla.gnome.org/show_bug.cgi?id=767789
The Session Data Protocol doesn't allow specifying a cipher for the
SRTCP, so it will use the SRTP one. In the "srtpenc" element the cipher
"aes-128-icm" is the default for SRTP and SRTCP, but if we want to have
an SRTCP with the "aes-256-icm" cipher then we also need to set the SRTP
cipher to "aes-256-icm", otherwise "aes-128-icm" will be used instead.
https://bugzilla.gnome.org/show_bug.cgi?id=767799
With non-time segments, it now assumes that the arrival time of packets
is not relevant and that only the RTP timestamp matter and it produces
an output segment start at running time 0.
https://bugzilla.gnome.org/show_bug.cgi?id=766438
No variables were added/removed. This was just a good excuse to:
* Comment what most variables are used for (and when)
* Order them in such a way as to show first the common variables used
in all cases, followed by those only used in push-mode
We shouldn't go through segment activation as we will only have a limited
understanding of how the whole stream timeline looks like from the moof. We
only know about the current fragment, while upstream knows about the whole
stream.
This fixes seeking in DASH streams, both for seeks after the current moof and
for seeks into the current moof. The former would fail because the moof ends
and we can't activate any segment, the latter would cause a segment that stops
at the moof end, and no further fragments would be played because we end up
being EOS.
https://bugzilla.gnome.org/show_bug.cgi?id=767071
Some endpoints (like Tandberg E20) can send BYE packet containing our
internal SSRC. I this case we would detect SSRC collision and get rid
of the source at some point. But because we are still sending packets
with that SSRC the source will be recreated immediately.
This brand new internal source will not have some variables incorrectly
set in its state. For example 'seqnum-base` and `clock-rate` values will be
-1.
The fix is not to act on BYE RTCP if it contains internal or unknown
SSRC.
https://bugzilla.gnome.org/show_bug.cgi?id=762219
matroskademux would take the GST_OBJECT_LOCK in
- gst_matroska_demux_push_codec_data_all()
- gst_matroska_demux_query()
Some parse element such as FLAC checks upstream seekability, and
there is some use cases that matroska-demux is linked to a parse element
(e.g.,FLAC format) without intermediate elements (e.g., queue).
In this case, matroska-demux never returns from _push_codec_data_all()
because the parser can return only after it receives the response to
the upstream query, but that's not going to happen because it's
deadlocked.
Elements must not hold the object lock whilst pushing out events
or data.
https://bugzilla.gnome.org/show_bug.cgi?id=766645
The GST_BUFFER_OFFSET of output buffers returned to GstRtpBasePayload
should reflect the number of "samples" in the unit of the RTP clock in this
buffer. If this is not true, then it shouldn't be set.
https://bugzilla.gnome.org/show_bug.cgi?id=761943
segment_duration and media_time should be parsed based on version
of elst box. Specification defines that an elst box with version 1
has uint64 and int64 values for segment_duration and media_time,
respectively.
https://bugzilla.gnome.org/show_bug.cgi?id=766301
Set the async-handling property on GstBin to let it manage
async-handling instead of the local handling from the previous
commit. Works because of #174a5e in core
When switching fragments, hide the async-start/async-done
messages from the parent bin, as otherwise we sometimes (very rarely)
hang in PAUSED instead of returning / continuing to PLAYING
state.
1. according to RFC, T bit is only set when either the RTP packet only contains the J2K main header, or the packet contains tile parts from multiple tiles. This is now being managed correctly in the code. The second scenario cannot happen with our payloader, since tile headers are always placed in their own RTP packet, and so a packet cannot contain tile parts from multiple tiles.
However, I have added code to track if multiple tile parts are included in a single RTP packet, in case in the future we want to put header and data in same packet.
2. Old code would set the tile id to zero for all J2K packets. This is now set correctly to the appropriate tile id.
https://bugzilla.gnome.org/show_bug.cgi?id=745187
Properly handle edts segments for push-based operation seeking.
We only support edts that a single segment that has media at the end,
being preceeded by any number of gap segments.
This also allows the qt segment rate to be respected after seeks
https://bugzilla.gnome.org/show_bug.cgi?id=765669
When a packet arrives that has already been considered lost as part of a
large gap the "lost timer" for this will be cancelled. If the remaining
packets of this large gap never arrives, there will be missing entries
in the queue and the loop function will keep waiting for these packets
to arrive and never push another packet, effectively stalling the
pipeline.
The proposed fix conciders parts of a large gap definitely lost (since
they are calculated from latency) and ignores the late arrivals.
In practice the issue is rare since large gaps are scheduled immediately,
and for the stall to happen the late arrival needs to be processed
before this times out.
https://bugzilla.gnome.org/show_bug.cgi?id=765933
The access to the session hash table must happen while the session lock is
taken, otherwise another thread might modify the hash table while we're
creating the stats.
https://bugzilla.gnome.org/show_bug.cgi?id=766025
This signal allows a user to directly return a sorted list of
files to be joined, so that they don't have to follow the
filename pattern that the "location" property expects.
https://bugzilla.gnome.org/show_bug.cgi?id=753625
The wav spec tells that 'fmt' (and 'bext' if present) must come before 'data'.
There is no requirement for 'fmt' to be first. We already had a list of chunks
to skip, but it is easier to just skip any chunk while seeking for 'fmt'.
This fixes reading files generated by ProTools.
Via the MPEG-4 Part 3 spec we can support the other layers too.
Also correct the samples per frame calculation for MP3 if it's MPEG-2 or
MPEG-2.5.
https://bugzilla.gnome.org/show_bug.cgi?id=765725
We only changed them for UDP so far, which caused the wrong seqnum-base and
other information to be passed to rtpjitterbuffer/etc when seeking. This
usually wasn't that much of a problem as the code there is robust enough, but
every now and then it causes us to drop up to 32756 packets before we
continue doing anything meaningful.
https://bugzilla.gnome.org/show_bug.cgi?id=765689
