because _release_pad tries to release it from ctx->sinkpad, which is
multiqueue's sink pad, and currently fails because the probe is not
installed there
This also happens in the very beginning when we receive the first packet, a
warning would be very confusing here. In all places where we should warn about
this, we would've printed a warning already before.
Right above we consider lost_packet packets, each of them having duration,
as lost and triggered their timers immediately. Below we use expected_dts
to schedule retransmission or schedule lost timers for the packets that
come after expected_dts.
As we just triggered lost_packets packets as lost, there's no point in
scheduling new timers for them and we can just skip over all lost packets.
https://bugzilla.gnome.org/show_bug.cgi?id=739868
Resetting the jitterbuffer drops all packets and other things, and will cause
a discontinuity in the packets received by the depayloaders. They should now
also flush anything they had pending as the new data will start at a different
position.
https://bugzilla.gnome.org/show_bug.cgi?id=739868
When doing key uint seek, qtdemux calls gst_qtdemux_adjust_seek
to get proper offset. And then this offset is set to
segment.position and segment.time in gst_qtdemux_perform_seek but
segment.start is not updated.
After that, application sends segment query,
qtdemux sets start and stop to query using gst_segment_to_stream_time. Due
to the wrong value in segment.start, the stop position is smaller than
it should.
https://bugzilla.gnome.org/show_bug.cgi?id=746822
We always write the CTTS in qtmux. Ideally we only want to do that
for streams that need DTS, it should be present on the track information
rather than be decided based on each buffer
As qt uses durations, it doesn't matter, only the difference
between consecutive buffers is important. Also, collectpads
already replaces PTS/DTS with the running times for them.
Instead of checking various state variables around the muxer,
track the current muxing mode in a single 'mux_mode' enum.
Add some implementation notes about the different mux modes
gst_segment_do_seek() does that for us already, and doing it twice
will break non-flushing seeks in interesting ways. Leftover from 1.0
porting.
Also copy over segment offset and applied_rate, just in case.
When multifilesink is operating in any mode other than one file
per buffer, the last file created won't have a file message posted
as multifilesink doesn't handle the EOS event.
This patch fixes it by using the last position to post a file
message when EOS is received. This should ensure at least the
time related data and the filename are posted to the application
or other elements
https://bugzilla.gnome.org/show_bug.cgi?id=747000
When not in fast-start or fragmented mode, we need to be able
to rewrite the size of the mdat atom, or else the output just
won't be playable - the mdat placeholder with size == 0 will
cover the rest of the file, including any moov atom we write out.
https://bugzilla.gnome.org/show_bug.cgi?id=708808
New tags can be found on different parts of the file, so this patch
keeps the stream taglists around for the life cycle of the pad
and adds those new tags as found. Then a new tag is found, the
pad's is marked with a tags changed flag, making the element push
a new tag event on the next check. Before this, we were sending
only the newly found tags, as the element was losing its taglist
when pushing the event.
Global tags are already being read in matroskaparse, but they are not
currently being sent.
This patch makes global tags get sent incrementally whenever new ones
are found.
https://bugzilla.gnome.org/show_bug.cgi?id=746242
When planes property is set to 0, the pipeline executes in
an infinite loop and never exits. Since planes must never
be 0, set the minimum value in the property description
to 1.
https://bugzilla.gnome.org/show_bug.cgi?id=743906
It is expected that buffers are time-stamped with running time. Set
a segment accordingly. In this case we pick 0,-1 as this is what udpsrc
would do. Depayloaders will update the segment to reflect the playback
position.
https://bugzilla.gnome.org/show_bug.cgi?id=635701
The segment start/stop in the query is meant to represent the seekable
portion of the stream. It does not match the segment start/stop. Instead
export 0 to duration.
Previously we were setting new caps with the same content for every H264 or
AAC codec_data we found in the stream, spamming everything and causing
renegotiations.
Instead delay creating the caps until we read the codec_data from the stream,
or fail if we get normal data before the codec_data.
AAC raw caps and H264 avc caps always need codec_data, setting caps on the pad
without them is going to make negotiation fail most of the time. Even if we
later set new caps with the codec_data, that's usually going to be too late.
https://bugzilla.gnome.org/show_bug.cgi?id=746682
Make sure that the sync_src pad has caps before the segment event.
Otherwise we might get a segment event before caps from the receive
RTCP pad, and then later when receiving RTCP packets will set caps.
This will results in a sticky event misordering warning
This fixes warnings in the rtpaux unit test but also in the
rtpaux and rtx examples in tests/examples/rtp
https://bugzilla.gnome.org/show_bug.cgi?id=746445
Before we only started it when either:
- there is no send RTP stream
or
- we received an RTP packet for sending
This could mean that if the send RTP pads are connected but never receive any
RTP data, and the same session is also used for receiving RTP/RTCP, we would
never start the RTCP thread and would never send RTCP for the receiving part
of the session.
This can be reproduced with a pipeline like:
gst-launch-1.0 rtpbin name=rtpbin \
udpsrc port=5000 ! "application/x-rtp, media=video, clock-rate=90000, encoding-name=H264" ! rtpbin.recv_rtp_sink_0 \
udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 \
rtpbin.send_rtcp_src_0 ! fakesink name=rtcp_fakesink silent=false async=false sync=false \
rtpbin.recv_rtp_src_0_2553225531_96 ! decodebin ! xvimagesink \
fakesrc ! valve drop=true ! rtpbin.send_rtp_sink_0 \
rtpbin.send_rtp_src_0 ! fakesink name=rtp_fakesink silent=false async=false sync=false -v
Before this change the rtcp_fakesink would never send RTCP for the receiving
part of the session (i.e. no receiver reports!), after the change it does.
And before and after this change it would send RTCP for the receiving part of
the session if the sender part was omitted (the last two lines).
* Fix critical when new tags are found after segment event has already
been sent.
* Send global tags before stream tags.
* Split sending of tags out of gst_matroska_demux_send_event() into its
own function.
https://bugzilla.gnome.org/show_bug.cgi?id=745973
Previously we advanced the in_data pointer by bps for every channel, and then
later again for block_size*bps. This caused us to be one sample further than
expected if an input buffer covered two analysis frames. And in the end lead
to completely bogus values reported by level.
https://bugzilla.gnome.org/show_bug.cgi?id=746065
These are outside the expected range of sequence numbers and should be
clipped, especially for RTSP they might belong to packets from before a seek
or a previous stream in general.
We need to set up the transport in any case, not just if we have a container
stream or a non-interleaved stream. Only if we have an interleaved stream and
are retrying, we should not set up the stream again.
https://bugzilla.gnome.org/show_bug.cgi?id=745599
Otherwise we will get not-negotiated later from rtpbin, and will never be able
to send RTCP packets back to the server. Note that error flow returns from the
RTCP pads are ignored, that's why it didn't fail more visible before.
This reverts commit 1591adf4cd.
https://bugzilla.gnome.org/show_bug.cgi?id=745586#c1:
It's the beginning of an implementation of RFC 2762, which is needed for
large multicast groups. The implementation is not yet complete but why
not leave what is there and implement RFC 2762 instead?
rtpsession declares an array of maps to store srrcs but only the
the key 0 is being used. This patch replaces the array of maps
for just one map and remove useless parameters in rtpsession
https://bugzilla.gnome.org/show_bug.cgi?id=745586
In gst_avi_demux_handle_src_query, there is not needed code.
We already check about stream is vbr or not at the upper line.
o, we don't need to check this condition becase stream is not
vbr 100% in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=745276
Unlike many other seek flags, the KEY_UNIT seek
flag is not copied over into the GstSegment,
since it's only relevant for the seek itself,
so we need to pass it explicitly to the seek
handler here.
https://bugzilla.gnome.org/show_bug.cgi?id=745339
We need different symbol names, because these symbols are also present
in the fragmented plugin ... which will cause conflicts when doing
static linking
The number of FFTs is calculated with the following formula:
guint nfft = 2 * bands - 2;
nfft is passed to gst_fft_f32_new() as the len argument and is of type
unsigned integer. This method required that len is at leas 1, then
maximum G_MAXINT, as other values would be negative. If we extrapolate
from the formula above it means we need "bands" to be between 2 and
((guint)G_MAXINT + 2) / 2).
https://bugzilla.gnome.org/show_bug.cgi?id=744213
Using the sparse streams can make the push-based seeking return
too far in the stream. It also can lead to issues as the
sparse streams will be ignored when restarting playback and,
if the sparse stream is the one that has the earliest sample,
it will confuse qtdemux's offsets as one stream will have
an earlier offset than the demuxer's one which might lead to
early EOS.
https://bugzilla.gnome.org/show_bug.cgi?id=742661
Parse the 'sidx' atom and update the total duration according to the
parser result. The isoff parser code is imported from
gst-plugins-bad's dashdemux and a gst_isoff_sidx_parser_add_data()
function was factored out of the gst_isoff_sidx_parser_add_buffer()
function.
https://bugzilla.gnome.org/show_bug.cgi?id=743578
According to RFC 4585 section 3.5.3 step 1 we are not allowed to send
an early RTCP packet for the very first one. It must be a regular one.
Also make sure to not use last_rtcp_send_time in any calculations until
we actually sent an RTCP packet already. In specific this means that we
must not use it for forward reconsideration of the current RTCP send time.
Instead we don't do any forward reconsideration for the first RTCP packet.
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
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
The code would previously crash trying to insert a NULL string
into a hash table.
It does seem a little broken that indexing is done by MIME type
and not by index though, unless the spec says there cannot be
two parts with the same MIME type.
https://bugzilla.gnome.org/show_bug.cgi?id=659573
This event was not sent. Send it before caps, this requires the pad to
be parented. This removes warning like: "Got data flow before
stream-start event".
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=731475
If the wav header contains an extended chunk, we want to keep
the codec_data field, but not for raw audio.
This fixes some elements (such as adder) from failing to intersect
raw audio caps which would otherwise be intersectable.
Handle the transformation matrix cases where there are only simple rotations
(90, 180 or 270 degrees) and use a tag for those cases. This is a common scenario
when recording with mobile devices
https://bugzilla.gnome.org/show_bug.cgi?id=679522
tentacle3d.c:268:7: error: using integer absolute value function 'abs' when
argument is of floating point type [-Werror,-Wabsolute-value]
if (abs (tmp - fx_data->rot) > abs (tmp - (fx_data->rot + 2.0 * G_PI))) {
^
tests.c:161:16: error: taking the absolute value of unsigned type
'unsigned long' has no effect [-Werror,-Wabsolute-value]
t->diff += labs (GST_BUFFER_TIMESTAMP (buffer) - t->expected);
1) sources that have sent BYE in the past cannot be senders, since
they would have timed out to being receivers in the meantime...
2) sources that have sent BYE are now being removed earlier inside
this function
If we are inserting a packet into the jitter queue we need to keep
looping through the items until the right position is found. Currently,
the code stops as soon as an event is found in the queue.
Regarding events, we should only move packets before an event if there
is another packet before the event that has a larger seqnum.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=730078
If two streams request a retranmission for the same SSRC, ignore the second
one if the first oen is less than one second old, otherwise time out the first
one and ignore the second.
As we now replace the local RTPSource on a conflict, it's no longer possible
to keep local conflicts in the RTPSource, so they instead need to be kept
in the RTPSession.
Also fix the rtpcollision test to generate multiple collisions instead of
one by change the address, as otherwise we detected that it was a single one.
If we're missing part of the clut, do not try to use it. It seems
very likely the break was meant to break out of the switch rather
than from the loop.
Coverity 1139878
Even if one woul hope one pixel can fit in a MTU, ensure we do not
overwrite a buffer if this is not the case.
Spotted while looking at Coverity 1208786
Rework the packet queue so that the most common action (insert a packet
at the tail of the queue) goes very fast.
Report if a packet was inserted at the head instead of the tail so that
we can know when to retry _pop or _peek.
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
gstdeinterlace.c: In function 'gst_deinterlace_output_frame':
gstdeinterlace.c:1537:57: error: 'pattern.length' may be used uninitialized in this function [-Werror=maybe-uninitialized]
This actually is always initialized before it is used there, but
let's just silence gcc here.
Make a new method to disable the jitterbuffer buffering.
Rework the update_estimated_eos() method. Calculate how much time
there is left to play. If we have less than the delay of the
jitterbuffer, we disabled buffering because we might never be able to
fill the complete jitterbuffer again.
If we receive an EOS event, disable buffering. We will drain the
buffer and eventually push the EOS event out.
When we reach the estimated NPT timeout and we didn't receive an EOS
event, make one and queue it so that it can be pushed.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=728017
When the internal-ssrc property changes, we want to send a reconfigure
upstream to make payloaders use the new suggested ssrc.
Using the internal-ssrc property to change the SSRC of a stream is not a
good idea and doesn't work when there are multiple senders, we want to
set the SSRC directly on the payloaders. Therefore, deprecate this
property.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=725361
Rework the logic to make buffering messages a little, make sure we
don't make the same message multiple times.
Consider the buffer full when EOS was received.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=728017
While it seems to keep a compile time selection, I traced it
to some code copied from videoconvert, where it was removed,
with the following comment:
Also remove the high-quality I420 to BGRA fast-path as it needs
the same fix, which causes an additional instruction, which causes
orc to emit more than 96 variables, which then just crashes.
This can only be fixed in orc by breaking ABI and allowing more
variables.
Thus, I remove it here as well.
Coverity 206064
When we are buffering, we can't block and wait for the serialized query
to complete because the jitterbuffer will not try to forward the query
while buffering. Instead, just refuse the query.
The caps query handling function for the sinkpads was called for
the srcpad, and the sinkpads had none. This commit moves it to the
right pad, but nonetheless the negotiation still looks wrong.
This makes the test pass again after the recent coverity fix
and also allows interleave to work again, but someone should
really review the negotiation code and fix it.
The marker bit isn't mandatory and we had in place code to guess AU
boundaries by detecting a new picture start. This guessing code
didn't work with interlaced content that has proper marker bits
to indicate the AU boundaries. It was leaking the first field buffer
and producing a corrupted output.
fixes: https://bugzilla.gnome.org/show_bug.cgi?id=728041
The code handles a -1 pattern index, and it seems plausible
that a pattern might be found later, so it seems best to not
send an element error here.
Coverity 1139766
Create and make a key for encrypting the RTCP packets back to the server
and wrap this in a MIKEY message that we send as a header in the SETUP
request.
... as sender should keep track of segment base accumulation.
Rather, it may have some adverse effects as a spurious segment event,
e.g. in collectpads.
Try to avoid using the request-pt-map to get caps but set them directly
on the udpsrc element. That way, the caps get nicely transformed as they
pass through the different elements in the rtpbin, including the AUX and
decoder/encoder elements.
Protect caps with the lock.
Don't push the caps event from the set_property function but mark the
pad for reconfiguration so that it will renegotiate and push the new
caps event in the streaming thread.
We should open the socket when going to NULL<->READY and not in the
start/stop vemthod, which is called in READY<->PAUSED. This makes it
possible to allocate a socket without going to PAUSED (and starting the
negotiation).
Instead the queued buffer might have an old caps while the pad
is already storing the information for a new caps. Mixing those
while handling buffers will often lead to issues
https://bugzilla.gnome.org/show_bug.cgi?id=725948
Remove caps restrictions that correspond to the default and are not
required in SDP. With the new usage of having pads require a subset
of the caps, they will make the negotiation fail.
The "encoding-params" is optional in the SDP, because we now require
a subset of the caps, it would fail caps negotiatioin if it wasn't present.
So removed it from the template caps.
Keep track of what streams we did the SETUP for. We only need to
configure caps, wait for pads and push events on setup streams. We can
remove the disabled state of the stream and simplify some checks.
After we setup a stream, skip the other streams that have the same
control url. Use a skipped flag to mark streams that should be skipped.
Call gst_rtspsrc_connection_flush (src, FALSE) to reset connections as
non-flushing before sending PAUSE and PLAY with the new npt range. Without this
patch, those commands would fail with EINTR as the connections were still
flushing.
It is placed inside a 'vids' struct, so it was being exposed on
a pad named video_%d. XSUB are subtitles and this patch adds
an special case for it to be exposed in a subpicture_%d pad
A media stream can have multiple payload types. Parse all the payload
types and collect the caps information. We then have to store the
pt<->caps mapping instead of 1 pt and 1 caps.
Parse the profile from the SDP and use that to negotiate the transport
instead of always using AVP.
Rework how we do some tweaks for ASF and Realmedia.
It is possible that the DTS is invalid (when we receive RTP packets from
TCP, for example). As a fallback, use the reconstructed PTS value to
calculate the buffer level.
gstrtpjitterbuffer.c: In function 'gst_rtp_jitter_buffer_loop':
gstrtpjitterbuffer.c:2978:3: error: 'result' may be used uninitialized in this function
while (result == GST_FLOW_OK);
^
Several conditional statements perform comparison on RTP sequence
numbers without taking the sequence number rollover into account.
Instead, use the gst_rtp_buffer_compare_seqnum function to perform the
comparison.
https://bugzilla.gnome.org/show_bug.cgi?id=725159
This fixes an issue with gst-rtsp-server where no sps and pps are
sent for the first intra frame, because the payloader starts working
already when receiving DESCRIBE but there is no transports so it tries
to send sps and pps, but that fails with a FLUSHING flow. But the time
for last sent sps and pps would still be set, so when PLAY arrives and
the first intra frame is to be sent there is no sps and pps sent due to
that time since last sps pps is less than spspps_interval.
https://bugzilla.gnome.org/show_bug.cgi?id=724213
In the case where we have no suitable candidate we post a warning and plug a
fake-element. Do the same when non of the candidate work.
This is more consistent and plugin the fakesink as a fallback is probably
helpful for running unit tests without requiring hardware src/sink elements.
Fixes#722981
Adds two extra checks:
- Sampling frequency on header can't be 15.
- Frame size should be at least 9 or 7, depending
on whether CRC protection is present.
https://bugzilla.gnome.org/show_bug.cgi?id=724638
Add support for a new property: tls-database. If the property is set,
the certificate database will be given to the rtsp connection if TLS
protocol is being used. If the server certificate can't be verified with
the default database, this additional database will be used.
https://bugzilla.gnome.org/show_bug.cgi?id=724396
It turns out that the change in gtk-doc-1.20 which wraps the |[]| content in
CDATA break xi:inlcude examples. As in a whole jhbuild checkout these where
the only 4, we're fixing them instead.
recv_rtp_sink: allow proxying of the allocation query.
send_rtp_sink: allow proxying of caps and allocation. This allows us to
query caps downstream as well as get an allocator from downstream.
send_rtp_src: allow proxy of caps, this makes the caps query do
upstream.
See https://bugzilla.gnome.org/show_bug.cgi?id=723850
It was used in the past in 0.10 when there was no explicit DTS
field in buffers, now we have it in 1.x series and we can
check it directly with GST_BUFFER_DTS_IS_VALID
Do not try to use subsequent buffer timestamps to calculate
sparse streams durations because the stream is sparse and
the buffers might not be 'time adjacent'. So rely on the
duration and give the option to the pad to provide
custom 'empty' buffers to represent the gaps in the
stream, this can vary on how the data is represented.
Right now, the only sparse stream supported is tx3g subtitles.
This reverts commit 9f7b1128b1.
This should be handled automatically be rtspsrc if the AVPF profile
is used, and manual enabling of it can be done with the new-manager
signal.
If the expected packet (do_next_seqnum is TRUE) is the one we requested
for retranmission earlier, do the logic to update the retransmission
statistics as well before setting up the timers for the next expected
packet.
Also reset the retransmission counter if the timer is reused for another
seqnum.
Add an accumulator that stops the signal emission as soon as a caps has
been retrieved. Otherwise the default handler would continue emitting
the signal and possibly overwrite the result with NULL again.
Uses information gathered during EBML parsing to
forge a more suitable set of caps instead of blindly
assuming everything is video/x-matroska.
For consistency, stream type reset was added to
matroska-demux too.
https://bugzilla.gnome.org/show_bug.cgi?id=722311
To do that, enqueue the EOS event to be sent from the srcpad task
thread and flush the queue right afterwards, so that no more rtx
buffers can be sent, even if there are more requests coming in.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=722370
The reason behind this is to minimize the retransmission delay.
Previously, when a NACK was received, rtprtxsend would put a
retransmission packet in a queue and it would send it from chain(),
i.e. only after a new buffer would arrive.
This unfortunately was causing big delays, in the order of 60-100 ms,
which can be critical for the receiver side.
By having a separate GstTask for pushing buffers out of rtxsend,
we can push buffers out right after receiving the event, without
waiting for chain() to get called.
Instead do it like all other demuxers and let parsers and decoders
handle that. The keyframe information inside the container might
be completely wrong like in the sample file of the bug report,
and if it is correct and we push no keyframes, then the parsers
and decoders will handle that properly anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=682276
Make sure empty segments are used and pushed with a gap event
to represent its data (or lack of it)
Each QtSegment is mapped into a GstSegment with the corresponding
media range. For empty QtSegments a gap event is pushed instead
of GstBuffers and it advances to the next QtSegment.
To make this work with seeks, need to keep track of the starting
'base' to make sure it remains consistently increasing when
pushing new segment events.
For example: if a seek makes qtdemux start from 5s, the first
segment will have a base=0. When the next segment is activated,
its base time will be QtSegment.time - qtdemux.segment_base so
that it doesn't include the first 5s that weren't played and
shouldn't be accounted on the running time
This purposedly will remove the fix made for
https://bugzilla.gnome.org/show_bug.cgi?id=700264, at this
point it was decided to respect the gaps, even if they cause
a delay on playback, because that's the way the file was crafted.
https://bugzilla.gnome.org/show_bug.cgi?id=345830
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
AUX elements are elements that can be inserted into the rtpbin
pipeline right before or after 1 or more session elements.
The AUX elements are essential for implementing functionality such
as error correction (FEC) and retransmission (RTX).
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=711087
Keep track of elements that are added to multiple sessions and make sure
we only add them to the rtpbin once and that we clean them when no
session refers to them anymore.
When a collision is found on the internal ssrc, we have to change it.
Ideally, we want also the payloader upstream to follow this change and use
the new internal ssrc. Ideally we want this condition to be always met:
if there is one payloader sending on this session, its ssrc should match the
internal ssrc.
* gst/rtpmanager/gstrtpbin.[ch]: four new action signals have been
added (request-rtp-encoder, request-rtp-decoder, request-rtcp-encoder
and request-rtcp-decoder). The user will be able to provide encoders
or decoders dynamically. The encoders must follow the srtpenc API and
the decoders the srtpdec API. Having separate signals for RTP and RTCP
allows the user to use different encoders/decoders or provide the same
one (e.g. that would be the case for srtpenc).
Also, rtpbin now allows application/x-srtp in its pads.
https://bugzilla.gnome.org/show_bug.cgi?id=719938
Use the round-trip-time and average jitter to dynamically calculate the
retransmission interval and expected packet arrival time.
Based on patches from Torrie Fischer <torrie.fischer@collabora.co.uk>
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=711412
Don't use the current time calculated from the tmieout loop for when we
last scheduled the NACK because it might be unscheduled because of a max
packet misorder and then we don't accurately calculate the current time.
Instead, take the current element running time using the clock.
Make it clear what should be handled purely by mss mode:
1) Expose the streams on the first moof as there are no moov atoms
2) Properly cleanup streams on flushes
Add a note about the meaning of upstream_newsegment and mss_mode
for future reference.
Make all other special fragment handling shared for both dash
and mss streams.
In a fragmented scenario, qtdemux is operating in push mode
and it gets a fragmented buffer. While processing its data
downstream gets unlinked (or a input-selector changes its
active pad and returns not-linked). Qtdemux stops processing
this fragment and returns not-linked upstream, leaving the
remaining data in its adapter.
When it gets an EOS it should make sure that all the data it
had received is pushed before pushing EOS.
According to RFC 5104 section 4.3.1.2, RTCP PSFB FIR message SHALL
have a media_ssrc field set to 0. The actual media ssrc is in the FCI.
So in that case, we ignore the retained feedback and just let it through
to the rtp_session_process_fir() function which will check for the actual
SSRC inside the FCI.
Fixes a regression introduced by commit 57c27ec3
Previously, when the session had multiple internal sender SSRCs, it would
issue SR reports with RB blocks only on the first RTCP timeout and afterwards
SR reports would be sent empty. This was because the "generation" number
in RTPSource would increase more than once during the same cycle and afterwards
it would always be greater than the session's generation, which would cause
it to be skipped from being included in RBs.
This commit fixes this problem by:
1) Increasing the RTPSource generation only at the end of each cycle,
which essentially fixes the problem but only when the internal senders
are less than GST_RTCP_MAX_RB_COUNT.
2) Keeping for each RTPSource a set of SSRCs which stores which SSRC's
SR the given RTPSource has been reported in, which also fixes the problem
when the internal senders are more than GST_RTCP_MAX_RB_COUNT. This is
necessary because of the fact that any RTPSource is marked as reported
in itself's SR and makes it impossible to know if it has been reported
in other SRs too or not, and which.
Keep an extra stats structure for scheduling the BYE packets. When we
decide to schedule BYE, make a copy of the current stats into the
bye_stats. Then while we schedule the BYE, update and use only the
bye_stats. When we finished scheduling the BYE packet, we use the
regular stats again.
When we are scheduling BYE packets, ignore all RTCP for the sources that
are scheduling a BYE packet. Other sources that are not scheduling BYE
should continue receiving RTCP packets as usual.
Some buffers can have multiple moov atoms inside and the strategy
of using the gst_adapter_prev_pts timestamp to get the base timestamp
for the media of the fragment would fail as it would reuse the same
base timestamp for all moofs in the buffer instead of accumulating
the durations for all of them.
Heres a better explanation of the issue:
qtdemux receives a buffer where PTS(buf) = X
buf -> moofA | moofB | moofC
The problem was that PTS(buf) was used as the base timestamp for
all 3 moofs, causing all buffers to be X based. In this case we want
only moofA to be X based as it is what the PTS on buf means, and the
other moofB and moofC just use the accumulated timestamp from the
previous moofs durations.
To solve this, this patch uses gst_adapter_prev_pts distance
result, this allows qtdemux to calculate if it should use the
resulting pts or just accumulate the samples as it can identify
if the moofs belong to the same upstream buffer or not.
https://bugzilla.gnome.org/show_bug.cgi?id=719783
The parser can accept input that is not completely specified. Use the
ACCEPT_INTERSECT flag on the sinkpad to tweak the acceptcaps function to
check for intersection only. This allows us to proxy downstream
constraints while still allowing non-subset caps as input.
We can then also remove the appended template caps workaround.
Make a unit-test to check the new feature.
This reverts commit 26040ee38c
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=705024
In SmoothStreaming fragmented scenario, the timestamps are calculated
starting from the fragment buffer timestamp. When there is a not-linked
return from downstream, qtdemux will return upstream and will keep the
non-pushed data into its adapter.
On a new fragment buffer pushed to qtdemux, the new buffer timestamp
would overwrite the previous one that should be used on the still
to be pushed buffers. Because of this, this patch will also
update the fragment_start timestamp from the adapter last pts
to make sure the moof and timestamps are in sync and will result
in correct timestamps for all fragments.
In the scenario of "mdat | moov (with fragmented artifacts)" qtdemux
could read the moov again after the mdat because it was considering the
media as a fragmented one.
To avoid this loop this patch makes it store
the last processed moov_offset to avoid parsing it again.
And it also checks if there are any samples to play before
resturning to the mdat, so that it knows there is new data to be played.
https://bugzilla.gnome.org/show_bug.cgi?id=691570
When parsing a trak only free streams on failures if those streams
were created locally. They could have been created from a previous
fragment, in this case we they have valid info from the other fragment.
Including pads.
https://bugzilla.gnome.org/show_bug.cgi?id=691570
Don't reset the expected output seqnum when clearing the pt map because this
could stall the jitterbuffer forever.
Add a unit test for this.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=709800
As for text subtitles and as suggested in #712643, throw
away the 2 byte terminator packets that some encoders insert.
This will make things better when remuxing and causes generation
of gap events.
Otherwise there were race conditions where we would send tags
on a flushing srcpad.
We have a test for that in GES, but this should be tested
systematically with harness in the future as I believe it
is useful for exactly that kind of cases.
https://bugzilla.gnome.org/show_bug.cgi?id=708165
Clean up the handling of mp4s streams. Use the generic esds
descriptor function to extract the palette, instead of hard coding
a wrong magic offset.
Add some more size safety checks when parsing ES descriptors, and
replace magic numbers with the descriptive constants that are already
defined.
Enhance dump output for stsd atoms.
Streams from both bug 712643 and historic bug 568278 now both work
correctly.
Fixes: #712643
Remove bogus reconfigure event on collision, we don't want to send the event on
the receiving RTP pad and the collision event is now handling this
case.
See https://bugzilla.gnome.org/show_bug.cgi?id=711560
The problem here was that the jitterbuffer lock was unlocked to push
the event, but that caused another thread to remove the timer currently
being processed, probably because the amount of rtx events
(and therefore timers) was getting too high. The solution is to
unlock and push the event only after timer processing has finished.
fixes https://bugzilla.gnome.org/show_bug.cgi?id=711131
Restore the behavior of the element to the state before commit
db29522a43. A non-empty header is
generated and when the EOS event is received the header is generated
again, this time with the correct size.
https://bugzilla.gnome.org/show_bug.cgi?id=711699
An internal sender in a session is also a receiver of its own packets so update
the receiver stats. Other senders in the session will use this info to generate
correct RB blocks in their SR reports.
Assume a file with atoms in the following order: moov, mdat, moof,
mdat, moof ...
The first moov usually doesn't contain any sample entries atoms (or
they are all set to 0 length), because the real samples are signaled
at the moofs. In push mode, qtdemux parses the moov and then finds the mdat,
but then it has 0 entries and assumes it is EOS.
This patch makes it continue parsing in case it is a fragmented file so that
it might find the moofs and play the media.
https://bugzilla.gnome.org/show_bug.cgi?id=710623
In push mode, when qtdemux can't use a seek to skip the mdat buffer it has
to buffer it for later use.
The issue is that after parsing the next moov/moof, there might be some
trailing bytes from the next atom in the file. This data was being discarded
along with the already parsed moov/moof and playback would fail to continue
after the contents of this moov/moof are played.
This is particularly bad on fragmented files that have the mdat before the
corresponding moof. So you'd get:
mdat|moof|mdat|moof ...
When a moof was received, it usually came with some extra bytes that would
belong to the next mdat (because upstream doesn't care about atoms alignment).
So those bytes were being discarded and playback would fail.
This patch makes qtdemux store those extra bytes to reuse them later after the
mdat is emptied.
https://bugzilla.gnome.org/show_bug.cgi?id=710623
Add a new timestamp mode that assumes the local and remote clock are
synchronized. It takes the first timestamp as a base time and then uses the RTP
timestamps for the output PTS.
matroska-demux.c: In function 'gst_matroska_demux_add_stream':
matroska-demux.c:1379:7: error: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'guint64' [-Werror=format=]
"%03u", context->uid);
^
WebM has a couple of specific requirements we need to handle.
Idea is to set this flag once and just rely on mux->is_webm
at run time instead of repeatedly figuring this out from
GST_MATROSKA_DOCTYPE_WEBM (which requires a strcmp()).
WebM spec states SegmentUID is Unsupported. Files produced
with gstreamer without this change will spit an error like
this when passed to mkvalidator:
ERR201: Invalid 'SegmentUID' for profile 'webm' in Info at 192
When flush-stop arrives before we process the result of the _push() in the
loop function, we might pause even though we are not flushing anymore. Fix this
race by waiting for the srcpad loop function to completely pause after doing the
flush-start.
If we were not waiting for the missing seqnum when we insert the lost packet
event in the jitterbuffer, we end up not updating the next_seqnum and wait
forever for the lost packets to arrive. Instead, keep track of the amount of
packets contained by the jitterbuffer item and update the next expected
seqnum only after pushing the buffer/event. This makes sure we correctly handle
GAPS in the sequence numbers.
Doing so would be a regression over 1.0 and breaks the unit test.
However the result will be most likely unusable, so let's post
a warning message on the bus.
Use g_date_time seconds manipulation to allow to cover the quicktime
spec for creation_time. It uses seconds since 1904.
Both paths could be done using the generic approach of seconds since
1904 with GDateTime handling, but the first path using seconds from
1970 should be more commonly found and avoids a few objects creation and
ref/unref, so keep it there for performance.
Additionally, the code for handling seconds since 1970 changed from >
to >= because having 0 seconds since 1970 is also a valid case for that
path to handle.
https://bugzilla.gnome.org/show_bug.cgi?id=707975
Always prepare a lost event in the jitterbuffer, it is to wake up and make the
pushing thread continue. We drop the event when we are not supposed to push lost
events downstream.
Schedule the lost event by placing it inside the jitterbuffer with the seqnum
that was lost so that the pushing thread can interleave and push it properly.
Make the jitterbuffer operate on a structure containing all the packet
information. This avoids mapping the buffer multiple times just to get the RTP
information. It will also make it possible to store other miniobjects such as
events later.
Improve the order of the timeout events, if there are timers with the same
timeout, we want to trigger the lowest seqnum first. For this we need to loop
over the complete array of timers to find the best one before triggering the
timeout.
First send the lost event, then update the next_seqnum counter and then
send the signal to the pushing thread that it can retry to push a buffer. This
avoids pushing out buffers before the lost event is pushed.
There is no need to unschedule the timer in flush-start, flush-stop will remove
the timers and unschedule.
Unschedule the current timer before attempting to join the timer thread.
Use the more correct POFFSET macro to get the offset of a component in its
plane. The offset macro gives the offset of the component relative to the start
of the frame.
clang does not want or need a clobber list for emms:
error: clobbers must be last on the x87 stack
Patch taken from the FreeBSD ports, provided by
Dan McGregor <dan.mcgregor@usask.ca>
The streamable property only make sense for fragmented formats.
For regular MP4, when downstream is not seekable we can't rewrite
the headers, so qtmux can only work with fast-start=TRUE, where
the headers are written finishing the file.
For fragmented MP4, when streamable is not seekable and the streamable
property is FALSE, we must enforce streamable=TRUE warning the user
about this change
https://bugzilla.gnome.org/show_bug.cgi?id=707242
The most common use case for fragmented MP4 (Dash and Smooth Streaming)
is producing streamable content (even for VOD). streamable=FALSE would only
be used to generate fragmented MP4 with and index of MOOF's that could
be reproduced without a playlist/manifest
https://bugzilla.gnome.org/show_bug.cgi?id=707242
Don't assume planar formats have just one memory block with the data but use the
macros to access the right memory block where a component can be found.
Keep a separate delay in the timer so that we still know the original timestamp
of the packet that this timer refers to. We can then place the correct
running-time in the Retransmission event.
Instead of pushing the lost event from the chain function, schedule a timeout
that will push the lost event from the timer thread. This avoid blocking the
upstream thread while we push and sync the event.
When we have a large number of missing packets, generate one lost event for all
the packets that have no chance of being pushed out in time.
Fix and activate unit test for large gaps.
Keep track of the current time in the timeout loop.
Loop over all timers and trigger all the expired ones, we can do this in the
same loop that selects the new best timer.
Also update the timers when retransmission is disabled. We need to
do this because when we added LOST timers when we detected missing packets and
we need to remove those timers when the packet finally arrives.
Check for GST_SEEK_TYPE_NONE for stop poistion and only update
the stop time if it is requested. Otherwise just maintain whatever
was stored at the segment
https://bugzilla.gnome.org/show_bug.cgi?id=707530
We keep the DTS and PTS in running-time inside the jitterbuffer. Make sure to
transform it back to a buffer timestamp before pushing out the buffer.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=707931
When the segment has a defined stop position, qtdemux should check
when streams reach this position and mark those as EOS. When all
streams are EOS it will return GST_FLOW_EOS to upstream to allow
the pipeline to finish instead of continuously consume buffers
from upstream that are not useful for the segment.
https://bugzilla.gnome.org/show_bug.cgi?id=707530
When handling seeks in push mode, qtdemux converts the seek to bytes
and pushes upstream. It needs to keep track of the seek and the
subsequent segment to be able to map them back to the requested
seek time and properly preserve the segment stop of the seek.
This is done by using the start offset in bytes of the seek,
that should be the same of the segment from upstream. And this
is also backwards compatible with what qtdemux already was using.
https://bugzilla.gnome.org/show_bug.cgi?id=707530
Amendment 2 of ISO/IEC 14496-15 (AVC file format) is defining a new
structure for fragmented MP4 called "avc3". The principal difference
between AVC1 and AVC3 is the location of the codec initialisation
data (e.g. SPS, PPS). In AVC1 this data is placed in the initial
MOOV box (moov.trak.mdia.minf.stbl.stsd.avc1) but in AVC3 this data
goes in the first sample of every fragment (i.e. the first sample in
each mdat box). The principal reason for avc3 is to make it easier
for client implementations, because it removes the requirement to
insert the SPS+PPS in to the decoder pipeline every time there is a
representation change.
This commit adds support for the "avc3" atom, which is almost identical
to the "avc1" atom, except it does not contain any SPS or PPS data.
https://bugzilla.gnome.org/show_bug.cgi?id=702004
On Windows it's not possible to bind to a multicast address
but the OS will make sure to filter out all packets that
arrive not for the multicast address the socket joined.
On Linux and others it is necessary to bind to a multicast
address to let the OS filter out all packets that are received
on the same port but for different addresses than the multicast
address
And deprecate the multicast-group property and replace it with the
address property.
https://bugzilla.gnome.org/show_bug.cgi?id=707042
RTP buffer allocation should not be done with padding for the specific MPEG2
header as the padding is done at the end of the buffer and the last byte is
the size of the padding.
https://bugzilla.gnome.org/show_bug.cgi?id=706970
This should make decoders able to precisely push buffers until the stop
time in case they need the next keyframe to do it.
Also, according to gst_segment_clip, it should only push a buffer that
the starting ts is strictly smaller than the segment stop, so we change
the min < comparison for <=
Don't update the next RTCP check time in all cases but only when we
reconsidered. This avoids delaying sending a full RTCP packet when we
are doing early feedback.
We can't use the clock to time our config-interval because we are not
live (or there might not be a clock or the clock might not be running).
Instead just simply take the timestamp diff.
This is to make sure tags are cleared on the client if the
stream-start was previously lost, otherwise, the client may end
up with a merged taglist of multiple songs
This is useful in case the packet containing the inlined caps was lost
or if new client joins an already running RTP stream and they missed
the previous tag events.
This also makes the payloader keep a list of merged tags so the retransmitted
tag event contains all previously received. A STREAM_START event will
flush the list of tags.
This is necessary to fix event/caps sending. If we send a STREAM_START
packet, it will cause an error because the stream didn't receive its
caps and new-segment events, so we must wait for the first buffer before
sending the stream-start event buffer. However, the caps will be sent
at the same time and so the 'inline caps' will be set for the event.
We need to be able to payload individual packets (data, caps or events)
and only send them when we call flush.
Restructure handling of incomming packet and the gap with the expected seqnum
and register all timers from the _chain function.
Convert a timer to a LOST packet timer when the max amount of retransmission
requests has been reached.
This patch will prepend ADTS headers to raw AAC audio frames, allowing
upstream elements to link to decoders that only support AAC in ADTS format.
Note that no error correction bits are added to ADTS frames in this code.
https://bugzilla.gnome.org/show_bug.cgi?id=615740
In some cases the src caps determined by goom weren't writable, causing
a bunch of assertion failures and failed caps. Fixed by always
explicitely making the caps writable
https://bugzilla.gnome.org/show_bug.cgi?id=705475
If we change the seqnum of an existing timer and we were waiting for
that timer, unschedule it. If we change the timeout of an existing timer and we
were waiting on it, only unschedule when the new time is smaller.
Make the jitterbuffer schedule the timeouts based on the DTS instead
of the PTS. This makes it all smoother with reordered frames and gives
the decoder time to reorder the frames in time.
Refactor the jitterbuffer code. Make separate function for peeking a buffer,
pushing the next buffer, waiting for timeouts and handling the timeouts.
The main loop now tries to push as many buffers as it can until it runs out of
buffers or when it detects a seqnum discont. Then it will wait for some event to
happen before attempting to push more buffers.
Make methods to register timeouts in an array. These timeouts are registered
when we detect a missing packet, sync for the first packet or when we find an
estimation for the end-of-stream.
This greatly simplifies and clarifies the code and also makes it possible to
register more complicated timeout schemes later.
Make a method to suggest the best available SSRC. This is the SSRC of the last
created internal source and is used to instruct upstream to produce this
SSRC.
Store the BYE reason in our internal source object. Rename the methods on the
source object a little because now the BYE can be received in RTCP or
set when the session wants to send BYE.
Some muxers (eg, qtmux) only support raw AAC, so this allows linking
an encoder that outputs ADTS only to those muxers.
The conversion is simple (omit the first 7 or 9 bytes of the frame),
but has to be done in pre_push instead of handle_frame as 1.0 does
not seem to allow skipping bytes there as 0.10 used to.
Other conversions are not supported (yet).
According to http://wiki.multimedia.cx/index.php?title=ADTS,
the value stored in ADTS headers is one less than the object
type of the AAC stream.
A look at ffmpeg shows it also adds 1 to the value read off
the ADTS header.
Note that this might break other things that happen to have
an inverse off by one to match the existing code.
Use the same seqnum on messages and events for derived events.
Fixed for flushes / stream-start / segment after a seek, and segment
after a segment.
Fixes#676242
rtpbin can now send a custom in-band downstream event which informs
downstream that the bin has received an RTCP SR packet. This is useful
for applications which want to drop the initial unsynchronized received
RTP packets.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=703560
Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
There could be a case where:
1) you do a new set_caps after buffers have been processed.
2) ts_offset gets set to a different value, eg 0.033333333
3) your pads get EOS, but the check dor that doesn't work
because you use ts_offset + a truncated value < segment.stop
4) so in the next collected, you end up comparing for example:
0.9999999999 > 1., which is false and means you don't send EOS.
Also adds scale_round in two other places where it potentially could
have caused problems.
cca2f555d1 introduces a regression, where the demux segment is not
reset on flush stop, so the next upstream segment event will calculate
an invalid base time on the new segment to be sent downstream.
https://bugzilla.gnome.org/show_bug.cgi?id=704255
We'll have to pop buffer from collectpads and store it
internally only to get the timestamp of the next buffer.
If we continue to keep it in collectpads, no new buffer
to calculate the end time will ever arrive.
https://bugzilla.gnome.org/show_bug.cgi?id=703743
Call reset-sync on the rtpbin before we go to playing. This makes us require SR
packets for all streams again before we attempt to sync them. If we don't reset,
it might be that we combine SR packets from before and after the PAUSE/PLAYING
state change and end up with huge bogus offsets.
Don't throw away the first RTCP packet if it arrives before the first
RTP packet but remember and use it to signal sync once we get the
RTP packet.
See https://bugzilla.gnome.org/show_bug.cgi?id=691400
When we go to paused, we first flush the connection and then send the pause
command. As a result of the flushing, the scheduled paused command can get
lost. Wait until the connection is completely flushed and the rtsp task is
waiting before issuing the paused or playing request.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=702705
This can only reliably work if demuxers have a
separate streaming thread per srcpad. This should be
done in a demuxer base class, which integrates parts
of multiqueue
https://bugzilla.gnome.org/show_bug.cgi?id=701856
bug #700505
Following a representation change that causes a resolution change,
the video decoder fails to decode correctly. Dashdemux detects the
representation change and pushes a new caps event and an
initialization segment (a new moov atom) to the downstream qtdemux,
but it doesn't handle this new moov yet, it will only parse the
first one it receives.
This commit changes qtdemux to accept a new moov in a dash bitstream
switching scenario.
Lock the state of the all our elements and manage their states
outselves. Because we are working async, we can't rely on the state
change function to set the state at the right time or to return the
right return value from the state change function.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=702046
Use special variants for the case when we don't change the panorama (pan=0.0).
Simplify the processing functions by passing the panorama value directy instead
of the instance. Use orc for clearing buffers too.
When the segment start is not 0, this created a situation where
the output_end_time is inferior to output_start_time, and the duration
of the next buffer ended up underflowing.
https://bugzilla.gnome.org/show_bug.cgi?id=701385
This reverts commit 61666898cf.
This commit changes what the set_sps_pps() function does, not it doesn't
set caps anymore (and should have been renamed). The main problem is that
not all call sites are updated and thus leak the string.
It is not needed to do a state change from the _play() function on
ourselves. The state change function already did that and we don't want to
interfere with that (or use hacks to avoid interference).
Also send stream-start and segment event on the RTCP pad.
We don't need to send anything on the sync_src pad because we
already forwarded all incomming events.
The previous implementation had the formatting of SDP attributes happen
in each RTP payloader, now instead the constituent values are propagated
as caps fields. This allows for applications to do SDP offer/answer
based on caps negotiation.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=700748
The previous implementation had the formatting of SDP attributes happen
in each RTP payloader, now instead the constituent values are propagated
as caps fields. This allows for applications to do SDP offer/answer
based on caps negotiation.
Keep parsing a-framerate, x-framerate and x-dimensions in rtpjpegdepay
to be backwards compatible with previous payloaders.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=700748
There is no reason to send a flush-stop when receiving a seek event.
In the case of a flushing seek, we could eventually want to, but in
the code path were we check if the seek is "flushing", we have the
following comment that makes sense:
"we can't send FLUSH_STOP here since upstream could start pushing data
after we unlock mix->collect.
We set flush_stop_pending to TRUE instead and send FLUSH_STOP after
forwarding the seek upstream or from gst_videomixer_collected,
whichever happens first."
https://bugzilla.gnome.org/show_bug.cgi?id=684237
In case qtdemux is handling a mss stream, do not mark the stream to wait
for EOS after a segment. Even if it seems to be the last one according to
the current streams information.
MSS handling is different here because there is another demuxer driving
the pipeline
The samplerate field in the STSD atom is not right for some ALAC files
(usually when audio is 96kHz/24bits), so the audio caps must be
extracted from the codec data.
https://bugzilla.gnome.org/show_bug.cgi?id=700382
I took the opportunity to simplify that code a bit. We now use
gst_buffer_make_writable() to make the buffer writable and map twice the
same buffer, with first map being read/write, and second read only. This
get rid of the critical:
GStreamer-CRITICAL **: gst_structure_set_name: assertion `IS_MUTABLE
https://bugzilla.gnome.org/show_bug.cgi?id=700044
The exist one case where that we endup with original caps in ret, in which
case we are not guaratied to have writable caps. Simply ensure this is the
caps are writable before entering the loop.
https://bugzilla.gnome.org/show_bug.cgi?id=700044
This reverts commit 84ae670ab4.
Actually this is not how it is supposed to work. videomixer
creates a [0,-1] segment and then puts frames of the different
streams there based on their running times in their own segments.
For receiving video data via RTSP when the video is sent via
multicast there is no way to specify the udpsrc buffer-size.
On windows the native network buffer is not large and with video
i-frames being huge the buffer is to small and you get i-frame corruption,
it looks terrible, and there is no (easy) way to set the udpsrc buffer-size.
https://bugs.freedesktop.org/show_bug.cgi?id=52264
Whenever the demuxer has a new caps on a stream, it should set the
new_caps variable to true and a new caps event will be pushed before
the next buffer
qtdemux takes its buffers from a GstAdapter. Those buffers are created
from the larger buffer that it obtained from upstream and they carry
the same flags, including DISCONT if it is set. In these cases, all
buffers that qtdemux is going to push would be marked as DISCONT.
This scenario can make parsers/decoders flush on every buffer leading
to no decoding at all hapenning. This patch prevents this by unsetting
the flag if it shouldn't be set.
* Explicitly init variables for fragmented formats at init
* Do not use GstClockTime type if the variable isn't a timestamp
* Fix a style/readability issue at an if block
* Group 2 mss mode conditional blocks together to improve readability
Conflicts:
gst/isomp4/qtdemux.c
This can confuse downstream when they get a byte segment after receiving
the natural time segment from qtdemux that it sends when starting to
push buffers. This is specially the case with parsers that try to
convert the position from byte to time format and might miss the
correct position for playback to start.
Reset different variables on state changes to ready and when
handling a flush-stop. For handling flush stops we should check
if there is an upstream adaptive demuxer driving the pipeline as this
means that qtdemux will get a new moov atom. For 'standard' isomedia
streams this isn't true and qtdemux should keep the previous moov
information around.
Conflicts:
gst/isomp4/qtdemux.c
Whenever dashdemux switches bitrates it sends a new moov with the
new stream configuration. qtdemux should now handle this by splitting
the exposing and configuration of streams into separate functions. When
the stream is new it is configured and exposed, when it is a new bitrate
of an existing stream it is only reconfigured.
Conflicts:
gst/isomp4/qtdemux.c
smoothstreaming streams should be handled as a special kind of
fragmented isomedia. In MSS the fragments will not contain a
'moov' atom with the media descriptions, this has to be extracted
from the caps.
Additionally, there should be another demuxer upstream that is likely
going to be the one to answer/act on queries and events, so qtdemux has
to forward those upstream.
This is equivalent to multicast-group currently for backwards compatibility.
In 2.0 this should be handled separately, the former only being the multicast
group and the latter always being the address the socket is bound to, even if
a multicast group is given.
Return the output buffer from the process function instead of pushing
it ourselves. This way, the subclass can actually deal with the return
value of the push.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=693727
A marker bit on an audio packet does not mean a DISCONT (in the GStreamer sense
of missing data) but it means that the packet is the end of a talkspurt and thus
a good opportunity to resync to the clock. Use the RESYNC buffer flag to note
this.
Real discontinuities are marked with DISCONT still when the seqnum has a GAP or
when the input buffer has the DISCONT flag set.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=627204
When the server suggests a GstNetTimeProvider in the SDP, set up a
GstNetClientClock that slaves to the remote clock and suggest this clock in
provide_clock.
Previously we would skip level message when processing buffers > the requested
interval. Also the message frequency would contain quite some jitter due to only
considering them at the end of buffers.
Cleanup the tests while we're at it.
Otherwise we get a race where if the RTCP packet comes in first and while
it is added the pads, the segment event arrives on the RTP stream, the event
may be lost completely and never forwarded.
Calling gst_pad_peer_query_caps () on the src pad with the caps
upstream can produce as a filter from gst_rtp_h264_pay_getcaps ()
is wrong and makes caps negotiation fail if upstream caps are not
NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=695629
change_ssrc field of RTPSession should be set before calling
rtp_session_schedule_bye_locked () as this function will call reconsider function
that will wake up rtcp_thread which will call rtp_session_on_timeout () that will
check change_ssrc to change the ssrc.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=694184
Depending on the order g_object_set() calls aare made, the
target r/g/b settings will override the method if set to
green/blue. Change that so we do not use the target-r/g/b values
unless the method is set to custom.
https://bugzilla.gnome.org/show_bug.cgi?id=694374
Only delay the RTCP thread when we are a sender, which we can know because we
have a send_rtp_src pad. Otherwise we might delay the RTCP thread if we
are only a receiver and then there is no code path that wakes up the
RTCP thread and we end up without RTCP packets.
Don't unmap short MOOV atom buffer twice, which happened
in the case where we don't fix up the MOOV atom.
Fixes crashes when thumbnailing partial mp4 file where
the MOOV atom is still incomplete.
https://bugzilla.gnome.org/show_bug.cgi?id=694010
Delay sending the first RTCP packet until we have sent the first RTP packet.
Otherwise we will send out a Receiver Report instead of a sender report.
See https://bugzilla.gnome.org/show_bug.cgi?id=691400
Move the work of cleaning up the client streams in the free_stream
function. This allows us to properly clean up the client streams when we
remove an RTP stream as well.
Based on patch by Sujay <sdatar@cisco.com>
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=660156
Only run the skew estimation code when we have a new RTP timestamp. If we have
the same RTP timestamp, we simply use the previous estimation. This works
because the new observation with the same RTP timestamp has to have a bigger
receiver time and is thus not going to influence the estimation except for
causing more jitter.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=640023
Remove the pt restrictions for all the depayloaders that have an
encoding-name. We can use this to autoplug decoders.
Remove the encoding-name for all the payloaders with a fixed payload
type.
We now either have an encoding-name or a pt in the sinkpad caps of
a depayloader.
See https://bugzilla.gnome.org/show_bug.cgi?id=639292
encoding name is required in the caps and is a better fit for autoplugging than
the pt value. Hardware manufacturers have a bad habit of skimming through RFCs
and in this case; use unassigned numbers for encoders instead of dynamic
numbers.
In essence, this patch will add support for a lot of Bosch hardware encoders
without breaking autoplugging.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=639292
gst-plugins-good/gst/audioparsers/gstsbcparse.c: In function 'gst_sbc_parse_handle_frame':
gst-plugins-good/gst/audioparsers/gstsbcparse.c:210:32: error: 'ch_mode' may be used uninitialized i
Move the code that combines the last SR packet and the current jitterbuffer sync
values into a sync structure, into its own function. We want to reuse this bit
later.
When we make a mapping between an RTP timestamp and an NTP timestamp, include
the downstream latency applied to the sinks. This makes it possible to have
both sinks run with different latencies and still have correct sync on the
client. It also is more correct because the RTP timestamp in the SR report will
actually correspond more closely to the NTP time it was sent on the server.
For pipelines with high latency on the sender side, this actually allows a
GStreamer receiver to perform synchronisation instead of dropping the RTCP
packets.
There is no need to cast the event functions and only causes problems later when
we change the signature later and things silently compiles wrong code.
On Windows and OS/X, _get_available_bytes() may not return the size
of the next pending packet, but the size of all pending packets in
the kernel-side buffer, which might be rather large depending on
configuration. Sanity-check the size returned by _get_available_bytes()
to make sure we never allocate more memory than the max. size for
a packet, if it's an IPv4 socket.
https://bugzilla.gnome.org/show_bug.cgi?id=610364
Gather caps on all sink pads before setting the src pad caps. This is
specially needed when the audio channel mapping is set on the sink
pads and the element needs to preserve it on its src pad.
https://bugzilla.gnome.org/show_bug.cgi?id=690267
Otherwise we will intersect with the srcpad template caps and add all the caps fields
that the parser will ever set, no matter if downstream restricts this field or not.
This requires upstream to set this field on the caps to successfully negotiate.
https://bugzilla.gnome.org/show_bug.cgi?id=690184
The mutex locked is for the 'mux' object, but we unlock the
pad, which means that if the rtpmux gets a flush, then the
object lock will stay locked forever, causing it to freeze
the next time it tries to take it.
Fixes bug #627991
Factor out most of the buffer handling and implement a chain_list
function. Also, the DTMF muxer has been modified to just have a
function to accept or reject a buffer instead of having to subclass
both chain and chain_list.
Because of an allocated priv (GstRTPMuxPadPrivate), the element will
leak memory if not gst_rtp_mux_release_pad() is called. This would
previously only happen if release_request_pad() was called explicitly,
somthing that should not be neccesary.
Fixes#604099
Free the pad private data on pad release instead of using a weak ref,
which is not thread safe. Also, lock the content of the pad private using the element's
object lock.
No short-desc as we have them in the element details.
Also keep things (Makefile.am and sections.txt) sorted.
Reword ambigous returns. No text after since please.
Scaletempo was missing an update of 'stop' in
new segment parameters when pushing it downstream,
which caused files to end earlier when rate < 1.
Fixes#599903
Based on patch by: Bastian Hecht <hechtb@gmail.com>
The scenario where you have a gap in a steady flow of packets of
say 10 seconds (500 packets of with duration of 20ms), the jitterbuffer
will idle up until it receives the first buffer after the gap, but will
then go on to produce 499 lost-events, to "cover up" the gap.
Now this is obviously wrong, since the last possible time for the earliest
lost-events to be played out has obviously expired, but the fact that
the jitterbuffer has a "length", represented with its own latency combined
with the total latency downstream, allows for covering up at least some
of this gap.
So in the case of the "length" being 200ms, while having received packet
500, the jitterbuffer should still create a timeout for packet 491, which
will have its time expire at 10,02 seconds, specially since it might
actually arrive in time! But obviously, waiting for packet 100, that had
its time expire at 2 seconds, (remembering that the current time is 10)
is useless...
The patch will create one "big" lost-event for the first 490 packets,
and then go on to create single ones if they can reach their
playout deadline.
See https://bugzilla.gnome.org/show_bug.cgi?id=667838
Ignore other commands when reconnecting, otherwise the loop function would pause
and the reconnection would not happen. Continue looping after doing a reconnect
so that we have a chance to actually read the new data.
The src pad caps always describe a single audio channel so only the
first position matters if deinterleave is configured to keep channel
positions in its src pads.
Make it possible to set the timeout after we went to the READY state by using
the timeout when checking the condition. This also makes it possible to set the
timeout with a higher granularity than seconds.
* gst/rtsp/gstrtspsrc.c (gst_rtspsrc_play): state change might be
happening in the application thread, so we don't change the state to
PLAYING in the gstrtspsrc thread unless it is safe.
A specific case is when chaning the state to NULL from the application
thread. This will synchronously try to stop the task (with the element
state lock acquired), but we will try a gst_element_set_state from
gstrtspsrc thread which will block on the element state lock causing a
deadlock.
https://bugzilla.gnome.org/show_bug.cgi?id=684312
Shout2send only accepts webm format, not matroska, but due
to a bug in matroskamux, webmmux's source pad is also created
with the matroska source pad template as pad template, which
makes the link function think it can't link webmmux to shout2send.
Also add unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=689336
Make a segment event when we send a new range header to a client (first PLAY
request or after a seek). Send the segment event in interleaved mode.
Clean the segment event on cleanup
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=688382
* gst/rtsp/gstrtspsrc.[ch]: added new "udp-reconnect" property. Before,
rtspsrc always tried to reconnect to the server when the RTSP
connection was closed by the server. This property lets the user
decide whether it wants rtspsrc to reconnect or not.
https://bugzilla.gnome.org/show_bug.cgi?id=683912
When the user configured a port-range, propose ports from this range
as the multicast ports. The server is free to ignore this request but if it
honours it, increment our ports so that we suggest the next port pair for the
next stream.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=639420
This change enable automatic cropping using -1 set to left, top, right or
bottom property. In the case both side are set to automatic cropping, the
croping will be done equally on both side (in the odd case, right and
bottom cropping will be 1 pixel more).
https://bugzilla.gnome.org/show_bug.cgi?id=687761
This could have prevented images showing that should have when the
source height is greater than its width.
When width exceeds height, as is common, it probably only caused a
miniscule amount of unnecessary work. I haven't tested.
Spec is still in draft state, but should hopefully not
change much now. Besides, we announce things as VP8-DRAFT-IETF-01
in our caps, so even if things change in incompatible ways it
should not break anything.
https://bugzilla.gnome.org/show_bug.cgi?id=687263
VP8 uses a probabilistic bool coder, not a straight bit coder.
This fixes parsing when error-resilient is set.
This commit includes a copy of libvpx's bool coder, BSD licensed.
https://bugzilla.gnome.org/show_bug.cgi?id=652694
When setting up the initial mapping just act as if the global frame
information is another partition. This saves special-casing it later in
the actual packetizing code.
Caps events are sometimes not followed by a buffer but by an event. Flush any
pending caps before we make a packet with the event.
Chain up to the parent event handler before we attempt to push RTP packets, it
might be a segment event.
We currently only send tags and custom events. The other events
might interfere with the receiver timings or are otherwise handled
by RTP.
Conflicts:
gst/rtp/gstrtpgstpay.c
Use adapter to assemble the payload and make a flush function to
turn this payload into (fragmented) packets.
Conflicts:
gst/rtp/gstrtpgstpay.c
gst/rtp/gstrtpgstpay.h
Make sure we only insert the rtp packet in the adapter when the
frag_offset matches. When the first packet of a fragment is dropped,
it avoids putting the remaining packets in the adapter and processing
the partial fragment.
Conflicts:
gst/rtp/gstrtpgstdepay.c
Set the C flags on all the fragments instead of only those with
caps in them. This makes it easier in the receiver to check if there
is a caps in the assembled fragments just by looking at the last RTP
packet flags.
Place the capsversion on the outgoing caps so that they end up in
an SDP as well. Receivers need to know what capsversion a particular
caps is for to be able to match the caps to the CV in the RTP packets.
Place the caps inside the RTP packet whenever the caps change.
Based on patch by Andrzej Bieniek <andrzej.bieniek@pure.com>
Conflicts:
gst/rtp/gstrtpgstpay.c
gst/rtp/gstrtpgstpay.h
* Also expose unknown tags as key=value pairs.
* Arrange tag map in the same order tags are listed in Matroska spec, leaving
unmapped tags as comments.
* More specific TODOs.
* Remove duplicate DATE define.
Fixes#682615
Depends on #682524
* Reads TargetType and TargetTypeValue from a Tag.
* After Tag is completely read, processes taglist, substituting some of the
tags depending on target type value and the presence of video/subtitle streams.
* Supports reading two new simpletags - PART_NUMBER and TOTAL_PARTS
Depends on #682448Fixes#682524
If we run into any header parsing issues and we have a valid
STREAMINFO header already, don't error out, but just stop
header parsing and try to find some audio frames.
https://bugzilla.gnome.org/show_bug.cgi?id=684701
If both pads receive data at the same time, they will both get their
sink_setcaps called which will call the src_setcaps, but there is
a race condition where the second one might not be called.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=683842
Since it's not spec'ed, consider it a VfW compatibility
case. Many applications (e.g. avidemux) don't understand
the unofficial V_MJPEG id.
Fixes#659837.
Conflicts:
gst/matroska/matroska-mux.c
Inform the source when caps changed. This was removed in the port to 1.0
leaving the source unaware of the clock-rate and unable to interpollate
rtp timestamps for SR packets.
When use-pipeline-clock is set, use the running-time of the
pipeline to calculate the NTP timestamps. This method would previously
only work when the base-time is set to 0 but with this change it can
also work with different offsets and we can also implement pause/resume
of the sender and receiver now.
Fixes abort in push mode where the source is not seekable and the
size of the file is not available, as with
cat foo.mp4 | gst-launch-1.0 playbin uri=fd://0
Less noticable with releases, since we disable all
g_assert() there.
https://bugzilla.gnome.org/show_bug.cgi?id=686008
udpsrc already has support for setting the multicast interface, which
is useful for multi-homed machines. This patch adds the same code to
the multiudpsink.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=685864
Add an option to the multiudpsink that makes it possible to force
the use of an IPv4 socket.
This can e.g. be used to handle the issue described in
https://bugzilla.gnome.org/show_bug.cgi?id=682481
When playing an mp4 file with the MOOV atom at the end of the file, playback
fails with the error message "no 'moov' atom within the first 10 MB". This is
due to a mistake in the upstream_size typing, making the seek to the end of
file never happening.
https://bugzilla.gnome.org/show_bug.cgi?id=684972
gst_video_frame_map() increases the refcount, which makes
the buffer not writable any more technically, so calling
gst_buffer_memset() on it will cause nasty warnings.
Unit test disabled because it very rarely (for me)
fails, possibly negotiation-related.
https://bugzilla.gnome.org/show_bug.cgi?id=684398
This only affects behaviour in telecine cases with pattern locking
enabled. The default case should be untouched.
This works with the output from fieldanalysis at least, but the field
order looks swapped for telecine mixed buffers with the
David_slides_Schleef clip.
I don't understand why these lines were added, they don't make sense to
me now and both David and I agree that removing them moves closer to
related logic being correct, therefore, they're being removed.
I've tested a few progressive, interlaced and telecine clips and they
all behave properly timestamp-wise and visually after these changes.
In the current implementation, the custom pad query function is not called.
This patch, set that query function on the GstCollectPads to avoid this
shadowing.
See https://bugzilla.gnome.org/show_bug.cgi?id=684237
Handle G_MAXINT in the framerates better. If we cannot double or divide the
framerate, clamp to the smallest/largest possible value we can express instead
of failing.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=683861
Don't reset the segment because we need the values for accumulation. the segment
is reset at start and after a flushing seek. Fixes some problems with files with
quicktime segments.
MPEG DASH has defined a set of new boxes to specify duration, indexes and
offsets of ISOBMFF fragments.
The Track Fragment Base Media Decode Time (tfdt) Box can in particular be
included inside a traf box to specify the absolute decode time, measured on the
media timeline, of the first sample in decode order in the track fragment.
This information can be used by the isomp4 demux to find out the current position of
an MP4 fragment in the timeline.
This patch adds code to isomp4 to:
- parse the tfdt box
- adjust the time/position member of the new segment sent when playback starts
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=677535
Fix deinterlace unit test. Need to set right field on output caps.
Also remove right field (not old 0.10 "interlaced" boolean field)
from caps in unit test before comparing old and new.
Remove some bogus code I added during porting that would error out
on missing or variable framerates in input caps. Handle this like
we do in 0.10
Fixes test_mode_disabled_passthrough unit test check.
Block the RTP pad and associated RTCP pads while they are being
announced. This it to prevent a race where one is announced and
before the callback has connected it, the other one gets a buffer.
We can't use the "padlock" of ssrcdemux because it causes deadlocks.
This prevents a deadlock where something would try to push an event
through the SSRC demux from the callback, causing the pads to be iterated
and the lock taken.
RFF only occurs on progressive frames in telecine sequences. For
deinterlace, we don't want these repeated fields as we will simply be
pushing the progressive frame and then moving on.
However, we need to consider RFF in order to correctly identify patterns
and adjust the timestamps.
The logic now works better if we filter orphans, then progressive, then
telecine interlaced fields which need to be woven and fall through to
interlace. Telecine interlaced fields will be regularly deinterlaced if
there is no pattern lock for us to be sure that we have a telecine
pattern.
Telecine sequences that aren't 24fps progressive with RFF flags can't
really be tested until fieldanalysis is ported.
When we have a PLAY request, go into the LOOP function next. When we are
looping, keep on looping until we are told otherwise.
This fixed rtsp and TCP connections.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=680551
After pushing the buffer into the adapter, we should not let the baseclass push
it out anymore. This error was introduced while porting to 0.11.
See https://bugzilla.gnome.org/show_bug.cgi?id=680540
This ensures the detection (and proper downstream caps settings) will
actually happen when we have new incoming caps without codec_data.
This was easily triggered by streams from matroskademux which initially
provided caps with a constructed codec_data, but then pushed new caps
without the codec_data once it detected the stream was adts.
Convert all non GST_FORMAT_BYTES to format bytes:
fixes:
GStreamer-CRITICAL **: gst_query_set_duration: assertion `format ==
g_value_get_enum (gst_structure_id_get_value (s, GST_QUARK (FORMAT)))'
failed
when playing more than one wav stream.
gst-plugins-base/tests/icles/playback/test7 uri1.wav uri2.wav
Fix 'break' that got warped to the wrong place,
probably as part of a merge. Fixes GST_IS_BUFFER
criticals in parse_idit() when being accidentally
passed a NULL buffer because of the missing break.
gst-launch-1.0 playbin uri=http://docs.gstreamer.com/media/sintel_trailer-480i.avi
These will be picked automatically based on downstream caps now, so
if you want the depayloader to output a specific format, make sure
the element downstream advertises that preference or use a capsfilter
after the depayloader to force it.
rtph263ppay should accept any input compatible with its sink template
caps if it just outputs to e.g. udpsink or fakesink.
rtph263ppay ! rtph263pdepay should also work with any compatible input.
This would fail before with not-negotiated errors because the get_caps
function would see the encoding-name in the depayloader's template caps
and default to baseline H.263 because there's no profile/level information
in those caps, which is the right thing to do if downstream has filtercaps
from an SDP, but not if those fields are absent because they can be
anything like with the depayloader's template caps. Makes
videotestsrc ! avenc_h263p ! rtph263ppay ! rtph263pdepay ! fakesink
work.
Since the initial decoded still image buffer will have dts=pts=0, and
we only set PTS on buffers we push out, all buffers pushed out would
have a DTS of 0. Sinks, however, will prefer DTS over PTS if both are
set, and will therefore always see a timestamp of 0 no matter what
the PTS is set to.
Fixes unit test too.
When it receives a seek in push mode, the qtdemux should first try to push the event upstream, and only if upstream fails fall back to
its own seek logic.
Don't reset the time in flush-stop. Live sources can do this flush in the
playing state and so the pipeline will never have a chance to update the
base_time of the elements, which only happens when going from paused to
playing.
Always send the flushing events to the udp elements now that basesrc supports
this. This makes sure a segment event is sent correctly after a flush.
Keep track of the currently executing command and make it possible to specify
what command you want to cancel when starting a new async command.
See https://bugzilla.gnome.org/show_bug.cgi?id=677905
These should all be int instead of long, to avoid bugs
when passing these as varargs with g_object_set(), and
there was no reason to use long in the first place here.
Fixes FIXME.
They should take the filter caps into account and always return
the template caps appended to the actual caps. Otherwise the
parsers stop to accept unparsed streams where upstream does not
know about channels, rate, etc.
Fixes bug #677401.
From RFC 2250
2. Encapsulation of MPEG System and Transport Streams
...
For MPEG2 Transport Streams the RTP payload will contain an integral
number of MPEG transport packets. To avoid end system
inefficiencies, data from multiple small MTS packets (normally fixed
in size at 188 bytes) are aggregated into a single RTP packet. The
number of transport packets contained is computed by dividing RTP
payload length by the length of an MTS packet (188).
....
Since it needs to contain "an integral number of MPEG transport packets", a
simple fix is to check that's the case, and strip off any leftover data.
Fixes#676799
Conflicts:
gst/rtp/gstrtpmp2tdepay.c
demux->common.segment is populated during seek handling with the target
start/stop positions. Don't override them when sending out a NEWSEGMENT.
Conflicts:
gst/matroska/matroska-demux.c
If there are no profile restrictions downstream, return caps with
profile=constrained-baseline in the first structure and append
unrestricted caps as the last structure.
Fixes bug #672019
Setting GST_SEEK_FLAG_SKIP when sending a seek event in rtspsrc should
set the "Scale" field in the rtsp PLAY header.
Because the boolean "src->skip" is set after the call, "Speed" instead
of "Scale" is always set. Move the assignment before issuing the _play
request.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=676618
This fixes a not-negotiated error at least on mov files with
twos audio with two channels and video dvcp. As playbin and gst-launch
sample coming from the qtdemux.c file uses audioconvert and the latter
require format interleaved.
https://bugzilla.gnome.org/show_bug.cgi?id=675326
When all pads go to EOS immediately, we are not negotiated and our collected
function is called (without any available data). Handle this case gracefully.
Conflicts:
gst/interleave/interleave.c
Or perhaps it should just be a guint64 channel mask, which would
be nicer in C, but more awkward for bindings (even more so since
we can't add a flags type for it, since that only supports guint
size flags). Fixes wavenc unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=669643
... in that it will now call subclass with info on proposed audio format
without having set that info already in base class. As such,
subclass can not rely on audio format info being available there.
We do an ALLOCATION query to find out an allocator and parameters on the
srcpads. This way decoders (and sinks) can specify the memory and parameters
they want us to write into.
Set PTS and DTS on output buffers instead of just the PTS. In streaming cases
you want to synchronized encoded data based on the DTS because that is
monotonically increasing.
