1) pt can be lower than 96
2) there is no point in checking that because rtprtxsend will not
even store buffers for payload types that it doesn't know about,
so this case will never be reached
This patch moves the creation of rtx packets to be done early,
in the src_event() function, when they are requested. The purpose
is to run gst_rtp_rtx_buffer_new() with the object locked to
protect internal data, because if it is done at the pushing stage,
we would have to lock and unlock multiple times in a row while we
are pushing the rtx buffers.
Previously there was no locking at all, which was terribly wrong.
According to ISO/IEC 13818-7, "channel_config" field in ADTS header
may have value of 0, as in the case of frame with PCE.
gst_aac_parse_detect_streams() returned FALSE for those frames
and discarded them.
The need for rewriting apparently is obsolete 0.10 leftover.
We now have caps for subtitles when we create the headers,
so we always write the correct data in the first place.
This avoids issues with writing dummy data first, then having
to come back and write correct data later. Doing so prevents
the muxed stream from being actually streamable.
https://bugzilla.gnome.org/show_bug.cgi?id=712134
Mov spec says it uses a pascal style string, while isomedia uses
a null terminated one. Store the current atoms flavor into the HDLR
to be able to generate the correct output.
https://bugzilla.gnome.org/show_bug.cgi?id=705982
This reverts commit b3aa8755fe.
We are already using the running-time because they were placed on the
buffers with gst_collect_pads_clip_running_time(). Arguably it would be
better to not modify the incomming buffers but collectpads seems to want
to use absolute timestamps from the buffers for finding the best buffer
(this can be changed with a custom compare function..).
This property allows you to specify the amount of buffers
to keep in the retransmission queue expressed as time (ms)
instead of buffer count (which is the max_size_buffers property).
The purpose of the sender RTX object is to keep a history
of RTP packets up to a configurable limit (in time). It will
listen for custom retransmission events from downstream. When
it receives a request for retransmission, it will look up the
requested seqnum in its list of stored packets. If the packet
is available, it will create a RTX packet according to RFC 4588
and send this as an auxiliary stream.
The receiver will listen to the custom retransmission events
from the downstream jitterbuffer and will remember the SSRC1
of the stream and seqnum that was requested. When it sees a
packet with one of the stored seqnum, it associates the SSRC2
of the stream with the SSRC1 of the master stream. From then
on it knows that SSRC2 is the retransmission stream of SSRC1.
This algorithm is stated in RFC 4588. For this algorithm to
work, RFC4588 also states that no two pending retransmission
requests can exist for the same seqnum and different SSRCs or
else it would be impossible to associate the retransmission with
the original requester SSRC.
When the RTX receiver has associated the retransmission packets,
it can depayload and forward them to the source pad of the element.
RTX is SSRC-multiplexed
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=711084
