Jeremy Morton ffm...@game-point.net added the comment:
The other thing about bloating AVPacket with the extra 'source address' field;
what if it were just enabled with a build switch?
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
Luca Abeni lucab...@email.it added the comment:
Jeremy Morton wrote:
[...]
But I still have to understand what the requirements are, and why
providing the packet's source address in AVPacket would help (I suspect
it would be kind of useless for RTP...).
Luca,
The requirement is for the
Michael Niedermayer michae...@gmx.at added the comment:
On Sun, Jan 24, 2010 at 10:52:08AM +, Jeremy Morton wrote:
Jeremy Morton ffm...@game-point.net added the comment:
But I still have to understand what the requirements are, and why
providing the packet's source address in AVPacket
Jeremy Morton ffm...@game-point.net added the comment:
RTP has ssrc and seq numbers to get them right he will probably need
access to your network and if he does have access to it the IP will
not help you
But ffmpeg is receiving 2 valid video streams; both have valid ssrc and seq
numbers.
Luca Barbato lu_z...@gentoo.org added the comment:
On 01/24/2010 02:21 PM, Jeremy Morton wrote:
Jeremy Morton ffm...@game-point.net added the comment:
RTP has ssrc and seq numbers to get them right he will probably need
access to your network and if he does have access to it the IP will
Luca Barbato lu_z...@gentoo.org added the comment:
Adding myself
--
nosy: +lu_zero
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/roundup/ffmpeg/issue1688
Michael Niedermayer michae...@gmx.at added the comment:
On Tue, Jan 19, 2010 at 11:32:42AM +, Jeremy Morton wrote:
Jeremy Morton ffm...@game-point.net added the comment:
I dont think i will accept a patch that bloats AVPacket with this.
Its the job of the protocols to make sure the
Jeremy Morton ffm...@game-point.net added the comment:
Adding michaelni.
--
nosy: +michaelni
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/roundup/ffmpeg/issue1688
Jeremy Morton ffm...@game-point.net added the comment:
A couple of questions:
1) Is there anywhere in the public ffmpeg API at the moment where calling code
is exposed to a network address? If so, where?
2) If not, how would you go about exposing calling code to a network address via
the
Luca Abeni lucab...@email.it added the comment:
The UDP protocol code uses network addreeses. For example, see
udp_set_remote_url(). But I am not sure what you want to do, here. So, the
function I mentioned could be irrelevant.
If you want to export the source address in AVPacket (as the message
Jeremy Morton ffm...@game-point.net added the comment:
I am indeed thinking of exporting the source address in AVPacket. As for which
demuxer(s) should support this - any that may get packets over a network
connection? The one that stands out to me is rtsp.c, but you probably know
better than
Michael Niedermayer michae...@gmx.at added the comment:
On Mon, Jan 18, 2010 at 02:41:49PM +, Jeremy Morton wrote:
I am indeed thinking of exporting the source address in AVPacket. As for
which
demuxer(s) should support this - any that may get packets over a network
connection? The
Luca Abeni lucab...@email.it added the comment:
AVpackets are a demuxer thing, while UDP is a protocol... Which demuxers should
export the source IP address in AVPacket?
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
Luca Abeni lucab...@email.it added the comment:
Regarding SDP, AFAIK c= does not indicate the source address.
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/roundup/ffmpeg/issue1688
Luca Abeni lucab...@email.it added the comment:
In any case, patches are welcome. If they are clean and they make sense, the
patches will be committed (but right now I do not know what the bug is, so I
cannot imagine which kind of patch would make sense or not).
Jeremy Morton ffm...@game-point.net added the comment:
Regarding SDP, AFAIK c= does not indicate the source address.
It indicates, according to the SDP RFC, the 'fully-qualified domain name or the
unicast IP address of the expected data source or data relay or data sink as
determined by
Jeremy Morton ffm...@game-point.net added the comment:
An addenum of info; the web manpages here:
http://www.manpagez.com/man/4/udp/
... say that UDP sockets are connectionless, and are normally used with the
sendto and recvfrom calls, though the connect(2) call may also be used to fix
the
Jeremy Morton ffm...@game-point.net added the comment:
Adding self.
--
nosy: +jez
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/roundup/ffmpeg/issue1688
Ronald S. Bultje rsbul...@gmail.com added the comment:
The man 4 udp stuff I quoted earlier on IRC.
There's two questions here that are interesting.
1) UDP is - in ffmpeg - primarily used for RTP, which is point-to-point. It
makes no sense to provide the source IP to the client because we know
Jeremy Morton ffm...@game-point.net added the comment:
Actually, having perused the SDP RFC a little more, I think the only line in the
SDP that should really have a chance of limiting the traffic by source IP is the
c= line. This is supposed to specify the source IP for the data. The fact
Jeremy Morton ffm...@game-point.net added the comment:
(continuation, sorry, submitted too early):
I'm not sure whether the c= line in an SDP file is intended to say this is the
source IP for data; if it doesn't come from here, you ignore it, or is just
meant as a you may want to look here for
New submission from Jeremy Morton ffm...@game-point.net:
For connectionless protocols such as UDP (whose udp.c's udp_read needs changing
back from recv() to recvfrom() to be able to get the source address), code using
the ffmpeg library may want to filter incoming data based on a packet's source
22 matches
Mail list logo
