streaming guru needed

[Bakul Shah]

> Danny Pansters wrote:
> > On Wednesday 09 May 2007 21:03:35 Stefan Ehmann wrote:
> >> On Wednesday 09 May 2007 02:45:13 Julian Elischer wrote:
> >>> Julian Elischer wrote:
> >>>> So, to continue on the topic of my last email,
> >>>> I'll be webcasting from BSDCan and teh FreeBSD devsummit that is with
> >>>> it. however I'll be using my Mac because I've used it before
> >>>> and I don't have time to experiment.. (Hey it's BSD ok?)
> >>>>
> >>>> I'm currently (and often) broadcasting a test stream at
> >>>> rtsp://jello.ironport.com:80/Bsdtest.sdp
> >>>>
> >>>>
> >>>> I do have several questions.
> >>>>
> >>>> 1/ what is the best protocol/codec/etc.
> >>>>   I'm currently using mpeg-4 audio and video .. is that ok?
> >>>>    also for ease of coping with firewalls I'm using RTP over RTSP    (I
> >>>> think that's right) on port 80 though others might work....?
> >>>>
> >>>> 2/ does anyone know how to get mplayer to show this stuff?
> >>>>
> >>>> 3/ people have had success using VLC. does anyone have an
> >>>>   definative description of how to set it up to work?
> >>>    I have been told to use:
> >>>     Preferences -> check Advanced, go to Input/Codecs->Demuxers->RTP/RTSP
> >>> and check "Use RTP over RTSP (TCP)"
> >> For mplayer "-rtsp-stream-over-tcp" seems to be the equivalent (It works
> >> for me at least).
> >>
> > 
> > Just for the record, you may already know this. (from long time ago when I 
> had 
> > a more than healthy interest in RealVideo) Rtsp is preferably used over UDP
>  
> > (that is the A/V data) together with a control "channel" over TCP for the 
> > play/pause/feedback sort of things. So "rtsp over tcp" will be (very) 
> > suboptimal as there needs to be confirmation of every datagram. If it's als
> o 
> > possible to send the a/v stream over UDP  and to play it you'd rather use 
> > that.

This is not right.  The OP seem to have misunderstood rtsp.
It has been a while but from what I remember rtsp does not
have acks as it was designed to work the same way over udp
and tcp and A/V can tolerate loss of a few packets so no
sense in having acks.