Opened 10 years ago
Last modified 9 years ago
#4473 new defect
Can't receive RTP stream on FreeBSD
Reported by: | Andrey Zholos | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avformat |
Version: | unspecified | Keywords: | rtp |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
I'm trying to transmit a simple point-to-point RTP audio stream on FreeBSD.
Command to send the stream (codec parameters match one of the static RTP payload types):
$ ffmpeg -f lavfi -i 'sine=440:4:r=8000' -f rtp -acodec pcm_mulaw -ac 1 -ar 8000 rtp://127.0.0.1:20000
Command to receive the stream:
$ ffplay -f rtp rtp://127.0.0.1:20000
The send command works. The receive command receives the first packet and correctly detects the stream format, but doesn't receive the actual stream or even open a UDP socket for it.
The same thing happens trying to receive through the SDP file printed by the send command.
Logs attached.
I traced the reason to a failing getnameinfo()
call. The call has a salen
parameter which is passed sizeof(struct sockaddr_storage)
, but should be passed sizeof(struct sockaddr_in)
(or whatever the actual address struct is). I guess Linux accepts this but FreeBSD doesn't. The call returns EAI_FAIL
("non-recoverable failure in name resolution").
Relevant quote from the FreeBSD manpage:
The sockaddr structure sa should point to either a sockaddr_in,
sockaddr_in6 or sockaddr_dl structure (for IPv4, IPv6 or link-layer
respectively) that is salen bytes long.
And from POSIX:
The salen argument contains the length of the address pointed to by sa.
Patch that fixes the issue above attached, but there are other similar calls to getnameinfo()
.
Attachments (4)
Change History (5)
by , 10 years ago
by , 10 years ago
Attachment: | receive-bug.log added |
---|
by , 10 years ago
Attachment: | receive-works.log added |
---|
by , 10 years ago
comment:1 by , 9 years ago
Keywords: | rtp added |
---|
sockaddr_storage does not have a ss_len field. Aka this solution seems not portable