Assignment is done to variable segment.stop when the intention was to assign to
local variable stop. Instead of overwriting it, the value is now clamped and
segment.stop is set to it soon after.
CID #1265773
Handle the case where a short file reaches EOS while we're still
waiting for no-more-pads, and make sure we continue to the internal
READY state for real playback to work properly later.
Implement 2 new elements - splitmuxsink and splitmuxsrc.
splitmuxsink is a bin which wraps a muxer and takes 1 video stream,
plus audio/subtitle streams, and starts a new file
whenever necessary to avoid overrunning a threshold of either bytes
or time. New files are started at a keyframe, and corresponding audio
and subtitle streams are split at packet boundaries to match
video GOP timestamps.
splitmuxsrc is a corresponding source element which handles
the splitmux:// URL and plays back all component files,
reconstructing the original elementary streams as it goes.
We detect a container correctly now so we need to revert the weird
check there was before.
Use gst_rtspsrc_stream_push_event() to push the caps event on the
right pad.
See https://bugzilla.gnome.org/show_bug.cgi?id=739391
Keep global and stream tags separately and parse the udta node
that can be found under the trak atom. The udta will contain
stream specific tags and will be pushed as such
https://bugzilla.gnome.org/show_bug.cgi?id=692473
Tags received via events, when marked as stream tags, will
be stored on that stream's trak atom instead of being stored
in the main tags atom. This allows the resulting file to have
global and stream tags stored.
https://bugzilla.gnome.org/show_bug.cgi?id=692473
Refactor the functions that were bound to the 'moov' atom to
directly pass the desired 'udta' that should receive the tags.
This allows the tags to be written to 'udta' at the 'moov' or
the 'trak' level, creating tags that are for the container or
for a stream only.
https://bugzilla.gnome.org/show_bug.cgi?id=692473
Snap to the end of the file when seeking past the end in reverse mode,
and also fix GST_SEEK_TYPE_END and GST_SEEK_TYPE_NONE handling
for the stop position by always seeking on a segment in stream time
This will be emitted whenever an RTCP packet is received. Different to
on-feedback-rtcp, this signal gets every complete RTCP packet and not
just the individual feedback packets.
For fragmented streams with extra data at the end of the mdat
qtdemux was not dropping those bytes and would try to use
that extra data as the beginning of a new atom, causing the
stream to fail.
https://bugzilla.gnome.org/show_bug.cgi?id=743407
It had no effect since quite some time and also is not needed in general,
especially not to switch between immediate feedback mode and early feedback
mode. The latest understanding of the RFC is that from the endpoint point of
view, both modes are exactly the same. RTCP is only allowed to use the
bandwidth as given by the RFC constraints, as such it is only ever possible
to schedule a RTCP packet early but it's against the RFC to schedule more RTCP
packets.
The difference between immediate feedback mode and early feedback mode is that
the former guarantees that an RTCP packet can be sent for every event
"immediately", which means that the bandwidth calculations from the RFC have
resulted in an RTCP scheduling interval that is small enough. Early feedback
mode on the other hand means that we can schedule some packets early to make
that happen, but it's not guaranteed at all that it's possible to schedule
an RTCP packet per event (i.e. they need to be accumulated or dropped).
This indicates with a boolean return value if scheduling a new RTCP packet
within the requested delay was possible. Otherwise it behaves exactly like
send-rtcp. The only reason for adding a new signal is ABI compatibility.
No matter if gst_matroska_read_common_parse_index_cuetrack () returns that the
flow is OK or not, the check there will be a break from the switch. Removing the
check since the outcome is the same.
CID #1265762
Bringing back the check removed in the previous commit but have that check be a
g_assert. Changing the function to static void since return can never be False,
because audio format will never be unkown.
func_index is set by the sum of three ternary operators which add, 0:4, 0:2,
and 1:0. Minimum value would be 0+0+0=0, and maximum would be 4+2+1=7.
The conditional checking if func_index is >= 0 and < 8 will always be true.
Removing it.
CID 1226442
We (currently?) can't really handle gaps between RTP packets if they're not
properly timestamped. The current code would go into calculations with
GST_CLOCK_TIME_NONE and then cause assertions everywhere. It's probably
better to error out cleanly instead.
We set to PLAYING after we have configured the caps, otherwise we
might end up calling request_key (with SRTP) while caps are still
being configured, ending in a crash.
https://bugzilla.gnome.org/show_bug.cgi?id=740505
Actually copy the codec data instead of copying nothing
and then bombing out because there's no data.
Fixes: gst-launch-1.0 audiotestsrc ! avenc_alac ! qtmux ! fakesink
https://bugzilla.gnome.org/show_bug.cgi?id=741783
Apparently linphone sends an invalid RTP packet as very
first packet. We want to ignore that instead of erroring
out (same for any other invalid packets really).
https://bugzilla.gnome.org/show_bug.cgi?id=741398
Instead of constantly querying upstream, just cache the last duration,
and in the unlikelyness we might have gone over query again before
deciding we are EOS.
Cut 15% cpu off matroskademux streaming thread (srsly...)
This is meant to be so (https://wiki.xiph.org/MatroskaOpus - while
it is marked as a draft, this part was confirmed to be correct on
IRC), and allows one to determine whether a demuxed stream is
multistream or not, and thus set the multistream caps field
accordingly. In turn, this means downstream does not have to guess.
https://bugzilla.gnome.org/show_bug.cgi?id=740744
It's like rendering a buffer list, just with one buffer.
Has the added advantage that if there are multiple clients
we can send the buffer to all the clients in one go.
We unlock and re-lock the client lock while emitting the
removed signal, which causes inconsistencies in the client
list vs. the client counts. Instead, remove the client from
the list already before emitting the signal and put it into
a temporary list of clients to be removed. That way things
look consistent to the streaming thread, but signal callbacks
can still do things like get stats from removed clients.
Add prototype for a render_list() function that can use a
sendmmsg-style g_socket_send_messages() function once it lands
in GLib. We can use this infrastructure to send multiple buffers
made up by multiple memories to multiple clients in one go, which
drastically reduces the number of syscalls made when sending
high-bitrate video streams.
https://bugzilla.gnome.org/show_bug.cgi?id=732152
Use the refcount for memory management and keep track
of the number of duplicate clients in a separate
variable. This will be useful later, and means we
don't have to hold the OBJECT_LOCK all the time.
https://bugzilla.gnome.org/show_bug.cgi?id=732866
Since "basetransform: Fix caps equality check" commit a7f357,
set_info() will not be called anymore if crop didn't change
the caps. This is fixed by setting "need_update" boolean when
cropping properties has been changed, and then applying these
if they where not applied before rendering the next frame. This
patch also fixed the locking, dropping un-needed custom lock,
and no holding needless lock while doing the operation as we
already hold the streaming lock.
https://bugzilla.gnome.org/show_bug.cgi?id=740787
In some cases the currently set GstVideoInfo is not interlaced, but
upstream caps are interlaced and the info is passed in the filter,
we should take that info into account and make sure that we do not
consider that case as a "pass through" case.
https://bugzilla.gnome.org/show_bug.cgi?id=741407
A race condition in the state change function may cause buffers
to be unreffed while they are still used by the streaming thread
in gst_rtp_h264_pay_send_sps_pps() resulting in a crash. Chain
up to the parent class first in the state change function to
make sure streaming has stopped and only then free those buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=741381
When dealing with fragmented files, we will get more accurate duration
information via the mfra and moof atoms.
In order for playback to not stop at the initial duration (from the
moov atom), we need to check and update the various duration variables
when we find more information.
Fixes playback of fragmented files in pull mode
Adds a new set of properties to make pushfilesrc output a TIME SEGMENT
(instead of the filesrc BYTE SEGMENT).
When time-segment is set to True the following will happen:
* Seeks are refused (data starts from the beginning of the file)
* The BYTE segment will be replaced by a TIME segment with the values
specified in the various properties
* The first outgoing buffer will have a timestamp set on it (by default
it has a value of GST_CLOCK_TIME_NONE)
When seeking or finding the previous keyframe, do
comparisons against targets and segments using composition time
to correctly decide which sample times match.
We used to setup an iterator with 1 GValue set with a NULL object
pointer which is not the normal way to do that. Instead we should make
sure that the first call to gst_iterator_next returns GST_ITERATOR_DONE.
Currently during header parsing, we scan through the entire file
and skip every moof+mdat chunk for fragmented mp4s, which makes
start-up incredibly slow. Instead, just stop at the first moof
chunk when have a moov, and start exposing the streams, so we
can go and start handling the moofs for real.
When an caps-event is received, we must immediately change the crop
to videocrop correctly changed caps-event dimension, otherwise the
videocrop will first use the previous value of the crop that when
resizing video to a smaller resolution may cause an error.
https://bugzilla.gnome.org/show_bug.cgi?id=740671
Empty segments in an edit list have a media_start time of -1,
as they don't actually play any media. Allow for that when
aligning to the reference stream in reverse play.
Put a 0-byte at the end of the event string. Does not break ABI because
old depayloaders will skip the 0 byte (which is included in the length).
Expect a 0-byte at the end of the event string or a ; for old
payloaders.
See https://bugzilla.gnome.org/show_bug.cgi?id=737591
Both Firefox and Chrome uses VP8 as the encoding in their SDP.
Adding this now defacto standard name removes the need for special
case in SDP parsing code.
https://bugzilla.gnome.org/show_bug.cgi?id=737810
Add fixed payload type for mp2t to template caps as well, so
our output caps match the advertised default pt. Fixes a
regression from 1.2.
There's still something wrong with caps negotiation though,
rtpmp2tpay payload=96 ! fakesink will not output caps with
payload=96.
Fixes crash in audiotestsrc because of an unsupported format
getting negotiated on big-endian systems with
audiotestsrc ! interleave ! audioconvert ! wavenc
When the RTT and jitter are very low (such as on a local network), the
calculated retransmission timeout is very small. Set some sensible lower
boundary to the timeout by adding a new property. We use the packet
spacing as a lower boundary by default.
In early retransmission we are allowed to schedule 1 regular RTCP packet
at an earlier time. When we do that, we need to set allow_early to FALSE
and ignore/drop (or merge) all future requests for early transmission.
We now first check if we can schedule an early RTCP and if we can,
actually prepare the data for the next RTCP interval.
After we send the next regular RTCP after the early RTCP, we set
allow_early to TRUE again to allow more early requests.
Remove the condition for the immediate feedback for now.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=738319
Add a need-resync state, this is when we need to try to lock on to a
time/RTPtime pair.
Always check the RTP timestamps and if they go backwards, mark ourselves
as need-resync.
Only resync when need-resync is TRUE and we have a valid time. Otherwise
we keep the old values. This avoids locking on to an invalid time and
causing us to timestamp everything with -1.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=730417
rtpmux behaves like a funnel in that it forwards whatever upstream is
sending buffers. So setting proxy caps doesn't make sense as the
upstream don't have to have compatible caps, thus resulting in an empty
caps set as a result of a caps query. Instead set fixed caps just
as funnel does.
https://bugzilla.gnome.org/show_bug.cgi?id=738722
left, right, top, bottom can be set from range of -2147483648 to 2147483647
when i launch the videobox element with that values, it gives a critical error
(gst-check-1.0:29869): GStreamer-CRITICAL **: gst_value_set_int_range_step: assertion 'start < end' failed
This happens because min cannot be equal to max.
https://bugzilla.gnome.org/show_bug.cgi?id=738838
The loop in zoomFilterSetResolution is meant to change the values in the
zf->firedec[] array. Each iteration writes the value of decc onto the arrya,
but no conditions that change the value of decc are ever met and the array is
filled with zero for each element. Which is the initial state of the
array before the loop begins.
The loop does nothing.
https://bugzilla.gnome.org/show_bug.cgi?id=728353
We never initialize clock_rate explicitly, therefore it is 0 by default. The
parameter is a uint32 and the only caller ensure that it is >0, therefore it
won't become -1 ever.
In order to have a full mapping between channel positions in the audio
stream and loudspeaker positions, the channel-mask alone is not enough:
the channels must be interleaved following some Default Channel Ordering
as mentioned in the WAVEFORMATEXTENSIBLE[1] specification.
As a Default Channel Ordering use the one implied by
GstAudioChannelPosition which follows the ordering defined in SMPTE
2036-2-2008[2].
NOTE that the relative order in the Top Layer is not exactly the same as
the one from the WAVEFORMATEXTENSIBLE[1] specification; let's hope users
using so may channels are already aware of such discrepancies.
[1] http://msdn.microsoft.com/en-us/library/windows/hardware/dn653308%28v=vs.85%29.aspx
[2] http://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BS.2159-2-2011-PDF-E.pdf
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=737127
Otherwise the CAPS event will be dropped and we never configure any caps at
all, leading to weird behaviour in many situations. Especially header
rewriting is not going to work if a capsfilter is after wavenc.
https://bugzilla.gnome.org/show_bug.cgi?id=737735
This is about converting the format, not about converting any widths and
heights. Subclasses are expected to handler different resolutions themselves,
like the videomixers already do properly.
gstrtspsrc.c:7939:11: error: implicit conversion from enumeration type 'GstSDPResult' to different enumeration type
'GstRTSPResult' [-Werror,-Wenum-conversion]
res = gst_sdp_message_new (&sdp);
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~
gstrtspsrc.c:7944:11: error: implicit conversion from enumeration type 'GstSDPResult' to different enumeration type
'GstRTSPResult' [-Werror,-Wenum-conversion]
res = gst_sdp_message_parse_uri (uri, sdp);
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove pads from flow combiner and reset last
flow return to FLOW_OK by resetting the flow combiner.
This prevents FLOW_FLUSHING when trying to re-use the
demuxer after setting it back to NULL/READY state.
https://bugzilla.gnome.org/show_bug.cgi?id=737359
