This takes the timestamp of the earliest stream and offsets it so that
it starts at 0. Some software (VLC, ffmpeg-based) does not properly
handle Matroska files that start at timestamps much bigger than zero.
Closes https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/449
There is only a single sink element in async-finalize mode, and we would
keep the running time from previous fragments set in that case. As we
don't ever set the running time for the very last fragment on EOS, this
would mean that the closing time reported for the very last fragment is
the same as the closing time of the previous fragment.
This is a tiny clarification as the storage was loosely named "storage".
This change clarify that the storage is specificaly used for received RTP
packets. This is unlike the storage found in rtprtxsend that stores a
backlog of sent RTP packets.
We recently added code to remove outdate NACK to avoid using bandwidth
for packet that have no chance of arriving on time. Though, this had a
side effect, which is that it was to get an early RTCP packet with no
feedback into it. This was pretty useless but also had a side effect,
which is that the RTX RTT value would never be updated. So we we stared
having late RTX request due to high RTT, we'd never manage to recover.
This fixes the regression by making sure we keep at least one NACK in
this situation. This is really light on the bandwidth and allow for
quick recover after the RTT have spiked higher then the jitterbuffer
capacity.
The second udpsrc (rtcp) might not have seen the segment event if it was
not enabled or if rtcp is not available on the server. So if the
application tries to send an EOS event it will try to set an invalid
seqnum to the event.
Right now, we may call on-new-ssrc after we have processed the first
RTP packet. This prevents properly configuring the source as some
property like "probation" are copied internally for use as a
decreasing counter. For this specific property, it prevents the
application from disabling probation on auxiliary sparse stream.
Probation is harmful on sparse streams since the probation algorithm
assume frequent and contiguous RTP packets.
Scaletempo doesn't support non-interleaved layout. Not explicitely stating this
would trigger critical warnings and a caps negotiation failure when scaletempo
is used as playbin audio-filter.
Patch suggested by George Kiagiadakis <george.kiagiadakis@collabora.com>.
Fixes#591
Fix doc chunks to not use that syntax for links that have the
url as description, it will be put verbatim into the xml/*.xml
file and then the expat parser will throw a syntax error like:
File "../../common/mangle-db.py", line 71, in <module>
main()
File "../../common/mangle-db.py", line 69, in main
patch (details.replace("-details", ""), os.path.basename(details))
File "../../common/mangle-db.py", line 20, in patch
doc = xml.dom.minidom.parse(related)
File "/usr/lib/python2.7/xml/dom/minidom.py", line 1918, in parse
return expatbuilder.parse(file)
File "/usr/lib/python2.7/xml/dom/expatbuilder.py", line 924, in parse
result = builder.parseFile(fp)
File "/usr/lib/python2.7/xml/dom/expatbuilder.py", line 207, in parseFile
parser.Parse(buffer, 0)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 84, column 7
If the incoming frame buffer has GST_BUFFER_FLAG_DISCONT set this should
be preserved and set for the first output buffer too, like other
payloaders do.
Spotted with gst-validate-1.0 when adding integration tests for
rtpsession, a minimal test to reproduce the issue is:
$ gst-validate-1.0 videotestsrc num-buffers=1 ! rtpvrawpay ! identity ! fakesink
Starting pipeline
Pipeline started
warning : Buffer didn't have expected DISCONT flag333 speed: 1.000000 />
Detected on <identity0:sink>
Detected on <identity0:src>
Detected on <fakesink0:sink>
Description : Buffers after SEGMENT and FLUSH must have a DISCONT flag
Issues found: 1
=======> Test PASSED (Return value: 0)
This introduce a new signal on RTSession, on-sending-nacks is emited
right before the list of seqnums to be nacked are processed and
transformed into FB Nack. This allow implementing custom nacks
handling through another mechanism with APP feedback.
In order to do that, we now split the nacks registration from the actual
FB nack packet construction. We then try and add as many FB Nacks as
possible into the active packets and leave the remaining seqnums in the
RTPSource. In order to avoid sending outdated NACK later on, we save the
seqnum calculated deadline and cleanup the outdated seqnums before the
next RTCP send.
Fixes#583
Calling rtp_session_send_rtcp before marking the source as requiring a
pli/fir/nack meant the rtcp_thread could be scheduled and start running
before the source was updated. This meant the request would not be sent
early but instead was transmitted with the next regular RTCP packet.
Add test for nack generation.
If the current time is equal to the early rtcp time deadline, there is
no need to schedule a timer. This ensure that immediate feedback is
really immediate and simplify implementing unit tests with the test
clock, which stops perfectly on the timeout time.
This fix has been extracted from Pexip feature patch called
"rtpsession: Allow instant transmission of RTCP packets"
When used in combination with a rtponviftimestamp element
downstream, forwarding this flag ensures it gets correctly
serialized in the ONVIF header extension.
A missing colon after G_DEFINE_TYPE declaration was confusing gst-indent
and causing problem in the pre-commit hook.
Add the missing colon and fix the following function declaration to
follow the normal GStreamer style.
One comments in gst_rtp_session_chain_send_rtp_common() is referring to
groups in a buffer list, however this concept of "group" comes from
GStreamer 0.10 and does not exist anymore in GStreamer 1.0, so update the
comment to refer to buffers instead.
The update_receiver_stats() function is called also when sending packets
in rtp_source_send_rtp(), and sending packets may happen using a buffer
list rather than individual buffers.
So update the stats using the actual number of packets sent.
NOTE: this is fine for the receive path too (rtp_process_send_rtp)
because the receive path does not support buffer lists and
pinfo->packets would always be equal to 1 in this case.
This is needed for the case you don't know in advance all the sessions
you will be using, but would like to place all the related AUX element
in the same GstBin. As per current implementation, each time an sender
AUX bin is requested and returned, RTPBin will walk the src pads and
create sessions for these pads.
In the current implementation, if a src pad already have a sessions, it
returns an error and stops. As a side effect, if an AUX bin is reused in
a following AUX bin request, it can only work if the pads are created on
the last request.
This change simply relax the restriction in order to keep walking, and
just ensure that all newly created pads have a sessions.
Need to respect return of gst_video_guess_framerate() to ensure
non-zero denominator.
This patch is to fix below error with an abnormal (but has valid frame) file.
(gst-play-1.0:17940): GStreamer-CRITICAL **: passed '0' as denominator for `GstFraction'
This problem was found in Test. 2 of the YouTube 2018 EME
tests[1]. The code was accidentally not finding an mp4a's esds atom in
the sample description table when the stream was encrypted. It assumed
that if the stream is protected, then only an enca atom will be found
here. What happens with YouTube is they often provide protected
content with a few seconds of clear content, and then switch to the
encrypted stream.
The failure case here was an incorrect codec_data field being sent
into aacparse. The advertisement of stereo audio @ 44.1kHz for the
mp4a (unprotected) stream was incorrect. As usual, the esds contained
the real values here which were mono at 22050 Hz.
Here's what the MP4 tree looks like for these types of files,
demonstrating why the code was making a wrong assumption (or maybe
YouTube is being unusual),
[ftyp] size=8+16
...
[moov] size=8+1571
...
[trak] size=8+559
...
[stsd] size=12+234
entry-count = 2
[enca] size=8+147
channel_count = 2
sample_size = 16
sample_rate = 44100
[esds] size=12+27
...
...
[mp4a] size=8+67
channel_count = 2
sample_size = 16
sample_rate = 44100
[esds] size=12+27
...
In addition to fixing this, the checks for esds atoms in mp4a and mp4v
have been made symmetrical. While I haven't seen a test case for video
with the same problem, it seemed better to make the same checks. This
also fixes a crash reported from another user[2], they also noted the
asymmetry with mp4v and mp4a.
[1] https://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/2018.html?test_type=encryptedmedia-test
[2] https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/398
This can happen in various error cases that could happen between the
creation of the element in question and the adding to the rtspsrc.
It causes an ugly critical warning right now but is otherwise harmless.
The imagefreeze element can be handy for benchmarking downstream
elements because it re-uses the same buffer memory and introduces less
overhead compared to always creating new frames with videotestsrc.
However it's not possible to make imagefreeze send EOS when using
gst-launch-1.0.
Add a num-buffers property to make it look more like a source in the
above scenario.
In commit 28e5f9098 (rtpbin: use PacketInfo for the sender, 2013-09-13)
the rtp_source_send_rtp signature changed but the documentation was not
adjusted to match the new one.
Update the documentation to match the function signature.
Some functions now accept a generic 'gpointer data' parameter because
they can work either on a single buffer or a buffer list.
However the comments were still referring to the old 'GstBuffer *buffer'
parameter, so update the comments to match the actual functions
signature.
So far we assumed that if all sources are bye, this meant we needed to
send an EOS on the RTCP sink. The problem is that this case may happens
if we only had one internal source and it detected a collision.
So now we limit the EOS forwarding to when there is a send_rtp_sink pad
and that this pad has received EOS. We don'tcheck the recv_rtp_sink
since the code does not wait for the bye to be send before sending EOS
to the RTCP src pad.
RF64 encode support was added to wavenc quite some time
ago, but not declared in wavparse. It seems wavparse can
decode it though, so add it to the sink pad.
The RF64 support was added in
https://bugzilla.gnome.org/show_bug.cgi?id=735627
This is useful when implementing custom retransmission mechanism like
RIST to prevent RTCP from being produces for the retransmitted SSRC.
This would also be used in general for various purpose when customizing
an RTP base pipeline.
If it goes over 2^15 packets, it will think it has rolled over
and start dropping all packets. So make sure the seqnum distance is not too big.
But let's not limit it to a number that is too small to avoid emptying it
needlessly if there is a spurious huge sequence number, let's allow at
least 10k packets in any case.
Recent changes in ccextractor were attaching timecode meta to the closed
caption track. We shouldn't write timecode information for the closed
caption trak.
And let it the oportunity to get its other pad linked
Example:
```
$ gst-launch-1.0 uridecodebin uri=file:///home/thiblahute/gst-validate.save/gst-integration-testsuites/testsuites/../medias/defaults/flv/819290236.flv caps=audio/x-raw expose-all-streams=FALSE ! fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstFlvDemux:flvdemux0: Internal data stream error.
Additional debug info:
../subprojects/gst-plugins-good/gst/flv/gstflvdemux.c(2760): gst_flv_demux_loop (): /GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstFlvDemux:flvdemux0:
streaming stopped, reason not-linked (-1)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
```
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, and this also
applies to the webm subset of the format.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/550
When multiple nals are aggrgated, the marker bit should be associated only
with the last NAL of the packet. Otherwise we may break rendering in with
AU alignment.
And also add a property for setting this. By default it has the same
value as the metadatacreator metadata.
Various software is using encoder instead of metadatacreator, others are
using them both for different purposes. As such it's useful to have
support for setting both here.
Blocking in change_state() is a recipe for disaster, even more so if
we wait for another thread that also calls into various element API and
could then lead to deadlocks on e.g. the state lock.
EA608 closed caption tracks are a bit special in that each sample
can contain CCs for multiple frames, and CCs can be omitted and have to
be inferred from the duration of the sample then.
As such we take the framerate from the (first) video track here for
CEA608 as there must be one CC byte pair for every video frame
according to the spec.
For CEA708 all is fine and there is one sample per frame.
The duration field being a uint64, is stored in 8 bytes, not 4. So the offset of
the following field, language code, needs to be updated accordingly so that the
parsed language code is not garbage.
The documentation of "port-range" implies that passing NULL should be
valid, but currently it is not. Without this check, the sscanf() call
will crash.
This reverts commit dcd3ce9751.
This functionality was implemented for gstopenwebrtc, but it
turned out this was not actually needed for webrtc bundling
support, as shown in webrtcbin. It also doesn't correspond
to any standards.
This is an API break, but nothing should actually depend on
this, at least not for its initial purpose.
Changes in rtpbin.c were reverted manually, to preserve some
refactoring that had occurred in the original commit.
Fixes#537
This macro is not longer used. It was secretly checking if that nal was
a slice, and confusingly name to that one may think it was checking if
the nal is an AUD.
The code was reading the timestamp from the adapter before pushing the
new buffer into it. As a side effect, if the adapter was empty, we'd end
up using an older timestamp. In alignment=au, it means that all
timestamp was likely one frame in the past, while in alignment=nal, with
multiple slices per frame, the first slice would have the timestamp of
the previous one.
The marker bit is used for efficient decoding. The assumption that
it should be set on the AUD is wrong, since the AUD is conceptually
starts the frame, while the marker is to indicate the end.
So properly set the marker bit as soon as we know we are ending an
AU and also whenever upstream have set the GST_BUFFER_FLAG_MARKER
flag.
The code was reading the timestamp from the adapter before pushing the
new buffer into it. As a side effect, if the adapter was empty, we'd end
up using an older timestamp. In alignment=au, it means that all
timestamp was likely one frame in the past, while in alignment=nal, with
multiple slices per frame, the first slice would have the timestamp of
the previous one.
The marker bit is used for efficient decoding. The assumption that
it should be set on the AUD is wrong, since the AUD is conceptually
starts the frame, while the marker is to indicate the end.
So properly set the marker bit as soon as we know we are ending an
AU and also whenever upstream have set the GST_BUFFER_FLAG_MARKER
flag.
Don't allow external encoder to use one of the reserved NAL type
implicated in NAL aggreation. These out-of-spec NAL types, if passed
from the outside world will lead to an invalid RTP payload being
created.
When the EOS event is received, run all timers immediately and avoid
pushing the EOS downstream before this has been run. This ensures that
the lost packet statistics are accurate.
After EOS is received, it is pointless to wait for further events,
specially waiting on timers. This patches fixes two cases where we could
wait instead of returning GST_FLOW_EOS and trigger a spin of the loop
function when EOS is queued, regardless if this EOS is the queue head or
not.
stream.segment should be updated with the values of the current edit
list, also when a new `moov` is received. Unfortunately this was not
being the case because of an early return.
As a consequence of this bugs, no end of movie clipping was being
performed on the new moov and no segment event was being emitted.
When performing stream switching (e.g. in MSE) the new moov may have a
different edit list. This is often the case when switching between
baseline H.264 (which lacks B-frames) and more demanding profiles. For
this reason it's important to emit a new segment in order to be able
to get matching stream times.
This patch moves the initialization of QtDemuxStream.segment from
gst_qtdemux_add_stream() to _create_stream(). This ensures the segment
is always initialized when the stream is created.
Otherwise the segment format is left as GST_FORMAT_UNDEFINED in the case
were a track is reparsed and qtdemux_reuse_and_configure_stream() is
called instead of gst_qtdemux_add_stream(). (See
qtdemux_expose_streams() in the non streams-aware case.)
This is an extra internal recurisve lock use to avoid having to take
both sink pad streams lock all the time. This patch renamed it
INTERLNAL_STREAM_LOCK/UNLOCK() to avoid confusion with possible upstream
GST_PAD API.
This reverts "6f3734c305 rtpssrcdemux: Only forward stick events while
holding the sinkpad stream lock" and actually hold on the internal
stream lock. This prevents in some needed case having a second
streaming thread poping in and messing up event ordering.
While forwarding serialized event, we use gst_pad_forward() function.
In the forward callback (GstPadForwardFunction) we always return
TRUE. Returning true there will stop the dispatching procedure. As a
side effect, only one events is receiving the events. This breaks
when sending EOS from the applicaiton, it also breaks the latency
tracer.
This patch enables matroskademux to receive seeks before it reaches
GST_MATROSKA_READ_STATE_DATA.
Closes https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/514
This also enables receiving seeks in the element READY state.
When such a seek is received, it is stored to be later handled when
GST_MATROSKA_READ_STATE_DATA is reached.
Reset RTPSession when rtpsession changes state from PAUSED to READY.
Without this change, a stored last_rtptime in RTPSource could interfere
with RTP timestamp generation in RTCP Sender Report.
Fixes#510
If ctts (CompositionOffsetBox) has larger sample_offset
(offset between PTS and DTS) than (2 * duration) of the stream,
assume the ctts box to be corrupted and ignore the box.
https://bugzilla.gnome.org/show_bug.cgi?id=797262
This fixes a bug where in some files mehd.fragment_duration is one unit
less than the actual duration of the fragmented movie, as explained below:
mehd.fragment_duration is computed by scaling the end timestamp of
the last frame of the movie in (in nanoseconds) by the movie timescale.
In some situations, the end timestamp is innacurate due to lossy conversion to
fixed point required by GstBuffer upstream.
Take for instance a movie with 3 frames at exactly 3 fps.
$ gst-launch-1.0 -v videotestsrc num-buffers=3 \
! video/x-raw, framerate="(fraction)3/1" \
! x264enc \
! fakesink silent=false
dts: 999:59:59.333333334, pts: 1000:00:00.000000000, duration: 0:00:00.333333333
dts: 999:59:59.666666667, pts: 1000:00:00.666666666, duration: 0:00:00.333333334
dts: 1000:00:00.000000000, pts: 1000:00:00.333333333, duration: 0:00:00.333333333
The end timestamp is calculated by qtmux in this way:
end timestamp = last frame DTS + last frame DUR - first frame DTS =
= 1000:00:00.000000000 + 0:00:00.333333333 - 999:59:59.333333334 =
= 0:00:00.999999999
qtmux needs to round this timestamp to the declared movie timescale, which can
ameliorate this distortion, but it's important that round-neareast is used;
otherwise it would backfire badly.
Take for example a movie with a timescale of 30 units/s.
0.999999999 s * 30 units/s = 29.999999970 units
A round-floor (as it was done before this patch) would set fragment_duration to
29 units, amplifying the original distorsion from 1 nanosecond up to 33
milliseconds less than the correct value. The greatest distortion would occur
in the case where timescale = framerate, where an entire frame duration would
be subtracted.
Also, rounding is added to tkhd duration computation too, which
potentially has the same problem.
https://bugzilla.gnome.org/show_bug.cgi?id=793959
... before the old streams is not exposed yet for MSS stream.
In case of DASH, newly configured streams will be exposed
whenever demux got moov without delay.
Meanwhile, since there is no moov box in MSS stream,
the caps will act like moov. Then, there is delay for exposing new pads
until demux got the first moof.
So, following scenario is possible only for MSS but not for DASH,
STREAM-START -> CAPS -> (configure stream but NOT EXPOSED YET)
-> STREAM-START-> CAPS (configure stream again).
In above scenario, we can reuse old stream without any stream reconfigure.
https://bugzilla.gnome.org/show_bug.cgi?id=797239
Apart from the obvious drawbacks of hardcoding, the drawback here was
that, if we subtracted 2 frames (instead of 2.6) from the target running
time, we'd request the next keyframe a bit too far into the future,
which would make our files split at the wrong position.
https://bugzilla.gnome.org/show_bug.cgi?id=797293
Flv does not support various channels in AAC stream format, for example
flvdemux detect an audio channels of 2(stereo) when the AAC really is 1(mono).
https://bugzilla.gnome.org/show_bug.cgi?id=797275
Flv does support changing the stream type and stream properties
after the headers were started to be written, and for example H264
codec_data changes can be supported.
https://bugzilla.gnome.org/show_bug.cgi?id=797256
For drop-frame framerates, when the expected next max timecode wraps
around at the end of the day, we have to subtract the offset of the
daily jam, otherwise we end up with a duration that's a few frames too
long.
https://bugzilla.gnome.org/show_bug.cgi?id=797270
This commit:
1. Reads the WebM and Matroska ContentEncryption subelements.
2. Creates a GST_PROTECTION event for each ContentEncryption, which
will be sent before pushing the first source buffer.
The DRM system id field in this event is set to GST_PROTECTION_UNSPECIFIED_SYSTEM_ID,
because it isn't specified neither by Matroska nor by the WebM spec.
3. Reads the protection information of encrypted Block/SimpleBlock and
extracts the IV and the partitioning format (subsamples).
4. Creates the metadata protection for each encrypted Block/SimpleBlock,
with those informations: KeyID (extracted from ContentEncryption element),
IV and partitioning format.
5. Adds a new caps for WebM encrypted content named "application/x-webm-enc",
with the following new fields:
"encryption-algorithm": The encryption algorithm used.
values: "None", "DES", "3DES", "Twofish", "Blowfish", "AES".
"encoding-scope": The field that describes which Elements have been modified.
Values: "frame", "codec-data", "next-content".
"cipher-mode": The cipher mode used in the encryption.
Values: "None", "CTR".
https://bugzilla.gnome.org/show_bug.cgi?id=765275
Strip ADTS headers if we detect any, apparently some Sony cameras
send AAC with ADTS headers. We could also change the stream-format
in the output caps, but that would be unexpected to pipeline builders
and would not exactly be backwards compatible.
qtdemux_update_streams() is only ever called after checking
`qtdemux->streams_aware` is TRUE. There is no need to check for that
condition again.
`qtdemux->streams_aware` is only modified when the demuxer is
hard-resetted, which is mutually exclusive with demuxing, so it cannot
be modified during the call.
https://bugzilla.gnome.org/show_bug.cgi?id=797191
Currently matroskademux does not emit no-more-pads until the first
Cluster is parsed, even though the Tracks have already been parsed and
from that point on there can be no more tracks.
This is important in MSE because the browser needs to know when the MSE
initialization segment has been completely parsed so that it can expose
the tracks to the user. Some applications depend on this been done
before they feed frames to the demuxer.
As a consequence, historically WebKit has relied on hacks such as
listening to the `pad-added` event, which made impossible to support
multiple tracks in the same file. Let's fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=797187
This patch allows matroskademux to parse a second Tracks element,
erroring out if the tracks are not compatible (different number, type or
codec) and emitting new caps and tag events should they have changed.
https://bugzilla.gnome.org/show_bug.cgi?id=793333
This splits gst_matroska_demux_add_stream() into:
* gst_matroska_demux_parse_stream(): will read the Matroska bytestream
and fill a GstMatroskaTrackContext.
* gst_matroska_demux_parse_tracks(): will check there are no repeated
tracks.
* gst_matroska_demux_add_stream(): creates and sets up the pad for the
track.
https://bugzilla.gnome.org/show_bug.cgi?id=793333
This is necessary for MSE, where a new MSE initialization segment may be
appended at any point. These MSE initialization segments consist of an
entire WebM file until the first Cluster element (not included). [1]
Note that track definitions are ignored on successive headers, they must
match, but this is not checked by matroskademux (look for
`(!demux->tracks_parsed)` in the code).
Source pads are not altered when the new headers are read.
This patch has been splitted from the original patch from eocanha in [2].
[1] https://www.w3.org/TR/mse-byte-stream-format-webm/
[2] https://bug334082.bugzilla-attachments.gnome.org/attachment.cgi?id=362212https://bugzilla.gnome.org/show_bug.cgi?id=793333
The behaviour of split-now is to output the current GOP after
starting a new file.
The newly-added split-after signal will output the current GOP
to the old file if possible once a new GOP is opened.
https://bugzilla.gnome.org/show_bug.cgi?id=796982
For 59.94 FPS, it's common to set 60000 as timescale. For that
timescale, if the audio is late by as little as 0:00:00.000016666
(definitely less than one audio sample), lateness gets rounded to 1.
Added a safeguard that allows lateness up to 1 sample with the specific
trak's timescale, to make sure that values less than e.g. one audio
sample won't break the prefill mode. What will happen in this case is
that the audio will get squeezed back to the video's timestamp, which in
practice means that the audio will be 0.000016666 seconds early (with
the patch).
https://bugzilla.gnome.org/show_bug.cgi?id=797133
Accept wavpack correction streams (.wvc) on sink pad, so
that wavpackparse can also be used to packetise correction
streams.
Fix parsing of subblock ID tags - the higher bits are
flags and are not part of the ID. This resulted in
correction blocks not being recognised properly and
the output not having the right (correction) caps.
Currently, whenever we generate a 128-bit UID, we store it in a list and
return 0 if we ever encounter a collision. This is so mathematically
improbable that it's not worth checking for, so we can save memory and
time by not tracking the UID. Even if a collision happened, a list of
only 10 UIDs would be unlikely to detect it.
This article has a good description of how improbable a collision is:
https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisionshttps://bugzilla.gnome.org/show_bug.cgi?id=797086
This patch clears the sample table whenever the demuxing of a new
fragment begins. This avoids increasing memory usage for long videos.
This behavior was already present when upstream_format_is_time; this
patch extends it to all push mode operation (e.g. Media Source
Extensions).
https://bugzilla.gnome.org/show_bug.cgi?id=796899
Both rtpmp4vpay and rtpmp4gpay support MPEG4 elementary streams. But
the most supported variant is the video-specific one (rtpmp4vpay),
therefore increase the rank of that one so that auto-plugging of
payloaders for MPEG4 elementary streams ends up picking that one
and not the generic one.
If we have cluster prev size (GStreamer muxer will write it by default),
we can go back to the previous cluster efficiently, but if we don't then
just search backwards until we find a cluster ebml identifier, like we
do when searching for clusters in the bisection loop.
Add property instead of hardcoding it in the code.
In some scenarios such as CCTV variable fps and extra long GOPs are
used to minimise storage space, for example. In those cases there might
not be any keyframes for many minutes, so provide a property to override
the max allowed distance.
https://bugzilla.gnome.org/show_bug.cgi?id=790696
When seeking in pull mode without an index (because there is no index
or the file is still being written to) we bisect to find the right
cluster to jump to. However, it's possible the cluster we found doesn't
start with a keyframe, which leads to decoding errors, so if we know
that the found cluster starts with a delta frame try to scan back to
previous clusters until we find one that starts with a keyframe or
we are back at the beginning. Theoretically it's possible that all
clusters but the first one do not start with a keyframe and the
keyframes are in the middle of clusters, but this is extremely
unusual, so we will cover this case with a basic sanity check.
This problem is especially problematic with content recorded with
dynamic GOP and FPS, where long GOP lengths and low FPS may cause a
large set of clusters to lack key frames. Playback would then be
started on a non-keyframe cluster, and the large number of such frames
would make the content impossible to decode fo a long stretch of time.
Based on patch by: Mats Lindestam <matslm@axis.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790696
This is useful for reverse playback/trickmodes
without an index, and will also be useful in the
seek handler if we need to scan back to find a cluster
that starts with a keyframe.
https://bugzilla.gnome.org/show_bug.cgi?id=790696
This is an enum not a boolean, and a value of 2 signals
that the video is progressive, but we would mistakenly set
interlace-mode=mixed on the output caps.
https://bugzilla.gnome.org/show_bug.cgi?id=787206
On Linux, the kernel returns twice the size as it will allocate extra
space for accouting. We devides this value by two in order to ensure
that get/set value now match. This fixes the set buffer size validation
and allow having a nice warning when the size if surpassed and the
process does not have CAP_NET_ADMIN capabilities.
https://bugzilla.gnome.org/show_bug.cgi?id=727067
The udp buffer size is limited to a maximum of around 100K.
Some apps need to set the force bufsize for their own operation.
Use the SO_RCVBUFFORCE option in order to override the rmem_max limit
of linux kernel. Require user to have the CAP_NET_ADMIN privilege to
work.
Original patch from Kyungnam Bae <kyungnam.bae@lge.com>
https://bugzilla.gnome.org/show_bug.cgi?id=727067
rtph264pay and rtph265pay skip updating the parameter set timestamp if
the units they see contain no new configuration. This can result in
them injecting duplicate parameters.
https://bugzilla.gnome.org/show_bug.cgi?id=796748
The stream context was holding a reference to the
internal queue and pads, with pad probes that were
in turn holding references to the stream context.
This lead to a leak if the request pads weren't explicitly
released.
https://bugzilla.gnome.org/show_bug.cgi?id=796893
All these were copy pasted and would lead to assertion when chained with
rtpmux. This commit rewrite the negotiation with downstream. This also
drop the fallback to ancient names if the pad is unlinked. This was
completly arbitrary decision that made no sense.
https://bugzilla.gnome.org/show_bug.cgi?id=796809
Pass through closed caption data when deinterlacing. When two
deinterlaced frames are created for the same interlaced frame (e.g.
fields=all), the second of the two frames will have no closed caption
data.
Also fixed memory leaks related to timecode meta pass-through.
https://bugzilla.gnome.org/show_bug.cgi?id=796876
This causes rtspsrc to send a teardown and wait on
PAUSED->READY transition, with a configurable delay.
Otherwise, typically teardown never gets sent in
playbin / uridecodebin where the transition back to NULL
happens too quickly.
The timeout is set to 100ms default.
https://bugzilla.gnome.org/show_bug.cgi?id=751994
Just remove the code. It's not doing anything useful anyways. The modified
caps are the result of a caps query, so either not used afterwards of a
reference to some internal caps of another element that should not be
modified.
https://bugzilla.gnome.org/show_bug.cgi?id=796837
When it is trivial to pass-through a timecode, by only removing the
"interlaced" flag, do pass-through. Otherwise, double the fps_n and
adjust the "frames" field.
https://bugzilla.gnome.org/show_bug.cgi?id=796818
When handling input with timestamps that repeat, sometimes
splitmuxsink would get confused and ignore a keyframe.
The logic in question is a holdover from before the cmd queue
moved the file cutting to the multiqueue output side and made
it deterministic, so it's no longer needed on the input
here.
https://bugzilla.gnome.org/show_bug.cgi?id=796773
This reverts commit 3ac5430311.
There's no need to make a freshly created event writable,
and the other half of this patch was already fixed
and pushed in f2f15a1
Always wait with starting the RTCP thread until either a RTP or RTCP
packet is sent or received. Special handling is needed to make sure the
RTCP thread is started when requesting an early RTCP packet.
We want to wait with starting the RTCP thread until it's needed in order
to not send RTCP packets for an inactive source.
https://bugzilla.gnome.org/show_bug.cgi?id=795139
* When receiving a segment in TIME, use that seqnum
* Only reset the stored sequence number when doing HARD reset
(and not when we get a FLUSH event from upstream)
This patch aims at fixing the recent regressions in the adaptive test
suite.
All segment pushing in push mode is now done with
gst_qtdemux_check_send_pending_segment(), which is idempotent and
handles both edit lists cases and cases where the upstream TIME segments
have to be sent directly.
Fragmented files that start with a non-zero tfdt are also taken into
account, but their handling has been vastly simplified: now they are
handled as implicit default seeks so there is no need to extend the
GstSegment formulas as was being done before.
qtdemux->segment.duration is no longer modified when
upstream_format_is_time, respecting in this way the durations provided
by dashdemux and fixing bugs in reverse playback tests where mangled
durations appeared in the emitted segments.
https://bugzilla.gnome.org/show_bug.cgi?id=752603
Upstream driving elements such as dashdemux often do reverse playback by
feeding qtdemux with the fragments containing the requested playback
range in reverse order.
But the requested playback range stop may be somewhere in the
middle of a fragment. In that case, a naive pts >= segment.stop
condition may declare end of segment prematurely when demuxing this
first fragment.
This used not to happen because there were places in moov parsing where
segment.stop was overwritten to GST_CLOCK_TIME_NONE even if
upstream_format_is_time -- resulting in this case in a segment with rate
< 0 and stop == -1 and hence not triggering the EOS check, but that was
likely an accident.
This patch modifies the EOS check to take this case into account, not
sending EOS when upstream_format_is_time if rate < 0.
This fixes adaptive.dash.playback.seek_end_live.DASHIF_livestream_testpic_2s
https://bugzilla.gnome.org/show_bug.cgi?id=752603
Sample table based segment event (genereted by qtdemux) could break
presentation timeline. For example, qtdemux should not modify upstream
time format segment (e.g., adaptivedemux use case)
https://bugzilla.gnome.org/show_bug.cgi?id=796480
This field is actually only informatory and the user can potentially
choose something else. EME tests in WebKit testsuite actually doesn't
take it into and force another encryption system to be used, and expects
to be given the occasion to do so.
This basically also reverts 3e063703b3.
Instead of always keeping a safe segment (start=0) event from the beginning,
delay the creation of this event to when we really know the timestamp of the
first sample. This is important to properly start fragmented streams that
we might join in the middle or to play isolated fragment files that might
have an advanced tfdt.
https://bugzilla.gnome.org/show_bug.cgi?id=752603
Fragmented files often use elst.duration=0 which before
ee78825eae was wrongly interpreted as
having no frames.
Since that issue has now been fixed, there is no reason to disable edit
lists in fragmented files. This commit enables them, therefore producing
correct stream time for files containing edit lists.
https://bugzilla.gnome.org/show_bug.cgi?id=793058
Since ca068865c3 the duration of the first
frame is not used for estimating the frame rate.
For this purpose, stream->first_duration was initialized with the
duration of the first frame. In fragmented files, this was previously
done by peeking the first moof, but that can only be done in pull mode.
Fortunately, we don't really need to do that, at least with the current
design: When we are estimating the frame rate we already have the
sample table, regardless of the scheduling mode and whether the file is
fragmented or not, so we can obtain first_duration there much more
reliably.
This fixes frame rate estimation for fragmented files in push mode.
https://bugzilla.gnome.org/show_bug.cgi?id=796384
This mode is useful for muxers that can take a long time to finalize a
file. Instead of blocking the whole upstream pipeline while the muxer is
doing its stuff, we can unlink it and spawn a new muxer+sink combination
to continue running normally.
This requires us to receive the muxer and sink (if needed) as factories,
optionally accompanied by their respective properties structures. Also
added the muxer-added and sink-added signals, in case custom code has to
be called for them.
https://bugzilla.gnome.org/show_bug.cgi?id=783754
This is a straightforward translation of 5dd39d8, can be trivially
checked by running:
gst-launch-1.0 -v videotestsrc ! video/x-raw, colorimetry=2:4:7:1 ! \
matroskamux ! matroskademux ! fakesink
and verifying that the colorimetry is correctly preserved.
https://bugzilla.gnome.org/show_bug.cgi?id=796344
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.
