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.
