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.
