This might be necessary temporarily for changing the previous settings.
Make it an actual error if the settings are like this while processing a
buffer.
It is parsing frame data and so should check the data size against the
frame header size instead of the file header size. If don't, it is
possible to drop the last frame because IVF_FILE_HEADER_SIZE is greater
than IVF_FRAME_HEADER_SIZE
This patchs add support for configuring the bonding method used. There is
two method specified
- redundant: All the RTP packets are replicated
- combined: RTP packet are evenly distributed over each links
Additionally, an application can set the "dispatcher" property in order
to implement custom dispatching method. Whenever the "dispatcher"
property is set, "bonding-method" property will be ignored.
As we can now have multiple sessions, stats need to be implemented per
session. This follow RTPSession model with sources. The stats are now:
dropped: 0
received: 0
recovered: 0
permanently-lost: 0
duplicates: 0
retransmission-requests-sent: 0
rtx-roundtrip-time: 0
session-stats:
session-id=0
rtp-from=""
rtcp-from=""
dropped=0
received=0
session-id=1
rtp-from=""
rtcp-from=""
dropped=0
received=0
. . .
session-stats is a GValueArray as there is no better alternatives.
As we can now have multiple sessions, stats need to be implemented per
session. This follow RTPSession model with sources. The stats are now:
sent-original-packets: 0
sent-retransmitted-packets: 0
session-stats:
session-id=0
sent-original-packets=0
sent-retransmitted-packets=0
round-trip-time=0
session-id=1
sent-original-packets=0
sent-retransmitted-packets=0
round-trip-time=0
. . .
session-stats is a GValueArray as there is no better alternatives.
gstmpegtsmux.c:291:3: error: implicit declaration of function ‘memmove’ [-Werror=implicit-function-declaration]
memmove (map.data + 4, map.data, map.size - 4);
^
gstmpegtsmux.c:291:3: error: incompatible implicit declaration of built-in function ‘memmove’ [-Werror]
gstmpegtsmux.c:291:3: note: include ‘<string.h>’ or provide a declaration of ‘memmove’
... and set to caps if necessary.
Note 1) the mastering display info and content light level SEI meessages
are persistent in the corresponding codec video sequence (i.e., GOP).
So any bitstream containing those SEI messages
(and also all pictures are intended to be HDR rendered) should be ensured that
each first slice of codec video sequence follows those SEI messages.
Note 2) The codec video sequence is a group an [IRAP + NoRaslOutputFlag == 1]
and following AUs which are not [IRAP + NoRaslOutputFlag == 1]
The NoRaslOutputFlag is equal to 1 for each IDR AU, BLA AU and some CRA AU.
For a CRA AU to have NoRaslOutputFlag equal to 1, following condition should required.
* When the CRA AU is the first AU in the bitstream in decoding order
* or the CRA AU is the first AU that follows an end of sequence NAL in decoding order
* or the HandleCraAsBlaFlag equal to 1.
Due to the limited context in parse element, in this commint, CRA AU will not considered as
having the NoRaslOutputFlag equal to 1. Therefore, in the worst case,
mastering-display-info and content-light-level could be cleared one GOP after
when stream was chagned from HDR to SDR.
RIST TR-06-1 is a specification for video streaming made by the VSF
group. It is using a subset of RTP specification to which some
modification has been made to improve RTX behaviour and avoid any need
for signaling. The plugin implement ristrtxsend / ristrtxreceive element
which are the RIST specific equivalent of rtprtxsend/rtprtxreceive and
ristsink / ristsrc which implement rist transmitter and receiver. The
RIST protocol is meant to be used in unidirectional way. Typically, MPEG
TS over RTP is used.
Currently we support unicast and multicast streaming according to the
specification. This patch does not include any bonding support yet. The
ristsrc element introduce rist:// URI handling in parallel to it's
property configuration interface.
Expose SEI data in the H.264 bitstream parser API and
extract closed captions and other things that are not
specified in the H.264 spec itself in the videoparser.
Based on patch by: Mathieu Duponchelle <mathieu@centricular.com>
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/940
when computing timecode metas. Depending on the value of that flag,
n_frames is to be interpreted as a number of fields or a number of
frames. As GstVideoTimeCodeMeta always deals with frames, we want
to scale that number when needed.
