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
