[FFmpeg-devel] [PATCH] Support RTP/TCP in the RTSP muxer

Martin Storsjö martin
Mon Mar 22 15:35:34 CET 2010


Hi,

On Mon, 22 Mar 2010, Ronald S. Bultje wrote:

> On Mon, Mar 15, 2010 at 11:50 AM, Martin Storsj? <martin at martin.st> wrote:
> > The third part actually adds support for the TCP interleaved packets.
> > While things seem to work generally with darwin streaming server, some
> > packets seem to get lost in some cases, which I don't totally understand
> > at the moment. I don't know if this is DSS's fault or mine (the same
> > setups usually work just fine over UDP).
> 
> > diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> > +    if (handle)
> >      url_fdopen(&rtpctx->pb, handle);
> > +    else
> > +        url_open_dyn_packet_buf(&rtpctx->pb, RTSP_TCP_MAX_PACKET_SIZE);
> 
> We use if (..) { .. } else, since it costs no extra line of code.

Ok, will change.

> >      local_pkt = *pkt;
> >      local_pkt.stream_index = 0;
> > -    return av_write_frame(rtpctx, &local_pkt);
> > +    ret = av_write_frame(rtpctx, &local_pkt);
> > +    if (!ret && rt->lower_transport == RTSP_LOWER_TRANSPORT_TCP)
> > +        ret = tcp_write_packet(s, rtsp_st);
> > +    return ret;
> >  }
> 
> So what does this do exactly? It still writes the frame over the
> non-existing UDP session, right?

No, it writes the packet(s) to the dyn_packet_buf opened in the section 
you quoted above.

> Alternatively, Can we somehow change that so that av_write_frame() in 
> fact internally calls tcp_write_packet() for this case? Reason I'm 
> asking is because you add a lot of branching. I'm not so worried about 
> performance, but it's a lot of extra code that might be done otherwise.

That would require creating a ByteIOContext that wraps the tcp connection 
and writes the packet - I'm afraid this would add more uglyness than what 
this patch does, even if it would avoid this conditional.

// Martin



More information about the ffmpeg-devel mailing list