[FFmpeg-devel] [patch] fix problem receiving udp multicast

[Reimar Döffinger]

On Wed, Nov 20, 2013 at 10:22:49AM +0100, Deti Fliegl wrote:
> On 20.11.13 08:01, Reimar Döffinger wrote:
> > On 19.11.2013, at 23:29, Deti Fliegl <deti at fliegl.de> wrote:
> >> On 19.11.13 22:50, Reimar Döffinger wrote:
> >>> On Tue, Nov 19, 2013 at 10:41:10PM +0100, Deti Fliegl wrote:
> >>>> Hi there,
> >>>>
> >>>> I am using the trunk version of ffmpeg. When receiving udp multicast
> >>>
> >>> Why is AVIO_FLAG_WRITE set when _receiving_? That sounds like the
> >>> real bug to me...
> >> ... because RTP works in both directions. You receive on one port and on
> >> the second you receive and send RTCP data.
> > 
> > But you wrote
> > 
> >> This causes massively scrambled data containing every stream on the
> > network seen by libavformat.
> > 
> > And that shouldn't happen if only the rtcp port is affected as I understand it, since the actual stream data is on a different port.
> The rtp code opens two UDP sockets. IMHO the second one has always to be
> read-/writeable and the first one needs to be opened readable, writable
> or both. In rtp_open the flags argument gets passed through until the
> both ffurl_open functions. So the only way to properly open a rtp stream
> for sending or receiving is with flags AVIO_FLAG_READ_WRITE. My
> conclusion is that it breaks less other code when we just apply my
> minimal patch then changing the rtp code. What do you think?

I'm not familiar with the code, so I can't say if it makes sense
effort-wise, but ideally we should not be using AVIO_FLAG_READ_WRITE
if we know we will only read.
My suggestion would have been that rtp_open should only be called
with AVIO_FLAG_READ, but for the ffurl_open for RTCP it would
use flags | AVIO_FLAG_READ_WRITE
I have no idea if that would actually work though.