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
DTS delta is used to calculate sample duration. If buffer has missing DTS, we take either segment start or previous buffer end time, whichever is later.
This must only be done for non sparse streams, sparse streams can have gaps between buffers (which is handled later by adding extra empty buffer with duration that fills the gap)
https://bugzilla.gnome.org/show_bug.cgi?id=737095
In 1.0, we pass the complete caps to transform_caps to allow for better
optimizations. Make this function actually work on non-simple caps
instead of just ignoring the configured filter caps.
We have to skip 12 bytes of data for the chunk, and the data size
passed to the sub-chunk parsing functions should have 4 bytes less
than the data size.
Also when parsing the sub-chunks, check if we actually have enough
data to read instead of just crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=736266
Drop use of g_socket_get_available_bytes() which is
not useful on all systems (where it returns the size
of the entire buffer not that of the next pending
packet), and is yet another syscall and apparently
very inefficient on Windows in the UDP case.
Instead, when reading UDP packets, use the more featureful
g_socket_receive_message() call that allows to read into
scattered memory, and allocate one memory chunk which is
likely to be large enough for a packet, while also providing
a larger allocated memory chunk just in case the packet
is larger than expected. If the received data fits into the
first chunk, we'll just add that to the buffer we return
and re-use the fallback buffer for next time, otherwise we
add both chunks to the buffer.
This reduces memory waste more reliably on systems where
get_available_bytes() doesn't work properly.
In a multimedia streaming scenario, incoming UDP packets
are almost never fragmented and thus almost always smaller
than the MTU size, which is also why we don't try to do
something smarter with more fallback memory chunks of
different sizes. The fallback scenario is just for when
someone built a broken sender pipeline (not using a
payloader or somesuch)
https://bugzilla.gnome.org/show_bug.cgi?id=610364
This makes sure that also properties like the pixel-aspect-ratio are the same
between both streams and that the output caps contain all fields necessary for
complete video caps.
https://bugzilla.gnome.org/show_bug.cgi?id=735804
gst_buffer_ref and gst_buffer_writable is being used to create a writable copy of source buffer.
replacing the same with gst_buffer_copy as the functionality is same.
https://bugzilla.gnome.org/show_bug.cgi?id=735880
Adding an extra condition while calling gst_caps_unref (templ)
and replacing gst_caps_make_writable (gst_caps_ref (caps)) with
gst_caps_copy (caps) in line 177, since the functionality is same.
https://bugzilla.gnome.org/show_bug.cgi?id=735795
We return EOS after the first buffer, and GstPad will make sure now that we
won't get any other buffer afterwards until a flush happens. No need to check
for it ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=735581
FLV documentation stipulates that timestamp must start at zero.
In order to respect this rule, keep the first timestamp around
and offset the timestamp from this value. This allow for longer
recording time in presence of timestamp that does not start
at 0 already.
https://bugzilla.gnome.org/show_bug.cgi?id=731352
The tags in FLV are DTS. In audio cases, and for many video format this makes
no difference, but for AVC with B-Frames, PTS need to be computed from
composition timestamp CTS, with PTS = DTS + CTS.
https://bugzilla.gnome.org/show_bug.cgi?id=731352
The jitterbuffer shouldn't force clock-rate on its sink pad, this will cause a negotiation issue since rtpssrcdemux doesn't have the clock-rate and doesn't add it to the caps. The documentation states that the clock-rate can either be specified through the caps or through the request-pt-map signal, so we must remove clock-rate from the pad templates and we must accept the GST_EVENT_CAPS if the caps don't have the clock-rate.
https://bugzilla.gnome.org/show_bug.cgi?id=734322
udpsrc gtk-doc documentation refers to sockfd and closefd properties which has
been removed. This patch replaces those references to socket and close-socket
respectively.
https://bugzilla.gnome.org/show_bug.cgi?id=734987
The old default timescale of 1 millisecond produces irrational
numbers for a lot of framerate/audio-packet-duration multiples.
1/1800 is a nicer number, as it tends to produce better fractions
and therefore slightly higher accuracy overall
Change the way the output framerate is calculated
to ignore the first sample (which is sometimes truncated
in my testing) and use the new gst_video_guess_framerate()
function to recognise common standard framerates better.
Remove the code that was sorting the first 20 sample
durations and then ignoring the result.
Commit 2b9493b5 broke this in two ways: a) we should only
pass duration queries in TIME format upstream (or at least
not those in DEFAULT or BYTE format), and b) we mustn't
overwrite the default value of 'res' from TRUE to FALSE
and not set it again later. This led to bogus durations
being reported for FLV playback from file, because TIME
queries would fail (as 'res' had been set to FALSE) and
parsers then do a BYTE query as fallback and try to
guesstimate something in return, which of course goes
horribly wrong since the BYTE size returned is for the
muxed file.
When changing the properties to not be in passthrough mode anymore,
we will only accept caps we can process ourselves, potentially causing
a not-negotiated error.
https://bugzilla.gnome.org/show_bug.cgi?id=720345
This makes sense in DASH reverse playback, where the upstream dashdemux
will download DASH segments in reverse order, but push their buffers
forward to qtdemux and mark each segment start as DISCONT. This needs
to be forwarded downstream to the parser/decoder, otherwise it won't work.
https://bugzilla.gnome.org/show_bug.cgi?id=734443
When writing out a trak with an edit list, make sure the
overall file duration is also updated to reflect the
lengthening of the stream.
Add some more debug to qtdemux to warn about streams that
are longer than the file and get truncated.
We only want to unlock if we push an event downstream and
jump to done_unlock label afterwards. We would also unlock
in case of a segment seek and then unlock again later, and
nothing good can come of that.
(This code looks a bit dodgy anyway though, shouldn't it
also bail out with FLOW_EOS here in case of a segment seek
scenario, just without the event?)
gst_matroska_parse_take() would return FLOW_ERROR instead of
FLOW_EOS in case there's less data in the adapter than requested,
because buffer is NULL in that case which triggers the error
code path. This made the unit test fail (occasionally at least,
because of a bug in the unit test there's a race and it would
happen only sporadically).
Decoder complains about "notification: Invalid mode encountered.
The stream is corrupted" though, even if it works, so there's
probably something wrong with the generated codec headers.
Implement 3 different cases for handling the SR:
1) we don't have enough timing information to handle the SR packet and
we need to wait a little for more RTP packets. In that case we keep
the SR packet around and retry when we get an RTP packet in the
chain function.
2) the SR packet has a too old timestamp and should be discarded. It is
labeled invalid and the last_sr is cleared.
3) the SR packet is ok and there is enough timing information, proceed
with processing the SR packet.
Before this patch, case 2) and 1) were handled in the same way,
resulting that SR packets with too old timestamps were checked over and
over again for each RTP packet.
This patch adds supports for the incoming key management parameters for
encryption and authentication key lengths.
It also adds a new signal request-rtcp-key that allows the user to
provide the crypto parameters and key for the RTCP stream.
https://bugzilla.gnome.org/show_bug.cgi?id=730473
Use a different variable name to make it clear that we are calculating
the header size.
Correctly check that we have enough bytes to read the header bits. We
were checking if there were 5 bytes available in the header while we
only needed 3, causing the packet to be discarded as too small.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=723595
Similarly to what we did with the DELTA_UNIT flag, this patch
propagates the DISCONT flag to the first RTP packet being used to transfer a
DISCONT buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=730563
Downstream elements may be interested knowing if a RTP packet is the start
of a key frame (to implement a RTP extension as defined in the
ONVIF Streaming Spec for example).
We do this by checking the GST_BUFFER_FLAG_DELTA_UNIT flag we receive from
upstream and propagate it to the *first* RTP packet outputted to transfer this
buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=730563
Pre-allocate buffer list of the right size to avoid re-allocs.
Avoid plenty of double runtime cast checks and re-doing the
same calculation over and over again in rtp_vp8_calc_payload_len().
Only call gst_buffer_get_size() once.
Collect buffers to send out in buffer lists instead of
pushing out single buffers one at a time. For HD video
each frame might easily add up to a couple of thousand
packets, multiply that by the frame rate and that's a
lot of push() and sendmsg() calls per second.
A good reason to push out buffers as early as possible is
latency, so we don't accumulate the whole frame in a single
buffer list, but instead push it out in a few chunks, which
is hopefully a reasonable compromise.
Make sure that if AYUV is received it will detect that it can produce
both RGB and YUV formats
Signed-off-by: Ravi Kiran K N <ravi.kiran@samsung.com>
https://bugzilla.gnome.org/show_bug.cgi?id=725248
