[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