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
