As streams now flow independently, the GstSegment needs to be put
on each stream so they can track the position of each one correctly
instead of being mixed in a single segment
Download and push from the same task, makes code a lot simpler
to maintain. Also pushing from separate threads avoids deadlocking
when gst_pad_push blocks due to downstream queues being full
When a stream gets a not-linked return, it will be marked as so and
won't download any more new fragments until a reconfigure event
is received. This will make mssdemux expose all pads, but only download
fragments for the streams that are actually being used.
Relying on the pads being linked/unlinked isn't enough in this scenario
as there might be an input-selector downstream that is actually discarding
buffers for a given linked pad.
When streams are switching, the old active stream can be blocked because
input-selector will block not-linked streams. In case the mssdemux's
stream loop is blocked pushing a buffer to a full queue downstream it will
never unblock as the queue will not drain (input-selector is blocking).
In this scenario, stream switching will deadlock as input-selector is
waiting for the newly active stream data and the stream_loop that would
push this data is blocked waiting for input-selector.
To solve this issue, whenever an stream is reactivated on a reconfigure
it will enter into the 'catch up mode', in this mode it can push buffers
from its download thread until it reaches the currrent GstSegment's position.
This works because this timestamp will always be behind or equal to the maximum
timestamp pushed for all streams, after pushing data for this timestamp,
the stream will go back to default and be pushed sequentially from the main
streaming thread. By this time, the input-selector should have already
released the thread.
https://bugzilla.gnome.org/show_bug.cgi?id=711849
As it does not inherit from basesrc, this flag is not automatically set
and e.g. gst_bin_iterate_sources() and other code does not consider this
element a source.
https://bugzilla.gnome.org/show_bug.cgi?id=680700
The parser assumes that every time there is a 0 before the startcode,
it is part of the startcode. But that's not true.
From the specification
Byte stream NAL unit syntax
zero_byte is a single byte equal to 0x00.
When any of the following conditions are fulfilled, the zero_byte syntax
element shall be present.
– the nal_unit_type within the nal_unit( ) is equal to 7 (sequence parameter
set) or 8 (picture parameter set)
– the byte stream NAL unit syntax structure contains the first NAL unit of an
access unit in decoding order, as specified by subclause 7.4.1.2.3.
The problem with doing this for all startcodes is that a trailing zero can mess
up timestamps. The trailing zero gets prepended to the startcode, which will
carry the PTS and DTS of previous buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=664443
From ETSI EN 300 743 V1.3.1 (2006-11) 7.2.1 Display definition segment specifictations
the parameters of display window are in this order: Xmin, Xmax, Ymin, Ymax.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: Pierre-Yves Mordret <pierre-yves.mordret@st.com>
https://bugzilla.gnome.org/show_bug.cgi?id=720382
* ext/srtp/gstsrtp.[ch]: added GST_SRTP_CIPHER_AES_256_ICM to
GstSrtpCipherType and new function cipher_key_size.
* ext/srtp/gstsrtpenc.c: maximum key size is now 46 characters (14 for
the salt plus the key). If different ciphers are chosen for RTP and
RTCP the maximum needed key size is expected.
* ext/srtp/gstsrtpdec.c: minor documentation updates.
https://bugzilla.gnome.org/show_bug.cgi?id=720434
Set reorder_queue_frame_delay from the DPB size (in frames). Still not optimal,
as the DPB size is larger than the max bframe forward prediction length, but I
don't know how to compute the latter without parsing every group of pictures.
