Need to check that the number of bytes we want to copy from the adapter
actually is available and handle the error case gracefully. This error
may happen if malformed packets are received and we don't have a
complete frame.
https://bugzilla.gnome.org/show_bug.cgi?id=752663
For more optimised RTP packet handling: means we don't
need to map the input buffer again but can just re-use
the mapping the base class has already done.
https://bugzilla.gnome.org/show_bug.cgi?id=750235
For more optimised RTP packet handling: means we don't
need to map the input buffer again but can just re-use
the map the base class has already done.
https://bugzilla.gnome.org/show_bug.cgi?id=750235
endpos variable does not correctly understand in the
4.6.3 GCC version. So compile error appears when we do
compile rtph261pay using jhbuild.
This patch is fixed the compile error in 4.6.3 GCC version.
https://bugzilla.gnome.org/show_bug.cgi?id=751985
Draft 16 of "RTP Payload Format for VP8" states in section 4.2 that:
R: Bit reserved for future use. MUST be set to zero and MUST be
ignored by the receiver.
https://bugzilla.gnome.org/show_bug.cgi?id=751929
gstrtph261pay.c: In function 'gst_rtp_h261_pay_class_init':
gstrtph261pay.c:1003:17: error: variable 'gobject_class' set but not used [-Werror=unused-but-set-variable]
GObjectClass *gobject_class;
Implementation according to RFC 4587.
Payloader create fragments on MB boundaries in order to match MTU size
the best it can. Some decoders/depayloaders in the wild are very strict
about receiving a continuous bit-stream (e.g. no no-op bits between
frames), so the payloader will shift the compressed bit-stream of a
frame to align with the last significant bit of the previous frame.
Depayloader does not try to be fancy in case of packet loss. It simply
drops all packets for a frame if there is a loss, keeping it simple.
https://bugzilla.gnome.org/show_bug.cgi?id=751886
We always pushed one buffer into the adapter, then handled exactly that one
buffer and flushed it from the adapter. Now also don't memcpy() the actual
payload but just attach the input buffer's data to the output buffer.
This code still needs some serious refactoring/rewriting.
Compiling (with gcc-4.9-20150603) produces an error because of an access beyond
the end of an array. This patch fixes the error by initializing the loop
control/array index variable (i) to 1 and returning i - 1 when a match is found.
Also, because the values stored in the array increase in value as the index
increases, the >= test unnecessary, so it is removed.
This depayloader clash with the standard one for H263p. It produces an
H263p stream with a modified header. It uses encoding-name that is the
same as H263p (H263-1998) though the resulting ES is not decodable or
parsable in GStreamer, making it unsuable in dynamic pipeline. This
patch unrank this specialized depayloader since it can only be used in
custom pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=739935
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
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.
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.
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
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.
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
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.
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
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
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.
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.
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
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
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
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
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
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.
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
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
