Only the upper 2 bits of the first byte are known to be
a fixed value.
The lower bits in the first byte of a RTP packet could be set
if the input is from another RTP packetizers than libavformat's,
but for RTCP packets, they would also be set when sending RTCP RR
packets, triggering false warnings about incorrect input format
to the protocol.
Signed-off-by: Martin Storsjö <martin@martin.st>
Tell the user that the RTP muxer needs to be used to packetize
the data - using the RTP protocol on its own isn't enough.
Signed-off-by: Martin Storsjö <martin@martin.st>
By appending `?dscp=26` to the URL, IP packets will be classified as
AF31 (assured forwarding for multimedia flows with low probability of
loss). On congested network, this allows a user to assign priorities to
flows.
Signed-off-by: Vincent Bernat <vincent@bernat.im>
It appears this breaks build with MSVC
until someone who has MSVC setup has time to investigate and
workaround/fix this, its better to revert so that build is not broken
Thats even more so as the original commit only fixed a hypothetical issue
This reverts commit e587a428d7.
some video players on Android will not send udp hole punching messages if the rtcp port and rtp port are not two successive integers.
So, if the video player is behind NAT, it could not receive and rtp messages via udp
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
IPPROTO_IPV6 is unrelated here (it's only used in udp.c for
multicast sockopts), check for support for the sockaddr_in6
struct itself.
Signed-off-by: Martin Storsjö <martin@martin.st>
If we've received packets on the same socket before, the return
packets are sent to that address. If we've only received packets
on the other socket, try to guess the source port for the other
one assuming the basic +1/-1 logic.
Signed-off-by: Martin Storsjö <martin@martin.st>
Move the sources documentation up below the marker for deprecated
otpions. Also mention the new block parameter, that was added
in 749722209.
Signed-off-by: Martin Storsjö <martin@martin.st>
A separate rtcp port can already be set when opening the rtp
protocol normally, but when doing port setup as in RTSP (where
we first need to open the local ports and pass them to the peer,
and only then receive the remote peer port numbers), we didn't
check the same url parameter as in the normal open routine.
Signed-off-by: Martin Storsjö <martin@martin.st>
I doubt that anyone ever would try to send a 1 byte packet
via the RTP protocol, but check just in case - it shouldn't
crash at least.
Signed-off-by: Martin Storsjö <martin@martin.st>
If another peer is sending unicast packets to the same port that
we are listening on, those packets can end up being received despite
using source specific multicast. For those cases, manually check the
source address of received packets against the intended source address.
This only handles the case when the source list is one single IP
address for now, which probably is the most common case.
Based on a patch by Ed Torbett.
Signed-off-by: Martin Storsjö <martin@martin.st>
Blocking/exclusion is not supported yet.
The rtp protocol parameter takes the same form as the existing
sources parameter for the udp protocol.
Signed-off-by: Martin Storsjö <martin@martin.st>
Passes Source-Specific Multicast parameters read from an sdp file through to the UDP socket code,
allowing source-specific multicast streams to be correctly received. As an integral part of this
change, additional checking (currently only enabled in the case of SSM streams, but probably
useful in similar scenarios) has been added to the RTP protocol handler to distinguish UDP packets
arriving from multiple sources to the same port and process only the expected packets
(those transmitted from the expected UDP source address). This resolves an issue identified
when multiple instances of FFmpeg subscribe to different Source-Specific Multicast streams
but with each sharing the same destination port.
Signed-off-by: Edward Torbett <ed.torbett@simulation-systems.co.uk>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This definition is in two files, since the definitions will move
to the private header at the next bump.
Signed-off-by: Martin Storsjö <martin@martin.st>
This simplifies the open functions by avoiding one function
call that needs error checking, reducing the amount of
extra bulk code.
Signed-off-by: Martin Storsjö <martin@martin.st>
This helps catching cases where the format string doesn't
match what is passed in, or injection bugs where user data
is passed in as format string.
Signed-off-by: Martin Storsjö <martin@martin.st>
Make AVIO_FLAG_ access constants work as flags, and in particular fix
the behavior of functions (such as avio_check()) which expect them to
be flags rather than modes.
This breaks API.
Functions interrupted by url_interrupt_cb should not be restarted.
Therefore using AVERROR(EINTR) was wrong, as it did not allow to distinguish
when the underlying system call was interrupted and actually needed to be
restarted.
This fixes roundup issues 2657 and 2659 (ffplay not exiting for streamed
content).
Signed-off-by: Nicolas George <nicolas.george@normalesup.org>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Map EAGAIN and EINTR from ff_neterrno to the normal AVERROR()
error codes. Provide fallback definitions of other errno.h network
errors, mapping them to the corresponding winsock errors.
This eases catching these error codes in common code, without having
to distinguish between FF_NETERRNO(EAGAIN) and AVERROR(EAGAIN).
This fixes roundup issue 2614, unbreaking blocking network IO on
windows.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
(cherry picked from commit 28c4741a66)
Map EAGAIN and EINTR from ff_neterrno to the normal AVERROR()
error codes. Provide fallback definitions of other errno.h network
errors, mapping them to the corresponding winsock errors.
This eases catching these error codes in common code, without having
to distinguish between FF_NETERRNO(EAGAIN) and AVERROR(EAGAIN).
This fixes roundup issue 2614, unbreaking blocking network IO on
windows.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>