Fixes a warning using musl:
In file included from libavformat/rtpproto.c:43:0:
/usr/local/musl/include/sys/poll.h:1:2: warning: #warning redirecting incorrect #include <sys/poll.h> to <poll.h>
Since all URLContexts have the same AVOptions, such AVOptions
will be applied on the outermost context only and removed from the
dict, while they probably make sense on all contexts.
This makes sure that rw_timeout gets propagated to the innermost
URLContext (to make sure it gets passed to the tcp protocol, when
opening a http connection for instance).
Alternatively, such matching options would be kept in the dict
and only removed after the ffurl_connect call.
Signed-off-by: Martin Storsjö <martin@martin.st>
We cannot play multiple multicast streams with the same port at the
same time. This is because both rtp and rtcp port are opened in
read-write mode, so they will not bind to the multicast address. Try
to make rtp port as read-only by default to solve this bug.
Signed-off-by: Zhao Zhili <wantlamy@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Instead of a linked list constructed at av_register_all(), store them
in a constant array of pointers.
Since no registration is necessary now, this removes some global state
from lavf. This will also allow the urlprotocol layer caller to limit
the available protocols in a simple and flexible way in the following
commits.
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>
Carl Eugen Hoyos
Marton Balint
Rostislav Pehlivanov
Vlad Tarca
Diego Biurrun
Martin Storsjö
Zhao Zhili
Derek Buitenhuis
Anton Khirnov
Michael Niedermayer
Clément Bœsch
Michael Niedermayer
Luca Barbato
Vincent Bernat
lemonlinger@gmail.com
Dave Yeo
Ed Torbett
Jordi Ortiz
Mans Rullgard